The remote Ubuntu 16.04 LTS host has a package installed that is affected by multiple vulnerabilities as referenced in the USN-6777-3 advisory.

    Zheng Wang discovered that the Broadcom FullMAC WLAN driver in the Linux kernel contained a race condition     during device removal, leading to a use- after-free vulnerability. A physically proximate attacker could     possibly use this to cause a denial of service (system crash). (CVE-2023-47233)

    Several security issues were discovered in the Linux kernel. An attacker could possibly use these to     compromise the system. This update corrects flaws in the following subsystems:

    - Block layer subsystem;

    - Userspace I/O drivers;

    - Ceph distributed file system;

    - Ext4 file system;

    - JFS file system;

    - NILFS2 file system;

    - Bluetooth subsystem;

    - Networking core;

    - IPv4 networking;

    - IPv6 networking;

    - Logical Link layer;

    - MAC80211 subsystem;

    - Netlink;

    - NFC subsystem;

    - Tomoyo security module; (CVE-2023-52524, CVE-2023-52530, CVE-2023-52601, CVE-2023-52439, CVE-2024-26635,     CVE-2023-52602, CVE-2024-26614, CVE-2024-26704, CVE-2023-52604, CVE-2023-52566, CVE-2021-46981,     CVE-2024-26622, CVE-2024-26735, CVE-2024-26805, CVE-2024-26801, CVE-2023-52583)

Tenable has extracted the preceding description block directly from the Ubuntu 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 Rocky Linux 8.6 host has packages installed that are affected by multiple vulnerabilities as referenced in the CIQ ciqsa-2026_1220 advisory.

    This advisory aggregates security fixes for the kernel SRPM in CIQ LTS 8.6. It addresses 24 CVEs:
    CVE-2023-53821, CVE-2023-52530, CVE-2025-40277, CVE-2025-38415, CVE-2024-26585, and 19 more.

Tenable has extracted the preceding description block directly from the CIQ 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-2025:1758796886 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: can: j1939: j1939_netdev_start(): fix     UAF for rx_kref of j1939_priv It will trigger UAF for rx_kref of j1939_priv as following. cpu0 cpu1     j1939_sk_bind(socket0, ndev0, ...) j1939_netdev_start j1939_sk_bind(socket1, ndev0, ...)     j1939_netdev_start j1939_priv_set j1939_priv_get_by_ndev_locked j1939_jsk_add ..... j1939_netdev_stop     kref_put_lock(&priv->rx_kref, ...) kref_get(&priv->rx_kref, ...) REFCOUNT_WARN(addition on 0;...)     ==================================================== refcount_t: addition on 0; use-after-free. WARNING:
    CPU: 1 PID: 20874 at lib/refcount.c:25 refcount_warn_saturate+0x169/0x1e0 RIP:
    0010:refcount_warn_saturate+0x169/0x1e0 Call Trace: j1939_netdev_start+0x68b/0x920     j1939_sk_bind+0x426/0xeb0 ? security_socket_bind+0x83/0xb0 The rx_kref's kref_get() and kref_put() should     use j1939_netdev_lock to protect. (CVE-2021-47459)

  - In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix use-after-free bug in     hclgevf_send_mbx_msg Currently, the hns3_remove function firstly uninstall client instance, and then     uninstall acceletion engine device. The netdevice is freed in client instance uninstall process, but     acceletion engine device uninstall process still use it to trace runtime information. This causes a use     after free problem. So fixes it by check the instance register state to avoid use after free.
    (CVE-2021-47596)

  - In the Linux kernel, the following vulnerability has been resolved: i2c: mlxbf: prevent stack overflow in     mlxbf_i2c_smbus_start_transaction() memcpy() is called in a loop while 'operation->length' upper bound is     not checked and 'data_idx' also increments. (CVE-2022-48632)

  - In the Linux kernel, the following vulnerability has been resolved: PM: hibernate: defer device probing     when resuming from hibernation syzbot is reporting hung task at misc_open() [1], for there is a race     window of AB-BA deadlock which involves probe_count variable. Currently wait_for_device_probe() from     snapshot_open() from misc_open() can sleep forever with misc_mtx held if probe_count cannot become 0. When     a device is probed by hub_event() work function, probe_count is incremented before the probe function     starts, and probe_count is decremented after the probe function completed. There are three cases that can     prevent probe_count from dropping to 0. (a) A device being probed stopped responding (i.e.
    broken/malicious hardware). (b) A process emulating a USB device using /dev/raw-gadget interface stopped     responding for some reason. (c) New device probe requests keeps coming in before existing device probe     requests complete. The phenomenon syzbot is reporting is (b). A process which is holding     system_transition_mutex and misc_mtx is waiting for probe_count to become 0 inside     wait_for_device_probe(), but the probe function which is called from hub_event() work function is waiting     for the processes which are blocked at mutex_lock(&misc_mtx) to respond via /dev/raw-gadget interface.
    This patch mitigates (b) by deferring wait_for_device_probe() from snapshot_open() to snapshot_write() and     snapshot_ioctl(). Please note that the possibility of (b) remains as long as any thread which is emulating     a USB device via /dev/raw-gadget interface can be blocked by uninterruptible blocking operations (e.g.
    mutex_lock()). Please also note that (a) and (c) are not addressed. Regarding (c), we should change the     code to wait for only one device which contains the image for resuming from hibernation. I don't know how     to address (a), for use of timeout for wait_for_device_probe() might result in loss of user data in the     image. Maybe we should require the userland to wait for the image device before opening /dev/snapshot     interface. (CVE-2022-50202)

  - In the Linux kernel, the following vulnerability has been resolved: net: sched: sfb: fix null pointer     access issue when sfb_init() fails When the default qdisc is sfb, if the qdisc of dev_queue fails to be     inited during mqprio_init(), sfb_reset() is invoked to clear resources. In this case, the q->qdisc is     NULL, and it will cause gpf issue. The process is as follows: qdisc_create_dflt() sfb_init()     tcf_block_get() --->failed, q->qdisc is NULL ... qdisc_put() ... sfb_reset() qdisc_reset(q->qdisc)
    --->q->qdisc is NULL ops = qdisc->ops The following is the Call Trace information: general protection     fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-     deref in range [0x0000000000000018-0x000000000000001f] RIP: 0010:qdisc_reset+0x2b/0x6f0 Call Trace: <TASK>     sfb_reset+0x37/0xd0 qdisc_reset+0xed/0x6f0 qdisc_destroy+0x82/0x4c0 qdisc_put+0x9e/0xb0     qdisc_create_dflt+0x2c3/0x4a0 mqprio_init+0xa71/0x1760 qdisc_create+0x3eb/0x1000     tc_modify_qdisc+0x408/0x1720 rtnetlink_rcv_msg+0x38e/0xac0 netlink_rcv_skb+0x12d/0x3a0     netlink_unicast+0x4a2/0x740 netlink_sendmsg+0x826/0xcc0 sock_sendmsg+0xc5/0x100
    ____sys_sendmsg+0x583/0x690 ___sys_sendmsg+0xe8/0x160 __sys_sendmsg+0xbf/0x160 do_syscall_64+0x35/0x80     entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f2164122d04 </TASK> (CVE-2022-50356)

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

The CentOS Linux 6 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS6:CLSA-2025:1761139764 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: pid: take a reference when     initializing `cad_pid` During boot, kernel_init_freeable() initializes `cad_pid` to the init task's struct     pid. Later on, we may change `cad_pid` via a sysctl, and when this happens proc_do_cad_pid() will     increment the refcount on the new pid via get_pid(), and will decrement the refcount on the old pid via     put_pid(). As we never called get_pid() when we initialized `cad_pid`, we decrement a reference we never     incremented, can therefore free the init task's struct pid early. As there can be dangling references to     the struct pid, we can later encounter a use-after-free (e.g. when delivering signals). This was spotted     when fuzzing v5.13-rc3 with Syzkaller, but seems to have been around since the conversion of `cad_pid` to     struct pid in commit 9ec52099e4b8 ([PATCH] replace cad_pid by a struct pid) from the pre-KASAN stone age     of v2.6.19. Fix this by getting a reference to the init task's struct pid when we assign it to `cad_pid`.
    Full KASAN splat below. ================================================================== BUG: KASAN:
    use-after-free in ns_of_pid include/linux/pid.h:153 [inline] BUG: KASAN: use-after-free in     task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 Read of size 4 at addr ffff23794dda0004 by task syz-     executor.0/273 CPU: 1 PID: 273 Comm: syz-executor.0 Not tainted 5.12.0-00001-g9aef892b2d15 #1 Hardware     name: linux,dummy-virt (DT) Call trace: ns_of_pid include/linux/pid.h:153 [inline]     task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 do_notify_parent+0x308/0xe60 kernel/signal.c:1950     exit_notify kernel/exit.c:682 [inline] do_exit+0x2334/0x2bd0 kernel/exit.c:845 do_group_exit+0x108/0x2c8     kernel/exit.c:922 get_signal+0x4e4/0x2a88 kernel/signal.c:2781 do_signal arch/arm64/kernel/signal.c:882     [inline] do_notify_resume+0x300/0x970 arch/arm64/kernel/signal.c:936 work_pending+0xc/0x2dc Allocated by     task 0: slab_post_alloc_hook+0x50/0x5c0 mm/slab.h:516 slab_alloc_node mm/slub.c:2907 [inline] slab_alloc     mm/slub.c:2915 [inline] kmem_cache_alloc+0x1f4/0x4c0 mm/slub.c:2920 alloc_pid+0xdc/0xc00 kernel/pid.c:180     copy_process+0x2794/0x5e18 kernel/fork.c:2129 kernel_clone+0x194/0x13c8 kernel/fork.c:2500     kernel_thread+0xd4/0x110 kernel/fork.c:2552 rest_init+0x44/0x4a0 init/main.c:687     arch_call_rest_init+0x1c/0x28 start_kernel+0x520/0x554 init/main.c:1064 0x0 Freed by task 270:
    slab_free_hook mm/slub.c:1562 [inline] slab_free_freelist_hook+0x98/0x260 mm/slub.c:1600 slab_free     mm/slub.c:3161 [inline] kmem_cache_free+0x224/0x8e0 mm/slub.c:3177 put_pid.part.4+0xe0/0x1a8     kernel/pid.c:114 put_pid+0x30/0x48 kernel/pid.c:109 proc_do_cad_pid+0x190/0x1b0 kernel/sysctl.c:1401     proc_sys_call_handler+0x338/0x4b0 fs/proc/proc_sysctl.c:591 proc_sys_write+0x34/0x48     fs/proc/proc_sysctl.c:617 call_write_iter include/linux/fs.h:1977 [inline] new_sync_write+0x3ac/0x510     fs/read_write.c:518 vfs_write fs/read_write.c:605 [inline] vfs_write+0x9c4/0x1018 fs/read_write.c:585     ksys_write+0x124/0x240 fs/read_write.c:658 __do_sys_write fs/read_write.c:670 [inline] __se_sys_write     fs/read_write.c:667 [inline] __arm64_sys_write+0x78/0xb0 fs/read_write.c:667 __invoke_syscall     arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall arch/arm64/kernel/syscall.c:49 [inline]     el0_svc_common.constprop.1+0x16c/0x388 arch/arm64/kernel/syscall.c:129 do_el0_svc+0xf8/0x150     arch/arm64/kernel/syscall.c:168 el0_svc+0x28/0x38 arch/arm64/kernel/entry-common.c:416     el0_sync_handler+0x134/0x180 arch/arm64/kernel/entry-common.c:432 el0_sync+0x154/0x180     arch/arm64/kernel/entry.S:701 The buggy address belongs to the object at ffff23794dda0000 which belongs to     the cache pid of size 224 The buggy address is located 4 bytes inside of 224-byte region [ff
    ---truncated--- (CVE-2021-47118)

  - In the Linux kernel, the following vulnerability has been resolved: i2c: i801: Don't generate an interrupt     on bus reset Now that the i2c-i801 driver supports interrupts, setting the KILL bit in a attempt to     recover from a timed out transaction triggers an interrupt. Unfortunately, the interrupt handler     (i801_isr) is not prepared for this situation and will try to process the interrupt as if it was signaling     the end of a successful transaction. In the case of a block transaction, this can result in an out-of-     range memory access. This condition was reproduced several times by syzbot:
    https://syzkaller.appspot.com/bug?extid=ed71512d469895b5b34e     https://syzkaller.appspot.com/bug?extid=8c8dedc0ba9e03f6c79e     https://syzkaller.appspot.com/bug?extid=c8ff0b6d6c73d81b610e     https://syzkaller.appspot.com/bug?extid=33f6c360821c399d69eb     https://syzkaller.appspot.com/bug?extid=be15dc0b1933f04b043a     https://syzkaller.appspot.com/bug?extid=b4d3fd1dfd53e90afd79 So disable interrupts while trying to reset     the bus. Interrupts will be enabled again for the following transaction. (CVE-2021-47153)

  - In the Linux kernel, the following vulnerability has been resolved: watchdog: Fix possible use-after-free     by calling del_timer_sync() This driver's remove path calls del_timer(). However, that function does not     wait until the timer handler finishes. This means that the timer handler may still be running after the     driver's remove function has finished, which would result in a use-after-free. Fix by calling     del_timer_sync(), which makes sure the timer handler has finished, and unable to re-schedule itself.
    (CVE-2021-47321)

  - In the Linux kernel, the following vulnerability has been resolved: virtio-net: Add validation for used     length This adds validation for used length (might come from an untrusted device) to avoid data corruption     or loss. (CVE-2021-47352)

  - In the Linux kernel, the following vulnerability has been resolved: tty: Fix out-of-bound vmalloc access     in imageblit This issue happens when a userspace program does an ioctl FBIOPUT_VSCREENINFO passing the     fb_var_screeninfo struct containing only the fields xres, yres, and bits_per_pixel with values. If this     struct is the same as the previous ioctl, the vc_resize() detects it and doesn't call the resize_screen(),     leaving the fb_var_screeninfo incomplete. And this leads to the updatescrollmode() calculates a wrong     value to fbcon_display->vrows, which makes the real_y() return a wrong value of y, and that value,     eventually, causes the imageblit to access an out-of-bound address value. To solve this issue I made the     resize_screen() be called even if the screen does not need any resizing, so it will fix and fill the     fb_var_screeninfo independently. (CVE-2021-47383)

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	Name	Product	Family	Published	Updated	Severity
197600	Ubuntu 16.04 LTS : Linux kernel (GCP) vulnerabilities (USN-6777-3)	Nessus	Ubuntu Local Security Checks	5/22/2024	1/15/2025	high
353467	Rocky Linux 8.6 [CIQ] Security Update: bpftool / bpftool-debuginfo / kernel / kernel-abi-stablelists / etc Multiple Vulnerabilities (ciqsa-2026_1220)	Nessus	Rocky Linux Local Security Checks	10/1/2026	10/12/2026	high
361135	AlmaLinux 9.2 [TuxCare] Security Update: bpftool / kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2025:1758796886)	Nessus	Alma Linux Local Security Checks	10/1/2026	10/19/2026	high
351647	CentOS Linux 6 [TuxCare] Security Update: kernel / kernel-abi-whitelists / kernel-debug / kernel-debug-devel / etc Multiple Vulnerabilities (CENTOS6:CLSA-2025:1761139764)	Nessus	CentOS Local Security Checks	9/30/2026	10/22/2026	high
203657	Photon OS 5.0: Linux PHSA-2023-5.0-0130	Nessus	PhotonOS Local Security Checks	7/23/2024	10/13/2026	high
332630	Photon OS 5.0: Linux PHSA-2023-5.0-91-0130	Nessus	PhotonOS Local Security Checks	8/5/2026	8/5/2026	high

Detections

Analytics

Plugins Search

high

high

high

high

high

high