CVE-2026-43496
MediumCVSS 5.5Exploitation Probability (EPSS)
Low risk2th percentile - higher than 2% of all known CVEs
Summary
In the Linux kernel network subsystem, a vulnerability was found in the RED queuing discipline. When RED has children (e.g., qfq) and a parent (e.g., tbf) calls dequeue after peek, a null pointer dereference and kernel panic can occur. The fix replaces the direct dequeue call with qdisc_dequeue_peeked().
Risk Assessment
An attacker can trigger a kernel panic by sending crafted network traffic to a system with specific queuing discipline chains (RED with qfq and tbf), causing a denial of service (DoS).
Recommendation
Immediately update the Linux kernel to a version containing the fix (commit resolving the issue). If an update is not possible, temporarily avoid the RED -> qfq -> tbf queuing discipline chain configuration.
Other vulnerabilities in Linux kernel
See all- CVE-2026-99282Unknown
In the Linux kernel, net/sched: sch_teql contains a use-after-free vulnerability. teql_master_xmit() incorrectly treats NET_XMIT_DROP as an unconsumed packet and operates on freed memory. The issue affects configurations with VLAN interfaces and pfifo qdisc with limit 0.
- CVE-2026-99281Unknown
A flaw in the Linux kernel tun/tap mechanism allowed processes without CAP_NET_ADMIN to attach to persistent tun devices that had no owner or group set. Anyone able to open /dev/net/tun could attach to such devices and intercept or inject network traffic. The fix now requires CAP_NET_ADMIN to attach to an ownerless, groupless device.
- CVE-2026-99280Unknown
In the Linux kernel, the following vulnerability has been resolved: ksmbd: drain session procfs readers before dropping table references. Session registration failure and connection cleanup can drop the table reference while the per-session procfs entry is still accessible. If a reader holds the last remaining reference, its final put calls proc_remove() from its own callback and waits for that callback to finish. Remove the procfs entry before dropping the table reference in the registration failure path. Queue sessions removed during connection cleanup and drain their procfs readers after releasing both session locks, then return their table references. Keep the global hash node unhashed while a session is queued so a concurrent unregister cannot drop the reference again. Previous-session replacement also destroys the file table before the session is finally freed. Detach the idr under the lock used by procfs file counters, and report zero files after it has been detached. This prevents a reader from accessing the idr during or after its destruction.
- CVE-2026-99278Unknown
In the Linux kernel, the following vulnerability has been resolved: ksmbd: limit sessions on each connection. The pending setup limit only counts InProgress sessions. A client can complete authentication repeatedly and retain an unbounded number of Valid sessions on one connection. Reserve a connection slot before allocating a session and retain a connection reference while authentication is in progress. The first SMB3 channel takes over that reservation; binding to another connection reserves one slot there. Reauthentication and authentication continuation reuse the existing reservation. Return slots on allocation or insertion failure, channel removal, and final session destruction. Accept max_sessions_per_connection in reserved startup-request space and default to 64 when older tools leave it zero. Keep the request size and existing field offsets unchanged. Expose the configured limit in procfs. The existing connection limits bound the aggregate number of sessions without a separate global session allocation limit.
- CVE-2026-99259Unknown
In the Linux kernel, the soc/tegra: pmc driver has an uninitialised early_pmc->rate variable for legacy 32-bit Tegra devices. The variable is never configured and remains 0, triggering a warning in tegra_pmc_enter_suspend_mode(). The issue appeared after the PMC driver was changed to create the PMC context dynamically, updating rate only in the new context.
- CVE-2026-99258Unknown
In the Linux kernel, hv_apicid_to_vp_index() uses per-CPU hypercall input and output pages. In an SEV-SNP CoCo VM without a paravisor the output page is not allocated, so the hypervisor stores the resulting VP index into memory not allocated by the guest. The fix uses the input page for both input and output.
- CVE-2026-99257Unknown
In the Linux kernel, the shared GPIO mechanism based on platform lookup tables requires an associated struct device. An fwnode-based lookup with no associated device currently causes a NULL-pointer dereference. The fix adds a check that lets the kernel gracefully handle this situation with an error.
- CVE-2026-99256Unknown
In the Linux kernel, the dm cache module used a rw_semaphore for background_work_lock, although write locks on rw_semaphores have strict owner semantics. The locking process was not always the same as the unlocking one, triggering a warning with CONFIG_DEBUG_RWSEMS during suspend/resume of a cache device. The fix replaces the rw_semaphore with a spinlock and a wait queue.
- CVE-2026-99251Unknown
In the Linux kernel, init_vp_index() contains a retry loop that strips CPUs from a node if they are already in the allocated cpumask or outside the HK_TYPE_MANAGED_IRQ housekeeping cpumask. If the housekeeping cpumask contains no CPU in that node, the loop becomes infinite. The fix skips NUMA nodes with no housekeeping CPU and aborts early when no online housekeeping CPUs exist.
- CVE-2026-99250Unknown
In the Linux kernel, the NBCON console printing kthreads are started very early during boot via early_initcall(). Asynchronously enabling/disabling interrupts during early boot may interfere with early SMP setup on some hardware platforms, causing hangs. The fix postpones kthread startup until after all arch initcalls have completed.
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_red: Replace direct dequeue call with peek and qdisc_dequeue_peeked When red qdisc has children (eg qfq qdisc) whose peek() callback is qdisc_peek_dequeued(), we could get a kernel panic. When the parent of such qdiscs (eg illustrated in patch #3 as tbf) wants to retrieve an skb from its child (red in this case), it will do the following: 1a. do a peek() - and when sensing there's an skb the child can offer, then - the child in this case(red) calls its child's (qfq) peek. qfq does the right thing and will return the gso_skb queue packet. Note: if there wasnt a gso_skb entry then qfq will store it there. 1b. invoke a dequeue() on the child (red). And herein lies the problem. - red will call the child's dequeue() which will essentially just try to grab something of qfq's queue. [ 78.667668][ T363] KASAN: null-ptr-deref in range [0x0000000000000048-0x000000000000004f] [ 78.667927][ T363] CPU: 1 UID: 0 PID: 363 Comm: ping Not tainted 7.1.0-rc1-00033-g46f74a3f7d57-dirty #790 PREEMPT(full) [ 78.668263][ T363] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 78.668486][ T363] RIP: 0010:qfq_dequeue+0x446/0xc90 [sch_qfq] [ 78.668718][ T363] Code: 54 c0 e8 dd 90 00 f1 48 c7 c7 e0 03 54 c0 48 89 de e8 ce 90 00 f1 48 8d 7b 48 b8 ff ff 37 00 48 89 fa 48 c1 e0 2a 48 c1 ea 03 <80> 3c 02 00 74 05 e8 ef a1 e1 f1 48 8b 7b 48 48 8d 54 24 58 48 8d [ 78.669312][ T363] RSP: 0018:ffff88810de573e0 EFLAGS: 00010216 [ 78.669533][ T363] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 78.669790][ T363] RDX: 0000000000000009 RSI: 0000000000000004 RDI: 0000000000000048 [ 78.670044][ T363] RBP: ffff888110dc4000 R08: ffffffffb1b0885a R09: fffffbfff6ba9078 [ 78.670297][ T363] R10: 0000000000000003 R11: ffff888110e31c80 R12: 0000001880000000 [ 78.670560][ T363] R13: ffff888110dc4150 R14: ffff888110dc42b8 R15: 0000000000000200 [ 78.670814][ T363] FS: 00007f66a8f09c40(0000) GS:ffff888163428000(0000) knlGS:0000000000000000 [ 78.671110][ T363] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 78.671324][ T363] CR2: 000055db4c6a30a8 CR3: 000000010da67000 CR4: 0000000000750ef0 [ 78.671585][ T363] PKRU: 55555554 [ 78.671713][ T363] Call Trace: [ 78.671843][ T363] <TASK> [ 78.671936][ T363] ? __pfx_qfq_dequeue+0x10/0x10 [sch_qfq] [ 78.672148][ T363] ? __pfx__printk+0x10/0x10 [ 78.672322][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.672496][ T363] ? lockdep_hardirqs_on_prepare+0xa8/0x1a0 [ 78.672706][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.672875][ T363] ? trace_hardirqs_on+0x19/0x1a0 [ 78.673047][ T363] red_dequeue+0x65/0x270 [sch_red] [ 78.673217][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.673385][ T363] tbf_dequeue.cold+0xb0/0x70c [sch_tbf] [ 78.673566][ T363] __qdisc_run+0x169/0x1900 The right thing to do in #1b is to grab the skb off gso_skb queue. This patchset fixes that issue by changing #1b to use qdisc_dequeue_peeked() method instead.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

