In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix use-after-free in nf_tables_addchain() nf_tables_addchain() publishes the chain to table->chains via list_add_tail_rcu() (in nft_chain_add()) before registering hooks. If nf_tables_register_hook() then fails, the error path calls nft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy() with no RCU grace period in between. This creates two use-after-free conditions: 1) Control-plane: nf_tables_dump_chains() traverses table->chains under rcu_read_lock(). A concurrent dump can still be walking the chain when the error path frees it. 2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft_do_chain() via the transient IPv4 hook can still be dereferencing chain->blob_gen_X when the error path frees the chain. Add synchronize_rcu() between nft_chain_del() and the chain destroy so that all RCU readers -- both dump threads and in-flight packet evaluation -- have finished before the chain is freed.

The remote CentOS Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the kernel-5.14.0-688.el9 build changelog.

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix use-after-     free in nf_tables_addchain() nf_tables_addchain() publishes the chain to table->chains via     list_add_tail_rcu() (in nft_chain_add()) before registering hooks. If nf_tables_register_hook() then     fails, the error path calls nft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy() with no     RCU grace period in between. This creates two use-after-free conditions: 1) Control-plane:
    nf_tables_dump_chains() traverses table->chains under rcu_read_lock(). A concurrent dump can still be     walking the chain when the error path frees it. 2) Packet path: for NFPROTO_INET, nf_register_net_hook()     briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft_do_chain() via the     transient IPv4 hook can still be dereferencing chain->blob_gen_X when the error path frees the chain. Add     synchronize_rcu() between nft_chain_del() and the chain destroy so that all RCU readers -- both dump     threads and in-flight packet evaluation -- have finished before the chain is freed. (CVE-2026-23231)

  - In the Linux kernel, the following vulnerability has been resolved: autofs: fix memory leak of waitqueues     in autofs_catatonic_mode Syzkaller reports a memory leak: BUG: memory leak unreferenced object     0xffff88810b279e00 (size 96): comm syz-executor399, pid 3631, jiffies 4294964921 (age 23.870s) hex dump     (first 32 bytes): 00 00 00 00 00 00 00 00 08 9e 27 0b 81 88 ff ff ..........'..... 08 9e 27 0b 81 88 ff ff     00 00 00 00 00 00 00 00 ..'............. backtrace: [<ffffffff814cfc90>] kmalloc_trace+0x20/0x90     mm/slab_common.c:1046 [<ffffffff81bb75ca>] kmalloc include/linux/slab.h:576 [inline] [<ffffffff81bb75ca>]     autofs_wait+0x3fa/0x9a0 fs/autofs/waitq.c:378 [<ffffffff81bb88a7>] autofs_do_expire_multi+0xa7/0x3e0     fs/autofs/expire.c:593 [<ffffffff81bb8c33>] autofs_expire_multi+0x53/0x80 fs/autofs/expire.c:619     [<ffffffff81bb6972>] autofs_root_ioctl_unlocked+0x322/0x3b0 fs/autofs/root.c:897 [<ffffffff81bb6a95>]     autofs_root_ioctl+0x25/0x30 fs/autofs/root.c:910 [<ffffffff81602a9c>] vfs_ioctl fs/ioctl.c:51 [inline]     [<ffffffff81602a9c>] __do_sys_ioctl fs/ioctl.c:870 [inline] [<ffffffff81602a9c>] __se_sys_ioctl     fs/ioctl.c:856 [inline] [<ffffffff81602a9c>] __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:856     [<ffffffff84608225>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<ffffffff84608225>]     do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [<ffffffff84800087>]     entry_SYSCALL_64_after_hwframe+0x63/0xcd autofs_wait_queue structs should be freed if their wait_ctr     becomes zero. Otherwise they will be lost. In this case an AUTOFS_IOC_EXPIRE_MULTI ioctl is done, then a     new waitqueue struct is allocated in autofs_wait(), its initial wait_ctr equals 2. After that     wait_event_killable() is interrupted (it returns -ERESTARTSYS), so that 'wq->name.name == NULL' condition     may be not satisfied. Actually, this condition can be satisfied when autofs_wait_release() or     autofs_catatonic_mode() is called and, what is also important, wait_ctr is decremented in those places.
    Upon the exit of autofs_wait(), wait_ctr is decremented to 1. Then the unmounting process begins: kill_sb     calls autofs_catatonic_mode(), which should have freed the waitqueues, but it only decrements its usage     counter to zero which is not a correct behaviour. edit:imk This description is of course not correct. The     umount performed as a result of an expire is a umount of a mount that has been automounted, it's not the     autofs mount itself. They happen independently, usually after everything mounted within the autofs file     system has been expired away. If everything hasn't been expired away the automount daemon can still exit     leaving mounts in place. But expires done in both cases will result in a notification that calls     autofs_wait_release() with a result status. The problem case is the summary execution of of the automount     daemon. In this case any waiting processes won't be woken up until either they are terminated or the mount     is umounted. end edit: imk So in catatonic mode we should free waitqueues which counter becomes zero.
    edit: imk Initially I was concerned that the calling of autofs_wait_release() and autofs_catatonic_mode()     was not mutually exclusive but that can't be the case (obviously) because the queue entry (or entries) is     removed from the list when either of these two functions are called. Consequently the wait entry will be     freed by only one of these functions or by the woken process in autofs_wait() depending on the order of     the calls. end edit: imk (CVE-2023-54134)

  - In the Linux kernel, the following vulnerability has been resolved: mm: hugetlb: independent PMD page     table shared count The folio refcount may be increased unexpectly through try_get_folio() by caller such     as split_huge_pages. In huge_pmd_unshare(), we use refcount to check whether a pmd page table is shared.
    The check is incorrect if the refcount is increased by the above caller, and this can cause the page table     leaked: BUG: Bad page state in process sh pfn:109324 page: refcount:0 mapcount:0 mapping:0000000000000000     index:0x66 pfn:0x109324 flags: 0x17ffff800000000(node=0|zone=2|lastcpupid=0xfffff) page_type: f2(table)     raw: 017ffff800000000 0000000000000000 0000000000000000 0000000000000000 raw: 0000000000000066     0000000000000000 00000000f2000000 0000000000000000 page dumped because: nonzero mapcount ... CPU: 31 UID:
    0 PID: 7515 Comm: sh Kdump: loaded Tainted: G B 6.13.0-rc2master+ #7 Tainted: [B]=BAD_PAGE Hardware name:
    QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 Call trace: show_stack+0x20/0x38 (C)     dump_stack_lvl+0x80/0xf8 dump_stack+0x18/0x28 bad_page+0x8c/0x130 free_page_is_bad_report+0xa4/0xb0     free_unref_page+0x3cc/0x620 __folio_put+0xf4/0x158 split_huge_pages_all+0x1e0/0x3e8     split_huge_pages_write+0x25c/0x2d8 full_proxy_write+0x64/0xd8 vfs_write+0xcc/0x280 ksys_write+0x70/0x110
    __arm64_sys_write+0x24/0x38 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0xc8/0xf0     do_el0_svc+0x24/0x38 el0_svc+0x34/0x128 el0t_64_sync_handler+0xc8/0xd0 el0t_64_sync+0x190/0x198 The issue     may be triggered by damon, offline_page, page_idle, etc, which will increase the refcount of page table.
    1. The page table itself will be discarded after reporting the nonzero mapcount. 2. The HugeTLB page     mapped by the page table miss freeing since we treat the page table as shared and a shared page table will     not be unmapped. Fix it by introducing independent PMD page table shared count. As described by comment,     pt_index/pt_mm/pt_frag_refcount are used for s390 gmap, x86 pgds and powerpc, pt_share_count is used for     x86/arm64/riscv pmds, so we can reuse the field as pt_share_count. (CVE-2024-57883)

  - In the Linux kernel, the following vulnerability has been resolved: net: atm: fix /proc/net/atm/lec     handling /proc/net/atm/lec must ensure safety against dev_lec[] changes. It appears it had dev_put() calls     without prior dev_hold(), leading to imbalance and UAF. (CVE-2025-38180)

  - In the Linux kernel, the following vulnerability has been resolved: HID: intel-thc-hid: intel-thc: Fix     incorrect pointer arithmetic in I2C regs save Improper use of secondary pointer (&dev->i2c_subip_regs)     caused kernel crash and out-of-bounds error: BUG: KASAN: slab-out-of-bounds in
    _regmap_bulk_read+0x449/0x510 Write of size 4 at addr ffff888136005dc0 by task kworker/u33:5/5107 CPU: 3     UID: 0 PID: 5107 Comm: kworker/u33:5 Not tainted 6.16.0+ #3 PREEMPT(voluntary) Workqueue: async     async_run_entry_fn Call Trace: <TASK> dump_stack_lvl+0x76/0xa0 print_report+0xd1/0x660 ?
    __pfx__raw_spin_lock_irqsave+0x10/0x10 ? kasan_complete_mode_report_info+0x26/0x200     kasan_report+0xe1/0x120 ? _regmap_bulk_read+0x449/0x510 ? _regmap_bulk_read+0x449/0x510
    __asan_report_store4_noabort+0x17/0x30 _regmap_bulk_read+0x449/0x510 ? __pfx__regmap_bulk_read+0x10/0x10     regmap_bulk_read+0x270/0x3d0 pio_complete+0x1ee/0x2c0 [intel_thc] ? __pfx_pio_complete+0x10/0x10     [intel_thc] ? __pfx_pio_wait+0x10/0x10 [intel_thc] ? regmap_update_bits_base+0x13b/0x1f0     thc_i2c_subip_pio_read+0x117/0x270 [intel_thc] thc_i2c_subip_regs_save+0xc2/0x140 [intel_thc] ?
    __pfx_thc_i2c_subip_regs_save+0x10/0x10 [intel_thc] [...] The buggy address belongs to the object at     ffff888136005d00 which belongs to the cache kmalloc-rnd-12-192 of size 192 The buggy address is located 0     bytes to the right of allocated 192-byte region [ffff888136005d00, ffff888136005dc0) Replaced with direct     array indexing (&dev->i2c_subip_regs[i]) to ensure safe memory access. (CVE-2025-39818)

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

The remote Oracle Linux 10 host has packages installed that are affected by multiple vulnerabilities as referenced in the ELSA-2026-6053 advisory.

    - scsi: qla2xxx: Fix bsg_done() causing double free (Ewan D. Milne) [RHEL-153413] {CVE-2025-71238}

Tenable has extracted the preceding description block directly from the Oracle 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.

The remote Redhat Enterprise Linux 10 host has packages installed that are affected by multiple vulnerabilities as referenced in the RHSA-2026:6053 advisory.

    The kernel packages contain the Linux kernel, the core of any Linux operating system.

    Security Fix(es):

    * kernel: kernel: Privilege escalation or denial of service via use-after-free in nf_tables_addchain()     (CVE-2026-23231)

    * kernel: Linux kernel (qla2xxx): Double free vulnerability leads to denial of service and potential     privilege escalation. (CVE-2025-71238)

    For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and     other related information, refer to the CVE page(s) listed in the References section.

Tenable has extracted the preceding description block directly from the Red Hat Enterprise 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.

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

  - netfilter: nf_tables: fix use-after-free in nf_tables_addchain() nf_tables_addchain() publishes the chain     to table->chains via list_add_tail_rcu() (in nft_chain_add()) before registering hooks. If     nf_tables_register_hook() then fails, the error path calls nft_chain_del() (list_del_rcu()) followed by     nf_tables_chain_destroy() with no RCU grace period in between. This creates two use-after-free conditions:
    1) Control-plane: nf_tables_dump_chains() traverses table->chains under rcu_read_lock(). A concurrent dump     can still be walking the chain when the error path frees it. 2) Packet path: for NFPROTO_INET,     nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering     nft_do_chain() via the transient IPv4 hook can still be dereferencing chain->blob_gen_X when the error     path frees the chain. Add synchronize_rcu() between nft_chain_del() and the chain destroy so that all RCU     readers -- both dump threads and in-flight packet evaluation -- have finished before the chain is freed.
    (CVE-2026-23231)

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

ID	Name	Product	Family	Severity
304415	CentOS 9 : kernel-5.14.0-688.el9	Nessus	CentOS Local Security Checks	high
304356	Oracle Linux 10 : kernel (ELSA-2026-6053)	Nessus	Oracle Linux Local Security Checks	high
304301	RHEL 10 : kernel (RHSA-2026:6053)	Nessus	Red Hat Local Security Checks	high
303585	Photon OS 5.0: Linux PHSA-2026-5.0-0794	Nessus	PhotonOS Local Security Checks	high
303411	Photon OS 4.0: Linux PHSA-2026-4.0-0983	Nessus	PhotonOS Local Security Checks	high
301036	Linux Distros Unpatched Vulnerability : CVE-2026-23231	Nessus	Misc.	high

Detections

Analytics

CVE-2026-23231

high

Tenable Plugins

high

high

high

high

high

high