OESA-2026-3529

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

thermal: core: Fix thermal zone governor cleanup issues

If thermalzonedeviceregisterwith_trips() fails after adding a thermal governor to the thermal zone being registered, the governor is not removed from it as appropriate which may lead to a memory leak.

In turn, thermalzonedeviceunregister() calls thermalset_governor() without acquiring the thermal zone lock beforehand which may race with a governor update via sysfs and may lead to a use-after-free in that case.

Address these issues by adding two thermalsetgovernor() calls, one to thermal_release() to remove the governor from the given thermal zone, and one to the thermal zone registration error path to cover failures preceding the thermal zone device registration.(CVE-2026-46021)

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

crypto: authencesn - reject short ahash digests during instance creation

authencesn requires either a zero authsize or an authsize of at least 4 bytes because the ESN encrypt/decrypt paths always move 4 bytes of high-order sequence number data at the end of the authenticated data.

While cryptoauthencesnsetauthsize() already rejects explicit non-zero authsizes in the range 1..3, cryptoauthencesncreate() still copied auth->digestsize into inst->alg.maxauthsize without validating it. The AEAD core then initialized the tfm's default authsize from that value.

As a result, selecting an ahash with digest size 1..3, such as cbcmac(ciphernull), exposed authencesn instances whose default authsize was invalid even though setauthsize() would have rejected the same value. AFALG could then trigger the ESN tail handling with a too-short tag and hit an out-of-bounds access.

Reject authencesn instances whose ahash digest size is in the invalid non-zero range 1..3 so that no tfm can inherit an unsupported default authsize.(CVE-2026-46033)

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

mm/damon/sysfs-schemes: protect memcgpath kfree() with damonsysfs_lock

Patch series "mm/damon/sysfs-schemes: fix use-after-free for [memcg_]path".

Reads of 'memcg_path' and 'path' files in DAMON sysfs interface could race with their writes, results in use-after-free. Fix those.

This patch (of 2):

damonsysfsschemefilter->mmecgpath can be read and written by users, via DAMON sysfs memcgpath file. It can also be indirectly read, for the parameters {on,off}line committing to DAMON. The reads for parameters committing are protected by damonsysfslock to avoid the sysfs files being destroyed while any of the parameters are being read. But the user-driven direct reads and writes are not protected by any lock, while the write is deallocating the memcgpath-pointing buffer. As a result, the readers could read the already freed buffer (user-after-free). Note that the user-reads don't race when the same open file is used by the writer, due to kernfs's open file locking. Nonetheless, doing the reads and writes with separate open files would be common. Fix it by protecting both the user-direct reads and writes with damonsysfslock.(CVE-2026-46121)

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

Bluetooth: hcildisc: Clear HCIUARTPROTOINIT on error

When hciregisterdev() fails in hciuartregisterdev() HCIUARTPROTOINIT is not cleared before calling hu->proto->close(hu) and setting hu->hdev to NULL. This means incoming UART data will reach the protocol-specific recv handler in hciuarttty_receive() after resources are freed.

Clear HCIUARTPROTO_INIT with a write lock before calling hu->proto->close() and setting hu->hdev to NULL. The write lock ensures all active readers have completed and no new reader can enter the protocol recv path before resources are freed.

This allows the protocol-specific recv functions to remove the "HCIUARTREGISTERED" guard without risking a null pointer dereference if hciregisterdev() fails.(CVE-2026-53073)

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

thunderbolt: Clamp XDomain response data copy to allocation size

tbxdppropertiesrequest() derives the per-packet copy length from the response header without checking that it fits in the previously allocated data buffer. A malicious peer can set its length field larger than the declared datalength, causing memcpy to write past the kcalloc allocation.

Clamp the per-packet copy length so that the cumulative offset never exceeds data_len.(CVE-2026-53148)

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

fuse: limit FUSENOTIFYRETRIEVE to uptodate folios

FUSENOTIFYRETRIEVE must be limited to uptodate folios; !uptodate folios can contain uninitialized data. Since FUSENOTIFYRETRIEVE is intended to only return data that is already in the page cache and not wait for data from the FUSE daemon, treat !uptodate folios as if they weren't present.

This only has security impact on systems that don't enable automatic zero-initialization of all page allocations via CONFIGINITONALLOCDEFAULTON or initon_alloc=1.(CVE-2026-53167)

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

fuse: reject fuse_notify() pagecache ops on directories

The operations FUSENOTIFYSTORE and FUSENOTIFYRETRIEVE allow the FUSE daemon to actively write/read pagecache contents.

For directories with FOPENCACHEDIR, the pagecache is used as kernel-internal cache storage, and userspace is not supposed to have direct access to this cache - in particular, fuseparsecache() will hit WARN_ON() if the cache contains bogus data.

Reject FUSENOTIFYSTORE and FUSENOTIFYRETRIEVE on anything other than regular files with -EINVAL.(CVE-2026-53168)

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)