CVE-2026-80589In the Linux kernel, the following vulnerability has been resolved:
block: stop the timeout timer when releasing a never added disk
disk_release() undoes blk_mq_init_allocated_queue() for a disk whose
probe failed before add_disk(), but it only calls blk_mq_exit_queue().
Nothing there stops q->timeout, and that timer rolls forward: it stays
pending until it next expires, not until the last request completes.
So if the driver issued any I/O before adding the disk, the
request_queue is freed while still linked into a timer wheel bucket.
Commit 6f8191fdf41d ("block: simplify disk shutdown") dropped the
blk_cleanup_queue() call that used to stop it. __del_gendisk() and
blk_mq_destroy_queue() still do; only the probe failure path lost it.
nvme gets there because nvme_update_ns_info() submits Report Zones or
FDP io-mgmt-recv on ns->queue before the disk is added, so a later
failure - a concurrent reset setting NVME_CTRL_FROZEN, or
device_add_disk() failing - lands in put_disk() with the timer armed:
BUG: KASAN: slab-use-after-free in detach_if_pending+0x30c/0x340
Write of size 8 at addr ffff888004d71310 by task kworker/u8:2/37
__timer_delete_sync+0x156/0x240 kernel/time/timer.c:1621
blk_sync_queue+0x22/0x40 block/blk-core.c:222
nvme_sync_queues+0x100/0x150 drivers/nvme/host/core.c:5362
nvme_reset_work+0x138/0x930 drivers/nvme/host/pci.c:3264
Allocated by task 34:
__blk_mq_alloc_disk+0x33/0x100 block/blk-mq.c:4462
nvme_alloc_ns+0x290/0x3870 drivers/nvme/host/core.c:4146
Freed by task 0:
blk_free_queue_rcu+0x3a/0x50 block/blk-core.c:254
rcu_core+0xc10/0x1730 kernel/rcu/tree.c:2857
The queue being synced there is ctrl->admin_q, only a victim sharing a
timer wheel bucket with the freed queue's dangling entry; other runs
tripped in enqueue_timer(), __run_timers() or blk_mq_timeout_work().
Failing nvme_alloc_ns() with a debug patch makes it deterministic: one
leaked timer trips KASAN within seconds, while 1987 patched releases
produced no splat.
Stop the timer and the queue work items before blk_mq_exit_queue(), like
blk_mq_destroy_queue() does.
Found by FuzzNvme.
2026-08-26 · score —
CVE-2026-80588In the Linux kernel, the following vulnerability has been resolved:
mptcp: reclaim forward-allocated memory on RX path errors
After commit 9db5b3cec4ec ("mptcp: borrow forward memory from subflow"),
errors in the receive path prior to queueing skbs into the receive
queue do not trigger forward-allocated memory reclaiming.
Prevent forward memory from growing unboundedly in pathological drop
scenarios by explicitly reclaiming memory when skbs are dropped.
2026-08-26 · score —
CVE-2026-80587In the Linux kernel, the following vulnerability has been resolved:
mptcp: avoid combining some incoming suboptions
Some MPTCP suboptions are mutually exclusive according to the RFC8684,
but also because in different places, the code doesn't expect some
combinations to be present. That's specially true for suboptions that
would be present twice, but with different attributes.
The new restrictions are the same as the ones applied on the output
side, with mptcp_write_options. The same rules can be reused with a
small fix: an MP_FASTCLOSE can be used with a DSS when the sender picks
this option [1], which is not the case on Linux. Here are the rules:
Which options can be used together?
X: mutually exclusive
O: often used together
C: can be used together in some cases
P: could be used together but we prefer not to (optimisations)
| Opt: | MPC | MPJ | DSS | ADD | RM | PRIO | FAIL | FC |
|------|------|------|------|------|------|------|------|------|
| MPC |------|------|------|------|------|------|------|------|
| MPJ | X |------|------|------|------|------|------|------|
| DSS | X | X |------|------|------|------|------|------|
| ADD | X | X | P |------|------|------|------|------|
| RM | C | C | C | P |------|------|------|------|
| PRIO | X | C | C | C | C |------|------|------|
| FAIL | X | X | C | X | X | X |------|------|
| FC | X | X | P | X | X | X | X |------|
| RST | X | X | X | X | X | X | O | O |
|------|------|------|------|------|------|------|------|------|
The only difference is with the 'P': another stack could send and
ADD_ADDR with other suboptions (DSS, RM_ADDR), and this should be
allowed.
A few points of attention:
- In theory, an MP_CAPABLE could be used with a RM_ADDR, but there is
no reason to add it with a SYN. Note that even with a 4th ACK, it
doesn't seem to be useful, except when IDs are known in advance via
another channel. Better not to break that.
- Now, combining both an MP_CAPABLE and an MP_JOIN will no longer
result to a reject of the two options, but only the second suboption
is ignored. That seems OK to do that for this unexpected error. At
least now all inconsistent combinations are handled the same way.
This could change later in next. This also means the explicit checks
for having both MPC + MPJ in subflow.c will now be unreachable.
That's fine, they will be removed in a follow-up patch.
- In case of conflicting combinations, the extra suboption(s) is/are
ignored: having such combinations either means the remote peer is
buggy, or is evil. The simplest action is then taken in this case:
stop processing the current suboption.
- In mp_opt->suboptions, there is also a bit reserved to the checksum,
which can be used in an MP_CAPABLE and a DSS. Each time a DSS option
can be used in parallel with another option, the checksum can be set,
so the verification is combined into a new OPTIONS_MPTCP_DSS macro.
- An MP_CAPABLE ACK can carry a Data-Level Length, and an optional
Checksum: they are the same as the ones found in a DSS, because a DSS
cannot be used in parallel to an MP_CAPABLE. Similarly, even if there
is room, a DSS cannot be used with an MP_JOIN.
2026-08-26 · score —
CVE-2026-80586In the Linux kernel, the following vulnerability has been resolved:
mptcp: options: reset DSS fields in case of unexpected size
A remote peer could send a malformed DSS with a wrong size, followed by
another DSS or MPC + Data. In this case, the first suboption will be
ignored, but leaving some fields written, which could lead to
inconsistency or access uninitialized data.
Explicitly reset the fields that could have been modified in case of
unexpected size.
2026-08-26 · score —
CVE-2026-80585In the Linux kernel, the following vulnerability has been resolved:
mptcp: fastopen: only mark MPTFO subflows with SYN data
Passive TCP Fast Open accepts a valid-cookie SYN even when it carries
no data. In that case the child socket's receive queue is intentionally
left empty.
mptcp_fastopen_subflow_synack_set_params() set is_mptfo before checking
for queued SYN data. That made data-less TFO SYNs hit a WARN and, if
the warning was non-fatal, left stale MPTFO state behind. The stale
flag could later trigger a state-confusion bug in
check_fully_established().
Only mark the subflow as MPTFO after confirming that an SKB was queued.
Return quietly when the receive queue is empty.
Note that mptcp_subflow_context's is_mptfo field is now not just about
subflows where the TFO was present, but about MPTFO subflow that
consumed SYN data. Only having a valid cookie but not carrying data is
not really "doing TFO".
2026-08-26 · score —
