In the Linux kernel, the following vulnerability has been resolved: net: ipv4: Fix UDP length overflow with PMTU discover and big MTU This commit bounds cork->base.fragsize to IP_MAX_MTU to avoid a possible overflow of UDP length that triggers a WARN in udp_set_len_short when setsockopt IP_MTU_DISCOVER is set to IP_PMTUDISC_PROBE, and a large packet is sent over a netdev with an unusually large MTU. Steps to reproduce: 1. Set device MTU bigger than IP_MAX_MTU + 20. cork->base.fragsize will be set to that MTU in ip_setup_cork. 2. Set IP_MTU_DISCOVER to IP_PMTUDISC_PROBE. It lets maxnonfragsize be set to device MTU (cork->fragsize) in __ip_append_data, rather than to IP_MAX_MTU. 3. Send 65528 bytes of payload (+8 bytes of UDP header, +20 bytes of IPv4 header). Device MTU allows it (it's only one byte bigger than IP_MAX_MTU + IPv4 header, and the device MTU is bigger than that). 4. The UDP length in the built packet is 65536, which overflows the 16-bit length field and triggers the WARN in udp_set_len_short. Note: IP_PMTUDISC_DO with IPv4 is safe, because ip_dst_mtu_maybe_forward always clamps at IP_MAX_MTU, unlike ip6_dst_mtu_maybe_forward. The Fixes tag points at the first commit where I could reproduce the overflow with IPv4 and IP_PMTUDISC_PROBE.

ubuntu_linux USN-8959-1: Ubuntu 24.04 LTS / Ubuntu 26.04 LTS / Ubuntu Pro Realtime 24.04 LTS : Linux kernel vulnerabilities (USN-8959-1)

The CentOS Linux 7 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS7:CLSA-2026:1793321383 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix premature hw access     after PCI error After a recoverable PCI error has been detected and recovered, qla driver needs to check     to see if the error condition still persist and/or wait for the OS to give the resume signal. Sep 8     22:26:03 localhost kernel: WARNING: CPU: 9 PID: 124606 at qla_tmpl.c:440 qla27xx_fwdt_entry_t266+0x55/0x60     [qla2xxx] Sep 8 22:26:03 localhost kernel: RIP: 0010:qla27xx_fwdt_entry_t266+0x55/0x60 [qla2xxx] Sep 8     22:26:03 localhost kernel: Call Trace: Sep 8 22:26:03 localhost kernel: ? qla27xx_walk_template+0xb1/0x1b0     [qla2xxx] Sep 8 22:26:03 localhost kernel: ? qla27xx_execute_fwdt_template+0x12a/0x160 [qla2xxx] Sep 8     22:26:03 localhost kernel: ? qla27xx_fwdump+0xa0/0x1c0 [qla2xxx] Sep 8 22:26:03 localhost kernel: ?     qla2xxx_pci_mmio_enabled+0xfb/0x120 [qla2xxx] Sep 8 22:26:03 localhost kernel: ?     report_mmio_enabled+0x44/0x80 Sep 8 22:26:03 localhost kernel: ? report_slot_reset+0x80/0x80 Sep 8     22:26:03 localhost kernel: ? pci_walk_bus+0x70/0x90 Sep 8 22:26:03 localhost kernel: ?     aer_dev_correctable_show+0xc0/0xc0 Sep 8 22:26:03 localhost kernel: ? pcie_do_recovery+0x1bb/0x240 Sep 8     22:26:03 localhost kernel: ? aer_recover_work_func+0xaa/0xd0 Sep 8 22:26:03 localhost kernel: ?     process_one_work+0x1a7/0x360 .. Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-8041:22: detected     PCI disconnect. Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-107ff:22: qla27xx_fwdt_entry_t262:
    dump ram MB failed. Area 5h start 198013h end 198013h Sep 8 22:26:03 localhost kernel: qla2xxx     [0000:42:00.2]-107ff:22: Unable to capture FW dump Sep 8 22:26:03 localhost kernel: qla2xxx     [0000:42:00.2]-1015:22: cmd=0x0, waited 5221 msecs Sep 8 22:26:03 localhost kernel: qla2xxx     [0000:42:00.2]-680d:22: mmio enabled returning. Sep 8 22:26:03 localhost kernel: qla2xxx     [0000:42:00.2]-d04c:22: MBX Command timeout for cmd 0, iocontrol=ffffffff jiffies=10140f2e5     mb[0-3]=[0xffff 0xffff 0xffff 0xffff] (CVE-2022-49157)

  - In the Linux kernel, the following vulnerability has been resolved: mrp: introduce active flags to prevent     UAF when applicant uninit The caller of del_timer_sync must prevent restarting of the timer, If we have no     this synchronization, there is a small probability that the cancellation will not be successful. And     syzbot report the fellowing crash: ================================================================== BUG:
    KASAN: use-after-free in hlist_add_head include/linux/list.h:929 [inline] BUG: KASAN: use-after-free in     enqueue_timer+0x18/0xa4 kernel/time/timer.c:605 Write at addr f9ff000024df6058 by task syz-fuzzer/2256     Pointer tag: [f9], memory tag: [fe] CPU: 1 PID: 2256 Comm: syz-fuzzer Not tainted     6.1.0-rc5-syzkaller-00008- ge01d50cbd6ee #0 Hardware name: linux,dummy-virt (DT) Call trace:
    dump_backtrace.part.0+0xe0/0xf0 arch/arm64/kernel/stacktrace.c:156 dump_backtrace     arch/arm64/kernel/stacktrace.c:162 [inline] show_stack+0x18/0x40 arch/arm64/kernel/stacktrace.c:163
    __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x68/0x84 lib/dump_stack.c:106     print_address_description mm/kasan/report.c:284 [inline] print_report+0x1a8/0x4a0 mm/kasan/report.c:395     kasan_report+0x94/0xb4 mm/kasan/report.c:495 __do_kernel_fault+0x164/0x1e0 arch/arm64/mm/fault.c:320     do_bad_area arch/arm64/mm/fault.c:473 [inline] do_tag_check_fault+0x78/0x8c arch/arm64/mm/fault.c:749     do_mem_abort+0x44/0x94 arch/arm64/mm/fault.c:825 el1_abort+0x40/0x60 arch/arm64/kernel/entry-common.c:367     el1h_64_sync_handler+0xd8/0xe4 arch/arm64/kernel/entry-common.c:427 el1h_64_sync+0x64/0x68     arch/arm64/kernel/entry.S:576 hlist_add_head include/linux/list.h:929 [inline] enqueue_timer+0x18/0xa4     kernel/time/timer.c:605 mod_timer+0x14/0x20 kernel/time/timer.c:1161 mrp_periodic_timer_arm     net/802/mrp.c:614 [inline] mrp_periodic_timer+0xa0/0xc0 net/802/mrp.c:627     call_timer_fn.constprop.0+0x24/0x80 kernel/time/timer.c:1474 expire_timers+0x98/0xc4     kernel/time/timer.c:1519 To fix it, we can introduce a new active flags to make sure the timer will not     restart. (CVE-2022-50697)

  - In the Linux kernel, the following vulnerability has been resolved: crypto: qat - fix DMA transfer     direction When CONFIG_DMA_API_DEBUG is selected, while running the crypto self test on the QAT crypto     algorithms, the function add_dma_entry() reports a warning similar to the one below, saying that     overlapping mappings are not supported. This occurs in tests where the input and the output scatter list     point to the same buffers (i.e. two different scatter lists which point to the same chunks of memory). The     logic that implements the mapping uses the flag DMA_BIDIRECTIONAL for both the input and the output     scatter lists which leads to overlapped write mappings. These are not supported by the DMA layer. Fix by     specifying the correct DMA transfer directions when mapping buffers. For in-place operations where the     input scatter list matches the output scatter list, buffers are mapped once with DMA_BIDIRECTIONAL,     otherwise input buffers are mapped using the flag DMA_TO_DEVICE and output buffers are mapped with     DMA_FROM_DEVICE. Overlapping a read mapping with a write mapping is a valid case in dma-coherent devices     like QAT. The function that frees and unmaps the buffers, qat_alg_free_bufl() has been changed accordingly     to the changes to the mapping function. DMA-API: 4xxx 0000:06:00.0: cacheline tracking EEXIST, overlapping     mappings aren't supported WARNING: CPU: 53 PID: 4362 at kernel/dma/debug.c:570 add_dma_entry+0x1e9/0x270     ... Call Trace: dma_map_page_attrs+0x82/0x2d0 ? preempt_count_add+0x6a/0xa0     qat_alg_sgl_to_bufl+0x45b/0x990 [intel_qat] qat_alg_aead_dec+0x71/0x250 [intel_qat]     crypto_aead_decrypt+0x3d/0x70 test_aead_vec_cfg+0x649/0x810 ? number+0x310/0x3a0 ? vsnprintf+0x2a3/0x550 ?     scnprintf+0x42/0x70 ? valid_sg_divisions.constprop.0+0x86/0xa0 ? test_aead_vec+0xdf/0x120     test_aead_vec+0xdf/0x120 alg_test_aead+0x185/0x400 alg_test+0x3d8/0x500 ?     crypto_acomp_scomp_free_ctx+0x30/0x30 ? __schedule+0x32a/0x12a0 ? ttwu_queue_wakelist+0xbf/0x110 ?
    _raw_spin_unlock_irqrestore+0x23/0x40 ? try_to_wake_up+0x83/0x570 ? _raw_spin_unlock_irqrestore+0x23/0x40     ? __set_cpus_allowed_ptr_locked+0xea/0x1b0 ? crypto_acomp_scomp_free_ctx+0x30/0x30     cryptomgr_test+0x27/0x50 kthread+0xe6/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30     (CVE-2022-50774)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: cfg80211: Pass the PMK     in binary instead of hex Apparently the hex passphrase mechanism does not work on newer chips/firmware     (e.g. BCM4387). It seems there was a simple way of passing it in binary all along, so use that and avoid     the hexification. OpenBSD has been doing it like this from the beginning, so this should work on all     chips. Also clear the structure before setting the PMK. This was leaking uninitialized stack contents to     the device. (CVE-2023-53715)

  - In the Linux kernel, the following vulnerability has been resolved: posix-timers: Ensure timer ID search-     loop limit is valid posix_timer_add() tries to allocate a posix timer ID by starting from the cached ID     which was stored by the last successful allocation. This is done in a loop searching the ID space for a     free slot one by one. The loop has to terminate when the search wrapped around to the starting point. But     that's racy vs. establishing the starting point. That is read out lockless, which leads to the following     problem: CPU0 CPU1 posix_timer_add() start = sig->posix_timer_id; lock(hash_lock); ... posix_timer_add()     if (++sig->posix_timer_id < 0) start = sig->posix_timer_id; sig->posix_timer_id = 0; So CPU1 can observe a     negative start value, i.e. -1, and the loop break never happens because the condition can never be true:
    if (sig->posix_timer_id == start) break; While this is unlikely to ever turn into an endless loop as the     ID space is huge (INT_MAX), the racy read of the start value caught the attention of KCSAN and Dmitry     unearthed that incorrectness. Rewrite it so that all id operations are under the hash lock.
    (CVE-2023-53728)

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

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - In the Linux kernel, the following vulnerability has been resolved: net: ipv4: Fix UDP length overflow
    with PMTU discover and big MTU This commit bounds cork->base.fragsize to IP_MAX_MTU to avoid a possible
    overflow of UDP length that triggers a WARN in udp_set_len_short when setsockopt IP_MTU_DISCOVER is set to
    IP_PMTUDISC_PROBE, and a large packet is sent over a netdev with an unusually large MTU. Steps to
    reproduce: 1. Set device MTU bigger than IP_MAX_MTU + 20. cork->base.fragsize will be set to that MTU in
    ip_setup_cork. 2. Set IP_MTU_DISCOVER to IP_PMTUDISC_PROBE. It lets maxnonfragsize be set to device MTU
    (cork->fragsize) in __ip_append_data, rather than to IP_MAX_MTU. 3. Send 65528 bytes of payload (+8 bytes
    of UDP header, +20 bytes of IPv4 header). Device MTU allows it (it's only one byte bigger than IP_MAX_MTU
    + IPv4 header, and the device MTU is bigger than that). 4. The UDP length in the built packet is 65536,
    which overflows the 16-bit length field and triggers the WARN in udp_set_len_short. Note: IP_PMTUDISC_DO
    with IPv4 is safe, because ip_dst_mtu_maybe_forward always clamps at IP_MAX_MTU, unlike
    ip6_dst_mtu_maybe_forward. The Fixes tag points at the first commit where I could reproduce the overflow
    with IPv4 and IP_PMTUDISC_PROBE. (CVE-2026-98393)

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

  - net: ipv4: Fix UDP length overflow with PMTU discover and big MTU This commit bounds cork->base.fragsize     to IP_MAX_MTU to avoid a possible overflow of UDP length that triggers a WARN in udp_set_len_short when     setsockopt IP_MTU_DISCOVER is set to IP_PMTUDISC_PROBE, and a large packet is sent over a netdev with an     unusually large MTU. Steps to reproduce: 1. Set device MTU bigger than IP_MAX_MTU + 20.
    cork->base.fragsize will be set to that MTU in ip_setup_cork. 2. Set IP_MTU_DISCOVER to IP_PMTUDISC_PROBE.
    It lets maxnonfragsize be set to device MTU (cork->fragsize) in __ip_append_data, rather than to     IP_MAX_MTU. 3. Send 65528 bytes of payload (+8 bytes of UDP header, +20 bytes of IPv4 header). Device MTU     allows it (it's only one byte bigger than IP_MAX_MTU + IPv4 header, and the device MTU is bigger than     that). 4. The UDP length in the built packet is 65536, which overflows the 16-bit length field and     triggers the WARN in udp_set_len_short. Note: IP_PMTUDISC_DO with IPv4 is safe, because     ip_dst_mtu_maybe_forward always clamps at IP_MAX_MTU, unlike ip6_dst_mtu_maybe_forward. The Fixes tag     points at the first commit where I could reproduce the overflow with IPv4 and IP_PMTUDISC_PROBE.
    (CVE-2026-98393)

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

ID	Name	Product	Family	Type	Severity
375672	CentOS Linux 7 [TuxCare] Security Update: bpftool / kernel / kernel-debug / kernel-debug-devel / kernel-devel / etc Multiple Vulnerabilities (CENTOS7:CLSA-2026:1793321383)	Nessus	CentOS Local Security Checks	Local	high
475156	Google: sys-kernel/cchost-kernel-6_12, sys-kernel/cchost-kernel-6_18, sys-kernel/csql-kernel-6_12, sys-kernel/csql-kernel-6_18, sys-kernel/lakitu-kernel-6_12, sys-kernel/lakitu-kernel-6_18, sys-kernel/lakitu-nc-kernel-6_12, sys-kernel/lakitu-nc-kernel-6_18: security update to 19999.44.106	Tenable Cloud Security	Google COS Security Checks	Local	medium
475156	Google: sys-kernel/cchost-kernel-6_12, sys-kernel/cchost-kernel-6_18, sys-kernel/csql-kernel-6_12, sys-kernel/csql-kernel-6_18, sys-kernel/lakitu-kernel-6_12, sys-kernel/lakitu-kernel-6_18, sys-kernel/lakitu-nc-kernel-6_12, sys-kernel/lakitu-nc-kernel-6_18: security update to 19999.44.106	Tenable Self-Hosted Container Security	Google COS Security Checks	Local	medium
365928	Linux Distros Unpatched Vulnerability : CVE-2026-98393	Nessus	Misc.	Local	medium
365258	Amazon Linux 2023 : bpftool6.18, kernel6.18, kernel6.18-devel (ALAS2023-2026-3192)	Nessus	Amazon Linux Local Security Checks	Local	high

Detections

Analytics

CVE-2026-98393

high

Tenable Plugins

Coming Soon

high

medium

medium

medium

high