In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't WARN for connections on invalid channels It's not clear (to me) how exactly syzbot managed to hit this, but it seems conceivable that e.g. regulatory changed and has disabled a channel between scanning (channel is checked to be usable by cfg80211_get_ies_channel_number) and connecting on the channel later. With one scenario that isn't covered elsewhere described above, the warning isn't good, replace it with a (more informative) error message.

The Rocky Linux 9.6 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.6:CLSA-2026:1782155469 advisory.

  - A vulnerability classified as problematic has been found in Linux Kernel. Affected is the function     j1939_session_destroy of the file net/can/j1939/transport.c. The manipulation leads to memory leak. It is     recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211932.
    (CVE-2022-3633)

  - In the Linux kernel, the following vulnerability has been resolved: udf: Fix preallocation discarding at     indirect extent boundary When preallocation extent is the first one in the extent block, the code would     corrupt extent tree header instead. Fix the problem and use udf_delete_aext() for deleting extent to avoid     some code duplication. (CVE-2022-48946)

  - In the Linux kernel, the following vulnerability has been resolved: xen/privcmd: fix error exit of     privcmd_ioctl_dm_op() The error exit of privcmd_ioctl_dm_op() is calling unlock_pages() potentially with     pages being NULL, leading to a NULL dereference. Additionally lock_pages() doesn't check for     pin_user_pages_fast() having been completely successful, resulting in potentially not locking all pages     into memory. This could result in sporadic failures when using the related memory in user mode. Fix all of     that by calling unlock_pages() always with the real number of pinned pages, which will be zero in case     pages being NULL, and by checking the number of pages pinned by pin_user_pages_fast() matching the     expected number of pages. (CVE-2022-49989)

  - In the Linux kernel, the following vulnerability has been resolved: net: USB: Fix wrong-direction WARNING     in plusb.c The syzbot fuzzer detected a bug in the plusb network driver: A zero-length control-OUT     transfer was treated as a read instead of a write. In modern kernels this error provokes a WARNING: usb     1-1: BOGUS control dir, pipe 80000280 doesn't match bRequestType c0 WARNING: CPU: 0 PID: 4645 at     drivers/usb/core/urb.c:411 usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411 Modules linked in: CPU:
    1 PID: 4645 Comm: dhcpcd Not tainted 6.2.0-rc6-syzkaller-00050-g9f266ccaa2f5 #0 Hardware name: Google     Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023 RIP: 0010:usb_submit_urb+0x14a7/0x1880     drivers/usb/core/urb.c:411 ... Call Trace: <TASK> usb_start_wait_urb+0x101/0x4b0     drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core/message.c:102 [inline]     usb_control_msg+0x320/0x4a0 drivers/usb/core/message.c:153 __usbnet_read_cmd+0xb9/0x390     drivers/net/usb/usbnet.c:2010 usbnet_read_cmd+0x96/0xf0 drivers/net/usb/usbnet.c:2068 pl_vendor_req     drivers/net/usb/plusb.c:60 [inline] pl_set_QuickLink_features drivers/net/usb/plusb.c:75 [inline]     pl_reset+0x2f/0xf0 drivers/net/usb/plusb.c:85 usbnet_open+0xcc/0x5d0 drivers/net/usb/usbnet.c:889
    __dev_open+0x297/0x4d0 net/core/dev.c:1417 __dev_change_flags+0x587/0x750 net/core/dev.c:8530     dev_change_flags+0x97/0x170 net/core/dev.c:8602 devinet_ioctl+0x15a2/0x1d70 net/ipv4/devinet.c:1147     inet_ioctl+0x33f/0x380 net/ipv4/af_inet.c:979 sock_do_ioctl+0xcc/0x230 net/socket.c:1169     sock_ioctl+0x1f8/0x680 net/socket.c:1286 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870     [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856 do_syscall_x64     arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80     entry_SYSCALL_64_after_hwframe+0x63/0xcd The fix is to call usbnet_write_cmd() instead of     usbnet_read_cmd() and remove the USB_DIR_IN flag. (CVE-2023-52742)

  - In the Linux kernel, the following vulnerability has been resolved: tracing: Make sure trace_printk() can     output as soon as it can be used Currently trace_printk() can be used as soon as early_trace_init() is     called from start_kernel(). But if a crash happens, and ftrace_dump_on_oops is set on the kernel command     line, all you get will be: [ 0.456075] <idle>-0 0dN.2. 347519us : Unknown type 6 [ 0.456075] <idle>-0     0dN.2. 353141us : Unknown type 6 [ 0.456075] <idle>-0 0dN.2. 358684us : Unknown type 6 This is because the     trace_printk() event (type 6) hasn't been registered yet. That gets done via an early_initcall(), which     may be early, but not early enough. Instead of registering the trace_printk() event (and other ftrace     events, which are not trace events) via an early_initcall(), have them registered at the same time that     trace_printk() can be used. This way, if there is a crash before early_initcall(), then the     trace_printk()s will actually be useful. (CVE-2023-53007)

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.6 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.6:CLSA-2026:1782155469 advisory.

  - A vulnerability classified as problematic has been found in Linux Kernel. Affected is the function     j1939_session_destroy of the file net/can/j1939/transport.c. The manipulation leads to memory leak. It is     recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211932.
    (CVE-2022-3633)

  - In the Linux kernel, the following vulnerability has been resolved: udf: Fix preallocation discarding at     indirect extent boundary When preallocation extent is the first one in the extent block, the code would     corrupt extent tree header instead. Fix the problem and use udf_delete_aext() for deleting extent to avoid     some code duplication. (CVE-2022-48946)

  - In the Linux kernel, the following vulnerability has been resolved: xen/privcmd: fix error exit of     privcmd_ioctl_dm_op() The error exit of privcmd_ioctl_dm_op() is calling unlock_pages() potentially with     pages being NULL, leading to a NULL dereference. Additionally lock_pages() doesn't check for     pin_user_pages_fast() having been completely successful, resulting in potentially not locking all pages     into memory. This could result in sporadic failures when using the related memory in user mode. Fix all of     that by calling unlock_pages() always with the real number of pinned pages, which will be zero in case     pages being NULL, and by checking the number of pages pinned by pin_user_pages_fast() matching the     expected number of pages. (CVE-2022-49989)

  - In the Linux kernel, the following vulnerability has been resolved: net: USB: Fix wrong-direction WARNING     in plusb.c The syzbot fuzzer detected a bug in the plusb network driver: A zero-length control-OUT     transfer was treated as a read instead of a write. In modern kernels this error provokes a WARNING: usb     1-1: BOGUS control dir, pipe 80000280 doesn't match bRequestType c0 WARNING: CPU: 0 PID: 4645 at     drivers/usb/core/urb.c:411 usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411 Modules linked in: CPU:
    1 PID: 4645 Comm: dhcpcd Not tainted 6.2.0-rc6-syzkaller-00050-g9f266ccaa2f5 #0 Hardware name: Google     Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023 RIP: 0010:usb_submit_urb+0x14a7/0x1880     drivers/usb/core/urb.c:411 ... Call Trace: <TASK> usb_start_wait_urb+0x101/0x4b0     drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core/message.c:102 [inline]     usb_control_msg+0x320/0x4a0 drivers/usb/core/message.c:153 __usbnet_read_cmd+0xb9/0x390     drivers/net/usb/usbnet.c:2010 usbnet_read_cmd+0x96/0xf0 drivers/net/usb/usbnet.c:2068 pl_vendor_req     drivers/net/usb/plusb.c:60 [inline] pl_set_QuickLink_features drivers/net/usb/plusb.c:75 [inline]     pl_reset+0x2f/0xf0 drivers/net/usb/plusb.c:85 usbnet_open+0xcc/0x5d0 drivers/net/usb/usbnet.c:889
    __dev_open+0x297/0x4d0 net/core/dev.c:1417 __dev_change_flags+0x587/0x750 net/core/dev.c:8530     dev_change_flags+0x97/0x170 net/core/dev.c:8602 devinet_ioctl+0x15a2/0x1d70 net/ipv4/devinet.c:1147     inet_ioctl+0x33f/0x380 net/ipv4/af_inet.c:979 sock_do_ioctl+0xcc/0x230 net/socket.c:1169     sock_ioctl+0x1f8/0x680 net/socket.c:1286 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870     [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856 do_syscall_x64     arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80     entry_SYSCALL_64_after_hwframe+0x63/0xcd The fix is to call usbnet_write_cmd() instead of     usbnet_read_cmd() and remove the USB_DIR_IN flag. (CVE-2023-52742)

  - In the Linux kernel, the following vulnerability has been resolved: tracing: Make sure trace_printk() can     output as soon as it can be used Currently trace_printk() can be used as soon as early_trace_init() is     called from start_kernel(). But if a crash happens, and ftrace_dump_on_oops is set on the kernel command     line, all you get will be: [ 0.456075] <idle>-0 0dN.2. 347519us : Unknown type 6 [ 0.456075] <idle>-0     0dN.2. 353141us : Unknown type 6 [ 0.456075] <idle>-0 0dN.2. 358684us : Unknown type 6 This is because the     trace_printk() event (type 6) hasn't been registered yet. That gets done via an early_initcall(), which     may be early, but not early enough. Instead of registering the trace_printk() event (and other ftrace     events, which are not trace events) via an early_initcall(), have them registered at the same time that     trace_printk() can be used. This way, if there is a crash before early_initcall(), then the     trace_printk()s will actually be useful. (CVE-2023-53007)

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:1783791447 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: phy: mdio: fix memory leak Syzbot     reported memory leak in MDIO bus interface, the problem was in wrong state logic. MDIOBUS_ALLOCATED     indicates 2 states: 1. Bus is only allocated 2. Bus allocated and __mdiobus_register() fails, but     device_register() was called In case of device_register() has been called we should call put_device() to     correctly free the memory allocated for this device, but mdiobus_free() calls just kfree(dev) in case of     MDIOBUS_ALLOCATED state To avoid this behaviour we need to set bus->state to MDIOBUS_UNREGISTERED _before_     calling device_register(), because put_device() should be called even in case of device_register()     failure. (CVE-2021-47416)

  - An out-of-bounds read flaw was found in the Linux kernel's TeleTYpe subsystem. The issue occurs in how a     user triggers a race condition using ioctls TIOCSPTLCK and TIOCGPTPEER and TIOCSTI and TCXONC with leakage     of memory in the flush_to_ldisc function. This flaw allows a local user to crash the system or read     unauthorized random data from memory. (CVE-2022-1462)

  - In the Linux kernel, the following vulnerability has been resolved: can: isotp: sanitize CAN ID checks in     isotp_bind() Syzbot created an environment that lead to a state machine status that can not be reached     with a compliant CAN ID address configuration. The provided address information consisted of CAN ID     0x6000001 and 0xC28001 which both boil down to 11 bit CAN IDs 0x001 in sending and receiving. Sanitize the     SFF/EFF CAN ID values before performing the address checks. (CVE-2022-49269)

  - In the Linux kernel, the following vulnerability has been resolved: tty: fix deadlock caused by calling     printk() under tty_port->lock pty_write() invokes kmalloc() which may invoke a normal printk() to print     failure message. This can cause a deadlock in the scenario reported by syz-bot below: CPU0 CPU1 CPU2 ----
    ---- ---- lock(console_owner); lock(&port_lock_key); lock(&port->lock); lock(&port_lock_key);
    lock(&port->lock); lock(console_owner); As commit dbdda842fe96 (printk: Add console owner and waiter     logic to load balance console writes) said, such deadlock can be prevented by using printk_deferred() in     kmalloc() (which is invoked in the section guarded by the port->lock). But there are too many printk() on     the kmalloc() path, and kmalloc() can be called from anywhere, so changing printk() to printk_deferred()     is too complicated and inelegant. Therefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so     that printk() will not be called, and this deadlock problem can be avoided. Syzbot reported the following     lockdep error: ====================================================== WARNING: possible circular locking     dependency detected 5.4.143-00237-g08ccc19a-dirty #10 Not tainted
    ------------------------------------------------------ syz-executor.4/29420 is trying to acquire lock:
    ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752     [inline] ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470     kernel/printk/printk.c:2023 but task is already holding lock: ffff8880119c9158 (&port->lock){-.-.}-{2:2},     at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120 which lock already depends on the new lock. the existing     dependency chain (in reverse order) is: -> #2 (&port->lock){-.-.}-{2:2}: __raw_spin_lock_irqsave     include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50     kernel/locking/spinlock.c:159 tty_port_tty_get drivers/tty/tty_port.c:288 [inline] <-- lock(&port->lock);
    tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47 serial8250_tx_chars+0x530/0xa80     drivers/tty/serial/8250/8250_port.c:1767 serial8250_handle_irq.part.0+0x31f/0x3d0     drivers/tty/serial/8250/8250_port.c:1854 serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827     [inline] <-- lock(&port_lock_key); serial8250_default_handle_irq+0xb2/0x220     drivers/tty/serial/8250/8250_port.c:1870 serial8250_interrupt+0xfd/0x200     drivers/tty/serial/8250/8250_core.c:126 __handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156     [...] -> #1 (&port_lock_key){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110     [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159     serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198 <-- lock(&port_lock_key);
    call_console_drivers kernel/printk/printk.c:1819 [inline] console_unlock+0x8cb/0xd00     kernel/printk/printk.c:2504 vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024 <-- lock(console_owner);
    vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394 printk+0xba/0xed kernel/printk/printk.c:2084     register_console+0x8b3/0xc10 kernel/printk/printk.c:2829 univ8250_console_init+0x3a/0x46     drivers/tty/serial/8250/8250_core.c:681 console_init+0x49d/0x6d3 kernel/printk/printk.c:2915     start_kernel+0x5e9/0x879 init/main.c:713 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241 ->     #0 (console_owner){....}-{0:0}: [...] lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734     console_trylock_spinning kernel/printk/printk.c:1773 ---truncated--- (CVE-2022-49441)

  - In the Linux kernel, the following vulnerability has been resolved: list: fix a data-race around     ep->rdllist ep_poll() first calls ep_events_available() with no lock held and checks if ep->rdllist is     empty by list_empty_careful(), which reads rdllist->prev. Thus all accesses to it need some protection to     avoid store/load-tearing. Note INIT_LIST_HEAD_RCU() already has the annotation for both prev and next.
    Commit bf3b9f6372c4 (epoll: Add busy poll support to epoll with socket fds.) added the first lockless     ep_events_available(), and commit c5a282e9635e (fs/epoll: reduce the scope of wq lock in epoll_wait())     made some ep_events_available() calls lockless and added single call under a lock, finally commit     e59d3c64cba6 (epoll: eliminate unnecessary lock for zero timeout) made the last ep_events_available()     lockless. BUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait write to 0xffff88810480c7d8 of 8 bytes by     task 1802 on cpu 0: INIT_LIST_HEAD include/linux/list.h:38 [inline] list_splice_init     include/linux/list.h:492 [inline] ep_start_scan fs/eventpoll.c:622 [inline] ep_send_events     fs/eventpoll.c:1656 [inline] ep_poll fs/eventpoll.c:1806 [inline] do_epoll_wait+0x4eb/0xf40     fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281     [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80     fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0     arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff88810480c7d8 of 8 bytes     by task 1799 on cpu 1: list_empty_careful include/linux/list.h:329 [inline] ep_events_available     fs/eventpoll.c:381 [inline] ep_poll fs/eventpoll.c:1797 [inline] do_epoll_wait+0x279/0xf40     fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281     [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80     fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0     arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0xffff88810480c7d0 ->     0xffff888103c15098 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 1799 Comm: syz-fuzzer Tainted:
    G W 5.17.0-rc7-syzkaller-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS     Google 01/01/2011 (CVE-2022-49443)

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

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

  - wifi: mac80211: don't WARN for connections on invalid channels It's not clear (to me) how exactly syzbot     managed to hit this, but it seems conceivable that e.g. regulatory changed and has disabled a channel     between scanning (channel is checked to be usable by cfg80211_get_ies_channel_number) and connecting on     the channel later. With one scenario that isn't covered elsewhere described above, the warning isn't good,     replace it with a (more informative) error message. (CVE-2025-71227)

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

ID	Name	Product	Family	Type	Severity
359694	Rocky Linux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1782155469)	Nessus	Rocky Linux Local Security Checks	Local	low
359640	AlmaLinux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1782155469)	Nessus	Alma Linux Local Security Checks	Local	low
352871	AlmaLinux 9.2 [TuxCare] Security Update: bpftool / kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1783791447)	Nessus	Alma Linux Local Security Checks	Local	low
299438	Linux Distros Unpatched Vulnerability : CVE-2025-71227	Nessus	Misc.	Local	medium

Detections

Analytics

CVE-2025-71227

medium

Tenable Plugins

low

low

low

medium