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

serial: core: fix infinite loop in handletx() for PORTUNKNOWN

uartwriteroom() and uartwrite() behave inconsistently when xmitbuf is NULL (which happens for PORTUNKNOWN ports that were never properly initialized):

- uartwriteroom() returns kfifoavail() which can be > 0 - uartwrite() checks xmitbuf and returns 0 if NULL

This inconsistency causes an infinite loop in drivers that rely on ttywriteroom() to determine if they can write:

while (ttywriteroom(tty) > 0) { written = tty->ops->write(...); // written is always 0, loop never exits }

For example, caifserial's handletx() enters an infinite loop when used with PORTUNKNOWN serial ports, causing system hangs.

Fix by making uartwriteroom() also check xmitbuf and return 0 if it's NULL, consistent with uartwrite().

Reproducer: https://gist.github.com/mrpre/d9a694cc0e19828ee3bc3b37983fde13

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

drm/xe/sync: Cleanup partially initialized sync on parse failure

xesyncentryparse() can allocate references (syncobj, fence, chain fence, or user fence) before hitting a later failure path. Several of those paths returned directly, leaving partially initialized state and leaking refs.

Route these error paths through a common freesync label and call xesyncentrycleanup(sync) before returning the error.

(cherry picked from commit f939bdd9207a5d1fc55cced5459858480686ce22)

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

EFI/CPER: don't dump the entire memory region

The current logic at cperprintfwerr() doesn't check if the error record length is big enough to handle offset. On a bad firmware, if the ofset is above the actual record, length -= offset will underflow, making it dump the entire memory.

The end result can be:

- the logic taking a lot of time dumping large regions of memory; - data disclosure due to the memory dumps; - an OOPS, if it tries to dump an unmapped memory region.

Fix it by checking if the section length is too small before doing a hex dump.

[ rjw: Subject tweaks ]

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

net/mlx5e: RX, Fix XDP multi-buf frag counting for striding RQ

XDP multi-buf programs can modify the layout of the XDP buffer when the program calls bpfxdppulldata() or bpfxdpadjusttail(). The referenced commit in the fixes tag corrected the assumption in the mlx5 driver that the XDP buffer layout doesn't change during a program execution. However, this fix introduced another issue: the dropped fragments still need to be counted on the driver side to avoid page fragment reference counting issues.

The issue was discovered by the drivers/net/xdp.py selftest, more specifically the testxdpnativetxmb: - The mlx5 driver allocates a pagepool page and initializes it with a frag counter of 64 (pprefcount=64) and the internal frag counter to 0. - The test sends one packet with no payload. - On RX (mlx5eskbfromcqempwrqnonlinear()), mlx5 configures the XDP buffer with the packet data starting in the first fragment which is the page mentioned above. - The XDP program runs and calls bpfxdppulldata() which moves the header into the linear part of the XDP buffer. As the packet doesn't contain more data, the program drops the tail fragment since it no longer contains any payload (pprefcount=63). - mlx5 device skips counting this fragment. Internal frag counter remains 0. - mlx5 releases all 64 fragments of the page but page pprefcount is 63 => negative reference counting error.

Resulting splat during the test:

WARNING: CPU: 0 PID: 188225 at ./include/net/pagepool/helpers.h:297 mlx5epagereleasefragmented.isra.0+0xbd/0xe0 [mlx5core] Modules linked in: [...] CPU: 0 UID: 0 PID: 188225 Comm: ip Not tainted 6.18.0-rc7forupstreammindebug202512081144 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5epagereleasefragmented.isra.0+0xbd/0xe0 [mlx5core] [...] Call Trace: <TASK> mlx5efreerxmpwqe+0x20a/0x250 [mlx5core] mlx5edeallocrxmpwqe+0x37/0xb0 [mlx5core] mlx5efreerxdescs+0x11a/0x170 [mlx5core] mlx5ecloserq+0x78/0xa0 [mlx5core] mlx5eclosequeues+0x46/0x2a0 [mlx5core] mlx5eclosechannel+0x24/0x90 [mlx5core] mlx5eclosechannels+0x5d/0xf0 [mlx5core] mlx5esafeswitchparams+0x2ec/0x380 [mlx5core] mlx5echangemtu+0x11d/0x490 [mlx5core] mlx5echangenicmtu+0x19/0x30 [mlx5core] netifsetmtuext+0xfc/0x240 dosetlink.isra.0+0x226/0x1100 rtnlnewlink+0x7a9/0xba0 rtnetlinkrcvmsg+0x220/0x3c0 netlinkrcvskb+0x4b/0xf0 netlinkunicast+0x255/0x380 netlinksendmsg+0x1f3/0x420 socksendmsg+0x38/0x60 syssendmsg+0x1e8/0x240 syssendmsg+0x7c/0xb0 [...] syssendmsg+0x5f/0xb0 dosyscall64+0x55/0xc70

The problem applies for XDPPASS as well which is handled in a different code path in the driver.

This patch fixes the issue by doing page frag counting on all the original XDP buffer fragments for all relevant XDP actions (XDPTX , XDPREDIRECT and XDPPASS). This is basically reverting to the original counting before the commit in the fixes tag.

As fragpage is still pointing to the original tail, the nrfrags parameter to xdpupdateskbfragsinfo() needs to be calculated in a different way to reflect the new nrfrags.

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

xfrm: iptfs: fix skbput() panic on non-linear skb during reassembly

In iptfsreassemcont(), IP-TFS attempts to append data to the new inner packet 'newskb' that is being reassembled. First a zero-copy approach is tried if it succeeds then newskb becomes non-linear.

When a subsequent fragment in the same datagram does not meet the fast-path conditions, a memory copy is performed. It calls skbput() to append the data and as newskb is non-linear it triggers SKBLINEARASSERT check.

Oops: invalid opcode: 0000 [#1] SMP NOPTI [...] RIP: 0010:skbput+0x3c/0x40 [...] Call Trace: <IRQ> iptfsreassemcont+0x1ab/0x5e0 [xfrmiptfs] iptfsinputordered+0x2af/0x380 [xfrmiptfs] iptfsinput+0x122/0x3e0 [xfrmiptfs] xfrminput+0x91e/0x1a50 xfrm4esprcv+0x3a/0x110 ipprotocoldeliverrcu+0x1d7/0x1f0 iplocaldeliverfinish+0xbe/0x1e0 netifreceiveskbcore.constprop.0+0xb56/0x1120 netifreceiveskblistcore+0x133/0x2b0 netifreceiveskblistinternal+0x1ff/0x3f0 napicompletedone+0x81/0x220 virtnetpoll+0x9d6/0x116e [virtionet] napipoll.constprop.0+0x2b/0x270 netrxaction+0x162/0x360 handlesoftirqs+0xdc/0x510 irqexitrcu+0xe7/0x110 irqexitrcu+0xe/0x20 commoninterrupt+0x85/0xa0 </IRQ> <TASK>

Fix this by checking if the skb is non-linear. If it is, linearize it by calling skblinearize(). As the initial allocation of newskb originally reserved enough tailroom for the entire reassembled packet we do not need to check if we have enough tailroom or extend it.

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

drm/amd/display: Do not skip unrelated mode changes in DSC validation

Starting with commit 17ce8a6907f7 ("drm/amd/display: Add dsc pre-validation in atomic check"), amdgpu resets the CRTC state modechanged flag to false when recomputing the DSC configuration results in no timing change for a particular stream.

However, this is incorrect in scenarios where a change in MST/DSC configuration happens in the same KMS commit as another (unrelated) mode change. For example, the integrated panel of a laptop may be configured differently (e.g., HDR enabled/disabled) depending on whether external screens are attached. In this case, plugging in external DP-MST screens may result in the modechanged flag being dropped incorrectly for the integrated panel if its DSC configuration did not change during precomputation in prevalidatedsc().

At this point, however, dmupdatecrtcstate() has already created new streams for CRTCs with DSC-independent mode changes. In turn, amdgpudmcommitstreams() will never release the old stream, resulting in a memory leak. amdgpudmatomiccommittail() will never acquire a reference to the new stream either, which manifests as a use-after-free when the stream gets disabled later on:

BUG: KASAN: use-after-free in dcstreamrelease+0x25/0x90 [amdgpu] Write of size 4 at addr ffff88813d836524 by task kworker/9:9/29977

Workqueue: events drmmodermfbworkfn Call Trace: <TASK> dumpstacklvl+0x6e/0xa0 printaddressdescription.constprop.0+0x88/0x320 ? dcstreamrelease+0x25/0x90 [amdgpu] printreport+0xfc/0x1ff ? srsoaliasreturnthunk+0x5/0xfbef5 ? virtaddrvalid+0x225/0x4e0 ? dcstreamrelease+0x25/0x90 [amdgpu] kasanreport+0xe1/0x180 ? dcstreamrelease+0x25/0x90 [amdgpu] kasancheckrange+0x125/0x200 dcstreamrelease+0x25/0x90 [amdgpu] dcstatedestruct+0x14d/0x5c0 [amdgpu] dcstaterelease.part.0+0x4e/0x130 [amdgpu] dmatomicdestroystate+0x3f/0x70 [amdgpu] drmatomicstatedefaultclear+0x8ee/0xf30 ? drmmodeobjectput.part.0+0xb1/0x130 drmatomicstatefree+0x15c/0x2d0 atomicremovefb+0x67e/0x980

Since there is no reliable way of figuring out whether a CRTC has unrelated mode changes pending at the time of DSC validation, remember the value of the modechanged flag from before the point where a CRTC was marked as potentially affected by a change in DSC configuration. Reset the modechanged flag to this earlier value instead in prevalidatedsc().

(cherry picked from commit cc7c7121ae082b7b82891baa7280f1ff2608f22b)

dlm: validate length in dlmsearchrsbtree

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

crypto: caam - fix DMA corruption on long hmac keys

When a key longer than block size is supplied, it is copied and then hashed into the real key. The memory allocated for the copy needs to be rounded to DMA cache alignment, as otherwise the hashed key may corrupt neighbouring memory.

The rounding was performed, but never actually used for the allocation. Fix this by replacing kmemdup with kmalloc for a larger buffer, followed by memcpy.

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

auxdisplay: line-display: fix NULL dereference in linedisprelease

linedisprelease() currently retrieves the enclosing struct linedisp via tolinedisp(). That lookup depends on the attachment list, but the attachment may already have been removed before putdevice() invokes the release callback. This can happen in linedispunregister(), and can also be reached from some linedispregister() error paths.

In that case, tolinedisp() returns NULL and linedisprelease() dereferences it while freeing the display resources.

The struct device released here is the embedded linedisp->dev used by linedispregister(), so retrieve the enclosing object directly with containerof() instead.

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

net: macb: properly unregister fixed rate clocks

The additional resources allocated with clkregisterfixedrate() need to be released with clkunregisterfixedrate(), otherwise they are lost.

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

f2fs: fix to avoid uninit-value access in f2fssanitychecknodefooter

syzbot reported a f2fs bug as below:

BUG: KMSAN: uninit-value in f2fssanitychecknodefooter+0x374/0xa20 fs/f2fs/node.c:1520 f2fssanitychecknodefooter+0x374/0xa20 fs/f2fs/node.c:1520 f2fsfinishreadbio+0xe1e/0x1d60 fs/f2fs/data.c:177 f2fsreadendio+0x6ab/0x2220 fs/f2fs/data.c:-1 bioendio+0x1006/0x1160 block/bio.c:1792 submitbionoacct+0x533/0x2960 block/blk-core.c:891 submitbio+0x57a/0x620 block/blk-core.c:926 blkcryptosubmitbio include/linux/blk-crypto.h:203 [inline] f2fssubmitreadbio+0x12c/0x360 fs/f2fs/data.c:557 f2fssubmitpagebio+0xee2/0x1450 fs/f2fs/data.c:775 readnodefolio+0x384/0x4b0 fs/f2fs/node.c:1481 getnodefolio+0x5db/0x15d0 fs/f2fs/node.c:1576 f2fsgetinodefolio+0x40/0x50 fs/f2fs/node.c:1623 doreadinode fs/f2fs/inode.c:425 [inline] f2fsiget+0x1209/0x9380 fs/f2fs/inode.c:596 f2fsfillsuper+0x8f5a/0xb2e0 fs/f2fs/super.c:5184 gettreebdevflags+0x6e6/0x920 fs/super.c:1694 gettreebdev+0x38/0x50 fs/super.c:1717 f2fsgettree+0x35/0x40 fs/f2fs/super.c:5436 vfsgettree+0xb3/0x5d0 fs/super.c:1754 fcmount fs/namespace.c:1193 [inline] donewmountfc fs/namespace.c:3763 [inline] donewmount+0x885/0x1dd0 fs/namespace.c:3839 pathmount+0x7a2/0x20b0 fs/namespace.c:4159 domount fs/namespace.c:4172 [inline] dosysmount fs/namespace.c:4361 [inline] sesysmount+0x704/0x7f0 fs/namespace.c:4338 x64sysmount+0xe4/0x150 fs/namespace.c:4338 x64syscall+0x39f0/0x3ea0 arch/x86/include/generated/asm/syscalls64.h:166 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0x134/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

The root cause is: in f2fsfinishreadbio(), we may access uninit data in folio if we failed to read the data from device into folio, let's add a check condition to avoid such issue.

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

ipc/shm: serialize orphan cleanup with shmnattch updates

shmdestroyorphaned() walks the shm idr under shmids(ns).rwsem, but that does not serialize all fields tested by shmmaydestroy(). In particular, shmnattch is updated while holding shmperm.lock, and attach paths can do that without holding the rwsem.

Do not decide that an orphaned segment is unused before taking the object lock. Move the shmmaydestroy() check under shmperm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal.

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

smb: client: validate the whole DACL before rewriting it in cifsacl

buildsecdesc() and idmodetocifsacl() derive a DACL pointer from a server-supplied dacloffset and then use the incoming ACL to rebuild the chmod/chown security descriptor.

The original fix only checked that the struct smbacl header fits before reading daclptr->size or daclptr->numaces. That avoids the immediate header-field OOB read, but the rewrite helpers still walk ACEs based on pdacl->numaces with no structural validation of the incoming DACL body.

A malicious server can return a truncated DACL that still contains a header, claims one or more ACEs, and then drive replacesidsandcopyaces() or setchmoddacl() past the validated extent while they compare or copy attacker-controlled ACEs.

Factor the DACL structural checks into validatedacl(), extend them to validate each ACE against the DACL bounds, and use the shared validator before the chmod/chown rebuild paths. parsedacl() reuses the same validator so the read-side parser and write-side rewrite paths agree on what constitutes a well-formed incoming DACL.

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

net/sched: netem: fix queue limit check to include reordered packets

The queue limit check in netemenqueue() uses q->tlen which only counts packets in the internal tfifo. Packets placed in sch->q by the reorder path (qdiscenqueuehead) are not counted, allowing the total queue occupancy to exceed sch->limit under reordering.

Include sch->q.qlen in the limit check.

dm cache: fix dirty mapping checking in passthrough mode switching

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

pppoe: drop PFC frames

RFC 2516 Section 7 states that Protocol Field Compression (PFC) is NOT RECOMMENDED for PPPoE. In practice, pppd does not support negotiating PFC for PPPoE sessions, and the current PPPoE driver assumes an uncompressed (2-byte) protocol field. However, the generic PPP layer function pppinput() is not aware of the negotiation result, and still accepts PFC frames.

If a peer with a broken implementation or an attacker sends a frame with a compressed (1-byte) protocol field, the subsequent PPP payload is shifted by one byte. This causes the network header to be 4-byte misaligned, which may trigger unaligned access exceptions on some architectures.

To reduce the attack surface, drop PPPoE PFC frames. Introduce pppskbiscompressedproto() helper function to be used in both pppgeneric.c and pppoe.c to avoid open-coding.

drm/amdgpu/sdma4: replace BUGON with WARNON in fence emission

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

iommu/riscv: Add IOTINVAL after updating DDT/PDT entries

Add riscviommuiodiriotinval() to perform required TLB and context cache invalidations after updating DDT or PDT entries, as mandated by the RISC-V IOMMU specification (Section 6.3.1 and 6.3.2).

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

RDMA/mlx5: Fix error path fall-through in mlx5ibdevressrqinit()

mlx5ibdevressrqinit() allocates two SRQs, s0 and s1. When ibcreatesrq() fails for s1, the error branch destroys s0 but falls through and unconditionally assigns the freed s0 and the ERRPTR s1 to devr->s0 and devr->s1.

This leads to several problems: the lock-free fast path checks "if (devr->s1) return 0;" and treats the ERRPTR as already initialised; users in mlx5ibcreateqp() dereference the freed SRQ or ERRPTR via tomsrq(devr->s0)->msrq.srqn; and mlx5ibdevrescleanup() dereferences the ERRPTR and double-frees s0 on teardown.

Fix by adding the same goto unlock in the s1 failure path.

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

RDMA/hns: Fix unlocked call to hnsroceqpremove()

Sashiko points out that hnsroceqpremove() requires the caller to hold locks. The error flow in hnsrocecreateqpcommon() doesn't hold those locks for the error unwind so it risks corrupting memory.

Grab the same locks the other two callers use.

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

selinux: use sk blob accessor in socket permission helpers

SELinux socket state lives in the composite LSM socket blob.

sockhasperm() and nlmsgsockhasextendedperms() currently dereference sk->sksecurity directly, which assumes the SELinux socket blob is at offset zero.

In stacked configurations that assumption does not hold. If another LSM allocates socket blob storage before SELinux, these helpers may read the wrong blob and feed invalid SID and class values into AVC checks.

Use selinuxsock() instead of accessing sk->sksecurity directly.

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

usb: ulpi: fix memory leak on ulpiregister() error paths

Commit 01af542392b5 ("usb: ulpi: fix double free in ulpiregisterinterface() error path") removed kfree(ulpi) from ulpiregisterinterface() to fix a double-free when deviceregister() fails.

But when ulpiofregister() or ulpireadid() fail before deviceregister() is called, the ulpi allocation is leaked.

Add kfree(ulpi) on both error paths to properly clean up the allocation.

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

serial: caif: fix use-after-free in caifserial ldiscclose()

There is a use-after-free bug in caifserial where handletx() may access ser->tty after the tty has been freed.

The race condition occurs between ldiscclose() and packet transmission:

CPU 0 (close) CPU 1 (xmit) ------------- ------------ ldiscclose() ttykrefput(ser->tty) [tty may be freed here] <-- race window --> caifxmit() handletx() tty = ser->tty // dangling ptr tty->ops->write() // UAF! schedulework() serrelease() unregisternetdevice()

The root cause is that ttykrefput() is called in ldiscclose() while the network device is still active and can receive packets.

Since ser and tty have a 1:1 binding relationship with consistent lifecycles (ser is allocated in ldiscopen and freed in serrelease via unregisternetdevice, and each ser binds exactly one tty), we can safely defer the tty reference release to serrelease() where the network device is unregistered.

Fix this by moving ttykrefput() from ldiscclose() to serrelease(), after unregisternetdevice(). This ensures the tty reference is held as long as the network device exists, preventing the UAF.

Note: We save ser->tty before unregisternetdevice() because ser is embedded in netdev's private data and will be freed along with netdev (needsfreenetdev = true).

How to reproduce: Add mdelay(500) at the beginning of ldiscclose() to widen the race window, then run the reproducer program [1].

Note: There is a separate deadloop issue in handletx() when using PORTUNKNOWN serial ports (e.g., /dev/ttyS3 in QEMU without proper serial backend). This deadloop exists even without this patch, and is likely caused by inconsistency between uartwriteroom() and uartwrite() in serial core. It has been addressed in a separate patch [2].

KASAN report:

================================================================== BUG: KASAN: slab-use-after-free in handletx+0x5d1/0x620 Read of size 1 at addr ffff8881131e1490 by task caifuaftrigge/9929

Call Trace: <TASK> dumpstacklvl+0x10e/0x1f0 printreport+0xd0/0x630 kasanreport+0xe4/0x120 handletx+0x5d1/0x620 devhardstartxmit+0x9d/0x6c0 devqueuexmit+0x6e2/0x4410 packetxmit+0x243/0x360 packetsendmsg+0x26cf/0x5500 syssendto+0x4a3/0x520 x64syssendto+0xe0/0x1c0 dosyscall64+0xc9/0xf80 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f615df2c0d7

Allocated by task 9930:

Freed by task 64:

Last potentially related work creation:

The buggy address belongs to the object at ffff8881131e1000 which belongs to the cache kmalloc-cg-2k of size 2048 The buggy address is located 1168 bytes inside of freed 2048-byte region [ffff8881131e1000, ffff8881131e1800)

The buggy address belongs to the physical page: pageowner tracks the page as allocated page last free pid 9778 tgid 9778 stack trace:

Memory state around the buggy address: ffff8881131e1380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881131e1400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881131e1480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881131e1500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881131e1580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== [1]: https://gist.github.com/mrpre/f683f244544f7b11e7fa87df9e6c2eeb [2]: https://lore.kernel.org/linux-serial/20260204074327.226165-1-jiayuan.chen@linux.dev/T/#u

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

hwmon: (pt5161l) Fix bugs in pt5161lreadblockdata()

Fix two bugs in pt5161lreadblockdata():

1. Buffer overrun: The local buffer rbuf is declared as u8 rbuf[24], but i2csmbusreadblockdata() can return up to I2CSMBUSBLOCKMAX (32) bytes. The i2c-core copies the data into the caller's buffer before the return value can be checked, so the post-read length validation does not prevent a stack overrun if a device returns more than 24 bytes. Resize the buffer to I2CSMBUSBLOCKMAX.

2. Unexpected positive return on length mismatch: When all three retries are exhausted because the device returns data with an unexpected length, i2csmbusreadblockdata() returns a positive byte count. The function returns this directly, and callers treat any non-negative return as success, processing stale or incomplete buffer contents. Return -EIO when retries are exhausted with a positive return value, preserving the negative error code on I2C failure.

afkey: validate families in pfkeysendmigrate()

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 deviceadd() 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 deviceadd().

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

cxl/mbox: validate payload size before accessing contents in cxlpayloadfromuserallowed()

cxlpayloadfromuserallowed() casts and dereferences the input payload without first verifying its size. When a raw mailbox command is sent with an undersized payload (ie: 1 byte for CXLMBOXOPCLEARLOG, which expects a 16-byte UUID), uuidequal() reads past the allocated buffer, triggering a KASAN splat:

BUG: KASAN: slab-out-of-bounds in memcmp+0x176/0x1d0 lib/string.c:683 Read of size 8 at addr ffff88810130f5c0 by task syz.1.62/2258

CPU: 2 UID: 0 PID: 2258 Comm: syz.1.62 Not tainted 6.19.0-dirty #3 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0xab/0xe0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xce/0x650 mm/kasan/report.c:482 kasanreport+0xce/0x100 mm/kasan/report.c:595 memcmp+0x176/0x1d0 lib/string.c:683 uuidequal include/linux/uuid.h:73 [inline] cxlpayloadfromuserallowed drivers/cxl/core/mbox.c:345 [inline] cxlmboxcmdctor drivers/cxl/core/mbox.c:368 [inline] cxlvalidatecmdfromuser drivers/cxl/core/mbox.c:522 [inline] cxlsendcmd+0x9c0/0xb50 drivers/cxl/core/mbox.c:643 cxlmemdevioctl drivers/cxl/core/memdev.c:698 [inline] cxlmemdevioctl+0x14f/0x190 drivers/cxl/core/memdev.c:713 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:597 [inline] sesysioctl fs/ioctl.c:583 [inline] x64sysioctl+0x18e/0x210 fs/ioctl.c:583 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xa8/0x330 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7fdaf331ba79 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:00007fdaf1d77038 EFLAGS: 00000246 ORIGRAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fdaf3585fa0 RCX: 00007fdaf331ba79 RDX: 00002000000001c0 RSI: 00000000c030ce02 RDI: 0000000000000003 RBP: 00007fdaf33749df R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fdaf3586038 R14: 00007fdaf3585fa0 R15: 00007ffced2af768 </TASK>

Add 'insize' parameter to cxlpayloadfromuserallowed() and validate the payload is large enough.

btrfs: do not strictly require dirty metadata threshold for metadata writepages

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

tcp: secureseq: add back ports to TS offset

This reverts 28ee1b746f49 ("secureseq: 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.

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

nfc: llcp: Fix memleak in nfcllcpsenduiframe().

syzbot reported various memory leaks related to NFC, struct nfcllcpsock, skbuff, nfcdev, etc. [0]

The leading log hinted that nfcllcpsenduiframe() failed to allocate skb due to sockerror(sk) being -ENXIO.

ENXIO is set by nfcllcpsocketrelease() when struct nfcllcplocal is destroyed by localcleanup().

The problem is that there is no synchronisation between nfcllcpsenduiframe() and localcleanup(), and skb could be put into local->txqueue after it was purged in localcleanup():

CPU1 CPU2 ---- ---- nfcllcpsenduiframe() localcleanup() |- do { ' |- pdu = nfcallocsendskb(..., &err) | . | |- nfcllcpsocketrelease(local, false, ENXIO); | |- skbqueuepurge(&local->txqueue); | | ' | |- skbqueuetail(&local->txqueue, pdu); | ... | |- pdu = nfcallocsendskb(..., &err) | ^..'

localcleanup() is called for struct nfcllcplocal only after nfcllcpremovelocal() unlinks it from llcpdevices.

If we hold local->txqueue.lock then, we can synchronise the thread and nfcllcpsenduiframe().

Let's do that and check listempty(&local->list) before queuing skb to local->txqueue in nfcllcpsenduiframe().

[0]: [ 56.074943][ T6096] llcp: nfcllcpsenduiframe: Could not allocate PDU (error=-6) [ 64.318868][ T5813] kmemleak: 6 new suspected memory leaks (see /sys/kernel/debug/kmemleak) BUG: memory leak unreferenced object 0xffff8881272f6800 (size 1024): comm "syz.0.17", pid 6096, jiffies 4294942766 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 27 00 03 40 00 00 00 00 00 00 00 00 00 00 00 00 '..@............ backtrace (crc da58d84d): kmemleakallocrecursive include/linux/kmemleak.h:44 [inline] slabpostallochook mm/slub.c:4979 [inline] slaballocnode mm/slub.c:5284 [inline] dokmallocnode mm/slub.c:5645 [inline] kmallocnoprof+0x3e3/0x6b0 mm/slub.c:5658 kmallocnoprof include/linux/slab.h:961 [inline] skprotalloc+0x11a/0x1b0 net/core/sock.c:2239 skalloc+0x36/0x360 net/core/sock.c:2295 nfcllcpsockalloc+0x37/0x130 net/nfc/llcpsock.c:979 llcpsockcreate+0x71/0xd0 net/nfc/llcpsock.c:1044 nfcsockcreate+0xc9/0xf0 net/nfc/afnfc.c:31 sockcreate+0x1a9/0x340 net/socket.c:1605 sockcreate net/socket.c:1663 [inline] syssocketcreate net/socket.c:1700 [inline] syssocket+0xb9/0x1a0 net/socket.c:1747 dosyssocket net/socket.c:1761 [inline] sesyssocket net/socket.c:1759 [inline] x64syssocket+0x1b/0x30 net/socket.c:1759 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xa4/0xfa0 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

BUG: memory leak unreferenced object 0xffff88810fbd9800 (size 240): comm "syz.0.17", pid 6096, jiffies 4294942850 hex dump (first 32 bytes): 68 f0 ff 08 81 88 ff ff 68 f0 ff 08 81 88 ff ff h.......h....... 00 00 00 00 00 00 00 00 00 68 2f 27 81 88 ff ff .........h/'.... backtrace (crc 6cc652b1): kmemleakallocrecursive include/linux/kmemleak.h:44 [inline] slabpostallochook mm/slub.c:4979 [inline] slaballocnode mm/slub.c:5284 [inline] kmemcacheallocnodenoprof+0x36f/0x5e0 mm/slub.c:5336 allocskb+0x203/0x240 net/core/skbuff.c:660 allocskb include/linux/skbuff.h:1383 [inline] allocskbwithfrags+0x69/0x3f0 net/core/sk ---truncated---