CVSS base score: 7.8 (High) vendor CNA · v3.1
Score assigned by the vendor's own CVE Numbering Authority (CNA); CISA's Vulnrichment program adds a score only when the CNA omits one.
Vendor: Linux Product: Linux
In the Linux kernel, the following vulnerability has been resolved: net_sched: sch_sfq: don't allow 1 packet limit The current implementation does not work correctly with a limit of 1. iproute2 actually checks for this and this patch adds the check in kernel as well. This fixes the following syzkaller reported crash: UBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:210:6 index 65535 is out of range for type 'struct sfq_head[128]' CPU: 0 PID: 2569 Comm: syz-executor101 Not tainted 5.10.0-smp-DEV #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x125/0x19f lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:148 [inline] __ubsan_handle_out_of_bounds+0xed/0x120 lib/ubsan.c:347 sfq_link net/sched/sch_sfq.c:210 [inline] sfq_dec+0x528/0x600 net/sched/sch_sfq.c:238 sfq_dequeue+0x39b/0x9d0 net/sched/sch_sfq.c:500 sfq_reset+0x13/0x50 net/sched/sch_sfq.c:525 qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026 tbf_reset+0x3d/0x100 net/sched/sch_tbf.c:319 qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026 dev_reset_queue+0x8c/0x140 net/sched/sch_generic.c:1296 netdev_for_each_tx_queue include/linux/netdevice.h:2350 [inline] dev_deactivate_many+0x6dc/0xc20 net/sched/sch_generic.c:1362 __dev_close_many+0x214/0x350 net/core/dev.c:1468 dev_close_many+0x207/0x510 net/core/dev.c:1506 unregister_netdevice_many+0x40f/0x16b0 net/core/dev.c:10738 unregister_netdevice_queue+0x2be/0x310 net/core/dev.c:10695 unregister_netdevice include/linux/netdevice.h:2893 [inline] __tun_detach+0x6b6/0x1600 drivers/net/tun.c:689 tun_detach drivers/net/tun.c:705 [inline] tun_chr_close+0x104/0x1b0 drivers/net/tun.c:3640 __fput+0x203/0x840 fs/file_table.c:280 task_work_run+0x129/0x1b0 kernel/task_work.c:185 exit_task_work include/linux/task_work.h:33 [inline] do_exit+0x5ce/0x2200 kernel/exit.c:931 do_group_exit+0x144/0x310 kernel/exit.c:1046 __do_sys_exit_group kernel/exit.c:1057 [inline] __se_sys_exit_group kernel/exit.c:1055 [inline] __x64_sys_exit_group+0x3b/0x40 kernel/exit.c:1055 do_syscall_64+0x6c/0xd0 entry_SYSCALL_64_after_hwframe+0x61/0xcb RIP: 0033:0x7fe5e7b52479 Code: Unable to access opcode bytes at RIP 0x7fe5e7b5244f. RSP: 002b:00007ffd3c800398 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe5e7b52479 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000 RBP: 00007fe5e7bcd2d0 R08: ffffffffffffffb8 R09: 0000000000000014 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe5e7bcd2d0 R13: 0000000000000000 R14: 00007fe5e7bcdd20 R15: 00007fe5e7b24270 The crash can be also be reproduced with the following (with a tc recompiled to allow for sfq limits of 1): tc qdisc add dev dummy0 handle 1: root tbf rate 1Kbit burst 100b lat 1s ../iproute2-6.9.0/tc/tc qdisc add dev dummy0 handle 2: parent 1:10 sfq limit 1 ifconfig dummy0 up ping -I dummy0 -f -c2 -W0.1 8.8.8.8 sleep 1 Scenario that triggers the crash: * the first packet is sent and queued in TBF and SFQ; qdisc qlen is 1 * TBF dequeues: it peeks from SFQ which moves the packet to the gso_skb list and keeps qdisc qlen set to 1. TBF is out of tokens so it schedules itself for later. * the second packet is sent and TBF tries to queues it to SFQ. qdisc qlen is now 2 and because the SFQ limit is 1 the packet is dropped by SFQ. At this point qlen is 1, and all of the SFQ slots are empty, however q->tail is not NULL. At this point, assuming no more packets are queued, when sch_dequeue runs again it will decrement the qlen for the current empty slot causing an underflow and the subsequent out of bounds access.
No mentions found in monitored research blogs or news feeds.
| Date | Advisory | Issuer |
|---|---|---|
| 2026-10-22 | ICSA-26-295-16: Siemens SIMATIC S7-1500 TM MFP | CISA |
| 2025-06-11 | ICSA-25-162-05: Siemens SIMATIC S7-1500 CPU family | CISA |
Each milestone comes from a different source, so gaps between them are gaps in what those sources publish, not evidence that nothing happened. EPSS history for this CVE holds 3 points from 2026-11-05, tracked daily from 2026-11-05; earlier points are weekly, which dates a spike to within a week. Peak probability 0.3% on 2026-11-05.
Check whether a specific version is affected →
What each source publishes about which product versions carry this vulnerability, kept as written rather than merged. Absence here means no source has published applicability data, not that nothing is affected.
Blind spot. No public detection — verify by version/patch. Nothing in the monitored scanner, IDS, SIEM or offensive-tool collections references this CVE, so exposure has to be established from asset inventory and patch level rather than from a signature.
Coverage across public collections only: Nuclei and OpenVAS NVT (scan);
Snort and Suricata ET Open (network); Sigma and YARA (host/SIEM);
Metasploit, Exploit-DB, public GitHub repositories and NVD exploit references (exploit). Absence
here means nothing public was found, not that detection is impossible.
GitHub PoC repositories are collected automatically by
PoC-in-GitHub (CC0) and filtered to repositories that are
still online, contain code, and are starred or at least two weeks old. They are
still not vetted: some are fakes and some are malware. Treat
them as evidence that code was published, not as code to run.
NVD exploit references are links NVD's analysts tag as exploits; they confirm
an exploit was referenced but carry no date. This product uses data from the
NVD but is not endorsed or certified by the NVD.
OpenVAS coverage derives from the Greenbone Community Feed, made available
under the Open Database License (ODbL) v1.0;
its individual Vulnerability Tests are licensed
GNU GPL v2.
No exploit-tool sightings recorded for this CVE.
Metasploit is dated by the first commit of the module file, Exploit-DB by its publication date, and GitHub repositories by their creation date. GitHub PoC repositories are filtered (still online, contain code, starred or at least two weeks old) but not vetted: some are fakes and some are malware, so they show that code was published, not that it works or is safe to run. Evidence tiers are explained on the About page.
Where the distribution has shipped a fix, and in which version. Green means the release has resolved it, amber that it is still open. Data from the Debian Security Tracker, used under Debian's MIT / GPLv2+ terms. Debian is upstream of several other distributions, so a fix here often precedes theirs.
No CISA Vulnrichment record for this CVE.
| If the asset is | Remediate within | Table 1 row |
|---|---|---|
| Publicly exposed | 14 days | 7 of 16 |
| Not publicly exposed | Fix on system upgrade | 15 of 16 |
BOD 26-04 replaced the single KEV deadline of BOD 22-01 with four inputs: whether the asset is publicly exposed, KEV status, whether exploitation is automatable, and technical impact. Exposure belongs to each agency's asset, not to the CVE, so both outcomes are shown. Automatable and technical impact come from the CISA assessment above. Days are calendar days; for KEV entries the clock starts on the date it was added, and otherwise when the agency identifies the vulnerability on an asset. Assumed: Automatable not assessed — assumed no; Technical impact not assessed — assumed total, following CISA's defaults for missing data. Agencies make the final exposure call asset by asset, and may set shorter timelines.
CVE.org record → NVD entry → FortiGuard Labs → Rapid7 AttackerKB →