Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - bpf修复同步回调的引用状态管理 目前验证程序会验证回调函数同步和异步好像它们将被执行一次即其探索执行状态好像该函数会被调用一次。要探索的下一个 insn 已设置为 subprog 的开头且嵌套帧的退出使用 curframe > 0 和 prepare_func_exit 进行处理。如果是异步回调其使用 push_stack 的自定义变体模拟一种分支从而为异步回调设置自定义状态和执行上下文。虽然此方法简单且在回调实际上仅执行一次的情况下有效但对于当前所有 for_each 样式的帮助程序即多次执行回调而言这是不安全的。释放已获取的调用程序引用的回调可多次执行此操作但当前验证器将其视为框架内的一次调用框架然后会返回到调用程序。因此它认为自己释放了 cb eg 通过 callback_ctx寄存器从堆栈上溢出的类型化寄存器填充到 cb 内的某个引用。同样地它可能发现回调内获取调用未配对因此调用程序将复制回调的引用状态然后必须使用新的 ref_obj_ids 释放寄存器。但同样，回调可能执行多次，但验证程序将仅考虑针对回调的单次符号执行获取的引用，这将导致泄漏。请注意对于异步回调情况情况有所不同。虽然目前我们的 bpf_timer_set_callback 只执行一次但即使多次执行也是安全的因为引用状态为空而 check_reference_leak 会强制程序在 BPF_EXIT 之前释放状态。状态也不会受到调用程序框架分析的影响。因此异步回调是安全的。由于我们希望引用状态易于访问例如通过 callback_ctx 的 PTR_TO_STACK 从堆栈加载的指针我们仍然必须将调用者的reference_state 复制到回调的 bpf_func_state但我们强制无论添加到该reference_state 中的任何引用在命中 BPF_EXIT 之前都必须释放。这需要在引用状态中引入一个新的 callback_ref 成员以区分调用者引用与被调用者引用。因此check_reference_leak 发现我们在 callback_fn 中并且尚未释放 callback_ref refs 现在会错误输出。由于可能存在多个嵌套的回调例如 frame 0 -> cb1 -> cb2 等。
    我们还需要区分此特定 ref 是属于这个回调框架还是父框架以及我们自己框架中的错误因此我们存储 state->frameno对于回调而言始终为非零。简而言之，回调可以读取父reference_state，但不能改变它，以使用调用程序获取的指针。它们必须仅在返回前在调用程序reference_state 上撤消其更改通过在 BPF_EXIT 之前释放其自己的 acquire_refs此时调用程序和回调状态无论如何都将匹配因此无需将其复制回调用程序。 (CVE-2022-50650)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

检测

Linux Distros 未修补的漏洞：CVE-2022-50650

high Nessus 插件 ID 278044

版本 1.5