CVE-2026-98393
UnknownSummary
In the Linux kernel IPv4 handling, a UDP length overflow occurs with PMTU discovery and a very large interface MTU. When IP_MTU_DISCOVER is set to IP_PMTUDISC_PROBE and a packet is sent over a netdev with MTU larger than IP_MAX_MTU + 20, the UDP length can exceed the 16-bit field and trigger a WARN in udp_set_len_short. This affects the IPv4 networking stack in the kernel.
Risk Assessment
Can trigger kernel warnings and potentially lead to system instability or denial of service in environments with unusually large MTU. However, it requires a specific configuration (IP_PMTUDISC_PROBE and very large MTU).
Recommendation
Update the Linux kernel to a version containing the fix that bounds cork->base.fragsize to IP_MAX_MTU. Avoid setting IP_MTU_DISCOVER to IP_PMTUDISC_PROBE on interfaces with MTU larger than IP_MAX_MTU + 20.
Other vulnerabilities in Linux kernel
See all- CVE-2026-98431Unknown
The Linux kernel contains an ABBA deadlock between the mmap_lock and disassociation_lock in the RDMA/uverbs subsystem. A thread performing mmap/fork acquires locks in the order mmap_lock → disassociation_lock, while the thread executing uverbs_user_mmap_disassociate() acquires them in reverse order, leading to a potential deadlock. The issue was resolved by removing disassociation_lock and using the existing hw_destroy_rwsem instead.
- CVE-2026-98430Unknown
In the Linux kernel, the RDMA/efa management IRQ handler accesses both the admin completion queue and the async event queue. The driver registered the IRQ before constructing these queues and destroyed them before freeing the IRQ, so the handler's lifetime was not contained by the resources it accesses. The fix initializes the queues with interrupts masked, requests the IRQ, then switches to interrupt mode, and on removal resets the device and frees the IRQ before destroying the queues.
- CVE-2026-98429Unknown
In the Linux kernel, the RDMA/efa completion IRQ handler accesses the EQ state and DMA buffer. Its IRQ was registered before that state was initialized, while teardown released the buffer before free_irq() synchronized the handler. The fix initializes the EQ without arming it, registers the IRQ, then arms it, and reverses the resource order during teardown by freeing the IRQ before destroying the EQ.
- CVE-2026-98428Unknown
In the Linux kernel, the USB 6fire driver uses URBs embedded in different structs for PCM, MIDI and communication, which is a buggy implementation nowadays; since a URB is managed with a refcount, this may lead to a UAF when the URB is released asynchronously. The fix converts those embedded URBs to ones properly allocated via usb_alloc_urb(), changing each embedded struct urb to a pointer and updating callers; resources are released in common destructors called at both the init error path and disconnect.
- CVE-2026-98427Unknown
In the Linux kernel, the CoDel scheduler's dropping loop in codel_dequeue() could fail to advance with very small interval values, draining the entire backlog under the qdisc lock in a single call. An unprivileged user could trigger a soft lockup this way. The fix ensures the control-law step is at least 1 tick and caps the dropping loop at 256 drops per codel_dequeue() call.
- CVE-2026-98426Unknown
In the Linux kernel, the mwifiex wifi driver's mwifiex_pcie_request_irq() registers each MSI-X vector with a per-index dev_id (&card->msix_ctx[i]). On a request_irq() failure the cleanup loop "for (j = 0; j < i; j++)" frees msix_entries[j].vector but passes the failed index's &card->msix_ctx[i] as the dev_id. Since free_irq() matches on (irq, dev_id), it fails to find the action registered with &card->msix_ctx[j]: the already-requested IRQ j is not freed (leaked) and free_irq() warns about freeing a non-existent IRQ. The fix uses &card->msix_ctx[j].
- CVE-2026-98425Unknown
In the Linux kernel, ieee80211_request_ibss_scan() in mac80211 warns when the regulatory domain leaves no allowed channel to scan. This can happen because the regdomain can change while IBSS is operating, and IBSS can continue to operate briefly during the 60s grace period until it is shut down. The fix removes the warning in this case.
- CVE-2026-98424Unknown
In the Linux kernel, cfg80211_switch_netns() in cfg80211 moves all interfaces, then moves the wiphy itself by setting its network namespace and renaming it, which makes sysfs move it. The rename can fail (only on allocation failures), leaving things mixed up and hitting a warning. The fix undoes the move and lets the change fail, and if undo fails it WARNs.
- CVE-2026-98423Unknown
In the Linux kernel, mac80211_hwsim checks ->started for frames coming from wmediumd, but the radio can be stopped after the check and before frame delivery, causing mac80211 to hit WARN_ON(!local->started). The fix expands the mutex for this case and synchronizes against it when the radio is stopped, and drops an error print that complicated the error path.
- CVE-2026-98422Unknown
In the Linux kernel, mac80211 AP_VLAN interfaces get crypto_tx_tailroom_needed_cnt from the AP interface on ifup, but it is never decremented unless the AP is also brought down. Bringing the same AP_VLAN up again increments the counter again and eventually hits the WARN_ON_ONCE sanity check. The fix resets it on ifdown.
Original NVD description (English source)
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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

