Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - f2fscompress修正以呼叫 f2fs_write_raw_pages() 中的 f2fs_wait_on_page_writeback()同時寫入檔案時會觸發 BUG_ON()因為相同頁面遭到回寫多次。 1597 void folio_end_writeback(struct folio *folio) 1598 { ...... 1618 if (!__folio_end_writeback(folio)) 1619 BUG()
    ...... 1625 } mm/filemap.c:1619 的核心錯誤呼叫追踪 <TASK> f2fs_write_end_io+0x1a0/0x370 blk_update_request+0x6c/0x410 blk_mq_end_request+0x15/0x130 blk_complete_reqs+0x3c/0x50
    __do_softirq+0xb8/0x29b ? sort_range+0x20/0x20 run_ksoftirqd+0x19/0x20 smpboot_thread_fn+0x10b/0x1d0 kthread+0xde/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 </TASK> 以下是並行情況[處理程序 A] [處理程序 B] [處理程序 C] f2fs_write_raw_pages() - redirty_page_for_writepage() - unlock page() f2fs_do_write_data_page() - lock_page() - clear_page_dirty_for_io() - set_page_writeback() [第一次回寫] ..... - 解除鎖定 page() generic_perform_write() - f2fs_write_begin() - wait_for_stable_page() - f2fs_write_end() - set_page_dirty() - lock_page() - f2fs_do_write_data_page() - set_page_writeback () [第 2 次回寫] 此問題是由之前的提交 7377e853967b 引入 (f2fs壓縮修正壓縮檔案的潛在鎖死)。所有頁面鎖定皆已在 f2fs_write_raw_pages() 中釋放但是在後續的寫入處理程序中會忽略該頁面是否處於回寫狀態。修正此問題的方法是等待頁面回寫後再寫入。 (CVE-2023-54068)

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

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

  - f2fscompress修复以在 f2fs_write_raw_pages() 中调用 f2fs_wait_on_page_writeback() 并发写入文件时将会触发 BUG_ON() 因为同一页面会回写多次。 1597 void folio_end_writeback(struct folio *folio) 1598 { ...... 1618 if (!__ folio_end_writeback(folio)) 1619 BUG();
    ...... 1625} mm/filemap.c:1619! 的内核缺陷调用跟踪 <TASK> f2fs_write_end_io+0x1a0/0x370 blk_update_request+0x6c/0x410 blk_mq_end_request+0x15/0x130 blk_complete_reqs+0x3c/0x50
    __do_softirq+0xb8/0x29b ? sort_range+0x20/0x20 run_ksoftirqd+0x19/0x20 smpboot_thread_fn+0x10b/0x1d0 kthread+0xde/0x110 kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 </TASK> 并发场景如下[进程 A] [进程 B] [进程 C] f2fs_write_raw_pages() - redirty_page_for_writepage() - 解锁 page() f2fs_do_write_data_page() - lock_page() - clear_page_dirty_for_io() - set_page_writeback() [第一次回写] ---- ---- 解锁 page() generic_perform_write() - f2fs_write_begin() - wait_for_stable_page() - f2fs_write_end() - set_page_dirty() - lock_page() - f2fs_do_write_data_page() - set_page_writeback () [第二次回写] 此问题由之前的提交 7377e853967bf2fs压缩修复压缩文件的潜在死锁引入。f2fs_write_raw_pages() 中释放了所有页面锁但在后续写入过程中会忽略页面是否处于回写状态。让我们通过在写入之前等待页面回写来修复它。 (CVE-2023-54068)

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

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

  - f2fscompress f2fs_write_raw_pages() の f2fs_wait_on_page_writeback() を呼び出すための修正。BUG_ON() は、ファイルを同時に書き込むと、同じページが複数回ライトバックされるため、同時に発生します。 1597 void folio_end_writeback(struct folio *folio) 1598 { ...1618 if (!__folio_end_writeback(folio)) 1619 BUG();
    ... 1625 } mm/filemap.c:1619! におけるカーネルのバグCall Trace: <TASK> f2fs_write_end_io+0x1a0/0x370 blk_update_request+0x6c/0x410 blk_mq_end_request+0x15/0x130 blk_complete_reqs+0x3c/0x50
    __do_softirq+0xb8/0x29b ? sort_range+0x20/0x20 run_ksoftirqd+0x19/0x20 smpboot_thread_fn+0x10b/0x1d0 kthread+0xde/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 </TASK> 以下は並行性のシナリオです [プロセス A] [プロセス B] [プロセス C] f2fs_write_raw_pages() - redirty_page_for_writepage() - unlock page() f2fs_do_write_data_page() - lock_page() - clear_page_dirty_for_io() - set_page_writeback() [1st writeback] ..... - unlock page() generic_perform_write() - f2fs_write_begin() - wait_for_stable_page() - f2fs_write_end() - set_page_dirty() - lock_page() - f2fs_do_write_data_page() - set_page_writeback [2st writeback] この問題は以前のコミット 7377e853967b により導入されましたf2fscompress圧縮ファイルの潜在的なデッドロックを修正します。f2fs_write_raw_pages() ですべてのページロックがリリースされましたが、ページがライトバック状態であるかどうかは、その後の書き込みプロセスで無視されていました。書き込む前にページがライトバックされるまで待機してこれを修正します。CVE-2023-54068

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

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

  - f2fs: compress: fix to call f2fs_wait_on_page_writeback() in f2fs_write_raw_pages() BUG_ON() will be     triggered when writing files concurrently, because the same page is writtenback multiple times. 1597 void     folio_end_writeback(struct folio *folio) 1598 { ...... 1618 if (!__folio_end_writeback(folio)) 1619 BUG();
    ...... 1625 } kernel BUG at mm/filemap.c:1619! Call Trace: <TASK> f2fs_write_end_io+0x1a0/0x370     blk_update_request+0x6c/0x410 blk_mq_end_request+0x15/0x130 blk_complete_reqs+0x3c/0x50
    __do_softirq+0xb8/0x29b ? sort_range+0x20/0x20 run_ksoftirqd+0x19/0x20 smpboot_thread_fn+0x10b/0x1d0     kthread+0xde/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 </TASK> Below is the     concurrency scenario: [Process A] [Process B] [Process C] f2fs_write_raw_pages() -     redirty_page_for_writepage() - unlock page() f2fs_do_write_data_page() - lock_page() -     clear_page_dirty_for_io() - set_page_writeback() [1st writeback] ..... - unlock page()     generic_perform_write() - f2fs_write_begin() - wait_for_stable_page() - f2fs_write_end() -     set_page_dirty() - lock_page() - f2fs_do_write_data_page() - set_page_writeback() [2st writeback] This     problem was introduced by the previous commit 7377e853967b (f2fs: compress: fix potential deadlock of     compress file). All pagelocks were released in f2fs_write_raw_pages(), but whether the page was in the     writeback state was ignored in the subsequent writing process. Let's fix it by waiting for the page to     writeback before writing. (CVE-2023-54068)

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

The remote Alibaba Cloud Linux 3 host has packages installed that are affected by multiple vulnerabilities as referenced in the ALINUX3-SA-2026:0139 advisory.

    Package updates are available for Alibaba Cloud Linux 3 that fix the following vulnerabilities:

    CVE-2023-54068:
    In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: fix to call     f2fs_wait_on_page_writeback() in f2fs_write_raw_pages() BUG_ON() will be triggered when writing files     concurrently.

    CVE-2026-23038:
    In the Linux kernel, the following vulnerability has been resolved:
    pnfs/flexfiles: Fix memory leak in nfs4_ff_alloc_deviceid_node()     In nfs4_ff_alloc_deviceid_node(), if the allocation for ds_versions fails,     the function jumps to the out_scratch label without freeing the already     allocated dsaddrs list, leading to a memory leak.
    Fix this by jumping to the out_err_drain_dsaddrs label, which properly     frees the dsaddrs list before cleaning up other resources.

    CVE-2026-23398:
    In the Linux kernel, the following vulnerability has been resolved:
    icmp: fix NULL pointer dereference in icmp_tag_validation()     icmp_tag_validation() unconditionally dereferences the result of     rcu_dereference(inet_protos[proto]) without checking for NULL.
    The inet_protos[] array is sparse -- only about 15 of 256 protocol     numbers have registered handlers. When ip_no_pmtu_disc is set to 3     (hardened PMTU mode) and the kernel receives an ICMP Fragmentation     Needed error with a quoted inner IP header containing an unregistered     protocol number, the NULL dereference causes a kernel panic in     softirq context.
    Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] SMP KASAN     NOPTI     KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]     RIP: 0010:icmp_unreach (net/ipv4/icmp.c:1085 net/ipv4/icmp.c:1143)     Call Trace:
    <IRQ>     icmp_rcv (net/ipv4/icmp.c:1527)     ip_protocol_deliver_rcu (net/ipv4/ip_input.c:207)     ip_local_deliver_finish (net/ipv4/ip_input.c:242)     ip_local_deliver (net/ipv4/ip_input.c:262)     ip_rcv (net/ipv4/ip_input.c:573)
    __netif_receive_skb_one_core (net/core/dev.c:6164)     process_backlog (net/core/dev.c:6628)     handle_softirqs (kernel/softirq.c:561)     </IRQ>     Add a NULL check before accessing icmp_strict_tag_validation. If the     protocol has no registered handler, return false since it cannot     perform strict tag validation.

    CVE-2026-23420:
    In the Linux kernel, the following vulnerability has been resolved:
    wifi: wlcore: Fix a locking bug     Make sure that wl->mutex is locked before it is unlocked. This has been     detected by the Clang thread-safety analyzer.

    CVE-2026-23449:
    In the Linux kernel, the following vulnerability has been resolved:
    net/sched: teql: Fix double-free in teql_master_xmit     Whenever a TEQL devices has a lockless Qdisc as root, qdisc_reset should     be called using the seq_lock to avoid racing with the datapath. Failure     to do so may cause crashes like the following:
    [  238.028993][  T318] BUG: KASAN: double-free in skb_release_data (net/core/skbuff.c:1139)     [  238.029328][  T318] Free of addr ffff88810c67ec00 by task poc_teql_uaf_ke/318     [  238.029749][  T318]     [  238.029900][  T318] CPU: 3 UID: 0 PID: 318 Comm: poc_teql_ke Not tainted 7.0.0-rc3-00149-ge5b31d988a41     #704 PREEMPT(full)     [  238.029906][  T318] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011     [  238.029910][  T318] Call Trace:
    [  238.029913][  T318]  <TASK>     [  238.029916][  T318]  dump_stack_lvl (lib/dump_stack.c:122)     [  238.029928][  T318]  print_report (mm/kasan/report.c:379 mm/kasan/report.c:482)     [  238.029940][  T318]  ? skb_release_data (net/core/skbuff.c:1139)     [  238.029944][  T318]  ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)     ...
    [  238.029957][  T318]  ? skb_release_data (net/core/skbuff.c:1139)     [  238.029969][  T318]  kasan_report_invalid_free (mm/kasan/report.c:221 mm/kasan/report.c:563)     [  238.029979][  T318]  ? skb_release_data (net/core/skbuff.c:1139)     [  238.029989][  T318]  check_slab_allocation (mm/kasan/common.c:231)     [  238.029995][  T318]  kmem_cache_free (mm/slub.c:2637 (discriminator 1) mm/slub.c:6168 (discriminator 1)     mm/slub.c:6298 (discriminator 1))     [  238.030004][  T318]  skb_release_data (net/core/skbuff.c:1139)     ...
    [  238.030025][  T318]  sk_skb_reason_drop (net/core/skbuff.c:1256)     [  238.030032][  T318]  pfifo_fast_reset (./include/linux/ptr_ring.h:171 ./include/linux/ptr_ring.h:309     ./include/linux/skb_array.h:98 net/sched/sch_generic.c:827)     [  238.030039][  T318]  ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)     ...
    [  238.030054][  T318]  qdisc_reset (net/sched/sch_generic.c:1034)     [  238.030062][  T318]  teql_destroy (./include/linux/spinlock.h:395 net/sched/sch_teql.c:157)     [  238.030071][  T318]  __qdisc_destroy (./include/net/pkt_sched.h:328 net/sched/sch_generic.c:1077)     [  238.030077][  T318]  qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053     net/sched/sch_api.c:1159)     [  238.030089][  T318]  ? __pfx_qdisc_graft (net/sched/sch_api.c:1091)     [  238.030095][  T318]  ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)     [  238.030102][  T318]  ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)     [  238.030106][  T318]  ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)     [  238.030114][  T318]  tc_get_qdisc (net/sched/sch_api.c:1529 net/sched/sch_api.c:1556)     ...
    [  238.072958][  T318] Allocated by task 303 on cpu 5 at 238.026275s:
    [  238.073392][  T318]  kasan_save_stack (mm/kasan/common.c:58)     [  238.073884][  T318]  kasan_save_track (mm/kasan/common.c:64 (discriminator 5) mm/kasan/common.c:79     (discriminator 5))     [  238.074230][  T318]  __kasan_slab_alloc (mm/kasan/common.c:369)     [  238.074578][  T318]  kmem_cache_alloc_node_noprof (./include/linux/kasan.h:253 mm/slub.c:4542     mm/slub.c:4869 mm/slub.c:4921)     [  238.076091][  T318]  kmalloc_reserve (net/core/skbuff.c:616 (discriminator 107))     [  238.076450][  T318]  __alloc_skb (net/core/skbuff.c:713)     [  238.076834][  T318]  alloc_skb_with_frags (./include/linux/skbuff.h:1383 net/core/skbuff.c:6763)     [  238.077178][  T318]  sock_alloc_send_pskb (net/core/sock.c:2997)     [  238.077520][  T318]  packet_sendmsg (net/packet/af_packet.c:2926 net/packet/af_packet.c:3019     net/packet/af_packet.c:3108)     [  238.081469][  T318]     [  238.081870][  T318] Freed by task 299 on cpu 1 at 238.028496s:
    [  238.082761][  T318]  kasan_save_stack (mm/kasan/common.c:58)     [  238.083481][  T318]  kasan_save_track (mm/kasan/common.c:64 (discriminator 5) mm/kasan/common.c:79     (discriminator 5))     [  238.085348][  T318]  kasan_save_free_info (mm/kasan/generic.c:587 (discriminator 1))     [  238.085900][  T318]  __kasan_slab_free (mm/
    ---truncated---

    CVE-2026-23450:
    In the Linux kernel, the following vulnerability has been resolved:
    net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock()     Syzkaller reported a panic in smc_tcp_syn_recv_sock() [1].
    smc_tcp_syn_recv_sock() is called in the TCP receive path     (softirq) via icsk_af_ops->syn_recv_sock on the clcsock (TCP     listening socket). It reads sk_user_data to get the smc_sock     pointer. However, when the SMC listen socket is being closed     concurrently, smc_close_active() sets clcsock->sk_user_data     to NULL under sk_callback_lock, and then the smc_sock itself     can be freed via sock_put() in smc_release().
    This leads to two issues:
    1) NULL pointer dereference: sk_user_data is NULL when     accessed.
    2) Use-after-free: sk_user_data is read as non-NULL, but the     smc_sock is freed before its fields (e.g., queued_smc_hs,     ori_af_ops) are accessed.
    The race window looks like this (the syzkaller crash [1]     triggers via the SYN cookie path: tcp_get_cookie_sock() ->     smc_tcp_syn_recv_sock(), but the normal tcp_check_req() path     has the same race):
    CPU A (softirq)              CPU B (process ctx)     tcp_v4_rcv()     TCP_NEW_SYN_RECV:
    sk = req->rsk_listener     sock_hold(sk)     /* No lock on listener */     smc_close_active():
    write_lock_bh(cb_lock)     sk_user_data = NULL     write_unlock_bh(cb_lock)     ...
    smc_clcsock_release()     sock_put(smc->sk) x2
    -> smc_sock freed!     tcp_check_req()     smc_tcp_syn_recv_sock():
    smc = user_data(sk)
    -> NULL or dangling     smc->queued_smc_hs
    -> crash!     Note that the clcsock and smc_sock are two independent objects     with separate refcounts. TCP stack holds a reference on the     clcsock, which keeps it alive, but this does NOT prevent the     smc_sock from being freed.
    Fix this by using RCU and refcount_inc_not_zero() to safely     access smc_sock. Since smc_tcp_syn_recv_sock() is called in     the TCP three-way handshake path, taking read_lock_bh on     sk_callback_lock is too heavy and would not survive a SYN     flood attack. Using rcu_read_lock() is much more lightweight.
    - Set SOCK_RCU_FREE on the SMC listen socket so that     smc_sock freeing is deferred until after the RCU grace     period. This guarantees the memory is still valid when     accessed inside rcu_read_lock().
    - Use rcu_read_lock() to protect reading sk_user_data.
    - Use refcount_inc_not_zero(&smc->sk.sk_refcnt) to pin the     smc_sock. If the refcount has already reached zero (close     path completed), it returns false and we bail out safely.
    Note: smc_hs_congested() has a similar lockless read of     sk_user_data without rcu_read_lock(), but it only checks for     NULL and accesses the global smc_hs_wq, never dereferencing     any smc_sock field, so it is not affected.
    Reproducer was verified with mdelay injection and smc_run,     the issue no longer occurs with this patch applied.
    [1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9

    CVE-2026-23452:
    In the Linux kernel, the following vulnerability has been resolved:
    PM: runtime: Fix a race condition related to device removal     The following code in pm_runtime_work() may dereference the dev->parent     pointer after the parent device has been freed:
    /* Maybe the parent is now able to suspend. */     if (parent && !parent->power.ignore_children) {     spin_unlock(&dev->power.lock);
    spin_lock(&parent->power.lock);
    rpm_idle(parent, RPM_ASYNC);
    spin_unlock(&parent->power.lock);
    spin_lock(&dev->power.lock);
    }     Fix this by inserting a flush_work() call in pm_runtime_remove().
    Without this patch blktest block/001 triggers the following complaint     sporadically:
    BUG: KASAN: slab-use-after-free in lock_acquire+0x70/0x160     Read of size 1 at addr ffff88812bef7198 by task kworker/u553:1/3081     Workqueue: pm pm_runtime_work     Call Trace:
    <TASK>     dump_stack_lvl+0x61/0x80     print_address_description.constprop.0+0x8b/0x310     print_report+0xfd/0x1d7     kasan_report+0xd8/0x1d0
    __kasan_check_byte+0x42/0x60     lock_acquire.part.0+0x38/0x230     lock_acquire+0x70/0x160
    _raw_spin_lock+0x36/0x50     rpm_suspend+0xc6a/0xfe0     rpm_idle+0x578/0x770     pm_runtime_work+0xee/0x120     process_one_work+0xde3/0x1410     worker_thread+0x5eb/0xfe0     kthread+0x37b/0x480     ret_from_fork+0x6cb/0x920     ret_from_fork_asm+0x11/0x20     </TASK>     Allocated by task 4314:
    kasan_save_stack+0x2a/0x50     kasan_save_track+0x18/0x40     kasan_save_alloc_info+0x3d/0x50
    __kasan_kmalloc+0xa0/0xb0
    __kmalloc_noprof+0x311/0x990     scsi_alloc_target+0x122/0xb60 [scsi_mod]
    __scsi_scan_target+0x101/0x460 [scsi_mod]     scsi_scan_channel+0x179/0x1c0 [scsi_mod]     scsi_scan_host_selected+0x259/0x2d0 [scsi_mod]     store_scan+0x2d2/0x390 [scsi_mod]     dev_attr_store+0x43/0x80     sysfs_kf_write+0xde/0x140     kernfs_fop_write_iter+0x3ef/0x670     vfs_write+0x506/0x1470     ksys_write+0xfd/0x230
    __x64_sys_write+0x76/0xc0     x64_sys_call+0x213/0x1810     do_syscall_64+0xee/0xfc0     entry_SYSCALL_64_after_hwframe+0x4b/0x53     Freed by task 4314:
    kasan_save_stack+0x2a/0x50     kasan_save_track+0x18/0x40     kasan_save_free_info+0x3f/0x50
    __kasan_slab_free+0x67/0x80     kfree+0x225/0x6c0     scsi_target_dev_release+0x3d/0x60 [scsi_mod]     device_release+0xa3/0x220     kobject_cleanup+0x105/0x3a0     kobject_put+0x72/0xd0     put_device+0x17/0x20     scsi_device_dev_release+0xacf/0x12c0 [scsi_mod]     device_release+0xa3/0x220     kobject_cleanup+0x105/0x3a0     kobject_put+0x72/0xd0     put_device+0x17/0x20     scsi_device_put+0x7f/0xc0 [scsi_mod]     sdev_store_delete+0xa5/0x120 [scsi_mod]     dev_attr_store+0x43/0x80     sysfs_kf_write+0xde/0x140     kernfs_fop_write_iter+0x3ef/0x670     vfs_write+0x506/0x1470     ksys_write+0xfd/0x230
    __x64_sys_write+0x76/0xc0     x64_sys_call+0x213/0x1810

    CVE-2026-23455:
    In the Linux kernel, the following vulnerability has been resolved:
    netfilter: nf_conntrack_h323: check for zero length in DecodeQ931()     In DecodeQ931(), the UserUserIE code path reads a 16-bit length from     the packet, then decrements it by 1 to skip the protocol discriminator     byte before passing it to DecodeH323_UserInformation(). If the encoded     length is 0, the decrement wraps to -1, which is then passed as a     large value to the decoder, leading to an out-of-bounds read.
    Add a check to ensure len is positive after the decrement.

    CVE-2026-23456:
    In the Linux kernel, the following vulnerability has been resolved:
    netfilter: nf_conntrack_h323: fix OOB read in decode_int() CONS case     In decode_int(), the CONS case calls get_bits(bs, 2) to read a length     value, then calls get_uint(bs, len) without checking that len bytes     remain in the buffer. The existing boundary check only validates the     2 bits for get_bits(), not the subsequent 1-4 bytes that get_uint()     reads. This allows a malformed H.323/RAS packet to cause a 1-4 byte     slab-out-of-bounds read.
    Add a boundary check for len bytes after get_bits() and before     get_uint().

    CVE-2026-23457:
    In the Linux kernel, the following vulnerability has been resolved:
    netfilter: nf_conntrack_sip: fix Content-Length u32 truncation in sip_help_tcp()     sip_help_tcp() parses the SIP Content-Length header with     simple_strtoul(), which returns unsigned long, but stores the result in     unsigned int clen.  On 64-bit systems, values exceeding UINT_MAX are     silently truncated before computing the SIP message boundary.
    For example, Content-Length 4294967328 (2^32 + 32) is truncated to 32,     causing the parser to miscalculate where the current message ends.  The     loop then treats trailing data in the TCP segment as a second SIP     message and processes it through the SDP parser.
    Fix this by changing clen to unsigned long to match the return type of     simple_strtoul(), and reject Content-Length values that exceed the     remaining TCP payload length.

    CVE-2026-31399:
    In the Linux kernel, the following vulnerability has been resolved:
    nvdimm/bus: Fix potential use after free in asynchronous initialization     Dingisoul with KASAN reports a use after free if device_add() fails in     nd_async_device_register().
    Commit b6eae0f61db2 (libnvdimm: Hold reference on parent while     scheduling async init) correctly added a reference on the parent device     to be held until asynchronous initialization was complete.  However, if     device_add() results in an allocation failure the ref count of the     device drops to 0 prior to the parent pointer being accessed.  Thus     resulting in use after free.
    The bug bot AI correctly identified the fix.  Save a reference to the     parent pointer to be used to drop the parent reference regardless of the     outcome of device_add().

    CVE-2026-31402:
    In the Linux kernel, the following vulnerability has been resolved:
    nfsd: fix heap overflow in NFSv4.0 LOCK replay cache     The NFSv4.0 replay cache uses a fixed 112-byte inline buffer     (rp_ibuf[NFSD4_REPLAY_ISIZE]) to store encoded operation responses.
    This size was calculated based on OPEN responses and does not account     for LOCK denied responses, which include the conflicting lock owner as     a variable-length field up to 1024 bytes (NFS4_OPAQUE_LIMIT).
    When a LOCK operation is denied due to a conflict with an existing lock     that has a large owner, nfsd4_encode_operation() copies the full encoded     response into the undersized replay buffer via read_bytes_from_xdr_buf()     with no bounds check. This results in a slab-out-of-bounds write of up     to 944 bytes past the end of the buffer, corrupting adjacent heap memory.
    This can be triggered remotely by an unauthenticated attacker with two     cooperating NFSv4.0 clients: one sets a lock with a large owner string,     then the other requests a conflicting lock to provoke the denial.
    We could fix this by increasing NFSD4_REPLAY_ISIZE to allow for a full     opaque, but that would increase the size of every stateowner, when most     lockowners are not that large.
    Instead, fix this by checking the encoded response length against     NFSD4_REPLAY_ISIZE before copying into the replay buffer. If the     response is too large, set rp_buflen to 0 to skip caching the replay     payload. The status is still cached, and the client already received the     correct response on the original request.

    CVE-2026-31431:
    In the Linux kernel, the following vulnerability has been resolved:
    crypto: algif_aead - Revert to operating out-of-place     This mostly reverts commit 72548b093ee3 except for the copying of     the associated data.
    There is no benefit in operating in-place in algif_aead since the     source and destination come from different mappings.  Get rid of     all the complexity added for in-place operation and just copy the     AD directly.

    CVE-2026-43284:
    In the Linux kernel, the following vulnerability has been resolved:
    xfrm: esp: avoid in-place decrypt on shared skb frags     MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP     marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(),     so later paths that may modify packet data can first make a private     copy. The IPv4/IPv6 datagram append paths did not set this flag when     splicing pages into UDP skbs.
    That leaves an ESP-in-UDP packet made from shared pipe pages looking     like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW     fast path for uncloned skbs without a frag_list and decrypts in place     over data that is not owned privately by the skb.
    Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching     TCP. Also make ESP input fall back to skb_cow_data() when the flag is     present, so ESP does not decrypt externally backed frags in place.
    Private nonlinear skb frags still use the existing fast path.
    This intentionally does not change ESP output. In esp_output_head(),     the path that appends the ESP trailer to existing skb tailroom without     calling skb_cow_data() is not reachable for nonlinear skbs:
    skb_tailroom() returns zero when skb->data_len is nonzero, while ESP     tailen is positive. Thus ESP output will either use the separate     destination-frag path or fall back to skb_cow_data().

Tenable has extracted the preceding description block directly from the Alibaba Cloud Linux security advisory.

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

An update of the linux package has been released.

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
280009	Linux Distros 未修補的弱點：CVE-2023-54068	Nessus	Misc.	2025/12/26	2026/7/17	medium
280009	Linux Distros 未修补的漏洞：CVE-2023-54068	Nessus	Misc.	2025/12/26	2026/7/17	medium
280009	Linux Distros のパッチ未適用の脆弱性: CVE-2023-54068	Nessus	Misc.	2025/12/26	2026/7/17	medium
280009	Linux Distros Unpatched Vulnerability : CVE-2023-54068	Nessus	Misc.	2025/12/26	2026/7/17	medium
317880	Alibaba Cloud Linux 3 : 0139: cloud-kernel bugfix, enhancement and (ALINUX3-SA-2026:0139)	Nessus	Alibaba Cloud Linux Local Security Checks	2026/5/29	2026/6/1	high
151965	Photon OS 4.0: Linux PHSA-2021-4.0-0065	Nessus	PhotonOS Local Security Checks	2021/7/22	2026/8/26	high

检测

插件搜索

medium

medium

medium

medium

high

high