OESA-2026-2930

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

wifi: mac80211: check tdls flag in ieee80211tdlsoper

When NL80211TDLSENABLE_LINK is called, the code only checks if the station exists but not whether it is actually a TDLS station. This allows the operation to proceed for non-TDLS stations, causing unintended side effects like modifying channel context and HT protection before failing.

Add a check for sta->sta.tdls early in the ENABLE_LINK case, before any side effects occur, to ensure the operation is only allowed for actual TDLS peers.(CVE-2026-43052)

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

wifi: brcmfmac: validate bsscfg indices in IF events

brcmffwehhandleifevent() validates the firmware-provided interface index before it touches drvr->iflist[], but it still uses the raw bsscfgidx field as an array index without a matching range check.

Reject IF events whose bsscfg index does not fit in drvr->iflist[] before indexing the interface array.

add missing wifi prefix

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

HID: roccat: fix use-after-free in roccatreportevent

roccatreportevent() iterates over the device->readers list without holding the readerslock. This allows a concurrent roccatrelease() to remove and free a reader while it's still being accessed, leading to a use-after-free.

Protect the readers list traversal with the readers_lock mutex.(CVE-2026-43111)

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

drm/amdkfd: Fix out-of-bounds write in kfdeventpage_set()

The kfdeventpageset() function writes KFDSIGNALEVENTLIMIT * 8 bytes via memset without checking the buffer size parameter. This allows unprivileged userspace to trigger an out-of bounds kernel memory write by passing a small buffer, leading to potential privilege escalation.(CVE-2026-43206)

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

ext4: drop extent cache after doing PARTIAL_VALID1 zeroout

When splitting an unwritten extent in the middle and converting it to initialized in ext4splitextent() with the EXT4EXTMAYZEROOUT and EXT4EXTDATAVALID2 flags set, it could leave a stale unwritten extent.

Assume we have an unwritten file and buffered write in the middle of it without dioread_nolock enabled, it will allocate blocks as written extent.

   0  A      B  N
   [UUUUUUUUUUUU] on-disk extent      U: unwritten extent
   [UUUUUUUUUUUU] extent status tree
   [--DDDDDDDD--]                     D: valid data
      |<-  ->| ----> this range needs to be initialized

ext4splitextent() first try to split this extent at B with EXT4EXTDATAPARTIALVALID1 and EXT4EXTMAYZEROOUT flag set, but ext4splitextentat() failed to split this extent due to temporary lack of space. It zeroout B to N and leave the entire extent as unwritten.

   0  A      B  N
   [UUUUUUUUUUUU] on-disk extent
   [UUUUUUUUUUUU] extent status tree
   [--DDDDDDDDZZ]                     Z: zeroed data

ext4splitextent() then try to split this extent at A with EXT4EXTDATA_VALID2 flag set. This time, it split successfully and leave an written extent from A to N.

   0  A      B  N
   [UUWWWWWWWWWW] on-disk extent      W: written extent
   [UUUUUUUUUUUU] extent status tree
   [--DDDDDDDDZZ]

Finally ext4mapcreate_blocks() only insert extent A to B to the extent status tree, and leave an stale unwritten extent in the status tree.

   0  A      B  N
   [UUWWWWWWWWWW] on-disk extent      W: written extent
   [UUWWWWWWWWUU] extent status tree
   [--DDDDDDDDZZ]

Fix this issue by always cached extent status entry after zeroing out the second part.(CVE-2026-45892)

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

ext4: drop extent cache when splitting extent fails

When the split extent fails, we might leave some extents still being processed and return an error directly, which will result in stale extent entries remaining in the extent status tree. So drop all of the remaining potentially stale extents if the splitting fails.(CVE-2026-45899)

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

ext4: don't cache extent during splitting extent

Caching extents during the splitting process is risky, as it may result in stale extents remaining in the status tree. Moreover, in most cases, the corresponding extent block entries are likely already cached before the split happens, making caching here not particularly useful.

Assume we have an unwritten extent, and then DIO writes the first half.

[UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this range

First, when ext4splitextentat() splits this extent, it truncates the existing extent and then inserts a new one. During this process, this extent status entry may be shrunk, and calls to ext4findextent() and ext4cache_extents() may occur, which could potentially insert the truncated range as a hole into the extent status tree. After the split is completed, this hole is not replaced with the correct status.

[UUUUUUU|UUUUUUUU] on-disk extent U: unwritten extent [UUUUUUU|HHHHHHHH] extent status tree H: hole

Then, the outer calling functions will not correct this remaining hole extent either. Finally, if we perform a delayed buffer write on this latter part, it will re-insert the delayed extent and cause an error in space accounting.

In adition, if the unwritten extent cache is not shrunk during the splitting, ext4cacheextents() also conflicts with existing extents when caching extents. In the future, we will add checks when caching extents, which will trigger a warning. Therefore, Do not cache extents that are being split.(CVE-2026-45912)

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

ipc: limit next_id allocation to the valid ID range

The checkpoint/restore sysctl path can request the next SysV IPC id through ids->nextid. ipcidralloc() currently forwards that request to idralloc() with an open-ended upper bound.

If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipc_mni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object.

The bug is in ipcidralloc() in the checkpoint/restore path.

1. ids->next_id is passed to:

   idralloc(&ids->ipcsidr, new, ipcidtoidx(next_id), 0, ...)

2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idralloc() can spill past ipcmni and allocate an entry beyond the valid IPC id range.

3. The new object id is still encoded with the narrower SysV IPC index width:

   new->id = (new->seq << ipcmni_seq_shift()) + idx
   

4. Later removal goes through ipc_rmid(), which uses:

   ipcid_to_idx(ipcp->id)
   

   That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index.

5. For shared memory, shm_destroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer.

6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory.

Prevent this by bounding the requested allocation to ipc_mni so the checkpoint/restore path fails once the valid range is exhausted.(CVE-2026-52923)

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

net: skbuff: fix missing zerocopy reference in pskb_carve helpers

pskbcarveinsideheader() and pskbcarveinsidenonlinear() both copy the old skbsharedinfo header into a new buffer via memcpy(), which includes the destructorarg pointer (uarg) for MSGZEROCOPY skbs. Neither function calls netzcopyget() for the new shinfo, creating an unaccounted holder: every skbsharedinfo with destructorarg set will call skbzcopyclear() once when freed, but the corresponding netzcopyget() was never called for the new copy. Repeated calls drive uarg->refcnt to zero prematurely, freeing ubufinfomsgzc while TX skbs still hold live destructorarg pointers.

KASAN reports use-after-free on a freed ubufinfomsgzc:

BUG: KASAN: slab-use-after-free in skbreleasedata+0x77b/0x810 Read of size 8 at addr ffff88801574d3e8 by task poc/220

Call Trace: skbreleasedata+0x77b/0x810 kfreeskblistreason+0x13e/0x610 skbreleasedata+0x4cd/0x810 skskbreasondrop+0xf3/0x340 skbqueuepurgereason+0x282/0x440 rdstcpincfree+0x1e/0x30 rds_recvmsg+0x354/0x1780 _sysrecvmsg+0xdf/0x180

Allocated by task 219: msgzerocopyrealloc+0x157/0x7b0 tcpsendmsglocked+0x2892/0x3ba0

Freed by task 219: iprecverror+0x74a/0xb10 tcp_recvmsg+0x475/0x530

The skb consuming the late access still referenced the same uarg via shinfo->destructorarg copied by pskbcarveinsidenonlinear() without a refcount bump. This has been verified to be reliably exploitable: a working proof-of-concept achieves full root privilege escalation from an unprivileged local user on a default kernel configuration.

The fix follows the pattern of pskbexpandhead() which has the same memcpy/cloned structure. For pskbcarveinsideheader(), netzcopyget() is placed after skborphanfrags() succeeds, so the orphan error path needs no cleanup. For pskbcarveinsidenonlinear(), netzcopyget() is placed after all failure points and just before skbreleasedata(), so no error path needs cleanup at all -- matching pskbexpandhead() more closely and avoiding the need for a balancing netzcopyput().(CVE-2026-52943)

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

ALSA: usb-audio: Bound MIDI endpoint descriptor scans

sndusbmidigetmsinfo() validates the internal MIDIStreaming endpoint descriptor size before using baAssocJackID[], but the descriptor walker can still return a class-specific endpoint descriptor whose bLength exceeds the remaining bytes in the endpoint-extra scan.

That leaves later flexible-array reads bounded by bLength, but not by the remaining bytes in the endpoint-extra scan.

Stop walking when bLength is zero or extends past the remaining endpoint-extra scan.(CVE-2026-52963)

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

netfilter: nft_ct: fix missing expect put in obj eval

nftctexpectobjeval() allocates an expectation and may call nfctexpect_related(), but never drops its local reference.

Add nfctexpect_put(exp) before return to balance allocation.(CVE-2026-52970)

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

netfilter: nfconntracksip: don't use simple_strtoul

Replace unsafe port parsing in epaddrlen(), ctsipparseheaderuri(), and ctsipparserequest() with a new sipparseport() helper that validates each digit against the buffer limit, eliminating the use of simple_strtoul() which assumes NUL-terminated strings.

The previous code dereferenced pointers without bounds checks after sipparseaddr() and relied on simple_strtoul() on non-NUL-terminated skb data. A port that reaches the buffer limit without a trailing character is also rejected as malformed.

Also get rid of all simple_strtoul() usage in conntrack, prefer a stricter version instead. There are intentional changes:

• Bail out if number is > UINT_MAX and indicate a failure, same for too long sequences. While we do accept 05535 as port 5535, we will not accept e.g. 'sip:10.0.0.1:005060'. While its syntactically valid under RFC 3261, we should restrict this to not waste cycles when presented with malformed packets with 64k '0' characters.

• Force base 10 in ctsipparsenumericalparam(). This is used to fetch 'expire=' and 'rports='; both are expected to use base-10.

• In nfnatsip.c, only accept the parsed value if its within the 1k-64k range.

• epaddrlen now returns 0 if the port is invalid, as it already does for invalid ip addresses. This is intentional. nfconntrack_sip performs lots of guesswork to find the right parts of the message to parse. Being stricter could break existing setups. Connection tracking helpers are designed to allow traffic to pass, not to block it.

Based on an earlier patch from Jenny Guanni Qu <(CVE-2026-52986)

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

sched/psi: fix race between file release and pressure write

A potential race condition exists between pressure write and cgroup file release regarding the priv member of struct kernfsopenfile, which triggers the uaf reported in [1].

Consider the following scenario involving execution on two separate CPUs:

CPU0 CPU1 ==== ==== vfsrmdir() kernfsioprmdir() cgrouprmdir() cgroupknlocklive() cgroupdestroylocked() cgroupaddrmfiles() cgrouprmfile() kernfsremovebyname() kernfsremovebynamens() vfs_write() _kernfsremove() newsyncwrite() kernfsdrain() kernfsfopwriteiter() kernfsdrainopenfiles() cgroupfilewrite() kernfsreleasefile() pressurewrite() cgroupfilerelease() ctx = of->priv; kfree(ctx); of->priv = NULL; cgroupknunlock() cgroupknlocklive() cgroupget(cgrp) cgroupknunlock() if (ctx->psi.trigger) // here, trigger uaf for ctx, that is of->priv

The cgrouprmdir() is protected by the cgroupmutex, it also safeguards the memory deallocation of of->priv performed within cgroupfilerelease(). However, the operations involving of->priv executed within pressurewrite() are not entirely covered by the protection of cgroupmutex. Consequently, if the code in pressurewrite(), specifically the section handling the ctx variable executes after cgroupfile_release() has completed, a uaf vulnerability involving of->priv is triggered.

Therefore, the issue can be resolved by extending the scope of the cgroupmutex lock within pressurewrite() to encompass all code paths involving of->priv, thereby properly synchronizing the race condition occurring between cgroupfilerelease() and pressure_write().

And, if an live kn lock can be successfully acquired while executing the pressure write operation, it indicates that the cgroup deletion process has not yet reached its final stage; consequently, the priv pointer within open_file cannot be NULL. Therefore, the operation to retrieve the ctx value must be moved to a point after the live kn lock has been successfully acquired.

In another situation, specifically after entering cgroupknlocklive() but before acquiring cgroupmutex, there exists a different class of race condition:

CPU0: write memory.pressure CPU1: write cgroup.pressure=0 =========================== =============================

kernfsfopwriteiter() kernfsgetactiveof(of) pressurewrite() cgroupknlocklive(memory.pressure) cgrouptryget(cgrp) kernfsbreakactiveprotection(kn) ... blocks on cgroup_mutex

                                      cgroup_pressure_write()
                                      cgroup_kn_lock_live(cgroup.pressure)
                                      cgroup_file_show(memory.pressure, false)
                                        kernfs_show(false)
                                          kernfs_drain_open_files()
                                            cgroup_file_release(of)
                                              kfree(ctx)
                                                of->priv = NULL
                                      cgroup_kn_unlock()

... acquires cgroup_mutex ctx = of->priv; // may now be NULL if (ctx->psi.trigger) // NULL dereference

Consequently, there is a possibility that of->priv is NULL, the pressure write needs to check for this.

Now that the scope of the cgroupmutex has been expanded, the original explicit cgroupget/put operations are no longer necessary, this is because acquiring/releasing the live kn lock inherently executes a cgroup get/put operation.

[1] BUG: KASAN: slab-use-after-free in pressurewrite+0xa4/0x210 kernel/cgroup/cgroup.c:4011 Call Trace: pressurewrite+0xa4/0x210 kernel/cgroup/cgroup.c:4011 cgroupfilewrite+0x36f/0x790 kernel/cgroup/cgroup.c:43 ---truncated---(CVE-2026-52991)

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

netfilter: nfnetlink_osf: fix potential NULL dereference in ttl check

The nfosfttl() function accessed skb->dev to perform a local interface address lookup without verifying that the device pointer was valid.

Additionally, the implementation utilized an indevforeachifa_rcu loop to match the packet source address against local interface addresses. It assumed that packets from the same subnet should not see a decrement on the initial TTL. A packet might appear it is from the same subnet but it actually isn't especially in modern environments with containers and virtual switching.

Remove the device dereference and interface loop. Replace the logic with a switch statement that evaluates the TTL according to the ttl_check.(CVE-2026-52998)

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

netfilter: conntrack: remove sprintf usage

Replace it with scnprintf, the buffer sizes are expected to be large enough to hold the result, no need for snprintf+overflow check.

Increase buffer size in manglecontentlen() while at it.

BUG: KASAN: stack-out-of-bounds in vsnprintf+0xea5/0x1270 Write of size 1 at addr [..] vsnprintf+0xea5/0x1270 sprintf+0xb1/0xe0 manglecontentlen+0x1ac/0x280 nfnatsdpsession+0x1cc/0x240 processsdp+0x8f8/0xb80 processinviterequest+0x108/0x2b0 processsipmsg+0x5da/0xf50 siphelptcp+0x45e/0x780 nf_confirm+0x34d/0x990 ..

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

gfs2: add some missing log locking

Function gfs2logd() calls the log flushing functions gfs2ail1start(), gfs2ail1wait(), and gfs2ail1empty() without holding sdp->sdlogflushlock, but these functions require exclusion against concurrent transactions.

To fix that, add a non-locking __gfs2logflush() function. Then, in gfs2logd(), take sdp->sdlogflushlock before calling the above mentioned log flushing functions and __gfs2logflush().(CVE-2026-53049)

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

Bluetooth: fix locking in hciconnrequestevt() with HCIPROTO_DEFER

When protocol sets HCIPROTODEFER, hciconnrequestevt() calls hciconnectcfm(conn) without hdev->lock. Generally hciconnect_cfm() assumes it is held, and if conn is deleted concurrently -> UAF.

Only SCO and ISO set HCIPROTODEFER and only for defer setup listen, and HCIEVCONNREQUEST is not generated for ISO. In the non-deferred listening socket code paths, hciconnect_cfm(conn) is called with hdev->lock held.

Fix by holding the lock.(CVE-2026-53072)

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

bus: fsl-mc: use generic driver_override infrastructure

When a driver is probed through __driverattach(), the bus' match() callback is called without the device lock held, thus accessing the driveroverride field without a lock, which can cause a UAF.

Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally.

Note that calling match() from _driverattach() without the device lock held is intentional. 1

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

USB: serial: kl5kusb105: fix bulk-out buffer overflow

klsi105preparewritebuffer() is called by the generic write path with the bulk-out buffer and its size (bulkoutsize, 64 bytes). It stores a two-byte length header at the start of the buffer and copies the payload from the write fifo starting at buf + KLSIHDRLEN, but passes the full buffer size as the number of bytes to copy:

count = kfifooutlocked(&port->writefifo, buf + KLSIHDR_LEN, size, &port->lock);

When the fifo holds at least size bytes, size bytes are copied starting two bytes into the size-byte buffer, writing KLSIHDRLEN bytes past its end. Copy at most size - KLSIHDRLEN bytes instead, leaving room for the header as safe_serial already does.

Writing bulkoutsize or more bytes to the tty triggers a slab out-of-bounds write, observed with KASAN by emulating the device with dummy_hcd and raw-gadget:

BUG: KASAN: slab-out-of-bounds in kfifocopyout+0x83/0xc0 Write of size 64 at addr ffff888112c62202 by task python3 kfifocopyout klsi105preparewritebuffer [kl5kusb105] usbserialgenericwritestart [usbserial] Allocated by task 139: usbserialprobe [usbserial] The buggy address is located 2 bytes inside of allocated 64-byte region

The out-of-bounds write no longer occurs with this change applied.(CVE-2026-53194)

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

USB: serial: ioti: fix heap overflow in buildi2cfwhdr()

buildi2cfwhdr() allocates a fixed-size buffer of (16*1024 - 512) + sizeof(struct tii2cfirmwarerec) bytes, then copies le16tocpu(img_header->Length) bytes into it without validating that Length fits within the available space after the firmware record header.

img_header->Length is a _le16 from the firmware file and can be up to 65535. checkfwsanity() validates the total firmware size but not imgheader->Length specifically.

Fix by rejecting images where img_header->Length exceeds the available destination space.(CVE-2026-53195)

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

Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig

net/bluetooth/l2capcore.c:l2capsigchannel() accepts BR/EDR signaling packets up to the channel MTU and dispatches each command without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer within radio range can send a fixed-channel CID 0x0001 packet that is larger than MTUsig and contains many L2CAPECHOREQ commands before pairing. In a real-radio stock-kernel run, one 681-byte signaling packet containing 168 zero-length ECHOREQ commands made the target transmit 168 ECHO_RSP frames over about 220 ms.

Impact: a Bluetooth BR/EDR peer within radio range, before pairing, can force 168 ECHORSP frames from one 681-byte fixed-channel signaling packet containing packed ECHOREQ commands.

Define Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and reject any larger signaling packet with one L2CAPCOMMANDREJECTRSP carrying L2CAPREJMTUEXCEEDED before any command is dispatched.

The Bluetooth Core spec wording for MTUExceeded says the reject identifier shall match the first request command in the packet, and that packets containing only responses shall be silently discarded. Linux intentionally deviates from that prescription: silently discarding desynchronizes the peer because the remote stack never learns its responses were dropped, and locating the first request command requires walking command headers past MTUsig, i.e. processing bytes from a packet we have already decided is too large to process. We therefore always emit one reject and use the identifier from the first command header, a single fixed-offset byte read.

The unrestricted BR/EDR signaling parser and ECHO_REQ response path both trace to the initial git import; no later introducing commit is available for a Fixes tag.(CVE-2026-53208)

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

tcp: restrict SOATTACHFILTER to priv users

This patch restricts the use of SOATTACHFILTER (cBPF) on TCP sockets to users with CAPNETADMIN capability.

This blocks potential side-channel attack where an unprivileged application attaches a filter to leak TCP sequence/acknowledgment numbers.(CVE-2026-53236)

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

netlabel: validate unlabeled address and mask attribute lengths

netlblunlabeladdrinfoget() used the address attribute length to determine whether the attribute data could be read as an IPv4 or IPv6 address, but did not independently validate the corresponding mask attribute length. A crafted Generic Netlink request could therefore provide a valid IPv4/IPv6 address attribute with a shorter mask attribute, which would later be read as a full struct inaddr or struct in6_addr.

NLABINARY policy lengths are maximum lengths by default, so use NLAPOLICYEXACTLEN() for the unlabeled IPv4/IPv6 address and mask attributes. This rejects short attributes during policy validation and also exposes the exact length requirements through policy introspection.(CVE-2026-53238)

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

net/802/mrp: fix vector attribute parsing in mrppduparse_vecattr

In mrppduparse_vecattr(), vector attribute events are encoded three per byte and valen tracks the number of events left to process.

The parser decrements valen after processing the first and second events from each event byte, but not after processing the third one. When valen is exactly a multiple of three, the loop continues after the last valid event and consumes the next byte as a new event byte, applying a spurious event to the MRP applicant state.

Additionally, when valen is zero the parser unconditionally consumes attrlen bytes as FirstValue and advances the offset, even though per IEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of zero and no FirstValue or Vector fields. This corrupts the offset for subsequent PDU parsing.

Also, when valen exceeds three the loop crosses byte boundaries but the attribute value is not incremented between the last event of one byte and the first event of the next. This causes the first event of the next byte to use the same attribute value as the third event rather than the next consecutive value.

Decrement valen after processing the third event, skip FirstValue consumption when valen is zero, and increment the attribute value at the end of each loop iteration.(CVE-2026-53245)

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

ipv4: restrict IPOPTSSRR and IPOPTLSRR options

This patch restricts setting Loose Source and Record Route (LSRR) and Strict Source and Record Route (SSRR) IP options to users with CAPNETRAW capability.

This prevents unprivileged applications from forcing packets to route through attacker-controlled nodes to leak TCP ISN and possibly other protocol information.

While LSRR and SSRR are commonly filtered in many network environments, they may still be supported and forwarded along some network paths.

RFC 7126 (Recommendations on Filtering of IPv4 Packets Containing IPv4 Options) recommend to drop these options in 4.3 and 4.4.(CVE-2026-53249)

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

Bluetooth: fix memory leak in error path of hciallocdev()

Early failures in Bluetooth HCI UART configuration leak SRCU percpu memory.

When device initialization fails before hciregisterdev() completes, the HCIUNREGISTER flag is never set. As a result, when the device reference count reaches zero, bthost_release() evaluates this flag as false and falls back to a direct kfree(hdev).

Because hcireleasedev() is bypassed, the SRCU struct initialized early in hciallocdev() is never cleaned up, resulting in a leak of percpu memory.

Fix the leak by explicitly calling cleanupsrcustruct() in the fallback (unregistered) branch of bthostrelease() before freeing the device.(CVE-2026-53252)

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

netfilter: bridge: make ebt_snat ARP rewrite writable

The ebtables SNAT target keeps the Ethernet source address rewrite behind skbensurewritable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skbmacheader()/ethhdr(), while skb->data points at the Ethernet payload. Asking skbensurewritable() for ETHHLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a.

However, the optional ARP sender hardware address rewrite is different. It writes through skbstorebits() at an offset relative to skb->data:

    skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN)

skbheaderpointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skbstorebits() maps the frag page and copies the new MAC address directly into it.

Ensure the ARP SHA range is writable before reading the ARP header and before calling skbstorebits().(CVE-2026-53266)

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

netfilter: conntrack_irc: fix possible out-of-bounds read

When parsing fails after we've matched the command string we should bail out instead of trying to match a different command.

This helper should be deprecated, given prevalence of TLS I doubt it has any relevance in 2026.(CVE-2026-53268)

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

netfilter: synproxy: add mutex to guard hook reference counting

As the synproxy infrastructure register netfilter hooks on-demand when a user adds the first iptables target or nftables expression, if done concurrently they can race each other.

Introduce a mutex to serialize the refcount control blocks access from both frontends. While a per namespace mutex might be more efficient, it is not needed for target/expression like SYNPROXY.(CVE-2026-53269)

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

ipvs: clear the svc scheduler ptr early on edit

ipvseditservice() while unbinding the old scheduler clears the svc->scheduler ptr after the scheduler module initiates RCU callbacks. This can cause packets to use the old scheduler at the time when svc->scheddata is already freed after RCU grace period.

Fix it by clearing the ptr early in ipvsunbindscheduler(), before the doneservice method schedules any RCU callbacks.

Also, if the new scheduler fails to initialize when replacing the old scheduler, try to restore the old scheduler while still returning the error code.(CVE-2026-53270)

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

ipv6: mcast: Fix use-after-free when processing MLD queries

When processing an MLD query, a pointer to the multicast group address is retrieved when initially parsing the packet. This pointer is later dereferenced without being reloaded despite the fact that the skb header might have been reallocated following the pskbmaypull() calls, leading to a use-after-free [1].

Fix by copying the multicast group address when the packet is initially parsed.

[1] BUG: KASAN: slab-use-after-free in __mldquerywork (net/ipv6/mcast.c:1512) Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118

Workqueue: mld mldquerywork Call Trace: <TASK> dumpstacklvl (lib/dumpstack.c:94 lib/dumpstack.c:120) printaddressdescription.constprop.0 (mm/kasan/report.c:378) printreport (mm/kasan/report.c:482) kasanreport (mm/kasan/report.c:595) _mldquerywork (net/ipv6/mcast.c:1512) mldquerywork (net/ipv6/mcast.c:1563) processonework (kernel/workqueue.c:3314) workerthread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) retfromfork (arch/x86/kernel/process.c:158) retfromforkasm (arch/x86/entry/entry64.S:245) </TASK>

[...]

Freed by task 118: kasansavestack (mm/kasan/common.c:57) kasansavetrack (mm/kasan/common.c:78) kasansavefree_info (mm/kasan/generic.c:584) __kasanslabfree (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566) pskbexpandhead (net/core/skbuff.c:2335) __pskbpulltail (net/core/skbuff.c:2878 (discriminator 4)) _mldquerywork (net/ipv6/mcast.c:1495 (discriminator 1)) mldquerywork (net/ipv6/mcast.c:1563) processonework (kernel/workqueue.c:3314) workerthread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) retfromfork (arch/x86/kernel/process.c:158) retfromforkasm (arch/x86/entry/entry64.S:245)(CVE-2026-53275)

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

Bluetooth: fix UAF in l2capsockcleanuplisten() vs l2capconn_del()

btacceptdequeue() unlinks a not-yet-accepted child from the parent accept queue and release_sock()s it before returning, so the returned sk has no caller reference and is unlocked.

l2capsockcleanuplisten() walks these children on listening-socket close. A concurrent HCI disconnect drives hcirxwork -> l2capconndel() which runs l2capchandel() + l2capsockkill() and frees the child sk and its l2capchan; cleanup_listen() then uses both:

BUG: KASAN: slab-use-after-free in l2capsockkill l2capsockkill / l2capsockcleanup_listen / _x64sysclose Freed by: l2capconndel -> l2capsockclosecb -> l2capsockkill

This is distinct from the two fixes already in this area: commit e83f5e24da741 ("Bluetooth: serialize acceptq access") serialises the acceptq list/poll and takes temporary refs inside btacceptdequeue(), and CVE-2025-39860 serialises the userspace close()/accept() race by calling cleanuplisten() under locksock() in l2capsockrelease(). Neither covers l2capconndel() running from hcirxwork, so this UAF still reproduces on current bluetooth/master.

Take the reference at the source: btacceptdequeue() does sockhold() while sk is still locked, before releasesock(); callers sockput(). cleanuplisten() pins the chan with l2capchanholdunlesszero() under a brief child sk lock (serialising vs l2capsockteardowncb()), drops it before l2capchanlock(), and skips a duplicate l2capsockkill() on SOCKDEAD. conn->lock is not taken here: cleanuplisten() runs under the parent sk lock and that would invert conn->lock -> chan->lock -> sklock (lockdep).

KASAN/SMP: an unprivileged listen/close vs HCI-disconnect race produced 12 use-after-free reports per run before this change; 0, and no lockdep report, over 1600+ raced iterations after it on bluetooth/master.(CVE-2026-53357)