最近， 11.0/ 14.2/ 12.4.9修补了一个网络安全问题：因__未查验->_而造成 的遮盖___的网络安全问题。这好像能够在碰到区块链查验不正确时重新启动系统软件，但想要知道，此外，它还能做些哪些。
如同所详解的那般，大家还可以根据寻找-2020-27932的修补程序流程。
依照详细介绍的方式 ，大家发觉此次修补的涵数是0076370：__。
而且，调整后的涵数仅仅提升了一项查验。
在下面的对话框中，表明了2个并列的代码块，而且，右侧有一行编码处在突显情况
原先的编码：
(!_() || ->_ || _() !=_){
改动后的编码：
(!_() || ->_ || ->_ || _() !=_){
事实上，这一段编码在老版/系统软件上运作时并没什么难题，但在 11.0/10.5.7版本号于11月升级至/ 14.2/ 12.4.9以后后，所述编码就会发生_不正确。
__ =____();
__ =__(__(), ___, );
这一涵数用以每每/系统软件上的日期或時间产生变化时获得相对的通告。
启用__会将端口加上到将接受日期/時间变更通告的端口的双向链表中。
为了更好地便于从连接列表中删掉端口，列表内容还将储存在端口的_字段名中。
___(, (__), __);
它会将_()设定为__， 并将->_设定为内容。
这就是内核如何把一个端口与一个内核目标关系起來的方法。别的意味着内核目标的端口，如每日任务端口或计时器端口，也应用_和_来储存他们关系的内核目标。
当端口被消毁时，它会启用___，再次载入列表内容，并将其从列表中消除连接。
(_()==__){
=(__)->_;
那麼，这种独特回复端口（ ）究竟有哪些独到之处呢？他们能做什么别的端口做不到的事儿？
在内核源码中搜索_，大家只找到29个引入，在其中绝大多数都和和相关。
在 中，端口是单边的，因而，当您向另一个过程推送消息时，另外必须出示一个回复端口。那样的话，远程控制过程会将它的回应推送回特定的回复端口。
下边的表明，源自//.：
* __ .
* - .
*
* __ " ". ,
* -
* . __,
* __, - , .
下边是消息的工作中电路原理图：
----------------------------------->[ ]
{,
[ ]_ ||
__->___ !=___ ||
__->___ !=__){
__=;
}{
_(_);
__->___=_;
__->___=___;
}
因此：假如能连接独特端口，且都还没承继端口，就可以把回复端口连接到目地端口。
当独特回复端口必须升级时（比如，在目地端口接到消息后，或是当一个旧的进程独特端口被新的端口替代时），内核就会启用______，依据独特回复端口的当今情况来升级其连接目标。
假如端口沒有被连接，则不容易产生一切事儿：
(__->___==___){
_:
(_){
_((_)__,
___(__), , __);
}
_(
_(__);
(_) {
_();
}
;
}
否则，根据状态和新的所需链接，在端口//之间进行链接交换。
据我所知，这两个函数是唯一对___执行写入操作的函数。此外， ______是唯一一个写入另外两个字段（即___和___）的函数。
为什么对这些字段的写入操作非常重要呢？
_、___、___和___是在一个共用体（）中声明的!
{
__ ;
___ _;
__ __;
*__;
*__;
} ;
然而，这些字段中的内容并不是集中存放的：_和___并不是一起存储的。
这意味着可以通过使用__的链表条目来覆盖___!
并且，为了实现上述目的，我们有多种方法可以使用，但这里将采用一个最简单的方法，利用这个漏洞让内核崩溃。
首先，我们需要调用____。
这将为这个线程创建一个新的特殊回复端口。
- ___: ___
- {_, ___*}:
- _: _
要改变___，我们需要调用_____函数。调用这个函数的最简单的方法，是尝试在特殊回复端口上接收消息，并将目标端口作为通知端口（如内核的单元测试/_.所示）。
之后，______将调用_____，从而将特殊回复端口与目的端口链接起来：
- ___: ___
- {_, ___*}:
- _: _
当它等待接收消息时，我们在另一个线程中调用__，从而在不改变___的情况下写入_和_：
- ___: ___
- {_, ___*}: (!!)
- _: __
当接收超时时，内核会调用______来解除端口的链接。
当函数得到一个链接的列表条目而不是它所期望的端口时，这应该会引起崩溃。
当然，说了这么多，但都是理论上的。
值得庆幸的是，特殊回复端口是内核中为数不多的在/_.中有单元测试的部分之一，因此，这里只需为它添加一个__ 调用。
我目前要做的事情，就是在自编译的 10.15.6内核上触发崩溃。
! =080237848
______ =080237848 =0
______ =0802348618
_____: =080237848 =0802348618 = =0 ___=0
: 080237848 -> 0802348618
____ =080237848 =1
__ 080237848 0802348618 0801206390
( 0 08006308): " _ (: 0801206390, : )"@/
////11///-/-6153.141.1///.:662
( 0), :
0959977580 : 08006273
09599775900 : 0800627349
09599775940 : 080064248
09599775990 : 0800647
095997750 : 0800647540
095997750 : 0800627278
0959977540 : 08006273916
095997750 : 080067266
0959977530 : 08006308
0959977560 : 080062373
0959977580 : 0800623933
095997750 : 0800624224
095997750 : 08006242
0959977550 : 0800625403
095997750 : 08006257
0959977560 : 0800625819
0959977580 : 0800623
095997750 : 08006472
也就是说，在我的内核中，
__ ( ..) (.:1008)
__ ( ..) (.:0)
_386_ ( ..) (_.:436)
_ ( ..) (.:785)
__ ( ..) + 38
( ..) (.:555)
___ ( ..) (.:877)
080007266 ( ..)
_ ( ..) (.:664)
__ ( ..) (_.:500)
_ ( ..) (_.:1872)
____ ( ..) (_.:1571)
______ ( ..) (_.:1867)
____ ( ..) (_.:719)
___ ( ..) (_.:334)
___ ( ..) (_.:492)
___ ( ..) (_.:993)
在 14.1上运行相同的代码，结果：
( 1 00266730): . 0025592, 0827025540 ( : 08157340)
除此之外，我们也可以在发送消息时触发内核崩溃。但是，我不知道这样做是否会更方便一些。
相反， 用//来覆盖_的链表条目， 则显得更加困难。
如前所述，对于一个带有___的新端口来说， 只能通过_____建链接，而且它还会检查是否存在已有的对象。所以，一旦__附加了一个对象，_____就不再起作用了。
不过我想，我们可以先链接一个端口，然后用__通过一个表项来覆盖这个端口，再用______通过或来覆盖表项。但是，具体如何操作，我还不是很清楚。
……我完全不知道这怎么会引起安全问题。
实际上，只有少数几种可以使用存储在_或___ *中的值的方法。
__：
我们显然不能使用它，因为上的应用不能改变系统时间。
___：
因为_被设置为通知，所以当端口被销毁时，___会被调用。
如前所述，我们不能使用_____来覆盖链表条目，因为它在覆盖之前会检查端口是否为空。如果我们想破坏___函数，我们需要想办法让______（唯一一个设置___*字段的函数）用或来覆盖对象。
即使这样，由于链表在取消链接时存在多种安全检查，导致上述方法仍无法奏效。
______或各种/方法。
您有没有好办法呢？如何使链表节点与任务端口//足够接近，从而使这些方法不会立即崩溃？
封装是非常重要的。
随你怎么笑，但你的101课本是对的：面向对象的编程本可以避免这种情况。
方法可以检查是否已经设置了，而方法可以为链接的端口做同样的检查。
通过把检查放在一个地方，对象的用户就不需要自己去验证对象的状态，也不会像我们这里看到的那样漏掉一个检查。
回复端口的使用方法
如何按照 和的指南编译内核以添加调试语句。
-2020-27932如何释放线程的特殊回复端口。
