CyberSecBulletin
CVE-2026-46031NVD status: Analyzed

Linux: Improper Locking

Published Updated By the CyberSecBulletin desk

CVE-2026-46031 is a high-severity improper locking vulnerability in Linux, with a CVSS 3.1 base score of 7.5 out of 10. It can be exploited remotely over the network by an unauthenticated attacker, without any action from a user. The record lists versions 1962027a6d223f90df8b372929f9d1a8d321ad6a, 640a7631d31db87d5fa1b34cea44a99b6e78854b, 518040324067d8efaa2da1992297b7e7bf5640f4 as the first without the flaw, so updating Linux to one of those releases or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.37% chance of exploitation within 30 days, which is low compared with other CVEs.

Next patch cycle

High severity with no evidence of exploitation so far.

What to do

  1. Update Linux to 1962027a6d223f90df8b372929f9d1a8d321ad6a or 640a7631d31db87d5fa1b34cea44a99b6e78854b or 518040324067d8efaa2da1992297b7e7bf5640f4 or be8aad558b4675f45b43080f81a9ffdeddea73a5, whichever matches your release line, or a later version.
  2. Update Linux Kernel to 6.1.175 or 6.6.140 or 6.9 or 6.12.86, whichever matches your release line, or a later version.
  3. Until you can update, restrict network access to the affected service so it is not reachable from untrusted networks.

Affected products and versions

VendorProductAffected versionsFixed in
LinuxLinux8a3ff43dcbab7c96f9e8cf2bd1049ab8d6e59545 up to, but not including, 1962027a6d223f90df8b372929f9d1a8d321ad6a; ae87f661f3c1a3134a7ed86ab69bf9f12af88993 up to, but not including, 640a7631d31db87d5fa1b34cea44a99b6e78854b; e0863634bf9f7cf36291ebb5bfa2d16632f79c49 up to, but not including, 518040324067d8efaa2da1992297b7e7bf5640f4; e0863634bf9f7cf36291ebb5bfa2d16632f79c49 up to, but not including, be8aad558b4675f45b43080f81a9ffdeddea73a5; e0863634bf9f7cf36291ebb5bfa2d16632f79c49 up to, but not including, 21f1707a8e978558dcb11b053855521e32ac0eec; e0863634bf9f7cf36291ebb5bfa2d16632f79c49 up to, but not including, 5c9fcac3c872224316714d0d8914d9af16c76a6d; 7e2901a2a9195da76111f351584bf77552a038f0; 6.1.91 up to, but not including, 6.1.175; and 3 more ranges1962027a6d223f90df8b372929f9d1a8d321ad6a, 640a7631d31db87d5fa1b34cea44a99b6e78854b, 518040324067d8efaa2da1992297b7e7bf5640f4, be8aad558b4675f45b43080f81a9ffdeddea73a5, 21f1707a8e978558dcb11b053855521e32ac0eec, 5c9fcac3c872224316714d0d8914d9af16c76a6d
LinuxLinux Kernel6.1.91 up to, but not including, 6.1.175; 6.6.31 up to, but not including, 6.6.140; 6.8.10 up to, but not including, 6.9; 6.9.1 up to, but not including, 6.12.86; 6.13 up to, but not including, 6.18.27; 6.19 up to, but not including, 7.0.4; 6.96.1.175, 6.6.140, 6.9, 6.12.86, 6.18.27, 7.0.4

Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.

How the severity score breaks down

Attack vector
NetworkCan be exploited remotely over a network, including the internet.
Attack complexity
LowNo special conditions are needed; the attack works reliably.
Privileges required
NoneNo account or login is needed.
User interaction
NoneNo action by a victim is required.
Scope
UnchangedImpact stays within the vulnerable component.
Confidentiality
NoneNo data is disclosed.
Integrity
NoneNothing can be modified.
Availability
HighThe component can be taken down completely.

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. Scored by CNA.

Official description

In the Linux kernel, the following vulnerability has been resolved: net: ks8851: Reinstate disabling of BHs around IRQ handler If the driver executes ks8851_irq() AND a TX packet has been sent, then the driver enables TX queue via netif_wake_queue() which schedules TX softirq to queue packets for this device. If CONFIG_PREEMPT_RT=y is set AND a packet has also been received by the MAC, then ks8851_rx_pkts() calls netdev_alloc_skb_ip_align() to allocate SKBs for the received packets. If netdev_alloc_skb_ip_align() is called with BH enabled, then local_bh_enable() at the end of netdev_alloc_skb_ip_align() will trigger the pending softirq processing, which may ultimately call the .xmit callback ks8851_start_xmit_par(). The ks8851_start_xmit_par() will try to lock struct ks8851_net_par .lock spinlock, which is already locked by ks8851_irq() from which ks8851_start_xmit_par() was called. This leads to a deadlock, which is reported by the kernel, including a trace listed below. If CONFIG_PREEMPT_RT is not set, then since commit 0913ec336a6c0 ("net: ks8851: Fix deadlock with the SPI chip variant") the deadlock can also be triggered without received packet in the RX FIFO. The pending softirqs will be processed on return from spin_unlock_bh(&ks->statelock) in ks8851_irq(), which triggers the deadlock as well. Fix the problem by disabling BH around critical sections, including the IRQ handler, thus preventing the net_tx_action() softirq from triggering during these critical sections. The net_tx_action() softirq is triggered once BH are re-enabled and at the end of the IRQ handler, once all the other IRQ handler actions have been completed. __schedule from schedule_rtlock+0x1c/0x34 schedule_rtlock from rtlock_slowlock_locked+0x548/0x904 rtlock_slowlock_locked from rt_spin_lock+0x60/0x9c rt_spin_lock from ks8851_start_xmit_par+0x74/0x1a8 ks8851_start_xmit_par from netdev_start_xmit+0x20/0x44 netdev_start_xmit from dev_hard_start_xmit+0xd0/0x188 dev_hard_start_xmit from sch_direct_xmit+0xb8/0x25c sch_direct_xmit from __qdisc_run+0x1f8/0x4ec __qdisc_run from qdisc_run+0x1c/0x28 qdisc_run from net_tx_action+0x1f0/0x268 net_tx_action from handle_softirqs+0x1a4/0x270 handle_softirqs from __local_bh_enable_ip+0xcc/0xe0 __local_bh_enable_ip from __alloc_skb+0xd8/0x128 __alloc_skb from __netdev_alloc_skb+0x3c/0x19c __netdev_alloc_skb from ks8851_irq+0x388/0x4d4 ks8851_irq from irq_thread_fn+0x24/0x64 irq_thread_fn from irq_thread+0x178/0x28c irq_thread from kthread+0x12c/0x138 kthread from ret_from_fork+0x14/0x28

Source: the CVE record as published by its numbering authority, via NVD and CVE.org.

The underlying weakness: Improper Locking

The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.

How developers prevent this class of flaw

  • Use industry standard APIs to implement locking mechanism.

More Improper Locking vulnerabilities (CWE-667)

Timeline

  1. CVE record published.
  2. Record last changed materially (score, affected products, status or references).

References

Recent Improper Locking vulnerabilities

Spotted an error? Tell us.