CVE-2024-49998
MediumCVSS 4.7Exploitation Probability (EPSS)
Low risk7th percentile - higher than 7% of all known CVEs
Summary
A vulnerability was found in the Linux kernel's DSA shutdown sequence. Two issues were identified: a use-after-free in the lan9303 driver due to dev_get_drvdata() calls after shutdown, and a race condition when zeroing conduit->dsa_ptr during packet reception. The fix closes the conduit interface before zeroing pointers, preventing access to the driver after shutdown.
Risk Assessment
Organizations may experience kernel panics or undefined behavior during DSA network interface shutdown, leading to service disruptions and potential data loss.
Recommendation
Immediately update the Linux kernel to a version containing the fix (commit 0650bf52b31f or later). For production systems, apply the security patch from the kernel distributor.
Other vulnerabilities in Linux kernel
See all- CVE-2026-98164Unknown
In the Linux kernel, KVM x86/mmu's kvm_gfn_is_write_tracked() only checks the supplied memslot, but page tracking is per-address-space and shadow pages are shared across address spaces. With SMM, a GFN can be write-tracked in one address space and appear untracked in another. The fix checks the supplied slot first, then the slot for the other address space, preventing mmu_try_to_unsync_pages() from marking an upper-level shadow page unsync and triggering a BUG in pte_list_remove().
- CVE-2026-98048Unknown
In the Linux kernel's BPF subsystem, mark_fastcall_pattern_for_call() must ensure that a matched "spill; call; fill" instruction series is not interrupted by a jump. Otherwise the rewrite applied by bpf_remove_fastcall_spills_fills() is unsound. The fix records instructions targeted by jumps in insn_aux_data[*].jump_target and uses this flag to stop growing a pattern.
- CVE-2026-98047Unknown
In the Linux kernel's BPF subsystem, in_rbtree_lock_required_cb() only checks the innermost verifier frame, so rbtree callback restrictions disappear in a nested static subprogram call frame. The subprogram can unlock the tree, remove and drop the node being compared, then relock, leading to freed memory being linked into the tree.
- CVE-2026-98046Unknown
In the Linux kernel's BPF subsystem, bpf_btf_find_by_name_kind() returns a new BTF object fd through __btf_new_fd(), which reaches anon_inode_getfd() that can sleep while allocating or expanding the current task fd table. The helper prototype does not set might_sleep, so the verifier allows the helper in non-sleepable contexts such as BPF timer callbacks.
- CVE-2026-98045Unknown
In the Linux kernel, a BPF verifier vulnerability affects stack helpers that may block on filesystem reads (e.g., resolving build IDs) but were not marked as sleepable. The verifier could still allow these helpers from non-sleepable regions such as RCU or preemption-disabled sections.
- CVE-2026-98044Unknown
In the Linux kernel, the BPF verifier mishandled legacy packet-load instructions (BPF_LD_ABS/BPF_LD_IND) reached from callbacks, triggering a verifier bug warning and an -EFAULT on BPF_PROG_LOAD. A privileged program loader could trigger this issue.
- CVE-2026-98043Unknown
In the Linux kernel, the BPF verifier incorrectly inferred that a pointer with an unbounded offset is non-NULL based solely on its type. As a result, a BPF program could pass verification while a NULL pointer dereference occurred at runtime.
- CVE-2026-98042Unknown
In the Linux kernel, the BPF verifier could resurrect a scalar id dropped by collect_linked_regs() because snapshots of compared registers were taken before linked registers were collected. This could lead to range inconsistencies and precision propagation issues.
- CVE-2026-98041High
In the Linux kernel, the BPF verifier incorrectly predicted the outcome of pointer vs zero comparisons in JMP32 instructions, failing to distinguish BPF_JMP from BPF_JMP32 comparisons. This led to incorrect inference that a jump is always taken.
- CVE-2026-98040Unknown
In the Linux kernel, the BPF verifier did not mark the zero register as precise for a register-form NULL check. As a result, one path was pruned and the program could dereference a zero pointer at runtime.
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: net: dsa: improve shutdown sequence Alexander Sverdlin presents 2 problems during shutdown with the lan9303 driver. One is specific to lan9303 and the other just happens to reproduce there. The first problem is that lan9303 is unique among DSA drivers in that it calls dev_get_drvdata() at "arbitrary runtime" (not probe, not shutdown, not remove): phy_state_machine() -> ... -> dsa_user_phy_read() -> ds->ops->phy_read() -> lan9303_phy_read() -> chip->ops->phy_read() -> lan9303_mdio_phy_read() -> dev_get_drvdata() But we never stop the phy_state_machine(), so it may continue to run after dsa_switch_shutdown(). Our common pattern in all DSA drivers is to set drvdata to NULL to suppress the remove() method that may come afterwards. But in this case it will result in an NPD. The second problem is that the way in which we set dp->conduit->dsa_ptr = NULL; is concurrent with receive packet processing. dsa_switch_rcv() checks once whether dev->dsa_ptr is NULL, but afterwards, rather than continuing to use that non-NULL value, dev->dsa_ptr is dereferenced again and again without NULL checks: dsa_conduit_find_user() and many other places. In between dereferences, there is no locking to ensure that what was valid once continues to be valid. Both problems have the common aspect that closing the conduit interface solves them. In the first case, dev_close(conduit) triggers the NETDEV_GOING_DOWN event in dsa_user_netdevice_event() which closes user ports as well. dsa_port_disable_rt() calls phylink_stop(), which synchronously stops the phylink state machine, and ds->ops->phy_read() will thus no longer call into the driver after this point. In the second case, dev_close(conduit) should do this, as per Documentation/networking/driver.rst: | Quiescence | ---------- | | After the ndo_stop routine has been called, the hardware must | not receive or transmit any data. All in flight packets must | be aborted. If necessary, poll or wait for completion of | any reset commands. So it should be sufficient to ensure that later, when we zeroize conduit->dsa_ptr, there will be no concurrent dsa_switch_rcv() call on this conduit. The addition of the netif_device_detach() function is to ensure that ioctls, rtnetlinks and ethtool requests on the user ports no longer propagate down to the driver - we're no longer prepared to handle them. The race condition actually did not exist when commit 0650bf52b31f ("net: dsa: be compatible with masters which unregister on shutdown") first introduced dsa_switch_shutdown(). It was created later, when we stopped unregistering the user interfaces from a bad spot, and we just replaced that sequence with a racy zeroization of conduit->dsa_ptr (one which doesn't ensure that the interfaces aren't up).
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

