远程主机上安装的内核版本低于 5.15.75-48.135。因此，会受到 ALAS2KERNEL-5.15-2025-090 公告中提及的多个漏洞影响。

    在 Linux 内核中发现了一个归类为“存在问题”的漏洞。此问题会影响组件 BPF 的文件 fs/nilfs2/segment.c 的函数 nilfs_attach_log_writer。此操纵漏洞会导致内存泄漏。攻击可从远程发起。建议应用补丁修复此问题。此漏洞获派的标识符为 VDB-211961。(CVE-2022-3646)

    在 5.19.9 及之前版本的 Linux 内核中，drivers/scsi/stex.c 允许本地用户从内核内存获取敏感信息，因为 stex_queuecommand_lck 缺少针对 PASSTHRU_CMD 案例的 memset。
    (CVE-2022-40768)

    低于版本 5.19.17 和 6.0.2 的 Linux 内核 NFSD 实现容易受到缓冲区溢出的影响。NFSD 通过将远程过程调用 (RPC) 的接收和发送缓冲区合并到一个页面数组中，来跟踪每个 NFSD 线程占用的页面数量。客户端可以通过在消息末尾添加垃圾数据的 TCP 发送 RPC 消息来强制缩小发送缓冲区。系统仍会根据规范正确形成包含垃圾数据的 RPC 消息，并将其传递给处理程序。NFSD 中的漏洞代码未预期超出分配的缓冲区空间的超大请求和写入。CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H (CVE-2022-43945)

    在 Linux 内核中，以下漏洞已修复：

    NFSD防范 NFSv2 READDIR 中的发送缓冲区溢出 (CVE-2022-50235)

    在 Linux 内核中，以下漏洞已修复：

    NFSD修复执行服务器间复制时源服务器上的释放后使用 (CVE-2022-50241)

    在 Linux 内核中，以下漏洞已修复：

    sctp处理从 sctp_auth_asoc_init_active_key 返回的错误 (CVE-2022-50243)

    在 Linux 内核中，以下漏洞已修复：

    xen/gntdev防止泄漏授予 (CVE-2022-50257)

    在 Linux 内核中，以下漏洞已修复：

    vhost/vsock：将 kvmalloc/kvfree 用于较大的数据包。 (CVE-2022-50271)

    在 Linux 内核中，以下漏洞已修复：

    md将 snprintf 替换为 scnprintfCVE-2022-50299

    在 Linux 内核中，以下漏洞已修复：

    nbd修复信号中断 nbd_start_device_ioctl() 时的挂起 (CVE-2022-50314)

    在 Linux 内核中，以下漏洞已修复：

    jbd2修复 jbd2_fc_wait_bufs 中潜在的释放后使用 (CVE-2022-50328)

    在 Linux 内核中，以下漏洞已修复：

    ext4修复 ext4_write_info 中的 null-ptr-deref (CVE-2022-50344)

    在 Linux 内核中，以下漏洞已修复：

    NFSD防范 NFSv3 READ 中的发送缓冲区溢出 (CVE-2022-50345)

    在 Linux 内核中，以下漏洞已修复：

    nfsd修复错误处理路径中的内存泄漏 (CVE-2022-50348)

    在 Linux 内核中，以下漏洞已修复：

    btrfs修复配额启用与配额重新扫描 ioctl 之间的争用CVE-2022-50379

    在 Linux 内核中，以下漏洞已修复：

    net/ieee802154拒绝零大小的 raw_sendmsg()CVE-2022-50397]

    在 Linux 内核中，以下漏洞已修复：

    net如果 sock 死机请勿访问 sk_stream_wait_memory 中的 sock sk_wq (CVE-2022-50409)

    在 Linux 内核中，以下漏洞已修复：

    NFSD防范 NFSv2 READ 中的发送缓冲区溢出 (CVE-2022-50410)

    在 Linux 内核中，以下漏洞已修复：

    scsilibsas修复 smp_execute_task_sg() 中的释放后使用缺陷 (CVE-2022-50422)

    在 Linux 内核中，以下漏洞已修复：

    ext4避免 DIO 写入之后的内联数据创建时崩溃 (CVE-2022-50435)

    在 Linux 内核中，以下漏洞已修复：

    xfrm通过工作队列重新注入传输模式数据包 (CVE-2022-50445)

    在 Linux 内核中，以下漏洞已修复：

    xen/gntdev适应 VMA 拆分 (CVE-2022-50471)

    在 Linux 内核中，以下漏洞已修复：

    drm/mipi-dsi删除主机时分离设备 (CVE-2022-50489)

    在 Linux 内核中，以下漏洞已修复：

    bpf将错误从 htab_lock_bucket() 传播到用户空间 (CVE-2022-50490)

    在 Linux 内核中，以下漏洞已修复：

    ext4修复 ext4_fc_record_regions() 中潜在的内存泄漏 (CVE-2022-50512)

    在 Linux 内核中，以下漏洞已修复：

    usbhostxhci修复 xhci_alloc_stream_info() 中可能的内存泄漏 (CVE-2022-50544)

    在 Linux 内核中，以下漏洞已修复：

    xfrm释放时以 NULL 更新 ipcomp_scratches (CVE-2022-50569)

    在 Linux 内核中，以下漏洞已修复：

    arm64ftrace修复具有 mcount 的模块 PLT (CVE-2022-50579)

    在 Linux 内核中，以下漏洞已修复：

    blk-throttle避免计算等待时间时发生溢出 (CVE-2022-50580)

    在 Linux 内核中，以下漏洞已修复：

    ext4修复 ext4_fc_record_modified_inode() 中可能的内存泄漏 (CVE-2022-50622)

    在 Linux 内核中，以下漏洞已修复：

    mmhugetlb修复 hugetlb_handle_userfault 中的 UAF (CVE-2022-50630)

    在 Linux 内核中，以下漏洞已修复：

    io-wq修复工作线程创建中的内存泄漏 (CVE-2022-50639)

    在 Linux 内核中，以下漏洞已修复：

    bpf修复同步回调的引用状态管理 (CVE-2022-50650)

    在 Linux 内核中，以下漏洞已修复：

    RDMA/siw修复 QP 破坏以等待丢弃所有引用。 (CVE-2022-50666)

    在 Linux 内核中，以下漏洞已修复：

    netrds从 rds_tcp_reset_callbacks() 取消工作时不保持 sock 锁定 (CVE-2022-50676)

    在 Linux 内核中，以下漏洞已修复：

    net/ieee802154不警告零大小的 raw_sendmsg() (CVE-2022-50706)

    在 Linux 内核中，以下漏洞已修复：

    cryptoakcipher - 用于设置私钥的默认实现 (CVE-2022-50731)

    在 Linux 内核中，以下漏洞已修复：

    md/raid5删除 raid5_read_one_chunk() 中不必要的 bio_put() (CVE-2022-50752)

    在 Linux 内核中，以下漏洞已修复：

    btrfs设置在调用 btrfs_init_new_buffer 中的 btrfs_clean_tree_block 之前生成 (CVE-2022-50766)

    在 Linux 内核中，以下漏洞已修复：

    jbd2在 fc_do_one_pass() 中添加未命中释放缓冲区头 (CVE-2022-50835)

    在 Linux 内核中，以下漏洞已修复：

    jbd2修复潜在的缓冲区引用计数泄漏 (CVE-2022-50839)

    在 Linux 内核中，以下漏洞已修复：

    cifs修复 VALIDATE_NEGOTIATE_INFO 消息的错误长度 (CVE-2022-50859)

    在 Linux 内核中，以下漏洞已修复：

    drm阻止 drm_copy_field() 尝试复制空指针 (CVE-2022-50884)

Tenable 已直接从测试产品的安全公告中提取上述描述块。

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

AlmaLinux 9.2 主机上存在安装的程序包，该程序包受到 TuxCare ALMALINUX9.2：CLSA-2026：U 1786761805公告中提及的多个漏洞的影响。

  - 在 KVM 的 AMD 嵌套虚拟化 (SVM) 中发现一个缺陷。恶意的 L1 客户机可能故意无法拦截协作嵌套客户机 (L2) 的关闭，从而可能导致主机 (L0) 中出现页面错误和内核错误。(CVE-2022-3344)

  - 已修复 Linux 内核中的下列漏洞：usbnet: Run unregister_netdev() before unbind() again Commit 2c9d6c2b871d (usbnet: run unbind() before unregister_netdev()) sought to fix a use-after-free on disconnect of USB Ethernet adapters. It turns out that a different fix is necessary to address the issue:
    https://lore.kernel.org/netdev/18b3541e5372bc9b9fc733d422f4e698c089077c.1650177997.git.lukas@wunner.de/ So the commit was not necessary. The commit made binding and unbinding of USB Ethernet asymmetrical: Before, usbnet_probe() first invoked the ->bind() callback and then register_netdev(). usbnet_disconnect() mirrored that by first invoking unregister_netdev() and then ->unbind(). Since the commit, the order in usbnet_disconnect() is reversed and no longer mirrors usbnet_probe(). One consequence is that a PHY disconnected (and stopped) in ->unbind() is afterwards stopped once more by unregister_netdev() as it closes the netdev before unregistering. That necessitates a contortion in ->stop() because the PHY may only be stopped if it hasn't already been disconnected. Reverting the commit allows making the call to phy_stop() unconditional in ->stop(). (CVE-2022-49501)

  - 已修复 Linux 内核中的下列漏洞：crypto: arm64/poly1305 - fix a read out-of-bound A kasan error was reported during fuzzing: BUG: KASAN: slab-out-of-bounds in neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon] Read of size 4 at addr ffff0010e293f010 by task syz-executor.5/1646715 CPU: 4 PID: 1646715 Comm: syz-executor.5 Kdump: loaded Not tainted 5.10.0.aarch64 #1 Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.59 01/31/2019 Call trace:
    dump_backtrace+0x0/0x394 show_stack+0x34/0x4c arch/arm64/kernel/stacktrace.c:196 __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x158/0x1e4 lib/dump_stack.c:118 print_address_description.constprop.0+0x68/0x204 mm/kasan/report.c:387 __kasan_report+0xe0/0x140 mm/kasan/report.c:547 kasan_report+0x44/0xe0 mm/kasan/report.c:564 check_memory_region_inline mm/kasan/generic.c:187 [inline] __asan_load4+0x94/0xd0 mm/kasan/generic.c:252 neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon] neon_poly1305_do_update+0x6c/0x15c [poly1305_neon] neon_poly1305_update+0x9c/0x1c4 [poly1305_neon] crypto_shash_update crypto/shash.c:131 [inline] shash_finup_unaligned+0x84/0x15c crypto/shash.c:179 crypto_shash_finup+0x8c/0x140 crypto/shash.c:193 shash_digest_unaligned+0xb8/0xe4 crypto/shash.c:201 crypto_shash_digest+0xa4/0xfc crypto/shash.c:217 crypto_shash_tfm_digest+0xb4/0x150 crypto/shash.c:229 essiv_skcipher_setkey+0x164/0x200 [essiv] crypto_skcipher_setkey+0xb0/0x160 crypto/skcipher.c:612 skcipher_setkey+0x3c/0x50 crypto/algif_skcipher.c:305 alg_setkey+0x114/0x2a0 crypto/af_alg.c:220 alg_setsockopt+0x19c/0x210 crypto/af_alg.c:253 __sys_setsockopt+0x190/0x2e0 net/socket.c:2123 __do_sys_setsockopt net/socket.c:2134 [inline] __se_sys_setsockopt net/socket.c:2131 [inline] __arm64_sys_setsockopt+0x78/0x94 net/socket.c:2131
    __invoke_syscall arch/arm64/kernel/syscall.c:36 [inline] invoke_syscall+0x64/0x100 arch/arm64/kernel/syscall.c:48 el0_svc_common.constprop.0+0x220/0x230 arch/arm64/kernel/syscall.c:155 do_el0_svc+0xb4/0xd4 arch/arm64/kernel/syscall.c:217 el0_svc+0x24/0x3c arch/arm64/kernel/entry-common.c:353 el0_sync_handler+0x160/0x164 arch/arm64/kernel/entry-common.c:369 el0_sync+0x160/0x180 arch/arm64/kernel/entry.S:683 This error can be reproduced by the following code compiled as ko on a system with kasan enabled: #include <linux/module.h> #include <linux/crypto.h> #include <crypto/hash.h> #include <crypto/poly1305.h> char test_data[] = \x00\x01\x02\x03\x04\x05\x06\x07 \x08\x09\x0a\x0b\x0c\x0d\x0e\x0f \x10\x11\x12\x13\x14\x15\x16\x17 \x18\x19\x1a\x1b\x1c\x1d\x1e; int init(void) { struct crypto_shash *tfm = NULL; char *data = NULL, *out = NULL; tfm = crypto_alloc_shash(poly1305, 0, 0); data = kmalloc(POLY1305_KEY_SIZE - 1, GFP_KERNEL); out = kmalloc(POLY1305_DIGEST_SIZE, GFP_KERNEL); memcpy(data, test_data, POLY1305_KEY_SIZE - 1);
    crypto_shash_tfm_digest(tfm, data, POLY1305_KEY_SIZE - 1, out); kfree(data); kfree(out); return 0; } void deinit(void) { } module_init(init) module_exit(deinit) MODULE_LICENSE(GPL); The root cause of the bug sits in neon_poly1305_blocks. The logic neon_poly1305_blocks() performed is that if it was called with both s[] and r[] uninitialized, it will first try to initialize them with the data from the first block that it believed to be 32 bytes in length. First 16 bytes are used as the key and the next 16 bytes for s[]. This would lead to the aforementioned read out-of-bound. However, after calling poly1305_init_arch(), only 16 bytes were deducted from the input and s[] is initialized yet again with the following 16 bytes.
    The second initialization of s[] is certainly redundent which indicates that the first initialization should be for r[] only. This patch fixes the issue by calling poly1305_init_arm64() instead o
    ---truncated--- (CVE-2022-50231)

  - 已修复 Linux 内核中的下列漏洞：bpf: Fix reference state management for synchronous callbacks Currently, verifier verifies callback functions (sync and async) as if they will be executed once, (i.e. it explores execution state as if the function was being called once). The next insn to explore is set to start of subprog and the exit from nested frame is handled using curframe > 0 and prepare_func_exit. In case of async callback it uses a customized variant of push_stack simulating a kind of branch to set up custom state and execution context for the async callback. While this approach is simple and works when callback really will be executed only once, it is unsafe for all of our current helpers which are for_each style, i.e. they execute the callback multiple times. A callback releasing acquired references of the caller may do so multiple times, but currently verifier sees it as one call inside the frame, which then returns to caller. Hence, it thinks it released some reference that the cb e.g. got access through callback_ctx (register filled inside cb from spilled typed register on stack).
    Similarly, it may see that an acquire call is unpaired inside the callback, so the caller will copy the reference state of callback and then will have to release the register with new ref_obj_ids. But again, the callback may execute multiple times, but the verifier will only account for acquired references for a single symbolic execution of the callback, which will cause leaks. Note that for async callback case, things are different. While currently we have bpf_timer_set_callback which only executes it once, even for multiple executions it would be safe, as reference state is NULL and check_reference_leak would force program to release state before BPF_EXIT. The state is also unaffected by analysis for the caller frame.
    Hence async callback is safe. Since we want the reference state to be accessible, e.g. for pointers loaded from stack through callback_ctx's PTR_TO_STACK, we still have to copy caller's reference_state to callback's bpf_func_state, but we enforce that whatever references it adds to that reference_state has been released before it hits BPF_EXIT. This requires introducing a new callback_ref member in the reference state to distinguish between caller vs callee references. Hence, check_reference_leak now errors out if it sees we are in callback_fn and we have not released callback_ref refs. Since there can be multiple nested callbacks, like frame 0 -> cb1 -> cb2 etc. we need to also distinguish between whether this particular ref belongs to this callback frame or parent, and only error for our own, so we store state->frameno (which is always non-zero for callbacks). In short, callbacks can read parent reference_state, but cannot mutate it, to be able to use pointers acquired by the caller. They must only undo their changes (by releasing their own acquired_refs before BPF_EXIT) on top of caller reference_state before returning (at which point the caller and callback state will match anyway, so no need to copy it back to caller). (CVE-2022-50650)

  - 已修复 Linux 内核中的下列漏洞：net: stmmac: fix possible memory leak in stmmac_dvr_probe() The bitmap_free() should be called to free priv->af_xdp_zc_qps when create_singlethread_workqueue() fails, otherwise there will be a memory leak, so we add the err path error_wq_init to fix it. (CVE-2022-50663)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

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/Unix 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - bpf修正同步回呼的參照狀態管理 目前驗證程式會驗證回呼函式 (同步與非同步)就像函式會執行一次一樣 (即它會探索執行狀態就像函式遭到呼叫一次一樣)。下一個要探索的 insn 設為 subprog 的開頭且使用 curframe > 0 和 prepare_func_exit 處理巢狀框架的結束。發生非同步回呼時它會使用 push_stack 的自訂變體模擬一種分支來設定非同步回呼的自訂狀態和執行內容。雖然這種方法很簡單而且在回呼確實只會執行一次時有效但是對於我們目前所有的 for_each 樣式協助程式而言它是不安全的即它們會執行回呼多次。釋放所取得之呼叫者之參照的回呼可能會多次執行此動作但目前驗證器會將其視為框架內的一個呼叫然後傳回給呼叫者。因此它會認為其已釋放某些參照使 cb 例如可透過 callback_ctx (從堆疊上的溢出輸入暫存器填入 cb 內的暫存器) 取得存取權。同樣地它可能會看到取得呼叫在回呼內未配對因此呼叫者將復制回呼的參照狀態然後必須以新的 ref_obj_ids 釋放暫存器。不過回呼可能會執行多次但驗證器只會針對回呼的單一符號執行考慮取得的參照而這會造成洩漏。請注意非同步回呼情況有所不同。雖然目前 bpf_timer_set_callback 只會執行一次但即使對於多次執行它也是安全的因為參照狀態為 NULL而且 check_reference_leak 會強製程式在 BPF_EXIT 之前釋放狀態。此狀態也不會受到呼叫者框架分析的影響。因此非同步回呼是安全的。由於我們希望參照狀態可供存取 (例如透過 callback_ctx 的 PTR_TO_STACK 從堆疊載入的指標)因此我們仍然必須將呼叫者的reference_state 複製到 callback 的 bpf_func_state但我們會強制其新增至該reference_state 的所有參照皆已在其命中 BPF_EXIT 之前釋放。這需要在參照狀態中引入新的 callback_ref 成員以區分呼叫者和被呼叫者參照。因此如果 check_reference_leak 發現我們在 callback_fn 中而且我們尚未釋放 callback_ref refs現在會出錯。由於可能有多個巢狀回呼例如 frame 0 -> cb1 -> cb2 等等。
    我們也需要辨別此特定參照是屬於此回呼框架還是父項以及僅屬於我們自己的錯誤因此我們儲存了 state->frameno (對於回呼其一律為非零)。簡而言之回呼可以讀取父項reference_state但無法加以變動以便能夠使用呼叫者取得的指標。必須在傳回之前於呼叫者reference_state 上復原變更 (透過在 BPF_EXIT 之前釋出自己的 acquire_refs)然後再傳回 (此時呼叫者和回呼狀態將以任何方式符合因此不需要將其複制回呼叫者)。 (CVE-2022-50650)

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

遠端主機上安裝的核心版本早於 5.15.75-48.135。因此，會受到 ALAS2KERNEL-5.15-2025-090 公告中所提及的多個弱點影響。

    在 Linux 核心中發現一個歸類爲「有問題」的弱點。這會影響 BPF 元件中 fs/nilfs2/segment.c 檔案的 nilfs_attach_log_writer 函式。攻擊者可利用此弱點造成記憶體洩漏。攻擊者可從遠端發起攻擊。建議套用修補程式以修正此問題。已爲此弱點指派識別碼 VDB-211961。(CVE-2022-3646)

    在 Linux 核心 5.19.9 版及其之前的所有版本中，因為 stex_queuecommand_lck 缺少適用於 PASSTHRU_CMD 的 memset，drivers/scsi/stex.c 允許本機使用者從核心記憶體取得敏感資訊。
    (CVE-2022-40768)

     5.19.17 和 6.0.2 版之前的 Linux 核心 NFSD 實作容易發生緩衝區溢位。NFSD 可將遠端程序呼叫 (RPC) 的接收和傳送緩衝區合併為一個頁面陣列，藉此追蹤每個 NFSD 執行緒保留的頁面數量。用戶端可透過 TCP 傳送在訊息結尾新增無用項目資料的 RPC 訊息，藉此強制縮小傳送緩衝區。但它仍會根據規範正確形成具有無用項目資料的 RPC 訊息，並將其轉送至處理程式。NFSD 中具有弱點的程式碼未預期超出配置的緩衝區空間有超大要求和寫入。CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H (CVE-2022-43945)

    在 Linux 核心中，下列弱點已解決：

    NFSD防止 NFSv2 READDIR 中的傳送緩衝區溢位 (CVE-2022-50235)

    在 Linux 核心中，下列弱點已解決：

    NFSD修正執行伺服器間複製時來源伺服器上的釋放後使用 (CVE-2022-50241)

    在 Linux 核心中，下列弱點已解決：

    sctp處理從 sctp_auth_asoc_init_active_key 傳回的錯誤 (CVE-2022-50243)

    在 Linux 核心中，下列弱點已解決：

    xen/gntdev防止洩漏授權 (CVE-2022-50257)

    在 Linux 核心中，下列弱點已解決：

    vhost/vsock針對較大的封包使用 kvmalloc/kvfree。 (CVE-2022-50271)

    在 Linux 核心中，下列弱點已解決：

    md將 snprintf 取代為 scnprintf (CVE-2022-50299)

    在 Linux 核心中，下列弱點已解決：

    nbd修正訊號中斷時發生的懸置 nbd_start_device_ioctl() (CVE-2022-50314)

    在 Linux 核心中，下列弱點已解決：

    jbd2修正 jbd2_fc_wait_bufs 中的潛在釋放後使用 (CVE-2022-50328)

    在 Linux 核心中，下列弱點已解決：

    ext4修正 ext4_write_info 中的 null-ptr-deref (CVE-2022-50344)

    在 Linux 核心中，下列弱點已解決：

    NFSD防止 NFSv3 READ 中的傳送緩衝區溢位 (CVE-2022-50345)

    在 Linux 核心中，下列弱點已解決：

    nfsd修正錯誤處理路徑中的記憶體洩漏 (CVE-2022-50348)

    在 Linux 核心中，下列弱點已解決：

    btrfs修正配額啟用和配額重新掃描 ioctl 之間的爭用 (CVE-2022-50379)

    在 Linux 核心中，下列弱點已解決：

    net/ieee802154拒絕零大小的 raw_sendmsg() (CVE-2022-50397)

    在 Linux 核心中，下列弱點已解決：

    net如果 sock 無作用請勿存取 sock 在 sk_stream_wait_memory 中的 sk_wq (CVE-2022-50409)

    在 Linux 核心中，下列弱點已解決：

    NFSD防止 NFSv2 READ 中的傳送緩衝區溢位 (CVE-2022-50410)

    在 Linux 核心中，下列弱點已解決：

    scsilibsas修正 smp_execute_task_sg() 中的釋放後使用錯誤 (CVE-2022-50422)

    在 Linux 核心中，下列弱點已解決：

    ext4避免在 DIO 寫入之後建立內嵌資料時當機 (CVE-2022-50435)

    在 Linux 核心中，下列弱點已解決：

    xfrm透過工作佇列重新插入傳輸模式封包 (CVE-2022-50445)

    在 Linux 核心中，下列弱點已解決：

    xen/gntdev容納 VMA 分割 (CVE-2022-50471)

    在 Linux 核心中，下列弱點已解決：

    drm/mipi-dsi移除主機時卸離裝置 (CVE-2022-50489)

    在 Linux 核心中，下列弱點已解決：

    bpf將錯誤從 htab_lock_bucket() 傳播至使用者空間 (CVE-2022-50490)

    在 Linux 核心中，下列弱點已解決：

    ext4修正 ext4_fc_record_regions() 中的潛在記憶體洩漏 (CVE-2022-50512)

    在 Linux 核心中，下列弱點已解決：

    usbhostxhci修正 xhci_alloc_stream_info() 中的潛在記憶體洩漏 (CVE-2022-50544)

    在 Linux 核心中，下列弱點已解決：

    xfrm釋放時以 NULL 更新 ipcomp_scratches (CVE-2022-50569)

    在 Linux 核心中，下列弱點已解決：

    arm64ftrace以 mcount 修正模組 PLT (CVE-2022-50579)

    在 Linux 核心中，下列弱點已解決：

    blk-throttle防止在計算等候時間時發生溢位 (CVE-2022-50580)

    在 Linux 核心中，下列弱點已解決：

    ext4修正 ext4_fc_record_modified_inode() 中的潛在記憶體洩漏 (CVE-2022-50622)

    在 Linux 核心中，下列弱點已解決：

    mmhugetlb修正 hugetlb_handle_userfault 中的 UAF (CVE-2022-50630)

    在 Linux 核心中，下列弱點已解決：

    io-wq修正背景工作建立中的記憶體洩漏 (CVE-2022-50639)

    在 Linux 核心中，下列弱點已解決：

    bpf修正同步回呼的參照狀態管理 (CVE-2022-50650)

    在 Linux 核心中，下列弱點已解決：

    RDMA/siw修正 QP 損毀以等待所有參照卸除。 (CVE-2022-50666)

    在 Linux 核心中，下列弱點已解決：

    netrds從 rds_tcp_reset_callbacks() 取消工作時不保留通訊端鎖定 (CVE-2022-50676)

    在 Linux 核心中，下列弱點已解決：

    net/ieee802154不警告零大小的 raw_sendmsg() (CVE-2022-50706)

    在 Linux 核心中，下列弱點已解決：

    cryptoakcipher - 設定私密金鑰的預設實作 (CVE-2022-50731)

    在 Linux 核心中，下列弱點已解決：

    md/raid5移除 raid5_read_one_chunk() 中不必要的 bio_put() (CVE-2022-50752)

    在 Linux 核心中，下列弱點已解決：

    btrfs在 btrfs_init_new_buffer 中呼叫 btrfs_clean_tree_block 前設定產生 (CVE-2022-50766)

    在 Linux 核心中，下列弱點已解決：

    jbd2在 fc_do_one_pass() 中新增未命中釋放緩衝區標頭 (CVE-2022-50835)

    在 Linux 核心中，下列弱點已解決：

    jbd2修正潛在的緩衝區標頭參照計數洩漏 (CVE-2022-50839)

    在 Linux 核心中，下列弱點已解決：

    cifs修正 VALIDATE_NEGOTIATE_INFO 訊息的錯誤長度 (CVE-2022-50859)

    在 Linux 核心中，下列弱點已解決：

    drm防止 drm_copy_field() 嘗試複製 NULL 指標 (CVE-2022-50884)

Tenable 已直接從所測試產品的安全公告擷取前置描述區塊。

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

AlmaLinux 9.2 主機已安裝的套件會受到 TuxCare ALMALINUX9.2：CLSA-2026：1786761805 公告中提及的多個弱點影響。

  - 在 KVM 的 AMD 巢狀虛擬化 (SVM) 中發現一個缺陷。惡意的 L1 來賓可有意放棄攔截合作巢狀來賓 (L2) 的關機動作，這可能導致主機 (L0) 中發生索引標籤錯誤和核心錯誤。(CVE-2022-3344)

  - 已解決 Linux 核心中的下列弱點：usbnet: Run unregister_netdev() before unbind() again Commit 2c9d6c2b871d (usbnet: run unbind() before unregister_netdev()) sought to fix a use-after-free on disconnect of USB Ethernet adapters. It turns out that a different fix is necessary to address the issue:
    https://lore.kernel.org/netdev/18b3541e5372bc9b9fc733d422f4e698c089077c.1650177997.git.lukas@wunner.de/ So the commit was not necessary. The commit made binding and unbinding of USB Ethernet asymmetrical: Before, usbnet_probe() first invoked the ->bind() callback and then register_netdev(). usbnet_disconnect() mirrored that by first invoking unregister_netdev() and then ->unbind(). Since the commit, the order in usbnet_disconnect() is reversed and no longer mirrors usbnet_probe(). One consequence is that a PHY disconnected (and stopped) in ->unbind() is afterwards stopped once more by unregister_netdev() as it closes the netdev before unregistering. That necessitates a contortion in ->stop() because the PHY may only be stopped if it hasn't already been disconnected. Reverting the commit allows making the call to phy_stop() unconditional in ->stop(). (CVE-2022-49501)

  - 已解決 Linux 核心中的下列弱點：crypto: arm64/poly1305 - fix a read out-of-bound A kasan error was reported during fuzzing: BUG: KASAN: slab-out-of-bounds in neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon] Read of size 4 at addr ffff0010e293f010 by task syz-executor.5/1646715 CPU: 4 PID: 1646715 Comm: syz-executor.5 Kdump: loaded Not tainted 5.10.0.aarch64 #1 Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.59 01/31/2019 Call trace:
    dump_backtrace+0x0/0x394 show_stack+0x34/0x4c arch/arm64/kernel/stacktrace.c:196 __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x158/0x1e4 lib/dump_stack.c:118 print_address_description.constprop.0+0x68/0x204 mm/kasan/report.c:387 __kasan_report+0xe0/0x140 mm/kasan/report.c:547 kasan_report+0x44/0xe0 mm/kasan/report.c:564 check_memory_region_inline mm/kasan/generic.c:187 [inline] __asan_load4+0x94/0xd0 mm/kasan/generic.c:252 neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon] neon_poly1305_do_update+0x6c/0x15c [poly1305_neon] neon_poly1305_update+0x9c/0x1c4 [poly1305_neon] crypto_shash_update crypto/shash.c:131 [inline] shash_finup_unaligned+0x84/0x15c crypto/shash.c:179 crypto_shash_finup+0x8c/0x140 crypto/shash.c:193 shash_digest_unaligned+0xb8/0xe4 crypto/shash.c:201 crypto_shash_digest+0xa4/0xfc crypto/shash.c:217 crypto_shash_tfm_digest+0xb4/0x150 crypto/shash.c:229 essiv_skcipher_setkey+0x164/0x200 [essiv] crypto_skcipher_setkey+0xb0/0x160 crypto/skcipher.c:612 skcipher_setkey+0x3c/0x50 crypto/algif_skcipher.c:305 alg_setkey+0x114/0x2a0 crypto/af_alg.c:220 alg_setsockopt+0x19c/0x210 crypto/af_alg.c:253 __sys_setsockopt+0x190/0x2e0 net/socket.c:2123 __do_sys_setsockopt net/socket.c:2134 [inline] __se_sys_setsockopt net/socket.c:2131 [inline] __arm64_sys_setsockopt+0x78/0x94 net/socket.c:2131
    __invoke_syscall arch/arm64/kernel/syscall.c:36 [inline] invoke_syscall+0x64/0x100 arch/arm64/kernel/syscall.c:48 el0_svc_common.constprop.0+0x220/0x230 arch/arm64/kernel/syscall.c:155 do_el0_svc+0xb4/0xd4 arch/arm64/kernel/syscall.c:217 el0_svc+0x24/0x3c arch/arm64/kernel/entry-common.c:353 el0_sync_handler+0x160/0x164 arch/arm64/kernel/entry-common.c:369 el0_sync+0x160/0x180 arch/arm64/kernel/entry.S:683 This error can be reproduced by the following code compiled as ko on a system with kasan enabled: #include <linux/module.h> #include <linux/crypto.h> #include <crypto/hash.h> #include <crypto/poly1305.h> char test_data[] = \x00\x01\x02\x03\x04\x05\x06\x07 \x08\x09\x0a\x0b\x0c\x0d\x0e\x0f \x10\x11\x12\x13\x14\x15\x16\x17 \x18\x19\x1a\x1b\x1c\x1d\x1e; int init(void) { struct crypto_shash *tfm = NULL; char *data = NULL, *out = NULL; tfm = crypto_alloc_shash(poly1305, 0, 0); data = kmalloc(POLY1305_KEY_SIZE - 1, GFP_KERNEL); out = kmalloc(POLY1305_DIGEST_SIZE, GFP_KERNEL); memcpy(data, test_data, POLY1305_KEY_SIZE - 1);
    crypto_shash_tfm_digest(tfm, data, POLY1305_KEY_SIZE - 1, out); kfree(data); kfree(out); return 0; } void deinit(void) { } module_init(init) module_exit(deinit) MODULE_LICENSE(GPL); The root cause of the bug sits in neon_poly1305_blocks. The logic neon_poly1305_blocks() performed is that if it was called with both s[] and r[] uninitialized, it will first try to initialize them with the data from the first block that it believed to be 32 bytes in length. First 16 bytes are used as the key and the next 16 bytes for s[]. This would lead to the aforementioned read out-of-bound. However, after calling poly1305_init_arch(), only 16 bytes were deducted from the input and s[] is initialized yet again with the following 16 bytes.
    The second initialization of s[] is certainly redundent which indicates that the first initialization should be for r[] only. This patch fixes the issue by calling poly1305_init_arm64() instead o
    ---truncated--- (CVE-2022-50231)

  - 已解決 Linux 核心中的下列弱點：bpf: Fix reference state management for synchronous callbacks Currently, verifier verifies callback functions (sync and async) as if they will be executed once, (i.e. it explores execution state as if the function was being called once). The next insn to explore is set to start of subprog and the exit from nested frame is handled using curframe > 0 and prepare_func_exit. In case of async callback it uses a customized variant of push_stack simulating a kind of branch to set up custom state and execution context for the async callback. While this approach is simple and works when callback really will be executed only once, it is unsafe for all of our current helpers which are for_each style, i.e. they execute the callback multiple times. A callback releasing acquired references of the caller may do so multiple times, but currently verifier sees it as one call inside the frame, which then returns to caller. Hence, it thinks it released some reference that the cb e.g. got access through callback_ctx (register filled inside cb from spilled typed register on stack).
    Similarly, it may see that an acquire call is unpaired inside the callback, so the caller will copy the reference state of callback and then will have to release the register with new ref_obj_ids. But again, the callback may execute multiple times, but the verifier will only account for acquired references for a single symbolic execution of the callback, which will cause leaks. Note that for async callback case, things are different. While currently we have bpf_timer_set_callback which only executes it once, even for multiple executions it would be safe, as reference state is NULL and check_reference_leak would force program to release state before BPF_EXIT. The state is also unaffected by analysis for the caller frame.
    Hence async callback is safe. Since we want the reference state to be accessible, e.g. for pointers loaded from stack through callback_ctx's PTR_TO_STACK, we still have to copy caller's reference_state to callback's bpf_func_state, but we enforce that whatever references it adds to that reference_state has been released before it hits BPF_EXIT. This requires introducing a new callback_ref member in the reference state to distinguish between caller vs callee references. Hence, check_reference_leak now errors out if it sees we are in callback_fn and we have not released callback_ref refs. Since there can be multiple nested callbacks, like frame 0 -> cb1 -> cb2 etc. we need to also distinguish between whether this particular ref belongs to this callback frame or parent, and only error for our own, so we store state->frameno (which is always non-zero for callbacks). In short, callbacks can read parent reference_state, but cannot mutate it, to be able to use pointers acquired by the caller. They must only undo their changes (by releasing their own acquired_refs before BPF_EXIT) on top of caller reference_state before returning (at which point the caller and callback state will match anyway, so no need to copy it back to caller). (CVE-2022-50650)

  - 已解決 Linux 核心中的下列弱點：net: stmmac: fix possible memory leak in stmmac_dvr_probe() The bitmap_free() should be called to free priv->af_xdp_zc_qps when create_singlethread_workqueue() fails, otherwise there will be a memory leak, so we add the err path error_wq_init to fix it. (CVE-2022-50663)

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

リモートホストにインストールされているカーネルのバージョンは、5.15.75-48.135より前のものです。したがって、ALAS2KERNEL-5.15-2025-090 のアドバイザリに記載されている複数の脆弱性の影響を受けます。

    問題として分類されている脆弱性が Linux カーネルで見つかりました。この問題は、コンポーネント BPF のファイル fs/nilfs2/segment.c の関数 nilfs_attach_log_writer に影響します。操作により、メモリリークが発生します。攻撃がリモートで開始される可能性があります。この問題を修正するパッチを適用することが推奨されます。識別子 VDB-211961 がこの脆弱性に割り当てられました。(CVE-2022-3646)

    5.19.9 までの Linux カーネルの drivers/scsi/stex.c により、stex_queuecommand_lck に PASSTHRU_CMD の場合の memset がないため、ローカルユーザーがカーネルメモリから機密情報を取得する可能性があります。
    (CVE-2022-40768)

    バージョン 5.19.17 および 6.0.2 より前の Linux カーネル NFSD の実装は、バッファオーバーフローに脆弱です。NFSD は、リモートプロシージャコール (RPC) の受信バッファと送信バッファを単一のページ配列に結合することで、各 NFSD スレッドが保持しているページ数を追跡します。クライアントは、ガベージデータがメッセージの最後に追加された RPC メッセージを TCP で送信することで、送信バッファを強制的に縮小できます。ガベージデータのある RPC メッセージは、依然として仕様に従って正しく形成されており、ハンドラーに転送されます。NFSD の脆弱なコードは、サイズが大きすぎるリクエストを想定しておらず、割り当てられたバッファスペースを超えて書き込みます。CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H (CVE-2022-43945)

    Linux カーネルで、以下の脆弱性が解決されています。

    NFSDNFSv2 READDIR での送信バッファオーバーフローに対する保護CVE-2022-50235]

    Linux カーネルで、以下の脆弱性が解決されています。

    NFSDサーバー間コピーを行う際のソースサーバーの use-after-free を修正しますCVE-2022-50241

    Linux カーネルで、以下の脆弱性が解決されています。

    sctpsctp_auth_asoc_init_active_key から返されるエラーを処理CVE-2022-50243

    Linux カーネルで、以下の脆弱性が解決されています。

    xen/gntdev認可の漏洩を防止CVE-2022-50257

    Linux カーネルで、以下の脆弱性が解決されています。

    vhost/vsock大きなパケットに対して kvmalloc/kvfree を使用します。CVE-2022-50271

    Linux カーネルで、以下の脆弱性が解決されています。

    mdsnprintf を scnprintf で置換しますCVE-2022-50299

    Linux カーネルで、以下の脆弱性が解決されています。

    nbdシグナルが nbd_start_device_ioctl() を割り込む際のハングアップを修正しますCVE-2022-50314]

    Linux カーネルで、以下の脆弱性が解決されています。

    jbd2jbd2_fc_wait_bufs の潜在的な use-after-free を修正しますCVE-2022-50328

    Linux カーネルで、以下の脆弱性が解決されています。

    ext4ext4_write_info の null-ptr-deref を修正CVE-2022-50344

    Linux カーネルで、以下の脆弱性が解決されています。

    NFSDNFSv3 READ の送信バッファオーバーフローに対する保護CVE-2022-50345

    Linux カーネルで、以下の脆弱性が解決されています。

    nfsdエラー処理パスでのメモリリークを修正しますCVE-2022-50348

    Linux カーネルで、以下の脆弱性が解決されています。

    btrfsクォータの有効化とクォータ再スキャンの ioctl の間の競合を修正しますCVE-2022-50379

    Linux カーネルで、以下の脆弱性が解決されています。

    net/ieee802154ゼロサイズの raw_sendmsg() を拒否しますCVE-2022-50397

    Linux カーネルで、以下の脆弱性が解決されています。

    netsock がデッドの場合は sk_stream_wait_memory の sock の sk_wq にアクセスしませんCVE-2022-50409

    Linux カーネルで、以下の脆弱性が解決されています。

    NFSDNFSv2 READ の送信バッファオーバーフローに対する保護CVE-2022-50410

    Linux カーネルで、以下の脆弱性が解決されています。

    scsilibsassmp_execute_task_sg() の use-after-free バグを修正しますCVE-2022-50422

    Linux カーネルで、以下の脆弱性が解決されています。

    ext4DIO 書き込みの後のインラインデータ作成でのクラッシュを回避しますCVE-2022-50435

    Linux カーネルで、以下の脆弱性が解決されています。

    xfrmworkqueue を通じてトランスポートモードパケットを再注入しますCVE-2022-50445

    Linux カーネルで、以下の脆弱性が解決されています。

    xen/gntdevVMA 分割に対応しますCVE-2022-50471

    Linux カーネルで、以下の脆弱性が解決されています。

    drm/mipi-dsiホストを削除する際にデバイスをデタッチしますCVE-2022-50489

    Linux カーネルで、以下の脆弱性が解決されています。

    bpfhtab_lock_bucket() からユーザー空間にエラーが伝播されますCVE-2022-50490]

    Linux カーネルで、以下の脆弱性が解決されています。

    ext4ext4_fc_record_regions() での潜在的なメモリリークを修正しますCVE-2022-50512]

    Linux カーネルで、以下の脆弱性が解決されています。

    usbhostxhcixhci_alloc_stream_info() の潜在的なメモリリークを修正しますCVE-2022-50544

    Linux カーネルで、以下の脆弱性が解決されています。

    xfrm解放時に ipcomp_scratches を NULL で更新しますCVE-2022-50569

    Linux カーネルで、以下の脆弱性が解決されています。

    arm64ftracemcount のあるモジュール PLT を修正しますCVE-2022-50579

    Linux カーネルで、以下の脆弱性が解決されています。

    blk-throttle待機時間の計算中のオーバーフローを防止しますCVE-2022-50580

    Linux カーネルで、以下の脆弱性が解決されています。

    ext4ext4_fc_record_modified_inode() での潜在的なメモリリークを修正しますCVE-2022-50622]

    Linux カーネルで、以下の脆弱性が解決されています。

    mmhugetlbhugetlb_handle_userfault の UAF を修正しますCVE-2022-50630

    Linux カーネルで、以下の脆弱性が解決されています。

    io-wqワーカー作成でのメモリリークを修正しますCVE-2022-50639

    Linux カーネルで、以下の脆弱性が解決されています。

    bpf同期コールバック用の参照状態管理を修正しますCVE-2022-50650

    Linux カーネルで、以下の脆弱性が解決されています。

    RDMA/swiwQP 破壊を修正し、すべての参照がドロップされるのを待機します。CVE-2022-50666

    Linux カーネルで、以下の脆弱性が解決されています。

    netrdsrds_tcp_reset_callbacks() から作業をキャンセルする際に sock ロックを保留しませんCVE-2022-50676]

    Linux カーネルで、以下の脆弱性が解決されています。

    net/ieee802154警告しませんゼロサイズの raw_sendmsg()CVE-2022-50706]

    Linux カーネルで、以下の脆弱性が解決されています。

    cryptoakcipher - 秘密鍵設定のデフォルト実装CVE-2022-50731

    Linux カーネルで、以下の脆弱性が解決されています。

    md/raid5raid5_read_one_chunk() の中の不要な bio_put() を削除しますCVE-2022-50752

    Linux カーネルで、以下の脆弱性が解決されています。

    btrfsbtrfs_init_new_buffer で btrfs_clean_tree_block を呼び出す前に、生成を設定しますCVE-2022-50766

    Linux カーネルで、以下の脆弱性が解決されています。

    jbd2fc_do_one_pass() にミスリリースバッファヘッドを追加しますCVE-2022-50835]

    Linux カーネルで、以下の脆弱性が解決されています。

    jbd2潜在的なバッファヘッド参照カウントの漏洩を修正しますCVE-2022-50839

    Linux カーネルで、以下の脆弱性が解決されています。

    cifsVALIDATE_NEGOTIATE_INFO メッセージのエラー長を修正CVE-2022-50859

    Linux カーネルで、以下の脆弱性が解決されています。

    drmdrm_copy_field() による NULL ポインターのコピーを試行することを阻止しますCVE-2022-50884]

Tenable は、前述の記述ブロックをテスト済み製品のセキュリティアドバイザリから直接抽出しています。

Nessus はこれらの問題をテストしておらず、代わりにアプリケーションが自己報告するバージョン番号にのみ依存していることに注意してください。

AlmaLinux 9.2 ホストには、TuxCare ALMALINUX9.2:CLSA-2026:1786761805アドバイザリに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - KVM の AMD ネスト化仮想化 (SVM) に欠陥が見つかりました。悪意のある L1 ゲストが意図的に協調的ネスト化ゲスト (L2) のシャットダウンの傍受に失敗し、ホスト (L0) でページ障害やカーネルパニックを引き起こす可能性があります。(CVE-2022-3344)

  - Linux カーネルでは、以下の脆弱性が解決されています: usbnet: Run unregister_netdev() before unbind() again Commit 2c9d6c2b871d (usbnet: run unbind() before unregister_netdev()) sought to fix a use-after-free on disconnect of USB Ethernet adapters. It turns out that a different fix is necessary to address the issue:
    https://lore.kernel.org/netdev/18b3541e5372bc9b9fc733d422f4e698c089077c.1650177997.git.lukas@wunner.de/ So the commit was not necessary. The commit made binding and unbinding of USB Ethernet asymmetrical: Before, usbnet_probe() first invoked the ->bind() callback and then register_netdev(). usbnet_disconnect() mirrored that by first invoking unregister_netdev() and then ->unbind(). Since the commit, the order in usbnet_disconnect() is reversed and no longer mirrors usbnet_probe(). One consequence is that a PHY disconnected (and stopped) in ->unbind() is afterwards stopped once more by unregister_netdev() as it closes the netdev before unregistering. That necessitates a contortion in ->stop() because the PHY may only be stopped if it hasn't already been disconnected. Reverting the commit allows making the call to phy_stop() unconditional in ->stop(). (CVE-2022-49501)

  - Linux カーネルでは、以下の脆弱性が解決されています: crypto: arm64/poly1305 - fix a read out-of-bound A kasan error was reported during fuzzing: BUG: KASAN: slab-out-of-bounds in neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon] Read of size 4 at addr ffff0010e293f010 by task syz-executor.5/1646715 CPU: 4 PID: 1646715 Comm: syz-executor.5 Kdump: loaded Not tainted 5.10.0.aarch64 #1 Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.59 01/31/2019 Call trace:
    dump_backtrace+0x0/0x394 show_stack+0x34/0x4c arch/arm64/kernel/stacktrace.c:196 __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x158/0x1e4 lib/dump_stack.c:118 print_address_description.constprop.0+0x68/0x204 mm/kasan/report.c:387 __kasan_report+0xe0/0x140 mm/kasan/report.c:547 kasan_report+0x44/0xe0 mm/kasan/report.c:564 check_memory_region_inline mm/kasan/generic.c:187 [inline] __asan_load4+0x94/0xd0 mm/kasan/generic.c:252 neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon] neon_poly1305_do_update+0x6c/0x15c [poly1305_neon] neon_poly1305_update+0x9c/0x1c4 [poly1305_neon] crypto_shash_update crypto/shash.c:131 [inline] shash_finup_unaligned+0x84/0x15c crypto/shash.c:179 crypto_shash_finup+0x8c/0x140 crypto/shash.c:193 shash_digest_unaligned+0xb8/0xe4 crypto/shash.c:201 crypto_shash_digest+0xa4/0xfc crypto/shash.c:217 crypto_shash_tfm_digest+0xb4/0x150 crypto/shash.c:229 essiv_skcipher_setkey+0x164/0x200 [essiv] crypto_skcipher_setkey+0xb0/0x160 crypto/skcipher.c:612 skcipher_setkey+0x3c/0x50 crypto/algif_skcipher.c:305 alg_setkey+0x114/0x2a0 crypto/af_alg.c:220 alg_setsockopt+0x19c/0x210 crypto/af_alg.c:253 __sys_setsockopt+0x190/0x2e0 net/socket.c:2123 __do_sys_setsockopt net/socket.c:2134 [inline] __se_sys_setsockopt net/socket.c:2131 [inline] __arm64_sys_setsockopt+0x78/0x94 net/socket.c:2131
    __invoke_syscall arch/arm64/kernel/syscall.c:36 [inline] invoke_syscall+0x64/0x100 arch/arm64/kernel/syscall.c:48 el0_svc_common.constprop.0+0x220/0x230 arch/arm64/kernel/syscall.c:155 do_el0_svc+0xb4/0xd4 arch/arm64/kernel/syscall.c:217 el0_svc+0x24/0x3c arch/arm64/kernel/entry-common.c:353 el0_sync_handler+0x160/0x164 arch/arm64/kernel/entry-common.c:369 el0_sync+0x160/0x180 arch/arm64/kernel/entry.S:683 This error can be reproduced by the following code compiled as ko on a system with kasan enabled: #include <linux/module.h> #include <linux/crypto.h> #include <crypto/hash.h> #include <crypto/poly1305.h> char test_data[] = \x00\x01\x02\x03\x04\x05\x06\x07 \x08\x09\x0a\x0b\x0c\x0d\x0e\x0f \x10\x11\x12\x13\x14\x15\x16\x17 \x18\x19\x1a\x1b\x1c\x1d\x1e; int init(void) { struct crypto_shash *tfm = NULL; char *data = NULL, *out = NULL; tfm = crypto_alloc_shash(poly1305, 0, 0); data = kmalloc(POLY1305_KEY_SIZE - 1, GFP_KERNEL); out = kmalloc(POLY1305_DIGEST_SIZE, GFP_KERNEL); memcpy(data, test_data, POLY1305_KEY_SIZE - 1);
    crypto_shash_tfm_digest(tfm, data, POLY1305_KEY_SIZE - 1, out); kfree(data); kfree(out); return 0; } void deinit(void) { } module_init(init) module_exit(deinit) MODULE_LICENSE(GPL); The root cause of the bug sits in neon_poly1305_blocks. The logic neon_poly1305_blocks() performed is that if it was called with both s[] and r[] uninitialized, it will first try to initialize them with the data from the first block that it believed to be 32 bytes in length. First 16 bytes are used as the key and the next 16 bytes for s[]. This would lead to the aforementioned read out-of-bound. However, after calling poly1305_init_arch(), only 16 bytes were deducted from the input and s[] is initialized yet again with the following 16 bytes.
    The second initialization of s[] is certainly redundent which indicates that the first initialization should be for r[] only. This patch fixes the issue by calling poly1305_init_arm64() instead o
    ---truncated--- (CVE-2022-50231)

  - Linux カーネルでは、以下の脆弱性が解決されています: bpf: Fix reference state management for synchronous callbacks Currently, verifier verifies callback functions (sync and async) as if they will be executed once, (i.e. it explores execution state as if the function was being called once). The next insn to explore is set to start of subprog and the exit from nested frame is handled using curframe > 0 and prepare_func_exit. In case of async callback it uses a customized variant of push_stack simulating a kind of branch to set up custom state and execution context for the async callback. While this approach is simple and works when callback really will be executed only once, it is unsafe for all of our current helpers which are for_each style, i.e. they execute the callback multiple times. A callback releasing acquired references of the caller may do so multiple times, but currently verifier sees it as one call inside the frame, which then returns to caller. Hence, it thinks it released some reference that the cb e.g. got access through callback_ctx (register filled inside cb from spilled typed register on stack).
    Similarly, it may see that an acquire call is unpaired inside the callback, so the caller will copy the reference state of callback and then will have to release the register with new ref_obj_ids. But again, the callback may execute multiple times, but the verifier will only account for acquired references for a single symbolic execution of the callback, which will cause leaks. Note that for async callback case, things are different. While currently we have bpf_timer_set_callback which only executes it once, even for multiple executions it would be safe, as reference state is NULL and check_reference_leak would force program to release state before BPF_EXIT. The state is also unaffected by analysis for the caller frame.
    Hence async callback is safe. Since we want the reference state to be accessible, e.g. for pointers loaded from stack through callback_ctx's PTR_TO_STACK, we still have to copy caller's reference_state to callback's bpf_func_state, but we enforce that whatever references it adds to that reference_state has been released before it hits BPF_EXIT. This requires introducing a new callback_ref member in the reference state to distinguish between caller vs callee references. Hence, check_reference_leak now errors out if it sees we are in callback_fn and we have not released callback_ref refs. Since there can be multiple nested callbacks, like frame 0 -> cb1 -> cb2 etc. we need to also distinguish between whether this particular ref belongs to this callback frame or parent, and only error for our own, so we store state->frameno (which is always non-zero for callbacks). In short, callbacks can read parent reference_state, but cannot mutate it, to be able to use pointers acquired by the caller. They must only undo their changes (by releasing their own acquired_refs before BPF_EXIT) on top of caller reference_state before returning (at which point the caller and callback state will match anyway, so no need to copy it back to caller). (CVE-2022-50650)

  - Linux カーネルでは、以下の脆弱性が解決されています: net: stmmac: fix possible memory leak in stmmac_dvr_probe() The bitmap_free() should be called to free priv->af_xdp_zc_qps when create_singlethread_workqueue() fails, otherwise there will be a memory leak, so we add the err path error_wq_init to fix it. (CVE-2022-50663)

Nessus はこれらの問題をテストしておらず、代わりにアプリケーションが自己報告するバージョン番号にのみ依存していることに注意してください。

Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - bpf同期コールバックの参照状態管理を修正現在、verifier はコールバック関数sync および asyncを、1 回実行されるかのように検証しますつまり、関数が一度呼び出されているかのように実行状態を探索します。探索する次の insn が subprog の開始に設定され、ネストされたフレームからの終了が、curframe > 0 および prepare_func_exit を使用して処理されます。async コールバックの場合、ある種のブランチをエミュレートする push_stack のカスタマイズされたバリアントが使用され、async コールバック用のカスタム状態と実行コンテキストが設定されます。このアプローチはシンプルで、コールバックが実際に一度だけ実行される場合は機能しますが、for_each スタイルである現在のすべてのヘルパーにとって安全ではありません。つまり、コールバックを複数回実行します。呼び出し元の取得した参照をリリースするコールバックは、複数回行われる可能性がありますが、現在の検証機能ではこれがフレーム内の 1 つの呼び出しと見なされ、呼び出し元に返されます。したがって、cb eg が callback_ctx を通じてアクセス権を取得したという参照をリリースしていましたスタックで、漏洩した型付きレジスターから cb の内部をレジスターで埋め込まれたと考えられます。同様に、取得呼び出しがコールバック内でペアリングされていないことが判明した場合、呼び出し側はコールバックの参照状態をコピーしてから、新しい ref_obj_ids でレジスターをリリースする必要があります。しかし、コールバックは複数回実行される可能性がありますが、検証機能はコールバックの単一のシンボリック実行のために取得された参照のみを考慮し、これにより漏洩が発生します。注意非同期コールバックの場合は状況が異なります。現在は、それを一度実行するだけの bpf_timer_set_callback がありますが、参照状態が NULL であり、check_reference_leak は BPF_EXIT の前にプログラムを強制的に状態を解放するため、複数の実行の場合でも安全です。状態は、呼び出し元フレームの分析によっても影響を受けません。したがって、async コールバックは安全です。参照状態をアクセス可能にしたいので、ポインターなどが callback_ctx の PTR_TO_STACK を通じてスタックからロードされた場合など、呼び出し元の Reference_state を callback の bpf_func_state へコピーする必要がありますが、参照状態に追加される参照はすべて、BPF_EXIT にヒットする前にリリースされるように強制します。これには、参照状態に新しい callback_ref メンバーを導入して、呼び出し元と呼び出し先の参照を区別する必要があります。そのため、check_reference_leak は、コールバック_fn 内にあり、callback_ref refs をリリースしていないことが判明した場合に、エラーを出力するようになりました。フレーム 0 -> cb1 -> cb2 など、複数のネスト化されたコールバックが存在する可能性があります。
    また、この特定の ref が、このコールバックフレームまたは親に属しているかどうかと、自分自身のもののみを区別する必要があるため、state->frameno を保存しますコールバックに対しては常にゼロではありません。つまり、コールバックは親の Reference_state を読み込むことができますが、それを変更することはできず、呼び出し側が取得したポインターを使用できるようになります。返す前に呼び出し側のreference_state に加えて、BPF_EXIT の前に独自のacquire_refs をリリースすることで変更を取り消すだけで済みますこの時点で呼び出し側とコールバックの状態は一致するため、呼び出し側にコピーして戻す必要はありません。CVE-2022-50650

Nessus は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - bpf: Fix reference state management for synchronous callbacks Currently, verifier verifies callback     functions (sync and async) as if they will be executed once, (i.e. it explores execution state as if the     function was being called once). The next insn to explore is set to start of subprog and the exit from     nested frame is handled using curframe > 0 and prepare_func_exit. In case of async callback it uses a     customized variant of push_stack simulating a kind of branch to set up custom state and execution context     for the async callback. While this approach is simple and works when callback really will be executed only     once, it is unsafe for all of our current helpers which are for_each style, i.e. they execute the callback     multiple times. A callback releasing acquired references of the caller may do so multiple times, but     currently verifier sees it as one call inside the frame, which then returns to caller. Hence, it thinks it     released some reference that the cb e.g. got access through callback_ctx (register filled inside cb from     spilled typed register on stack). Similarly, it may see that an acquire call is unpaired inside the     callback, so the caller will copy the reference state of callback and then will have to release the     register with new ref_obj_ids. But again, the callback may execute multiple times, but the verifier will     only account for acquired references for a single symbolic execution of the callback, which will cause     leaks. Note that for async callback case, things are different. While currently we have     bpf_timer_set_callback which only executes it once, even for multiple executions it would be safe, as     reference state is NULL and check_reference_leak would force program to release state before BPF_EXIT. The     state is also unaffected by analysis for the caller frame. Hence async callback is safe. Since we want the     reference state to be accessible, e.g. for pointers loaded from stack through callback_ctx's PTR_TO_STACK,     we still have to copy caller's reference_state to callback's bpf_func_state, but we enforce that whatever     references it adds to that reference_state has been released before it hits BPF_EXIT. This requires     introducing a new callback_ref member in the reference state to distinguish between caller vs callee     references. Hence, check_reference_leak now errors out if it sees we are in callback_fn and we have not     released callback_ref refs. Since there can be multiple nested callbacks, like frame 0 -> cb1 -> cb2 etc.
    we need to also distinguish between whether this particular ref belongs to this callback frame or parent,     and only error for our own, so we store state->frameno (which is always non-zero for callbacks). In short,     callbacks can read parent reference_state, but cannot mutate it, to be able to use pointers acquired by     the caller. They must only undo their changes (by releasing their own acquired_refs before BPF_EXIT) on     top of caller reference_state before returning (at which point the caller and callback state will match     anyway, so no need to copy it back to caller). (CVE-2022-50650)

Note that Nessus relies on the presence of the package as reported by the vendor.

The version of kernel installed on the remote host is prior to 5.15.75-48.135. It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2KERNEL-5.15-2025-090 advisory.

    A vulnerability, which was classified as problematic, has been found in Linux Kernel. This issue affects     the function nilfs_attach_log_writer of the file fs/nilfs2/segment.c of the component BPF. The     manipulation leads to memory leak. The attack may be initiated remotely. It is recommended to apply a     patch to fix this issue. The identifier VDB-211961 was assigned to this vulnerability. (CVE-2022-3646)

    drivers/scsi/stex.c in the Linux kernel through 5.19.9 allows local users to obtain sensitive information     from kernel memory because stex_queuecommand_lck lacks a memset for the PASSTHRU_CMD case.
    (CVE-2022-40768)

    The Linux kernel NFSD implementation prior to versions 5.19.17 and 6.0.2 are vulnerable to buffer     overflow. NFSD tracks the number of pages held by each NFSD thread by combining the receive and send     buffers of a remote procedure call (RPC) into a single array of pages. A client can force the send buffer     to shrink by sending an RPC message over TCP with garbage data added at the end of the message. The RPC     message with garbage data is still correctly formed according to the specification and is passed forward     to handlers. Vulnerable code in NFSD is not expecting the oversized request and writes beyond the     allocated buffer space. CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H (CVE-2022-43945)

    In the Linux kernel, the following vulnerability has been resolved:

    NFSD: Protect against send buffer overflow in NFSv2 READDIR (CVE-2022-50235)

    In the Linux kernel, the following vulnerability has been resolved:

    NFSD: fix use-after-free on source server when doing inter-server copy (CVE-2022-50241)

    In the Linux kernel, the following vulnerability has been resolved:

    sctp: handle the error returned from sctp_auth_asoc_init_active_key (CVE-2022-50243)

    In the Linux kernel, the following vulnerability has been resolved:

    xen/gntdev: Prevent leaking grants (CVE-2022-50257)

    In the Linux kernel, the following vulnerability has been resolved:

    vhost/vsock: Use kvmalloc/kvfree for larger packets. (CVE-2022-50271)

    In the Linux kernel, the following vulnerability has been resolved:

    md: Replace snprintf with scnprintf (CVE-2022-50299)

    In the Linux kernel, the following vulnerability has been resolved:

    nbd: Fix hung when signal interrupts nbd_start_device_ioctl() (CVE-2022-50314)

    In the Linux kernel, the following vulnerability has been resolved:

    jbd2: fix potential use-after-free in jbd2_fc_wait_bufs (CVE-2022-50328)

    In the Linux kernel, the following vulnerability has been resolved:

    ext4: fix null-ptr-deref in ext4_write_info (CVE-2022-50344)

    In the Linux kernel, the following vulnerability has been resolved:

    NFSD: Protect against send buffer overflow in NFSv3 READ (CVE-2022-50345)

    In the Linux kernel, the following vulnerability has been resolved:

    nfsd: Fix a memory leak in an error handling path (CVE-2022-50348)

    In the Linux kernel, the following vulnerability has been resolved:

    btrfs: fix race between quota enable and quota rescan ioctl (CVE-2022-50379)

    In the Linux kernel, the following vulnerability has been resolved:

    net/ieee802154: reject zero-sized raw_sendmsg() (CVE-2022-50397)

    In the Linux kernel, the following vulnerability has been resolved:

    net: If sock is dead don't access sock's sk_wq in sk_stream_wait_memory (CVE-2022-50409)

    In the Linux kernel, the following vulnerability has been resolved:

    NFSD: Protect against send buffer overflow in NFSv2 READ (CVE-2022-50410)

    In the Linux kernel, the following vulnerability has been resolved:

    scsi: libsas: Fix use-after-free bug in smp_execute_task_sg() (CVE-2022-50422)

    In the Linux kernel, the following vulnerability has been resolved:

    ext4: avoid crash when inline data creation follows DIO write (CVE-2022-50435)

    In the Linux kernel, the following vulnerability has been resolved:

    xfrm: Reinject transport-mode packets through workqueue (CVE-2022-50445)

    In the Linux kernel, the following vulnerability has been resolved:

    xen/gntdev: Accommodate VMA splitting (CVE-2022-50471)

    In the Linux kernel, the following vulnerability has been resolved:

    drm/mipi-dsi: Detach devices when removing the host (CVE-2022-50489)

    In the Linux kernel, the following vulnerability has been resolved:

    bpf: Propagate error from htab_lock_bucket() to userspace (CVE-2022-50490)

    In the Linux kernel, the following vulnerability has been resolved:

    ext4: fix potential memory leak in ext4_fc_record_regions() (CVE-2022-50512)

    In the Linux kernel, the following vulnerability has been resolved:

    usb: host: xhci: Fix potential memory leak in xhci_alloc_stream_info() (CVE-2022-50544)

    In the Linux kernel, the following vulnerability has been resolved:

    xfrm: Update ipcomp_scratches with NULL when freed (CVE-2022-50569)

    In the Linux kernel, the following vulnerability has been resolved:

    arm64: ftrace: fix module PLTs with mcount (CVE-2022-50579)

    In the Linux kernel, the following vulnerability has been resolved:

    blk-throttle: prevent overflow while calculating wait time (CVE-2022-50580)

    In the Linux kernel, the following vulnerability has been resolved:

    ext4: fix potential memory leak in ext4_fc_record_modified_inode() (CVE-2022-50622)

    In the Linux kernel, the following vulnerability has been resolved:

    mm: hugetlb: fix UAF in hugetlb_handle_userfault (CVE-2022-50630)

    In the Linux kernel, the following vulnerability has been resolved:

    io-wq: Fix memory leak in worker creation (CVE-2022-50639)

    In the Linux kernel, the following vulnerability has been resolved:

    bpf: Fix reference state management for synchronous callbacks (CVE-2022-50650)

    In the Linux kernel, the following vulnerability has been resolved:

    RDMA/siw: Fix QP destroy to wait for all references dropped. (CVE-2022-50666)

    In the Linux kernel, the following vulnerability has been resolved:

    net: rds: don't hold sock lock when cancelling work from rds_tcp_reset_callbacks() (CVE-2022-50676)

    In the Linux kernel, the following vulnerability has been resolved:

    net/ieee802154: don't warn zero-sized raw_sendmsg() (CVE-2022-50706)

    In the Linux kernel, the following vulnerability has been resolved:

    crypto: akcipher - default implementation for setting a private key (CVE-2022-50731)

    In the Linux kernel, the following vulnerability has been resolved:

    md/raid5: Remove unnecessary bio_put() in raid5_read_one_chunk() (CVE-2022-50752)

    In the Linux kernel, the following vulnerability has been resolved:

    btrfs: set generation before calling btrfs_clean_tree_block in btrfs_init_new_buffer (CVE-2022-50766)

    In the Linux kernel, the following vulnerability has been resolved:

    jbd2: add miss release buffer head in fc_do_one_pass() (CVE-2022-50835)

    In the Linux kernel, the following vulnerability has been resolved:

    jbd2: fix potential buffer head reference count leak (CVE-2022-50839)

    In the Linux kernel, the following vulnerability has been resolved:

    cifs: Fix the error length of VALIDATE_NEGOTIATE_INFO message (CVE-2022-50859)

    In the Linux kernel, the following vulnerability has been resolved:

    drm: Prevent drm_copy_field() to attempt copying a NULL pointer (CVE-2022-50884)

Tenable has extracted the preceding description block directly from the tested product security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The AlmaLinux 9.2 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.2:CLSA-2026:1786761805 advisory.

  - A flaw was found in the KVM's AMD nested virtualization (SVM). A malicious L1 guest could purposely fail     to intercept the shutdown of a cooperative nested guest (L2), possibly leading to a page fault and kernel     panic in the host (L0). (CVE-2022-3344)

  - In the Linux kernel, the following vulnerability has been resolved: usbnet: Run unregister_netdev() before     unbind() again Commit 2c9d6c2b871d (usbnet: run unbind() before unregister_netdev()) sought to fix a     use-after-free on disconnect of USB Ethernet adapters. It turns out that a different fix is necessary to     address the issue:
    https://lore.kernel.org/netdev/18b3541e5372bc9b9fc733d422f4e698c089077c.1650177997.git.lukas@wunner.de/ So     the commit was not necessary. The commit made binding and unbinding of USB Ethernet asymmetrical: Before,     usbnet_probe() first invoked the ->bind() callback and then register_netdev(). usbnet_disconnect()     mirrored that by first invoking unregister_netdev() and then ->unbind(). Since the commit, the order in     usbnet_disconnect() is reversed and no longer mirrors usbnet_probe(). One consequence is that a PHY     disconnected (and stopped) in ->unbind() is afterwards stopped once more by unregister_netdev() as it     closes the netdev before unregistering. That necessitates a contortion in ->stop() because the PHY may     only be stopped if it hasn't already been disconnected. Reverting the commit allows making the call to     phy_stop() unconditional in ->stop(). (CVE-2022-49501)

  - In the Linux kernel, the following vulnerability has been resolved: crypto: arm64/poly1305 - fix a read     out-of-bound A kasan error was reported during fuzzing: BUG: KASAN: slab-out-of-bounds in     neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon] Read of size 4 at addr ffff0010e293f010 by     task syz-executor.5/1646715 CPU: 4 PID: 1646715 Comm: syz-executor.5 Kdump: loaded Not tainted     5.10.0.aarch64 #1 Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.59 01/31/2019 Call trace:
    dump_backtrace+0x0/0x394 show_stack+0x34/0x4c arch/arm64/kernel/stacktrace.c:196 __dump_stack     lib/dump_stack.c:77 [inline] dump_stack+0x158/0x1e4 lib/dump_stack.c:118     print_address_description.constprop.0+0x68/0x204 mm/kasan/report.c:387 __kasan_report+0xe0/0x140     mm/kasan/report.c:547 kasan_report+0x44/0xe0 mm/kasan/report.c:564 check_memory_region_inline     mm/kasan/generic.c:187 [inline] __asan_load4+0x94/0xd0 mm/kasan/generic.c:252     neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon] neon_poly1305_do_update+0x6c/0x15c     [poly1305_neon] neon_poly1305_update+0x9c/0x1c4 [poly1305_neon] crypto_shash_update crypto/shash.c:131     [inline] shash_finup_unaligned+0x84/0x15c crypto/shash.c:179 crypto_shash_finup+0x8c/0x140     crypto/shash.c:193 shash_digest_unaligned+0xb8/0xe4 crypto/shash.c:201 crypto_shash_digest+0xa4/0xfc     crypto/shash.c:217 crypto_shash_tfm_digest+0xb4/0x150 crypto/shash.c:229 essiv_skcipher_setkey+0x164/0x200     [essiv] crypto_skcipher_setkey+0xb0/0x160 crypto/skcipher.c:612 skcipher_setkey+0x3c/0x50     crypto/algif_skcipher.c:305 alg_setkey+0x114/0x2a0 crypto/af_alg.c:220 alg_setsockopt+0x19c/0x210     crypto/af_alg.c:253 __sys_setsockopt+0x190/0x2e0 net/socket.c:2123 __do_sys_setsockopt net/socket.c:2134     [inline] __se_sys_setsockopt net/socket.c:2131 [inline] __arm64_sys_setsockopt+0x78/0x94 net/socket.c:2131
    __invoke_syscall arch/arm64/kernel/syscall.c:36 [inline] invoke_syscall+0x64/0x100     arch/arm64/kernel/syscall.c:48 el0_svc_common.constprop.0+0x220/0x230 arch/arm64/kernel/syscall.c:155     do_el0_svc+0xb4/0xd4 arch/arm64/kernel/syscall.c:217 el0_svc+0x24/0x3c arch/arm64/kernel/entry-     common.c:353 el0_sync_handler+0x160/0x164 arch/arm64/kernel/entry-common.c:369 el0_sync+0x160/0x180     arch/arm64/kernel/entry.S:683 This error can be reproduced by the following code compiled as ko on a     system with kasan enabled: #include <linux/module.h> #include <linux/crypto.h> #include <crypto/hash.h>     #include <crypto/poly1305.h> char test_data[] = \x00\x01\x02\x03\x04\x05\x06\x07     \x08\x09\x0a\x0b\x0c\x0d\x0e\x0f \x10\x11\x12\x13\x14\x15\x16\x17 \x18\x19\x1a\x1b\x1c\x1d\x1e; int     init(void) { struct crypto_shash *tfm = NULL; char *data = NULL, *out = NULL; tfm =     crypto_alloc_shash(poly1305, 0, 0); data = kmalloc(POLY1305_KEY_SIZE - 1, GFP_KERNEL); out =     kmalloc(POLY1305_DIGEST_SIZE, GFP_KERNEL); memcpy(data, test_data, POLY1305_KEY_SIZE - 1);
    crypto_shash_tfm_digest(tfm, data, POLY1305_KEY_SIZE - 1, out); kfree(data); kfree(out); return 0; } void     deinit(void) { } module_init(init) module_exit(deinit) MODULE_LICENSE(GPL); The root cause of the bug     sits in neon_poly1305_blocks. The logic neon_poly1305_blocks() performed is that if it was called with     both s[] and r[] uninitialized, it will first try to initialize them with the data from the first block     that it believed to be 32 bytes in length. First 16 bytes are used as the key and the next 16 bytes for     s[]. This would lead to the aforementioned read out-of-bound. However, after calling poly1305_init_arch(),     only 16 bytes were deducted from the input and s[] is initialized yet again with the following 16 bytes.
    The second initialization of s[] is certainly redundent which indicates that the first initialization     should be for r[] only. This patch fixes the issue by calling poly1305_init_arm64() instead o
    ---truncated--- (CVE-2022-50231)

  - In the Linux kernel, the following vulnerability has been resolved: bpf: Fix reference state management     for synchronous callbacks Currently, verifier verifies callback functions (sync and async) as if they will     be executed once, (i.e. it explores execution state as if the function was being called once). The next     insn to explore is set to start of subprog and the exit from nested frame is handled using curframe > 0     and prepare_func_exit. In case of async callback it uses a customized variant of push_stack simulating a     kind of branch to set up custom state and execution context for the async callback. While this approach is     simple and works when callback really will be executed only once, it is unsafe for all of our current     helpers which are for_each style, i.e. they execute the callback multiple times. A callback releasing     acquired references of the caller may do so multiple times, but currently verifier sees it as one call     inside the frame, which then returns to caller. Hence, it thinks it released some reference that the cb     e.g. got access through callback_ctx (register filled inside cb from spilled typed register on stack).
    Similarly, it may see that an acquire call is unpaired inside the callback, so the caller will copy the     reference state of callback and then will have to release the register with new ref_obj_ids. But again,     the callback may execute multiple times, but the verifier will only account for acquired references for a     single symbolic execution of the callback, which will cause leaks. Note that for async callback case,     things are different. While currently we have bpf_timer_set_callback which only executes it once, even for     multiple executions it would be safe, as reference state is NULL and check_reference_leak would force     program to release state before BPF_EXIT. The state is also unaffected by analysis for the caller frame.
    Hence async callback is safe. Since we want the reference state to be accessible, e.g. for pointers loaded     from stack through callback_ctx's PTR_TO_STACK, we still have to copy caller's reference_state to     callback's bpf_func_state, but we enforce that whatever references it adds to that reference_state has     been released before it hits BPF_EXIT. This requires introducing a new callback_ref member in the     reference state to distinguish between caller vs callee references. Hence, check_reference_leak now errors     out if it sees we are in callback_fn and we have not released callback_ref refs. Since there can be     multiple nested callbacks, like frame 0 -> cb1 -> cb2 etc. we need to also distinguish between whether     this particular ref belongs to this callback frame or parent, and only error for our own, so we store     state->frameno (which is always non-zero for callbacks). In short, callbacks can read parent     reference_state, but cannot mutate it, to be able to use pointers acquired by the caller. They must only     undo their changes (by releasing their own acquired_refs before BPF_EXIT) on top of caller reference_state     before returning (at which point the caller and callback state will match anyway, so no need to copy it     back to caller). (CVE-2022-50650)

  - In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix possible memory leak     in stmmac_dvr_probe() The bitmap_free() should be called to free priv->af_xdp_zc_qps when     create_singlethread_workqueue() fails, otherwise there will be a memory leak, so we add the err path     error_wq_init to fix it. (CVE-2022-50663)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
266163	Amazon Linux 2 内核 --advisory ALAS2KERNEL-5。15-2025-090 (ALASKERNEL-5.15-2025-090)	Nessus	Amazon Linux Local Security Checks	2025/9/30	2026/2/9	high
352031	AlmaLinux 9.2 [TuxCare] 安全更新：bpftool / kernel / kernel-abi-stablelists / kernel-core / 等多种漏洞（ALMALINUX9.2：CLSA-2026：1786761805）	Nessus	Alma Linux Local Security Checks	2026/9/30	2026/10/19	critical
278044	Linux Distros 未修补的漏洞：CVE-2022-50650	Nessus	Misc.	2025/12/10	2026/9/30	high
278044	Linux Distros 未修補的弱點：CVE-2022-50650	Nessus	Misc.	2025/12/10	2026/9/30	high
266163	Amazon Linux 2核心 --advisory ALAS2KERNEL-5。15-2025-090 (ALASKERNEL-5.15-2025-090)	Nessus	Amazon Linux Local Security Checks	2025/9/30	2026/2/9	high
352031	AlmaLinux 9.2 [TuxCare] 安全性更新：bpftool / kernel / kernel-abi-stablelists / kernel-core / etc多個弱點（ALMALINUX9.2：CLSA-2026：1786761805）	Nessus	Alma Linux Local Security Checks	2026/9/30	2026/10/19	critical
266163	Amazon Linux 2kernel、 --advisory ALAS2KERNEL-5。15-2025-090 ALASKERNEL-5.15-2025-090	Nessus	Amazon Linux Local Security Checks	2025/9/30	2026/2/9	high
352031	AlmaLinux 9.2 [TuxCare] セキュリティ更新プログラム:bpftool/kernel/kernel-abi-stablelists/kernel-core/etcの複数の脆弱性(ALMALINUX9.2:CLSA-2026:1786761805)	Nessus	Alma Linux Local Security Checks	2026/9/30	2026/10/19	critical
278044	Linux Distros のパッチ未適用の脆弱性: CVE-2022-50650	Nessus	Misc.	2025/12/10	2026/9/30	high
278044	Linux Distros Unpatched Vulnerability : CVE-2022-50650	Nessus	Misc.	2025/12/10	2026/9/30	high
266163	Amazon Linux 2 : kernel, --advisory ALAS2KERNEL-5.15-2025-090 (ALASKERNEL-5.15-2025-090)	Nessus	Amazon Linux Local Security Checks	2025/9/30	2026/2/9	high
352031	AlmaLinux 9.2 [TuxCare] Security Update: bpftool / kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1786761805)	Nessus	Alma Linux Local Security Checks	2026/9/30	2026/10/19	critical

检测

插件搜索

high

critical

high

high

high

critical

high

critical

high

high

high

critical