OESA-2026-1947

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

mptcp: Initialise rcvmss before calling tcpsendactivereset() in mptcpdofastclose().

syzbot reported divide-by-zero in __tcpselectwindow() by MPTCP socket. [0]

We had a similar issue for the bare TCP and fixed in commit 499350a5a6e7 ("tcp: initialize rcvmss to TCPMIN_MSS instead of 0").

Let's apply the same fix to mptcpdofastclose().

CPU: 0 UID: 0 PID: 6068 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 RIP: 0010:__tcpselectwindow+0x824/0x1320 net/ipv4/tcpoutput.c:3336 Code: ff ff ff 44 89 f1 d3 e0 89 c1 f7 d1 41 01 cc 41 21 c4 e9 a9 00 00 00 e8 ca 49 01 f8 e9 9c 00 00 00 e8 c0 49 01 f8 44 89 e0 99 <f7> 7c 24 1c 41 29 d4 48 bb 00 00 00 00 00 fc ff df e9 80 00 00 00 RSP: 0018:ffffc90003017640 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88807b469e40 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc90003017730 R08: ffff888033268143 R09: 1ffff1100664d028 R10: dffffc0000000000 R11: ffffed100664d029 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 000055557faa0500(0000) GS:ffff888126135000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f64a1912ff8 CR3: 0000000072122000 CR4: 00000000003526f0 Call Trace: <TASK> tcpselectwindow net/ipv4/tcpoutput.c:281 [inline] __tcptransmitskb+0xbc7/0x3aa0 net/ipv4/tcpoutput.c:1568 tcptransmitskb net/ipv4/tcpoutput.c:1649 [inline] tcpsendactivereset+0x2d1/0x5b0 net/ipv4/tcpoutput.c:3836 mptcpdofastclose+0x27e/0x380 net/mptcp/protocol.c:2793 mptcpdisconnect+0x238/0x710 net/mptcp/protocol.c:3253 mptcpsendmsgfastopen+0x2f8/0x580 net/mptcp/protocol.c:1776 mptcpsendmsg+0x1774/0x1980 net/mptcp/protocol.c:1855 socksendmsgnosec net/socket.c:727 [inline] __sock_sendmsg+0xe5/0x270 net/socket.c:742 __sys_sendto+0x3bd/0x520 net/socket.c:2244 __dosyssendto net/socket.c:2251 [inline] __sesyssendto net/socket.c:2247 [inline] _x64syssendto+0xde/0x100 net/socket.c:2247 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xfa/0xfa0 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f66e998f749 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffff9acedb8 EFLAGS: 00000246 ORIGRAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f66e9be5fa0 RCX: 00007f66e998f749 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007ffff9acee10 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007f66e9be5fa0 R14: 00007f66e9be5fa0 R15: 0000000000000006 </TASK>(CVE-2025-68291)

In the Linux kernel, the following vulnerability has been resolved:

tcp: secure_seq: add back ports to TS offset

This reverts 28ee1b746f49 ("secure_seq: downgrade to per-host timestamp offsets")

tcptwrecycle went away in 2017.

Zhouyan Deng reported off-path TCP source port leakage via SYN cookie side-channel that can be fixed in multiple ways.

One of them is to bring back TCP ports in TS offset randomization.

As a bonus, we perform a single siphash() computation to provide both an ISN and a TS offset.(CVE-2026-23247)

In the Linux kernel, the following vulnerability has been resolved:

apparmor: validate DFA start states are in bounds in unpack_pdb

Start states are read from untrusted data and used as indexes into the DFA state tables. The aadfanext() function call in unpackpdb() will access dfa->tables[YYTDID_BASE][start], and if the start state exceeds the number of states in the DFA, this results in an out-of-bound read.

================================================================== BUG: KASAN: slab-out-of-bounds in aadfanext+0x2a1/0x360 Read of size 4 at addr ffff88811956fb90 by task su/1097 ...

Reject policies with out-of-bounds start states during unpacking to prevent the issue.(CVE-2026-23269)

In the Linux kernel, the following vulnerability has been resolved:

ice: Fix memory leak in icesetringparam()

In icesetringparam, txrings and xdprings are allocated before rxrings. If the allocation of rxrings fails, the code jumps to the done label leaking both txrings and xdprings. Furthermore, if the setup of an individual Rx ring fails during the loop, the code jumps to the freetx label which releases txrings but leaks xdp_rings.

Fix this by introducing a freexdp label and updating the error paths to ensure both xdprings and txrings are properly freed if rxrings allocation or setup fails.

Compile tested only. Issue found using a prototype static analysis tool and code review.(CVE-2026-23389)

In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: Fix race condition during IPSec ESN update

In IPSec full offload mode, the device reports an ESN (Extended Sequence Number) wrap event to the driver. The driver validates this event by querying the IPSec ASO and checking that the esneventarm field is 0x0, which indicates an event has occurred. After handling the event, the driver must re-arm the context by setting esneventarm back to 0x1.

A race condition exists in this handling path. After validating the event, the driver calls mlx5accelespmodifyxfrm() to update the kernel's xfrm state. This function temporarily releases and re-acquires the xfrm state lock.

So, need to acknowledge the event first by setting esneventarm to 0x1. This prevents the driver from reprocessing the same ESN update if the hardware sends events for other reason. Since the next ESN update only occurs after nearly 2^31 packets are received, there's no risk of missing an update, as it will happen long after this handling has finished.

Processing the event twice causes the ESN high-order bits (esn_msb) to be incremented incorrectly. The driver then programs the hardware with this invalid ESN state, which leads to anti-replay failures and a complete halt of IPSec traffic.

Fix this by re-arming the ESN event immediately after it is validated, before calling mlx5accelespmodifyxfrm(). This ensures that any spurious, duplicate events are correctly ignored, closing the race window.(CVE-2026-23440)

In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: Prevent concurrent access to IPSec ASO context

The query or updating IPSec offload object is through Access ASO WQE. The driver uses a single mlx5eipsecaso struct for each PF, which contains a shared DMA-mapped context for all ASO operations.

A race condition exists because the ASO spinlock is released before the hardware has finished processing WQE. If a second operation is initiated immediately after, it overwrites the shared context in the DMA area.

When the first operation's completion is processed later, it reads this corrupted context, leading to unexpected behavior and incorrect results.

This commit fixes the race by introducing a private context within each IPSec offload object. The shared ASO context is now copied to this private context while the ASO spinlock is held. Subsequent processing uses this saved, per-object context, ensuring its integrity is maintained.(CVE-2026-23441)

In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: always free skb on ieee80211txprepare_skb() failure

ieee80211txprepareskb() has three error paths, but only two of them free the skb. The first error path (ieee80211txprepare() returning TXDROP) does not free it, while invoketxhandlers() failure and the fragmentation check both do.

Add kfreeskb() to the first error path so all three are consistent, and remove the now-redundant frees in callers (ath9k, mt76, mac80211hwsim) to avoid double-free.

Document the skb ownership guarantee in the function's kdoc.(CVE-2026-23444)

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: L2CAP: Fix use-after-free in l2capunregisteruser

After commit ab4eedb790ca ("Bluetooth: L2CAP: Fix corrupted list in hcichandel"), l2capconndel() uses conn->lock to protect access to conn->users. However, l2capregisteruser() and l2capunregisteruser() don't use conn->lock, creating a race condition where these functions can access conn->users and conn->hchan concurrently with l2capconndel().

This can lead to use-after-free and list corruption bugs, as reported by syzbot.

Fix this by changing l2capregisteruser() and l2capunregisteruser() to use conn->lock instead of hcidevlock(), ensuring consistent locking for the l2cap_conn structure.(CVE-2026-23461)

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: L2CAP: Validate L2CAPINFORSP payload length before access

l2capinformationrsp() checks that cmdlen covers the fixed l2capinfo_rsp header (type + result, 4 bytes) but then reads rsp->data without verifying that the payload is present:

• L2CAPITFEATMASK calls getunalignedle32(rsp->data), which reads 4 bytes past the header (needs cmdlen >= 8).

• L2CAPITFIXEDCHAN reads rsp->data[0], 1 byte past the header (needs cmdlen >= 5).

A truncated L2CAPINFORSP with result == L2CAPIRSUCCESS triggers an out-of-bounds read of adjacent skb data.

Guard each data access with the required payload length check. If the payload is too short, skip the read and let the state machine complete with safe defaults (featmask and remotefixedchan remain zero from kzalloc), so the info timer cleanup and l2capconn_start() still run and the connection is not stalled.(CVE-2026-31393)

In the Linux kernel, the following vulnerability has been resolved:

nvdimm/bus: Fix potential use after free in asynchronous initialization

Dingisoul with KASAN reports a use after free if deviceadd() fails in ndasyncdeviceregister().

Commit b6eae0f61db2 ("libnvdimm: Hold reference on parent while scheduling async init") correctly added a reference on the parent device to be held until asynchronous initialization was complete. However, if device_add() results in an allocation failure the ref count of the device drops to 0 prior to the parent pointer being accessed. Thus resulting in use after free.

The bug bot AI correctly identified the fix. Save a reference to the parent pointer to be used to drop the parent reference regardless of the outcome of device_add().(CVE-2026-31399)

In the Linux kernel, the following vulnerability has been resolved:

media: dvb-net: fix OOB access in ULE extension header tables

The ulemandatoryexthandlers[] and uleoptionalexthandlers[] tables in handleoneuleextension() are declared with 255 elements (valid indices 0-254), but the index htype is derived from network-controlled data as (ulesndu_type & 0x00FF), giving a range of 0-255. When htype equals 255, an out-of-bounds read occurs on the function pointer table, and the OOB value may be called as a function pointer.

Add a bounds check on htype against the array size before either table is accessed. Out-of-range values now cause the SNDU to be discarded.(CVE-2026-31405)

In the Linux kernel, the Bluetooth SCO module's scorecvframe() function contains a use-after-free vulnerability. The function reads conn->sk under scoconnlock() but immediately releases the lock without holding a reference to the socket. A concurrent close() operation can free the socket between the lock release and the subsequent sk->skstate access, resulting in a use-after-free vulnerability. Other functions in the same file (scosocktimeout(), scoconndel()) correctly use scosockhold() to safely hold references under the lock. The vulnerability is fixed by using scosockhold() to acquire a reference before releasing the lock and adding sockput() on all exit paths.(CVE-2026-31408)