In the Linux kernel, the following vulnerability has been resolved: net: stmmac: xgmac2: disable RBUE in default RX interrupt mask Enabling the RX Buffer Unavailable (RBUE) interrupt is counterproductive and can trigger a MAC interrupt storm under heavy RX pressure. When the DMA runs out of RX descriptors it fires RBUE continuously until software refills the ring. However, RBUE is redundant: the normal RX completion interrupt (RIE) already triggers NAPI, which processes completed descriptors and refills the ring, causing the DMA to resume. The RBUE handler itself only sets handle_rx - the same outcome as RIE. On Agilex5 under heavy RX pressure, the MAC interrupt (which includes RBUE) was observed firing 1,821,811,555 times against only 2,618,627 actual RX completions - a ~695x ratio - confirming the severity of the storm. RBUE does not provide OOM recovery. If page_pool is exhausted, stmmac_rx_refill() cannot advance the DMA tail pointer, the DMA stays suspended, and RBUE fires again on the next NAPI completion - a storm with no forward progress. This patch trades that storm for a clean stall with the same RX outcome. Proper OOM recovery is a pre-existing gap outside the scope of this fix. Note: as a consequence of disabling RBUE, the rx_buf_unav_irq ethtool counter will always read 0 on XGMAC2 devices. This behaviour is already inconsistent across DWMAC core versions. Remove RBUE from XGMAC_DMA_INT_DEFAULT_EN and XGMAC_DMA_INT_DEFAULT_RX to prevent the interrupt storm while keeping normal RX handling intact.

The remote Ubuntu 22.04 LTS host has a package installed that is affected by multiple vulnerabilities as referenced in the USN-8962-1 advisory.

    Duoming Zhou discovered race conditions in the AX.25 amateur radio protocol implementation in the Linux     kernel, leading to use-after-free vulnerabilities. A local attacker could possibly use this to cause a     denial of service (system crash). (CVE-2022-1205)

    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:

    - USB Gadget drivers;

    - ARM32 architecture;

    - ARM64 architecture;

    - OpenRISC architecture;

    - PowerPC architecture;

    - RISC-V architecture;

    - S390 architecture;

    - x86 architecture;

    - Block layer subsystem;

    - Speakup Console Speech Driver;

    - ACPI drivers;

    - Serial ATA and Parallel ATA drivers;

    - Auxiliary display drivers;

    - Drivers core;

    - Bluetooth drivers;

    - Character device driver;

    - TPM device driver;

    - Clock framework and drivers;

    - Clocksource drivers;

    - CPU frequency scaling framework;

    - Hardware crypto device drivers;

    - DMA engine subsystem;

    - EDAC drivers;

    - Google firmware drivers;

    - FPGA Framework;

    - GPIO subsystem;

    - GPU drivers;

    - HID subsystem;

    - HSI subsystem;

    - Hardware monitoring drivers;

    - CoreSight HW tracing drivers;

    - I2C subsystem;

    - I3C subsystem;

    - IIO subsystem;

    - InfiniBand drivers;

    - On-Chip Interconnect management framework;

    - IOMMU subsystem;

    - IRQ chip drivers;

    - Multiple devices driver;

    - Media drivers;

    - Analog Devices digital potentiometer driver;

    - Broadcom VK accelerator driver;

    - Fastrpc Driver;

    - MMC subsystem;

    - MTD block device drivers;

    - Ethernet bonding driver;

    - Network drivers;

    - Mellanox network drivers;

    - STMicroelectronics network drivers;

    - MediaTek network drivers;

    - Near Field Communication (NFC) drivers;

    - NTB driver;

    - NVDIMM (Non-Volatile Memory Device) drivers;

    - NVME drivers;

    - Device tree and open firmware driver;

    - PA-RISC drivers;

    - PCI subsystem;

    - PHY drivers;

    - Pin controllers subsystem;

    - Chrome hardware platform drivers;

    - Mellanox platform drivers;

    - Microsoft Surface platform drivers;

    - x86 platform drivers;

    - Power supply drivers;

    - RapidIO drivers;

    - Voltage and Current Regulator drivers;

    - Remote Processor subsystem;

    - RPMSG subsystem;

    - Real Time Clock drivers;

    - S/390 drivers;

    - SCSI subsystem;

    - SPI subsystem;

    - small TFT LCD display modules;

    - Greybus lights staging drivers;

    - Media staging drivers;

    - Realtek RTL8723BS SDIO drivers;

    - TCM subsystem;

    - Thermal drivers;

    - Thunderbolt and USB4 drivers;

    - TTY drivers;

    - Userspace I/O drivers;

    - USB DSL drivers;

    - Cypress C67X00 USB driver;

    - USB core drivers;

    - USB Host Controller drivers;

    - Mustek MDC800 USB digital camera driver;

    - USB Serial drivers;

    - USB Mass Storage drivers;

    - USB Type-C Connector System Software Interface driver;

    - USB over IP driver;

    - vDPA drivers;

    - VFIO drivers;

    - Virtio Host (VHOST) subsystem;

    - Framebuffer layer;

    - W1 Dallas's 1-wire bus driver;

    - Watchdog drivers;

    - File systems infrastructure;

    - BFS file system;

    - BTRFS file system;

    - Ceph distributed file system;

    - eCrypt file system;

    - EROFS file system;

    - Ext4 file system;

    - F2FS file system;

    - FAT file system;

    - FUSE (File system in Userspace);

    - HFS+ file system;

    - HugeTLB file system;

    - JFS file system;

    - Network file system (NFS) client;

    - Network file system (NFS) server daemon;

    - NILFS2 file system;

    - File system notification infrastructure;

    - NTFS3 file system;

    - OCFS2 file system;

    - OrangeFS file system;

    - SMB network file system;

    - SquashFS file system;

    - UBI file system;

    - UDF file system;

    - XFS file system;

    - BPF subsystem;

    - IPv4 networking;

    - Internal shared memory driver;

    - Networking core;

    - Scheduler infrastructure;

    - Sun RPC protocol;

    - Virtio network driver;

    - Amateur Radio drivers;

    - IP tunnels definitions;

    - Network traffic control;

    - SCTP protocol;

    - TCP network protocol;

    - eXpress Data Path;

    - XFRM subsystem;

    - User-space API (UAPI);

    - io_uring subsystem;

    - Audit subsystem;

    - Perf events;

    - KCOV code coverage framework;

    - Locking primitives;

    - RCU subsystem;

    - Signal handling mechanism;

    - Timer subsystem;

    - Tracing infrastructure;

    - Kernel build system;

    - Heterogeneous memory management;

    - UCS-2 string library;

    - Memory management;

    - Appletalk network protocol;

    - B.A.T.M.A.N. meshing protocol;

    - Bluetooth subsystem;

    - Ethernet bridge;

    - CAN network layer;

    - Ceph Core library;

    - Distributed Switch Architecture;

    - HSR network protocol;

    - IEEE802154.4 network protocol;

    - IPv6 networking;

    - IUCV driver;

    - KCM (Kernel Connection Multiplexor) sockets driver;

    - MAC80211 subsystem;

    - MultiProtocol Label Switching driver;

    - Multipath TCP;

    - Netfilter;

    - NFC subsystem;

    - Open vSwitch;

    - Packet sockets;

    - Phonet protocol;

    - Qualcomm IPC Router (QRTR);

    - RDS protocol;

    - SMC sockets;

    - TIPC protocol;

    - VMware vSockets driver;

    - Wireless networking;

    - AppArmor security module;

    - Integrity Measurement Architecture(IMA) framework;

    - Landlock security;

    - SELinux security module;

    - Simplified Mandatory Access Control Kernel framework;

    - ALSA framework;

    - Generic PCM loopback sound driver;

    - Generic sound devices;

    - ESS ES18xx ALSA driver;

    - Digigram PCXHR ALSA driver;

    - Cirrus Logic audio codecs;

    - QCOM ASoC drivers;

    - Realtek audio codecs;

    - WCD audio codecs;

    - Amlogic Meson SoC drivers;

    - Rockchip ASoC drivers;

    - SoC audio core drivers;

    - Spreadtrum ASoC drivers;

    - STI ASoC drivers;

    - Xilinx ASoC drivers;

    - USB sound devices;

    - Perf tools; (CVE-2022-49234, CVE-2022-49359, CVE-2022-49562, CVE-2022-49651, CVE-2022-49858,     CVE-2022-50071, CVE-2022-50303, CVE-2022-50406, CVE-2023-52676, CVE-2023-53231, CVE-2023-53320,     CVE-2023-53707, CVE-2024-41062, CVE-2024-46754, CVE-2024-49568, CVE-2024-50017, CVE-2024-53187,     CVE-2024-53210, CVE-2024-53220, CVE-2024-54683, CVE-2024-57945, CVE-2024-57982, CVE-2024-57999,     CVE-2024-58094, CVE-2024-58095, CVE-2024-58096, CVE-2025-21649, CVE-2025-21651, CVE-2025-21759,     CVE-2025-21801, CVE-2025-21812, CVE-2025-21947, CVE-2025-22039, CVE-2025-22057, CVE-2025-22083,     CVE-2025-22103, CVE-2025-37861, CVE-2025-37920, CVE-2025-38069, CVE-2025-38097, CVE-2025-38239,     CVE-2025-38259, CVE-2025-38349, CVE-2025-38361, CVE-2025-38615, CVE-2025-38643, CVE-2025-39726,     CVE-2025-39779, CVE-2025-39810, CVE-2025-39925, CVE-2025-40102, CVE-2025-40123, CVE-2025-68190,     CVE-2025-68794, CVE-2026-23191, CVE-2026-31420, CVE-2026-43088, CVE-2026-43437, CVE-2026-43456,     CVE-2026-46113, CVE-2026-46158, CVE-2026-46170, CVE-2026-46242, CVE-2026-52944, CVE-2026-52988,     CVE-2026-53078, CVE-2026-53089, CVE-2026-64561, CVE-2026-64581, CVE-2026-68236, CVE-2026-68399,     CVE-2026-68476, CVE-2026-72323, CVE-2026-74268, CVE-2026-74378, CVE-2026-74496, CVE-2026-74582,     CVE-2026-74626, CVE-2026-74632, CVE-2026-74637, CVE-2026-74647, CVE-2026-74662, CVE-2026-74663,     CVE-2026-74666, CVE-2026-74668, CVE-2026-74743, CVE-2026-80536, CVE-2026-80547, CVE-2026-80548,     CVE-2026-80552, CVE-2026-80553, CVE-2026-80555, CVE-2026-80557, CVE-2026-80562, CVE-2026-80583,     CVE-2026-80587, CVE-2026-80590, CVE-2026-80671, CVE-2026-80689, CVE-2026-80737, CVE-2026-80765,     CVE-2026-80766, CVE-2026-80767, CVE-2026-80768, CVE-2026-80781, CVE-2026-80782, CVE-2026-80783,     CVE-2026-80788, CVE-2026-80789, CVE-2026-80790, CVE-2026-80792, CVE-2026-80793, CVE-2026-80794,     CVE-2026-80795, CVE-2026-80796, CVE-2026-80797, CVE-2026-80798, CVE-2026-80799, CVE-2026-80800,     CVE-2026-80801, CVE-2026-80802, CVE-2026-80803, CVE-2026-80805, CVE-2026-80806, CVE-2026-80807,     CVE-2026-80808, CVE-2026-80809, CVE-2026-80812, CVE-2026-80814, CVE-2026-80819, CVE-2026-80823,     CVE-2026-80824, CVE-2026-80826, CVE-2026-80827, CVE-2026-80828, CVE-2026-80829, CVE-2026-80830,     CVE-2026-80831, CVE-2026-80832, CVE-2026-80833, CVE-2026-80834, CVE-2026-80840, CVE-2026-80842,     CVE-2026-80843, CVE-2026-80844, CVE-2026-80846, CVE-2026-80848, CVE-2026-80854, CVE-2026-80855,     CVE-2026-80856, CVE-2026-80863, CVE-2026-80888, CVE-2026-80912, CVE-2026-80916, CVE-2026-80917,     CVE-2026-80918, CVE-2026-80921, CVE-2026-80923, CVE-2026-80928, CVE-2026-80930, CVE-2026-80931,     CVE-2026-80932, CVE-2026-80938, CVE-2026-80941, CVE-2026-80944, CVE-2026-80949, CVE-2026-80951,     CVE-2026-80952, CVE-2026-80963, CVE-2026-80964, CVE-2026-80965, CVE-2026-80966, CVE-2026-80967,     CVE-2026-80968, CVE-2026-80969, CVE-2026-80971, CVE-2026-80972, CVE-2026-80973, CVE-2026-80976,     CVE-2026-80977, CVE-2026-80978, CVE-2026-80983, CVE-2026-80987, CVE-2026-80988, CVE-2026-80994,     CVE-2026-81000, CVE-2026-81001, CVE-2026-81002, CVE-2026-81003, CVE-2026-81005, CVE-2026-81007,     CVE-2026-81008, CVE-2026-81017, CVE-2026-89440, CVE-2026-89444, CVE-2026-89456, CVE-2026-89457,     CVE-2026-89458, CVE-2026-89461, CVE-2026-89463, CVE-2026-89464, CVE-2026-89469, CVE-2026-89470,     CVE-2026-89471, CVE-2026-89474, CVE-2026-89475, CVE-2026-89476, CVE-2026-89477, CVE-2026-89478,     CVE-2026-89479, CVE-2026-89480, CVE-2026-89482, CVE-2026-89483, CVE-2026-89485, CVE-2026-89487,     CVE-2026-89488, CVE-2026-89489, CVE-2026-89490, CVE-2026-89491, CVE-2026-89493, CVE-2026-89494,     CVE-2026-89495, CVE-2026-89496, CVE-2026-89497, CVE-2026-89498, CVE-2026-89504, CVE-2026-89508,     CVE-2026-89510, CVE-2026-89511, CVE-2026-89512, CVE-2026-89515, CVE-2026-89524, CVE-2026-89525,     CVE-2026-89532, CVE-2026-89533, CVE-2026-89538, CVE-2026-89540, CVE-2026-89541, CVE-2026-89542,     CVE-2026-89548, CVE-2026-89549, CVE-2026-89551, CVE-2026-89554, CVE-2026-89555, CVE-2026-89557,     CVE-2026-89559, CVE-2026-89560, CVE-2026-89562, CVE-2026-89563, CVE-2026-89569, CVE-2026-89573,     CVE-2026-89575, CVE-2026-89576, CVE-2026-89582, CVE-2026-89585, CVE-2026-89586, CVE-2026-89594,     CVE-2026-89595, CVE-2026-89596, CVE-2026-89597, CVE-2026-89599, CVE-2026-89605, CVE-2026-89606,     CVE-2026-89607, CVE-2026-89608, CVE-2026-89609, CVE-2026-89615, CVE-2026-89616, CVE-2026-89617,     CVE-2026-89621, CVE-2026-89626, CVE-2026-89627, CVE-2026-89628, CVE-2026-89643, CVE-2026-89649,     CVE-2026-89650, CVE-2026-89653, CVE-2026-89655, CVE-2026-89656, CVE-2026-89662, CVE-2026-89663,     CVE-2026-89665, CVE-2026-89669, CVE-2026-89673, CVE-2026-89674, CVE-2026-89684, CVE-2026-89694,     CVE-2026-89696, CVE-2026-89697, CVE-2026-89699, CVE-2026-89704, CVE-2026-89706, CVE-2026-89710,     CVE-2026-89711, CVE-2026-89712, CVE-2026-89720, CVE-2026-89723, CVE-2026-89724, CVE-2026-89725,     CVE-2026-89726, CVE-2026-89729, CVE-2026-89730, CVE-2026-89732, CVE-2026-89733, CVE-2026-89736,     CVE-2026-89741, CVE-2026-89742, CVE-2026-89749, CVE-2026-89752, CVE-2026-89753, CVE-2026-89765,     CVE-2026-89777, CVE-2026-89778, CVE-2026-89779, CVE-2026-89780, CVE-2026-89781, CVE-2026-89782,     CVE-2026-89783, CVE-2026-89784, CVE-2026-89785, CVE-2026-89786, CVE-2026-89787, CVE-2026-89789,     CVE-2026-89792, CVE-2026-89796, CVE-2026-89816, CVE-2026-89817, CVE-2026-89821, CVE-2026-89823,     CVE-2026-89843, CVE-2026-89845, CVE-2026-89846, CVE-2026-89847, CVE-2026-89849, CVE-2026-89850,     CVE-2026-89851, CVE-2026-89852, CVE-2026-89853, CVE-2026-89854, CVE-2026-89855, CVE-2026-89856,     CVE-2026-89858, CVE-2026-89861, CVE-2026-89863, CVE-2026-89864, CVE-2026-89865, CVE-2026-89871,     CVE-2026-89872, CVE-2026-89876, CVE-2026-89878, CVE-2026-89879, CVE-2026-89880, CVE-2026-89881,     CVE-2026-89883, CVE-2026-89887, CVE-2026-89888, CVE-2026-89890, CVE-2026-89891, CVE-2026-89892,     CVE-2026-89893, CVE-2026-89894, CVE-2026-89895, CVE-2026-89896, CVE-2026-89897, CVE-2026-89901,     CVE-2026-89923, CVE-2026-89924, CVE-2026-89925, CVE-2026-89926, CVE-2026-89927, CVE-2026-89930,     CVE-2026-89932, CVE-2026-89936, CVE-2026-89937, CVE-2026-89939, CVE-2026-89945, CVE-2026-89946,     CVE-2026-89947, CVE-2026-89948, CVE-2026-89949, CVE-2026-89951, CVE-2026-89952, CVE-2026-89953,     CVE-2026-89954, CVE-2026-89964, CVE-2026-89965, CVE-2026-89968, CVE-2026-89969, CVE-2026-89973,     CVE-2026-89979, CVE-2026-89982, CVE-2026-89983, CVE-2026-89984, CVE-2026-89989, CVE-2026-89993,     CVE-2026-89997, CVE-2026-89999, CVE-2026-90000, CVE-2026-90007, CVE-2026-90011, CVE-2026-90015,     CVE-2026-90017, CVE-2026-90018, CVE-2026-90019, CVE-2026-90020, CVE-2026-90025, CVE-2026-90031,     CVE-2026-90032, CVE-2026-90033, CVE-2026-90034, CVE-2026-90049, CVE-2026-90053, CVE-2026-90054,     CVE-2026-90055, CVE-2026-90056, CVE-2026-90058, CVE-2026-90062, CVE-2026-90063, CVE-2026-90067,     CVE-2026-90068, CVE-2026-90070, CVE-2026-90071, CVE-2026-90072, CVE-2026-90073, CVE-2026-90074,     CVE-2026-90075, CVE-2026-90078, CVE-2026-90081, CVE-2026-90088, CVE-2026-90102, CVE-2026-90103,     CVE-2026-90107, CVE-2026-90114, CVE-2026-90126, CVE-2026-90128, CVE-2026-90140, CVE-2026-90141,     CVE-2026-90143, CVE-2026-90151, CVE-2026-90157, CVE-2026-90160, CVE-2026-90198, CVE-2026-90202,     CVE-2026-90203, CVE-2026-90209, CVE-2026-90214, CVE-2026-90216, CVE-2026-90218, CVE-2026-90219,     CVE-2026-90221, CVE-2026-90222, CVE-2026-90223, CVE-2026-90224, CVE-2026-90225, CVE-2026-90226,     CVE-2026-90228, CVE-2026-90245, CVE-2026-90248, CVE-2026-90249, CVE-2026-90251, CVE-2026-90257,     CVE-2026-90274, CVE-2026-90281, CVE-2026-90283, CVE-2026-90284, CVE-2026-90285, CVE-2026-90286,     CVE-2026-90290, CVE-2026-90292, CVE-2026-90293, CVE-2026-90294, CVE-2026-90295, CVE-2026-90296,     CVE-2026-90297, CVE-2026-90298, CVE-2026-90302, CVE-2026-90303, CVE-2026-90307, CVE-2026-90314,     CVE-2026-90316, CVE-2026-90318, CVE-2026-90319, CVE-2026-90327, CVE-2026-90329, CVE-2026-90334,     CVE-2026-90341, CVE-2026-90348, CVE-2026-90360, CVE-2026-90361, CVE-2026-90362, CVE-2026-90372,     CVE-2026-90378, CVE-2026-90382, CVE-2026-90386, CVE-2026-90388, CVE-2026-90391, CVE-2026-90393,     CVE-2026-90394, CVE-2026-90395, CVE-2026-90403, CVE-2026-90411, CVE-2026-90413, CVE-2026-90414,     CVE-2026-90415, CVE-2026-90416, CVE-2026-90419, CVE-2026-90420, CVE-2026-90431, CVE-2026-90434,     CVE-2026-90435, CVE-2026-92476, CVE-2026-92494, CVE-2026-92496, CVE-2026-92498, CVE-2026-92501,     CVE-2026-92504, CVE-2026-92508, CVE-2026-92521, CVE-2026-92522, CVE-2026-92524, CVE-2026-93037,     CVE-2026-93039, CVE-2026-93040, CVE-2026-93041, CVE-2026-93046, CVE-2026-93048, CVE-2026-93049,     CVE-2026-93051, CVE-2026-93052, CVE-2026-93053, CVE-2026-93054, CVE-2026-93055, CVE-2026-93056,     CVE-2026-93061, CVE-2026-93067, CVE-2026-93095, CVE-2026-93098, CVE-2026-93102, CVE-2026-93103,     CVE-2026-93108, CVE-2026-93109, CVE-2026-93110, CVE-2026-93114, CVE-2026-93115, CVE-2026-93120,     CVE-2026-93130, CVE-2026-93131, CVE-2026-93138, CVE-2026-93140, CVE-2026-93141, CVE-2026-93145,     CVE-2026-93151, CVE-2026-93158, CVE-2026-93159, CVE-2026-93160, CVE-2026-93161, CVE-2026-93165,     CVE-2026-93167, CVE-2026-93170, CVE-2026-93177, CVE-2026-93178, CVE-2026-93183, CVE-2026-93185,     CVE-2026-93188, CVE-2026-93189, CVE-2026-93191, CVE-2026-93203, CVE-2026-93204, CVE-2026-93206,     CVE-2026-93213, CVE-2026-93214, CVE-2026-93219, CVE-2026-93222, CVE-2026-93226, CVE-2026-93234,     CVE-2026-93236, CVE-2026-93242, CVE-2026-93245, CVE-2026-93252, CVE-2026-93256, CVE-2026-93261,     CVE-2026-93262, CVE-2026-93264, CVE-2026-93268, CVE-2026-93271, CVE-2026-93274, CVE-2026-93280,     CVE-2026-93283, CVE-2026-93286, CVE-2026-93287, CVE-2026-93288, CVE-2026-93782, CVE-2026-93783,     CVE-2026-93784, CVE-2026-93785, CVE-2026-93789, CVE-2026-93795, CVE-2026-93797, CVE-2026-93798,     CVE-2026-93800, CVE-2026-93802, CVE-2026-93803, CVE-2026-93805, CVE-2026-93807, CVE-2026-93808,     CVE-2026-93811, CVE-2026-93812, CVE-2026-93813, CVE-2026-93815, CVE-2026-93816, CVE-2026-93819,     CVE-2026-93820, CVE-2026-93821, CVE-2026-93822, CVE-2026-93825, CVE-2026-93830, CVE-2026-97407,     CVE-2026-97408, CVE-2026-97411, CVE-2026-97413, CVE-2026-97416, CVE-2026-97417, CVE-2026-97418,     CVE-2026-97419, CVE-2026-97420, CVE-2026-97421, CVE-2026-97430, CVE-2026-97434, CVE-2026-97435,     CVE-2026-97436, CVE-2026-97437, CVE-2026-97438, CVE-2026-97439, CVE-2026-97440, CVE-2026-97441,     CVE-2026-97443, CVE-2026-97444, CVE-2026-97445, CVE-2026-97446, CVE-2026-97448, CVE-2026-97449,     CVE-2026-97450, CVE-2026-97451, CVE-2026-97452, CVE-2026-97453, CVE-2026-97454, CVE-2026-97455,     CVE-2026-97456, CVE-2026-97472, CVE-2026-97475, CVE-2026-97476, CVE-2026-97481, CVE-2026-97482,     CVE-2026-97483, CVE-2026-97484, CVE-2026-97485, CVE-2026-97486, CVE-2026-97487, CVE-2026-97488,     CVE-2026-97489, CVE-2026-97490, CVE-2026-97491, CVE-2026-97492, CVE-2026-97502, CVE-2026-97506,     CVE-2026-97507, CVE-2026-97508, CVE-2026-97510, CVE-2026-97523, CVE-2026-97524, CVE-2026-97568,     CVE-2026-97572, CVE-2026-97573, CVE-2026-97576, CVE-2026-97582, CVE-2026-97592, CVE-2026-97596,     CVE-2026-97598, CVE-2026-97601, CVE-2026-97604, CVE-2026-97608, CVE-2026-97611, CVE-2026-97612,     CVE-2026-97899, CVE-2026-97904, CVE-2026-97905, CVE-2026-97909, CVE-2026-97910, CVE-2026-97923,     CVE-2026-97926, CVE-2026-97927, CVE-2026-97930, CVE-2026-97931, CVE-2026-97940, CVE-2026-97948,     CVE-2026-97951, CVE-2026-97954, CVE-2026-97957, CVE-2026-97958, CVE-2026-97959, CVE-2026-97963,     CVE-2026-97964, CVE-2026-97969, CVE-2026-97970, CVE-2026-97981, CVE-2026-97982, CVE-2026-97991,     CVE-2026-97993, CVE-2026-97995, CVE-2026-97998, CVE-2026-98006, CVE-2026-98009, CVE-2026-98010,     CVE-2026-98011, CVE-2026-98012, CVE-2026-98013, CVE-2026-98014, CVE-2026-98015, CVE-2026-98016,     CVE-2026-98022, CVE-2026-98023, CVE-2026-98025, CVE-2026-98027, CVE-2026-98030, CVE-2026-98031,     CVE-2026-98063, CVE-2026-98064, CVE-2026-98066, CVE-2026-98068, CVE-2026-98069, CVE-2026-98070,     CVE-2026-98071, CVE-2026-98072, CVE-2026-98074, CVE-2026-98075, CVE-2026-98076, CVE-2026-98077,     CVE-2026-98078, CVE-2026-98080, CVE-2026-98088, CVE-2026-98090, CVE-2026-98091, CVE-2026-98094,     CVE-2026-98095, CVE-2026-98096, CVE-2026-98098, CVE-2026-98108, CVE-2026-98113, CVE-2026-98116,     CVE-2026-98121, CVE-2026-98123, CVE-2026-98130, CVE-2026-98154, CVE-2026-98157, CVE-2026-98158)

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.

An update of the linux package has been released.

The CentOS Linux 8 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS-STREAM8:CLSA-2026:1793362651 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: gfs2: fix use-after-free in     gfs2_qd_dealloc gfs2_qd_dealloc(), called as an RCU callback from gfs2_qd_dispose(), accesses the     superblock object sdp through qd->qd_sbd after freeing qd. It does so to decrement sd_quota_count and wake     up sd_kill_wait. However, by the time the RCU callback runs, gfs2_put_super() may have already freed sdp     via free_sbd(). This can happen when gfs2_quota_cleanup() is called during unmount: it disposes of quota     objects via call_rcu() and then waits on sd_kill_wait with a 60-second timeout. If the timeout expires, or     if gfs2_gl_hash_clear() triggers additional qd_put() calls that schedule more RCU callbacks after the wait     completes, gfs2_put_super() will proceed to free the superblock while RCU callbacks referencing it are     still pending. Add an rcu_barrier() before free_sbd() in gfs2_put_super() to ensure all pending RCU     callbacks (including gfs2_qd_dealloc) have completed before the superblock is freed. (CVE-2026-63804)

  - In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: Validate SVID index     in svdm_consume_modes() In svdm_consume_modes(), the SVID value is read from pmdata->svids using     pmdata->svid_index as an array index without bounds validation: paltmode->svid =     pmdata->svids[pmdata->svid_index]; If pmdata->svid_index is driven beyond SVID_DISCOVERY_MAX (16), it     results in an out-of-bounds read of the pmdata->svids array. Because pd_mode_data is embedded inside     struct tcpm_port, indexing past svids reads into adjacent fields. In particular: - At index 16, it reads     the altmodes count. - At index 18 and beyond, it reads into altmode_desc[], which contains partner-     supplied SVDM Discovery Modes VDOs. By injecting a chosen SVID into altmode_desc[0].vdo and driving     svid_index to 20, the partner can force paltmode->svid to be loaded with an arbitrary, partner- chosen     SVID, which is then registered via typec_partner_register_altmode(). Fix this by validating that     pmdata->svid_index is non-negative and strictly less than pmdata->nsvids before accessing the     pmdata->svids array inside svdm_consume_modes(). (CVE-2026-64330)

  - In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: hold event_mutex while     checkpointing CRIU events kfd_criu_checkpoint_events() counts the entries in p->event_idr via     kfd_get_num_events(), allocates an array sized to that count, and then walks the same IDR to fill it.
    Neither the count nor the walk holds p->event_mutex. The CRIU checkpoint caller holds only p->mutex. Event     create and destroy (kfd_event_create()/kfd_event_destroy()) take p->event_mutex and do not take p->mutex,     so a second thread in the same process can insert or remove events between the count and the walk. If an     event is inserted, the walk iterates more entries than were counted and writes past the end of the     ev_privs allocation; if an event is removed, the walk dereferences an entry that is being freed. Hold     p->event_mutex across the count and the walk so both observe a consistent view of p->event_idr. The lock     is released before copy_to_user(), which only touches the local buffer. The caller already holds p->mutex     and the create/destroy paths never take p->mutex, so the p->mutex -> p->event_mutex order is not inverted     and no deadlock is introduced. (cherry picked from commit ff57e223ab105795b05d3ef3f3c35a5a441bcbaa)     (CVE-2026-74446)

  - In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix potential UAF on     meter attach failure While attaching a newly created meter attach_meter() function makes the new meter     visible to other CPUs but can still fail afterwards. On failure, it detaches the meter back and returns an     error. However, this is an unexpected behavior for the ovs_meter_cmd_set() that uses a plain kfree(meter)     on attach failure without waiting for RCU readers to stop using it, assuming it was never visible. This is     never a problem for ovs-vswitchd as it always creates meters before creating any flows that use them. But     the UAF can be triggered with a custom application using uAPI: BUG: KASAN: slab-use-after-free in     ovs_meter_execute (net/openvswitch/meter.c:653) Read of size 8 at addr ffff88810d152650 by task meter/2508     Call Trace: ovs_meter_execute (net/openvswitch/meter.c:653) do_execute_actions     (net/openvswitch/actions.c:1407) ovs_execute_actions (net/openvswitch/actions.c:1584)     ovs_packet_cmd_execute (net/openvswitch/datapath.c:703) ... netlink_sendmsg (af_netlink.c:1900) Allocated     by task 2519: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) ovs_meter_cmd_set     (net/openvswitch/meter.c:422) ... netlink_sendmsg (af_netlink.c:1900) Freed by task 2519: kfree     (mm/slub.c:2705 mm/slub.c:6405 mm/slub.c:6720) ovs_meter_cmd_set (net/openvswitch/meter.c:479) ...
    netlink_sendmsg (af_netlink.c:1900) Fix that by making sure attach_meter() doesn't make the meter visible     until all the checks are done and the function can't fail anymore. This also makes sure the hash value     is calculated after the potential re-sizing of the table. Reported by Trend Micro's Zero Day Initiative as     ZDI-CAN-31642. (CVE-2026-74465)

  - In the Linux kernel, the following vulnerability has been resolved: mm/page_reporting: use     system_freezable_wq to fix UAF during suspend During PM freeze (e.g. S3 suspend or S4 hibernation), device     drivers like virtio_balloon reset their underlying virtio devices and delete their virtqueues via     vdev->config->del_vqs(). However, page reporting work (page_reporting_process) was scheduled on the global     system_wq. Because system_wq lacks the WQ_FREEZABLE flag, the PM freezer skips it, leaving     page_reporting_process active during suspend. If pages are freed into the buddy allocator while suspending     (for example, when core MM invokes the balloon shrinker during S4 hibernation image saving), page     reporting triggers virtballoon_free_page_report() on deleted virtqueues, resulting in a Use-After-Free /     General Protection Fault: [ 196.795226] general protection fault, probably for non-canonical address     0xaa1436fe70dae6df: 0000 [#1] SMP NOPTI [ 196.825967] Workqueue: events page_reporting_process [     196.831038] RIP: 0010:virtqueue_add_split+0x233/0x4c0 [virtio_ring] [ 196.927073]     virtballoon_free_page_report+0x3a/0xe0 [virtio_balloon] [ 196.946943] page_reporting_process+0x370/0x4f0     Fix this by switching page reporting work to system_freezable_wq. This ensures that the PM freezer pauses     page_reporting_process before device drivers destroy their reporting virtqueues. Because the reporting     worker is frozen, memory reclamation/freeing (e.g. via shrinker execution) can safely return pages to MM     during freeze without triggering unfrozen reporting work on deleted virtqueues. This aligns with the     driver's existing design. The comment in virtballoon_freeze() states: /* * The workqueue is already frozen     by the PM core before this * function is called. */ Testing: I have verified these fixes using Google's     virtualization infrastructure by running continuous suspend/resume iterations (40+ cycles) while churning     memory using stress-ng (`stress-ng --vm 4 --vm-bytes 60% --timeout 1`) to constantly create free pages for     the buddy allocator. We also set the `page_reporting_order` parameter to 0 to make the page reporting     worker highly sensitive, forcing it to pick up any 4K free pages. This confirmed that the UAF crashes are     no longer reproducible. (CVE-2026-74481)

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

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2026-146825 advisory.

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

    net: stmmac: xgmac2: disable RBUE in default RX interrupt mask

    Enabling the RX Buffer Unavailable (RBUE) interrupt is counterproductive     and can trigger a MAC interrupt storm under heavy RX pressure. When the     DMA runs out of RX descriptors it fires RBUE continuously until software     refills the ring.

    However, RBUE is redundant: the normal RX completion interrupt (RIE)     already triggers NAPI, which processes completed descriptors and refills     the ring, causing the DMA to resume. The RBUE handler itself only sets     handle_rx - the same outcome as RIE.

    On Agilex5 under heavy RX pressure, the MAC interrupt (which includes     RBUE) was observed firing 1,821,811,555 times against only 2,618,627     actual RX completions - a ~695x ratio - confirming the severity of the     storm.

    RBUE does not provide OOM recovery. If page_pool is exhausted,     stmmac_rx_refill() cannot advance the DMA tail pointer, the DMA stays     suspended, and RBUE fires again on the next NAPI completion - a storm     with no forward progress. This patch trades that storm for a clean     stall with the same RX outcome. Proper OOM recovery is a pre-existing     gap outside the scope of this fix.

    Note: as a consequence of disabling RBUE, the rx_buf_unav_irq ethtool     counter will always read 0 on XGMAC2 devices. This behaviour is already     inconsistent across DWMAC core versions.

    Remove RBUE from XGMAC_DMA_INT_DEFAULT_EN and XGMAC_DMA_INT_DEFAULT_RX     to prevent the interrupt storm while keeping normal RX handling intact.

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

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

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

  - In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Synchronous access b/w     reset and tm thread for reply queue When the task management thread processes reply queues while the reset     thread resets them, the task management thread accesses an invalid queue ID (0xFFFF), set by the reset     thread, which points to unallocated memory, causing a crash. Add flag 'io_admin_reset_sync' to synchronize     access between the reset, I/O, and admin threads. Before a reset, the reset handler sets this flag to     block I/O and admin processing threads. If any thread bypasses the initial check, the reset thread waits     up to 10 seconds for processing to finish. If the wait exceeds 10 seconds, the controller is marked as     unrecoverable. (CVE-2025-37861)

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: cancel mesh send     timer when hdev removed mesh_send_done timer is not canceled when hdev is removed, which causes crash if     the timer triggers after hdev is gone. Cancel the timer when MGMT removes the hdev, like other MGMT     timers. Should fix the BUG: sporadically seen by BlueZ test bot (in Mesh - Send cancel - 1 test). Log:
    ------ BUG: KASAN: slab-use-after-free in run_timer_softirq+0x76b/0x7d0 ... Freed by task 36:
    kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3a/0x60
    __kasan_slab_free+0x43/0x70 kfree+0x103/0x500 device_release+0x9a/0x210 kobject_put+0x100/0x1e0     vhci_release+0x18b/0x240 ------ (CVE-2025-40284)

  - In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: avs: Disable periods-     elapsed work when closing PCM avs_dai_fe_shutdown() handles the shutdown procedure for HOST HDAudio stream     while period-elapsed work services its IRQs. As the former frees the DAI's private context, these two     operations shall be synchronized to avoid slab-use-after-free or worse errors. (CVE-2025-40344)

  - In the Linux kernel, the following vulnerability has been resolved: ipv6: icmp: clear skb2->cb[] in     ip6_err_gen_icmpv6_unreach() Sashiko AI-review observed: In ip6_err_gen_icmpv6_unreach(), the skb is an     outer IPv4 ICMP error packet where its cb contains an IPv4 inet_skb_parm. When skb is cloned into skb2 and     passed to icmp6_send(), it uses IP6CB(skb2). IP6CB interprets the IPv4 inet_skb_parm as an inet6_skb_parm.
    The cipso offset in inet_skb_parm.opt directly overlaps with dsthao in inet6_skb_parm at offset 18. If an     attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao would be a non-zero offset. Inside     icmp6_send(), mip6_addr_swap() is called and uses ipv6_find_tlv(skb, opt->dsthao, IPV6_TLV_HAO). This     would scan the inner, attacker-controlled IPv6 packet starting at that offset, potentially returning a     fake TLV without checking if the remaining packet length can hold the full 18-byte struct     ipv6_destopt_hao. Could mip6_addr_swap() then perform a 16-byte swap that extends past the end of the     packet data into skb_shared_info? Should the cb array also be cleared in ip6_err_gen_icmpv6_unreach() and     ip6ip6_err() to prevent this? This patch implements the first suggestion. I am not sure if ip6ip6_err()     needs to be changed. A separate patch would be better anyway. (CVE-2026-43038)

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix double free in     rxe_srq_from_init In rxe_srq_from_init(), the queue pointer 'q' is assigned to 'srq->rq.queue' before     copying the SRQ number to user space. If copy_to_user() fails, the function calls rxe_queue_cleanup() to     free the queue, but leaves the now-invalid pointer in 'srq->rq.queue'. The caller of rxe_srq_from_init()     (rxe_create_srq) eventually calls rxe_srq_cleanup() upon receiving the error, which triggers a second     rxe_queue_cleanup() on the same memory, leading to a double free. The call trace looks like this:
    kmem_cache_free+0x.../0x... rxe_queue_cleanup+0x1a/0x30 [rdma_rxe] rxe_srq_cleanup+0x42/0x60 [rdma_rxe]     rxe_elem_release+0x31/0x70 [rdma_rxe] rxe_create_srq+0x12b/0x1a0 [rdma_rxe] ib_create_srq_user+0x9a/0x150     [ib_core] Fix this by moving 'srq->rq.queue = q' after copy_to_user. (CVE-2026-45852)

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

  - In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Synchronous access b/w     reset and tm thread for reply queue When the task management thread processes reply queues while the reset     thread resets them, the task management thread accesses an invalid queue ID (0xFFFF), set by the reset     thread, which points to unallocated memory, causing a crash. Add flag 'io_admin_reset_sync' to synchronize     access between the reset, I/O, and admin threads. Before a reset, the reset handler sets this flag to     block I/O and admin processing threads. If any thread bypasses the initial check, the reset thread waits     up to 10 seconds for processing to finish. If the wait exceeds 10 seconds, the controller is marked as     unrecoverable. (CVE-2025-37861)

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: cancel mesh send     timer when hdev removed mesh_send_done timer is not canceled when hdev is removed, which causes crash if     the timer triggers after hdev is gone. Cancel the timer when MGMT removes the hdev, like other MGMT     timers. Should fix the BUG: sporadically seen by BlueZ test bot (in Mesh - Send cancel - 1 test). Log:
    ------ BUG: KASAN: slab-use-after-free in run_timer_softirq+0x76b/0x7d0 ... Freed by task 36:
    kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3a/0x60
    __kasan_slab_free+0x43/0x70 kfree+0x103/0x500 device_release+0x9a/0x210 kobject_put+0x100/0x1e0     vhci_release+0x18b/0x240 ------ (CVE-2025-40284)

  - In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: avs: Disable periods-     elapsed work when closing PCM avs_dai_fe_shutdown() handles the shutdown procedure for HOST HDAudio stream     while period-elapsed work services its IRQs. As the former frees the DAI's private context, these two     operations shall be synchronized to avoid slab-use-after-free or worse errors. (CVE-2025-40344)

  - In the Linux kernel, the following vulnerability has been resolved: ipv6: icmp: clear skb2->cb[] in     ip6_err_gen_icmpv6_unreach() Sashiko AI-review observed: In ip6_err_gen_icmpv6_unreach(), the skb is an     outer IPv4 ICMP error packet where its cb contains an IPv4 inet_skb_parm. When skb is cloned into skb2 and     passed to icmp6_send(), it uses IP6CB(skb2). IP6CB interprets the IPv4 inet_skb_parm as an inet6_skb_parm.
    The cipso offset in inet_skb_parm.opt directly overlaps with dsthao in inet6_skb_parm at offset 18. If an     attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao would be a non-zero offset. Inside     icmp6_send(), mip6_addr_swap() is called and uses ipv6_find_tlv(skb, opt->dsthao, IPV6_TLV_HAO). This     would scan the inner, attacker-controlled IPv6 packet starting at that offset, potentially returning a     fake TLV without checking if the remaining packet length can hold the full 18-byte struct     ipv6_destopt_hao. Could mip6_addr_swap() then perform a 16-byte swap that extends past the end of the     packet data into skb_shared_info? Should the cb array also be cleared in ip6_err_gen_icmpv6_unreach() and     ip6ip6_err() to prevent this? This patch implements the first suggestion. I am not sure if ip6ip6_err()     needs to be changed. A separate patch would be better anyway. (CVE-2026-43038)

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix double free in     rxe_srq_from_init In rxe_srq_from_init(), the queue pointer 'q' is assigned to 'srq->rq.queue' before     copying the SRQ number to user space. If copy_to_user() fails, the function calls rxe_queue_cleanup() to     free the queue, but leaves the now-invalid pointer in 'srq->rq.queue'. The caller of rxe_srq_from_init()     (rxe_create_srq) eventually calls rxe_srq_cleanup() upon receiving the error, which triggers a second     rxe_queue_cleanup() on the same memory, leading to a double free. The call trace looks like this:
    kmem_cache_free+0x.../0x... rxe_queue_cleanup+0x1a/0x30 [rdma_rxe] rxe_srq_cleanup+0x42/0x60 [rdma_rxe]     rxe_elem_release+0x31/0x70 [rdma_rxe] rxe_create_srq+0x12b/0x1a0 [rdma_rxe] ib_create_srq_user+0x9a/0x150     [ib_core] Fix this by moving 'srq->rq.queue = q' after copy_to_user. (CVE-2026-45852)

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

  - In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix signed integer overflow in     l2tp_ip6_sendmsg When len >= INT_MAX - transhdrlen, ulen = len + transhdrlen will be overflow. To fix, we     can follow what udpv6 does and subtract the transhdrlen from the max. (CVE-2022-49727)

  - In the Linux kernel, the following vulnerability has been resolved: bpf: Fix accesses to uninit stack     slots Privileged programs are supposed to be able to read uninitialized stack memory (ever since     6715df8d5) but, before this patch, these accesses were permitted inconsistently. In particular, accesses     were permitted above state->allocated_stack, but not below it. In other words, if the stack was already     large enough, the access was permitted, but otherwise the access was rejected instead of being allowed     to grow the stack. This undesired rejection was happening in two places: - in     check_stack_slot_within_bounds() - in check_stack_range_initialized() This patch arranges for these     accesses to be permitted. A bunch of tests that were relying on the old rejection had to change; all of     them were changed to add also run unprivileged, in which case the old behavior persists. One tests     couldn't be updated - global_func16 - because it can't run unprivileged for other reasons. This patch also     fixes the tracking of the stack size for variable-offset reads. This second fix is bundled in the same     commit as the first one because they're inter-related. Before this patch, writes to the stack using     registers containing a variable offset (as opposed to registers with fixed, known values) were not     properly contributing to the function's needed stack size. As a result, it was possible for a program to     verify, but then to attempt to read out-of-bounds data at runtime because a too small stack had been     allocated for it. Each function tracks the size of the stack it needs in bpf_subprog_info.stack_depth,     which is maintained by update_stack_depth(). For regular memory accesses, check_mem_access() was calling     update_state_depth() but it was passing in only the fixed part of the offset register, ignoring the     variable offset. This was incorrect; the minimum possible value of that register should be used instead.
    This tracking is now fixed by centralizing the tracking of stack size in grow_stack_state(), and by     lifting the calls to grow_stack_state() to check_stack_access_within_bounds() as suggested by Andrii. The     code is now simpler and more convincingly tracks the correct maximum stack size.
    check_stack_range_initialized() can now rely on enough stack having been allocated for the access; this     helps with the fix for the first issue. A few tests were changed to also check the stack depth     computation. The one that fails without this patch is verifier_var_off:stack_write_priv_vs_unpriv.
    (CVE-2023-52452)

  - In the Linux kernel, the following vulnerability has been resolved: qed/qed_sriov: guard against NULL     derefs from qed_iov_get_vf_info We have to make sure that the info returned by the helper is valid before     using it. Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.
    (CVE-2023-53066)

  - In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Fix a server shutdown leak Fix     a race where kthread_stop() may prevent the threadfn from ever getting called. If that happens the     svc_rqst will not be cleaned up. (CVE-2023-53131)

  - In the Linux kernel, the following vulnerability has been resolved: pstore/ram: Add check for kstrdup Add     check for the return value of kstrdup() and return the error if it fails in order to avoid NULL pointer     dereference. (CVE-2023-54189)

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.

  - net: stmmac: xgmac2: disable RBUE in default RX interrupt mask Enabling the RX Buffer Unavailable (RBUE)     interrupt is counterproductive and can trigger a MAC interrupt storm under heavy RX pressure. When the DMA     runs out of RX descriptors it fires RBUE continuously until software refills the ring. However, RBUE is     redundant: the normal RX completion interrupt (RIE) already triggers NAPI, which processes completed     descriptors and refills the ring, causing the DMA to resume. The RBUE handler itself only sets handle_rx -     the same outcome as RIE. On Agilex5 under heavy RX pressure, the MAC interrupt (which includes RBUE) was     observed firing 1,821,811,555 times against only 2,618,627 actual RX completions - a ~695x ratio -     confirming the severity of the storm. RBUE does not provide OOM recovery. If page_pool is exhausted,     stmmac_rx_refill() cannot advance the DMA tail pointer, the DMA stays suspended, and RBUE fires again on     the next NAPI completion - a storm with no forward progress. This patch trades that storm for a clean     stall with the same RX outcome. Proper OOM recovery is a pre-existing gap outside the scope of this fix.
    Note: as a consequence of disabling RBUE, the rx_buf_unav_irq ethtool counter will always read 0 on XGMAC2     devices. This behaviour is already inconsistent across DWMAC core versions. Remove RBUE from     XGMAC_DMA_INT_DEFAULT_EN and XGMAC_DMA_INT_DEFAULT_RX to prevent the interrupt storm while keeping normal     RX handling intact. (CVE-2026-93830)

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

ID	Name	Product	Family	Type	Severity
376443	Ubuntu 24.04 LTS / 26.04 LTS : Linux kernel vulnerabilities (USN-8959-1)	Nessus	Ubuntu Local Security Checks	Local	high
375805	Ubuntu 22.04 LTS : Linux kernel (Azure CVM) vulnerabilities (USN-8962-1)	Nessus	Ubuntu Local Security Checks	Local	high
375804	Ubuntu 20.04 LTS / 22.04 LTS : Linux kernel vulnerabilities (USN-8961-1)	Nessus	Ubuntu Local Security Checks	Local	high
375113	Photon OS 5.0: Linux PHSA-2026-5.0-91-1014	Nessus	PhotonOS Local Security Checks	Local	high
375014	Photon OS 5.0: Linux PHSA-2026-5.0-92-1014	Nessus	PhotonOS Local Security Checks	Local	high
374957	Photon OS 5.0: Linux PHSA-2026-5.0-90-1034	Nessus	PhotonOS Local Security Checks	Local	high
374204	CentOS Linux 8 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS-STREAM8:CLSA-2026:1793362651)	Nessus	CentOS Local Security Checks	Local	high
373106	Unity Linux 20.1050a Security Update: kernel (UTSA-2026-146825)	Nessus	Unity Linux Local Security Checks	Local	high
371428	Rocky Linux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1792762308)	Nessus	Rocky Linux Local Security Checks	Local	high
371426	AlmaLinux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1792762308)	Nessus	Alma Linux Local Security Checks	Local	high
371223	AlmaLinux 9.2 [TuxCare] Security Update: bpftool / kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1792751700)	Nessus	Alma Linux Local Security Checks	Local	high
366919	Debian dla-4841 : ata-modules-6.1.0-53-armmp-di - security update	Nessus	Debian Local Security Checks	Local	high
362907	Debian dla-4817 : ata-modules-6.12.107+deb12-armmp-di - security update	Nessus	Debian Local Security Checks	Local	high
351155	Debian dsa-6528 : ata-modules-6.12.111+deb13-armmp-di - security update	Nessus	Debian Local Security Checks	Local	high
350013	Linux Distros Unpatched Vulnerability : CVE-2026-93830	Nessus	Misc.	Local	high

Detections

Analytics

CVE-2026-93830

high

Tenable Plugins

high

high

high

high

high

high

high

high

high

high

high

high

high

high

high