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

usb: gadget: udc: Fix use-after-free in gadgetmatchdriver

The udc structure acts as the management structure for the gadget, but their lifecycles are decoupled. A race condition exists where usbdelgadget() frees the udc memory (e.g., via mode-switch work) while gadgetmatchdriver() concurrently accesses the freed udc memory (e.g., via configfs), causing a Use-After-Free (UAF) that triggers a NULL pointer dereference when the freed memory is zeroed:

[39430.908615][ T1171] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [39430.911397][ T1171] pc : pistrcmp+0x20/0x140 [39430.911441][ T1171] lr : gadgetmatchdriver+0x34/0x60 ... [39430.911890][ T1171] usbgadgetregisterdriverowner+0x50/0xf8 [39430.911910][ T1171] gadgetdevdescUDCstore+0xf4/0x140 [39430.931308][ T1171] configfswriteiter+0xec/0x134

[39430.957058][ T1171] Workqueue: eventsfreezable dwc3setmode [39430.957287][ T1171] dwc3gadgetexit+0x34/0x8c [39430.957304][ T1171] dwc3setmode+0xc0/0x664

Fix this by ensuring the udc structure remains allocated until the gadget is released. To achieve this, introduce a new usbgadgetrelease() routine to the core. When the gadget is added, usbaddgadget() stores the gadget's release routine in the udc structure and takes a reference to the udc. When the gadget is released, usbgadgetrelease() drops the reference to the udc and then calls the gadget's release routine.

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

riscv: Fix register corruption from uninitialized cregs on error

compatriscvgprset() calls cregstoregs() unconditionally, even when userregsetcopyin() fails. Since cregs is an uninitialized stack variable, a copyin failure causes uninitialized stack data to be written into the target task's ptregs, corrupting its register state and potentially leaking kernel stack contents.

compatrestoresigcontext() has the same issue: it calls cregstoregs() even when copyfromuser() fails, leading to the same corruption of the signal-returning task's register state on error.

Only call cregstoregs() when the user copy succeeds.

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

mptcp: allow subflow rcv wnd to shrink

In MPTCP connection, the window field in the TCP header refers to the MPTCP-level rcvnxt and it's right edge should not move backward. Such constraint is enforced at DSS option generation time.

At the same time, the TCP stack ensures independently that the TCP-level rcv wnd right's edge does not move backward. That in turn causes artificial inflating of the MPTCP rcv window when the incoming data is acked at the TCP level and is OoO in the MPTCP sequence space (or lands in the backlog).

As a consequence, the incoming traffic can exceed the receiver rcvbuf size even when the sender is not misbehaving.

Prevent such scenario forcibly allowing the TCP subflow to shrink the TCP-level rcv wnd regardless of the current netns setting.

drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on GFX11

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

mtd: spi-nor: debugfs: fix out-of-bounds read in spinorparamsshow()

Sashiko noticed an out-of-bounds read [1].

In spinorparamsshow(), the snorfnames array is passed to spinorprintflags() using sizeof(snorfnames).

Since snorfnames is an array of pointers, sizeof() returns the total number of bytes occupied by the pointers (elementcount sizeof(void )) rather than the element count itself. On 64-bit systems, this makes the passed length 8x larger than intended.

Inside spinorprintflags(), the 'nameslen' argument is used to bounds-check the 'names' array access. An out-of-bounds read occurs if a flag bit is set that exceeds the array's actual element count but is within the inflated byte-size count.

Correct this by using ARRAYSIZE() to pass the actual number of string pointers in the array.

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

spi: imx: fix use-after-free on unbind

The SPI subsystem frees the controller and any subsystem allocated driver data as part of deregistration (unless the allocation is device managed).

Take another reference before deregistering the controller so that the driver data is not freed until the driver is done with it.

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

LoongArch: Add spectre boundry for syscall dispatch table

The LoongArch syscall number is directly controlled by userspace, but does not have a arrayindexnospec() boundry to prevent access past the syscall function pointer tables.

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

netfilter: nfconncount: increase the connection clean up limit to 64

After the optimization to only perform one GC per jiffy, a new problem was introduced. If more than 8 new connections are tracked per jiffy the list won't be cleaned up fast enough possibly reaching the limit wrongly.

In order to prevent this issue, only skip the GC if it was already triggered during the same jiffy and the increment is lower than the clean up limit. In addition, increase the clean up limit to 64 connections to avoid triggering GC too often and do more effective GCs.

This has been tested using a HTTP server and several performance tools while having nftconnlimit/xtconnlimit or OVS limit configured.

Output of slowhttptest + OVS limit at 52000 connections:

slow HTTP test status on 340th second: initializing: 0 pending: 432 connected: 51998 error: 0 closed: 0 service available: YES

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

net: wwan: t7xx: validate portcount against message length in t7xxportenummsghandler

t7xxportenummsghandler() uses the modem-supplied portcount field as a loop bound over portmsg->data[] without checking that the message buffer contains sufficient data. A modem sending portcount=65535 in a 12-byte buffer triggers a slab-out-of-bounds read of up to 262140 bytes.

Add a sizeof(portmsg) check before accessing the port message header fields to guard against undersized messages.

Add a structsize() check after extracting portcount and before the loop.

In t7xxparsehostrtdata(), guard the rtfeature header read with a remaining-buffer check before accessing datalen, validate featdatalen against the actual remaining buffer to prevent OOB reads and signed integer overflow on offset.

Pass msglen from both call sites: skb->len at the DPMAIF path after skbpull(), and the validated featdatalen at the handshake path.

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

iouring/kbuf: check if target buffer list is still legacy on recycle

There's a gap between when the buffer was grabbed and when it potentially gets recycled, where if the list is empty, someone could've upgraded it to a ring provided type. This can happen if the request is forced via io-wq. The legacy recycling is missing checking if the bufferlist still exists, and if it's of the correct type. Add those checks.

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

vhost: move vdpa group bound check to vhostvdpa

Remove duplication by consolidating these here. This reduces the posibility of a parent driver missing them.

While we're at it, fix a bug in vdpasim where a valid ASID can be assigned to a group equal to ngroups, causing an out of bound write.

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

smb: client: prevent races in ->queryinterfaces()

It was possible for two query interface works to be concurrently trying to update the interfaces.

Prevent this by checking and updating ifacelastupdate under ifacelock.

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

LoongArch: Make cpumaskofnode() robust against NUMANONODE

The arch definition of cpumaskofnode() cannot handle NUMANONODE - which is a valid index - so add a check for this.

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.

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

net: wwan: t7xx: fix potential skb->frags overflow in RX path

When receiving data in the DPMAIF RX path, the t7xxdpmaifsetfragtoskb() function adds page fragments to an skb without checking if the number of fragments has exceeded MAXSKBFRAGS. This could lead to a buffer overflow in skbshinfo(skb)->frags[] array, corrupting adjacent memory and potentially causing kernel crashes or other undefined behavior.

This issue was identified through static code analysis by comparing with a similar vulnerability fixed in the mt76 driver commit b102f0c522cf ("mt76: fix array overflow on receiving too many fragments for a packet").

The vulnerability could be triggered if the modem firmware sends packets with excessive fragments. While under normal protocol conditions (MTU 3080 bytes, BAT buffer 3584 bytes), a single packet should not require additional fragments, the kernel should not blindly trust firmware behavior. Malicious, buggy, or compromised firmware could potentially craft packets with more fragments than the kernel expects.

Fix this by adding a bounds check before calling skbaddrxfrag() to ensure nrfrags does not exceed MAXSKBFRAGS.

The check must be performed before unmapping to avoid a page leak and double DMA unmap during device teardown.

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

netfilter: nfconncount: update lastgc only when GC has been performed

Currently lastgc is being updated everytime a new connection is tracked, that means that it is updated even if a GC wasn't performed. With a sufficiently high packet rate, it is possible to always bypass the GC, causing the list to grow infinitely.

Update the lastgc value only when a GC has been actually performed.

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

arm64/fpsimd: signal: Fix restoration of SVE context

When SME is supported, Restoring SVE signal context can go wrong in a few ways, including placing the task into an invalid state where the kernel may read from out-of-bounds memory (and may potentially take a fatal fault) and/or may kill the task with a SIGKILL.

(1) Restoring a context with SVESIGFLAGSM set can place the task into an invalid state where SVCR.SM is set (and svestate is non-NULL) but TIFSME is clear, consequently resuting in out-of-bounds memory reads and/or killing the task with SIGKILL.

This can only occur in unusual (but legitimate) cases where the SVE signal context has either been modified by userspace or was saved in the context of another task (e.g. as with CRIU), as otherwise the presence of an SVE signal context with SVESIGFLAGSM implies that TIFSME is already set.

While in this state, taskfpsimdload() will NOT configure SMCRELx (leaving some arbitrary value configured in hardware) before restoring SVCR and attempting to restore the streaming mode SVE registers from memory via sveloadstate(). As the value of SMCRELx.LEN may be larger than the task's streaming SVE vector length, this may read memory outside of the task's allocated svestate, reading unrelated data and/or triggering a fault.

While this can result in secrets being loaded into streaming SVE registers, these values are never exposed. As TIFSME is clear, fpsimdbindtasktocpu() will configure CPACRELx.SMEN to trap EL0 accesses to streaming mode SVE registers, so these cannot be accessed directly at EL0. As fpsimdsaveuserstate() verifies the live vector length before saving (S)SVE state to memory, no secret values can be saved back to memory (and hence cannot be observed via ptrace, signals, etc).

When the live vector length doesn't match the expected vector length for the task, fpsimdsaveuserstate() will send a fatal SIGKILL signal to the task. Hence the task may be killed after executing userspace for some period of time.

(2) Restoring a context with SVESIGFLAGSM clear does not clear the task's SVCR.SM. If SVCR.SM was set prior to restoring the context, then the task will be left in streaming mode unexpectedly, and some register state will be combined inconsistently, though the task will be left in legitimate state from the kernel's PoV.

This can only occur in unusual (but legitimate) cases where ptrace has been used to set SVCR.SM after entry to the sigreturn syscall, as syscall entry clears SVCR.SM.

In these cases, the the provided SVE register data will be loaded into the task's svestate using the non-streaming SVE vector length and the FPSIMD registers will be merged into this using the streaming SVE vector length.

Fix (1) by setting TIFSME when setting SVCR.SM. This also requires ensuring that the task's smestate has been allocated, but as this could contain live ZA state, it should not be zeroed. Fix (2) by clearing SVCR.SM when restoring a SVE signal context with SVESIGFLAGSM clear.

For consistency, I've pulled the manipulation of SVCR, TIFSVE, TIFSME, and fptype earlier, immediately after the allocation of svestate/smestate, before the restore of the actual register state. This makes it easier to ensure that these are always modified consistently, even if a fault is taken while reading the register data from the signal context. I do not expect any software to depend on the exact state restored when a fault is taken while reading the context.

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

tcp: fix skbcopyubufs() vs BIG TCP

David Ahern reported crashes in skbcopyubufs() caused by TCP tx zerocopy using hugepages, and skb length bigger than ~68 KB.

skbcopyubufs() assumed it could copy all payload using up to MAXSKBFRAGS order-0 pages.

This assumption broke when BIG TCP was able to put up to 512 KB per skb.

We did not hit this bug at Google because we use CONFIGMAXSKBFRAGS=45 and limit gsomaxsize to 180000.

A solution is to use higher order pages if needed.

v2: add missing GFPCOMP, or we leak memory.

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

mm/hugememory: do not clobber swpentryt during THP split

The following has been observed when running stressng mmap since commit b653db77350c ("mm: Clear page->private when splitting or migrating a page")

watchdog: BUG: soft lockup - CPU#75 stuck for 26s! [stress-ng:9546] CPU: 75 PID: 9546 Comm: stress-ng Tainted: G E 6.0.0-revert-b653db77-fix+ #29 0357d79b60fb09775f678e4f3f64ef0579ad1374 Hardware name: SGI.COM C2112-4GP3/X10DRT-P-Series, BIOS 2.0a 05/09/2016 RIP: 0010:xasdescend+0x28/0x80 Code: cc cc 0f b6 0e 48 8b 57 08 48 d3 ea 83 e2 3f 89 d0 48 83 c0 04 48 8b 44 c6 08 48 89 77 18 48 89 c1 83 e1 03 48 83 f9 02 75 08 <48> 3d fd 00 00 00 76 08 88 57 12 c3 cc cc cc cc 48 c1 e8 02 89 c2 RSP: 0018:ffffbbf02a2236a8 EFLAGS: 00000246 RAX: ffff9cab7d6a0002 RBX: ffffe04b0af88040 RCX: 0000000000000002 RDX: 0000000000000030 RSI: ffff9cab60509b60 RDI: ffffbbf02a2236c0 RBP: 0000000000000000 R08: ffff9cab60509b60 R09: ffffbbf02a2236c0 R10: 0000000000000001 R11: ffffbbf02a223698 R12: 0000000000000000 R13: ffff9cab4e28da80 R14: 0000000000039c01 R15: ffff9cab4e28da88 FS: 00007fab89b85e40(0000) GS:ffff9cea3fcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fab84e00000 CR3: 00000040b73a4003 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> xasload+0x3a/0x50 filemapgetfolio+0x80/0x370 ? putswappage+0x163/0x360 pagecachegetpage+0x13/0x90 trytoreclaimswap+0x50/0x190 scanswapmapslots+0x31e/0x670 getswappages+0x226/0x3c0 folioallocswap+0x1cc/0x240 addtoswap+0x14/0x70 shrinkpagelist+0x968/0xbc0 reclaimpagelist+0x70/0xf0 reclaimpages+0xdd/0x120 madvisecoldorpageoutpterange+0x814/0xf30 walkpgdrange+0x637/0xa30 walkpagerange+0x142/0x170 walkpagerange+0x146/0x170 madvisepageout+0xb7/0x280 ? asmcommoninterrupt+0x22/0x40 madvisevmabehavior+0x3b7/0xac0 ? findvma+0x4a/0x70 ? findvma+0x64/0x70 ? madvisevmaanonname+0x40/0x40 madvisewalkvmas+0xa6/0x130 domadvise+0x2f4/0x360 x64sysmadvise+0x26/0x30 dosyscall64+0x5b/0x80 ? dosyscall64+0x67/0x80 ? syscallexittousermode+0x17/0x40 ? dosyscall64+0x67/0x80 ? syscallexittousermode+0x17/0x40 ? dosyscall64+0x67/0x80 ? dosyscall64+0x67/0x80 ? commoninterrupt+0x8b/0xa0 entrySYSCALL64afterhwframe+0x63/0xcd

The problem can be reproduced with the mmtests config config-workload-stressng-mmap. It does not always happen and when it triggers is variable but it has happened on multiple machines.

The intent of commit b653db77350c patch was to avoid the case where PGprivate is clear but folio->private is not-NULL. However, THP tail pages uses page->private for "swpentryt if foliotestswapcache()" as stated in the documentation for struct folio. This patch only clobbers page->private for tail pages if the head page was not in swapcache and warns once if page->private had an unexpected value.

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

scsi: mpi3mr: Fix issues in mpi3mrgetalltgtinfo()

The function mpi3mrgetalltgtinfo() has four issues:

1) It calculates valid entry length in alltgtinfo assuming the header part of the struct mpi3mrdevicemapinfo would equal to sizeof(u32). The correct size is sizeof(u64).

2) When it calculates the valid entry length kernentrylen, it excludes one entry by subtracting 1 from numdevices.

3) It copies numdevice by calling memcpy(). Substitution is enough.

4) It does not specify the calculated length to sgcopyfrombuffer(). Instead, it specifies the payload length which is larger than the alltgtinfo size. It causes "BUG: KASAN: slab-out-of-bounds".

Fix the issues by using the correct header size, removing the subtraction from numdevices, replacing the memcpy() with substitution and specifying the correct length to sgcopyfrombuffer().

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

lockd: set other missing fields when unlocking files

vfslockfile() expects the struct filelock to be fully initialised by the caller. Re-exported NFSv3 has been seen to Oops if the flfile field is NULL.

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

android: binder: stop saving a pointer to the VMA

Do not record a pointer to a VMA outside of the mmaplock for later use. This is unsafe and there are a number of failure paths after the recorded VMA pointer may be freed during setup. There is no callback to the driver to clear the saved pointer from generic mm code. Furthermore, the VMA pointer may become stale if any number of VMA operations end up freeing the VMA so saving it was fragile to being with.

Instead, change the binderalloc struct to record the start address of the VMA and use vmalookup() to get the vma when needed. Add lockdep mmaplock checks on updates to the vma pointer to ensure the lock is held and depend on that lock for synchronization of readers and writers - which was already the case anyways, so the smpwmb()/smprmb() was not necessary.

[akpm@linux-foundation.org: fix drivers/android/binderallocselftest.c]

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

mptcp: make fallback action and fallback decision atomic

Syzkaller reported the following splat:

WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcpdofallback net/mptcp/protocol.h:1223 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcpdofallback net/mptcp/protocol.h:1244 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 checkfullyestablished net/mptcp/options.c:982 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcpincomingoptions+0x21a8/0x2510 net/mptcp/options.c:1153 Modules linked in: CPU: 1 UID: 0 PID: 7704 Comm: syz.3.1419 Not tainted 6.16.0-rc3-gbd5ce2324dba #20 PREEMPT(voluntary) Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:mptcpdofallback net/mptcp/protocol.h:1223 [inline] RIP: 0010:mptcpdofallback net/mptcp/protocol.h:1244 [inline] RIP: 0010:checkfullyestablished net/mptcp/options.c:982 [inline] RIP: 0010:mptcpincomingoptions+0x21a8/0x2510 net/mptcp/options.c:1153 Code: 24 18 e8 bb 2a 00 fd e9 1b df ff ff e8 b1 21 0f 00 e8 ec 5f c4 fc 44 0f b7 ac 24 b0 00 00 00 e9 54 f1 ff ff e8 d9 5f c4 fc 90 <0f> 0b 90 e9 b8 f4 ff ff e8 8b 2a 00 fd e9 8d e6 ff ff e8 81 2a 00 RSP: 0018:ffff8880a3f08448 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8880180a8000 RCX: ffffffff84afcf45 RDX: ffff888090223700 RSI: ffffffff84afdaa7 RDI: 0000000000000001 RBP: ffff888017955780 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff8880180a8910 R14: ffff8880a3e9d058 R15: 0000000000000000 FS: 00005555791b8500(0000) GS:ffff88811c495000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000110c2800b7 CR3: 0000000058e44000 CR4: 0000000000350ef0 Call Trace: <IRQ> tcpreset+0x26f/0x2b0 net/ipv4/tcpinput.c:4432 tcpvalidateincoming+0x1057/0x1b60 net/ipv4/tcpinput.c:5975 tcprcvestablished+0x5b5/0x21f0 net/ipv4/tcpinput.c:6166 tcpv4dorcv+0x5dc/0xa70 net/ipv4/tcpipv4.c:1925 tcpv4rcv+0x3473/0x44a0 net/ipv4/tcpipv4.c:2363 ipprotocoldeliverrcu+0xba/0x480 net/ipv4/ipinput.c:205 iplocaldeliverfinish+0x2f1/0x500 net/ipv4/ipinput.c:233 NFHOOK include/linux/netfilter.h:317 [inline] NFHOOK include/linux/netfilter.h:311 [inline] iplocaldeliver+0x1be/0x560 net/ipv4/ipinput.c:254 dstinput include/net/dst.h:469 [inline] iprcvfinish net/ipv4/ipinput.c:447 [inline] NFHOOK include/linux/netfilter.h:317 [inline] NFHOOK include/linux/netfilter.h:311 [inline] iprcv+0x514/0x810 net/ipv4/ipinput.c:567 netifreceiveskbonecore+0x197/0x1e0 net/core/dev.c:5975 netifreceiveskb+0x1f/0x120 net/core/dev.c:6088 processbacklog+0x301/0x1360 net/core/dev.c:6440 napipoll.constprop.0+0xba/0x550 net/core/dev.c:7453 napipoll net/core/dev.c:7517 [inline] netrxaction+0xb44/0x1010 net/core/dev.c:7644 handlesoftirqs+0x1d0/0x770 kernel/softirq.c:579 dosoftirq+0x3f/0x90 kernel/softirq.c:480 </IRQ> <TASK> localbhenableip+0xed/0x110 kernel/softirq.c:407 localbhenable include/linux/bottomhalf.h:33 [inline] inetcsklistenstop+0x2c5/0x1070 net/ipv4/inetconnectionsock.c:1524 mptcpchecklistenstop.part.0+0x1cc/0x220 net/mptcp/protocol.c:2985 mptcpchecklistenstop net/mptcp/mib.h:118 [inline] mptcpclose+0x9b9/0xbd0 net/mptcp/protocol.c:3000 mptcpclose+0x2f/0x140 net/mptcp/protocol.c:3066 inetrelease+0xed/0x200 net/ipv4/afinet.c:435 inet6release+0x4f/0x70 net/ipv6/afinet6.c:487 sockrelease+0xb3/0x270 net/socket.c:649 sockclose+0x1c/0x30 net/socket.c:1439 fput+0x402/0xb70 fs/filetable.c:465 taskworkrun+0x150/0x240 kernel/taskwork.c:227 resumeusermodework include/linux/resumeusermode.h:50 [inline] exittousermodeloop+0xd4 ---truncated---

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

ipmi:msghandler: Fix potential memory corruption in ipmicreateuser()

The "intf" list iterator is an invalid pointer if the correct "intf->intfnum" is not found. Calling atomicdec(&intf->nrusers) on and invalid pointer will lead to memory corruption.

We don't really need to call atomicdec() if we haven't called atomicaddreturn() so update the if (intf->inshutdown) path as well.

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

NFSv4/pNFS: Fix a race to wake on NFSLAYOUTDRAIN

We found a few different systems hung up in writeback waiting on the same page lock, and one task waiting on the NFSLAYOUTDRAIN bit in pnfsupdatelayout(), however the pnfslayouthdr's plhoutstanding count was zero.

It seems most likely that this is another race between the waiter and waker similar to commit ed0172af5d6f ("SUNRPC: Fix a race to wake a sync task"). Fix it up by applying the advised barrier.

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

crypto: arm64/poly1305 - fix a read out-of-bound

A kasan error was reported during fuzzing:

BUG: KASAN: slab-out-of-bounds in neonpoly1305blocks.constprop.0+0x1b4/0x250 [poly1305neon] Read of size 4 at addr ffff0010e293f010 by task syz-executor.5/1646715 CPU: 4 PID: 1646715 Comm: syz-executor.5 Kdump: loaded Not tainted 5.10.0.aarch64 #1 Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.59 01/31/2019 Call trace: dumpbacktrace+0x0/0x394 showstack+0x34/0x4c arch/arm64/kernel/stacktrace.c:196 dumpstack lib/dumpstack.c:77 [inline] dumpstack+0x158/0x1e4 lib/dumpstack.c:118 printaddressdescription.constprop.0+0x68/0x204 mm/kasan/report.c:387 kasanreport+0xe0/0x140 mm/kasan/report.c:547 kasanreport+0x44/0xe0 mm/kasan/report.c:564 checkmemoryregioninline mm/kasan/generic.c:187 [inline] asanload4+0x94/0xd0 mm/kasan/generic.c:252 neonpoly1305blocks.constprop.0+0x1b4/0x250 [poly1305neon] neonpoly1305doupdate+0x6c/0x15c [poly1305neon] neonpoly1305update+0x9c/0x1c4 [poly1305neon] cryptoshashupdate crypto/shash.c:131 [inline] shashfinupunaligned+0x84/0x15c crypto/shash.c:179 cryptoshashfinup+0x8c/0x140 crypto/shash.c:193 shashdigestunaligned+0xb8/0xe4 crypto/shash.c:201 cryptoshashdigest+0xa4/0xfc crypto/shash.c:217 cryptoshashtfmdigest+0xb4/0x150 crypto/shash.c:229 essivskciphersetkey+0x164/0x200 [essiv] cryptoskciphersetkey+0xb0/0x160 crypto/skcipher.c:612 skciphersetkey+0x3c/0x50 crypto/algifskcipher.c:305 algsetkey+0x114/0x2a0 crypto/afalg.c:220 algsetsockopt+0x19c/0x210 crypto/afalg.c:253 syssetsockopt+0x190/0x2e0 net/socket.c:2123 dosyssetsockopt net/socket.c:2134 [inline] sesyssetsockopt net/socket.c:2131 [inline] arm64syssetsockopt+0x78/0x94 net/socket.c:2131 invokesyscall arch/arm64/kernel/syscall.c:36 [inline] invokesyscall+0x64/0x100 arch/arm64/kernel/syscall.c:48 el0svccommon.constprop.0+0x220/0x230 arch/arm64/kernel/syscall.c:155 doel0svc+0xb4/0xd4 arch/arm64/kernel/syscall.c:217 el0svc+0x24/0x3c arch/arm64/kernel/entry-common.c:353 el0synchandler+0x160/0x164 arch/arm64/kernel/entry-common.c:369 el0sync+0x160/0x180 arch/arm64/kernel/entry.S:683

This error can be reproduced by the following code compiled as ko on a system with kasan enabled:

#include <linux/module.h> #include <linux/crypto.h> #include <crypto/hash.h> #include <crypto/poly1305.h>

char testdata[] = "\x00\x01\x02\x03\x04\x05\x06\x07" "\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f" "\x10\x11\x12\x13\x14\x15\x16\x17" "\x18\x19\x1a\x1b\x1c\x1d\x1e";

int init(void) { struct cryptoshash tfm = NULL; char data = NULL, out = NULL;

tfm = cryptoallocshash("poly1305", 0, 0); data = kmalloc(POLY1305KEYSIZE - 1, GFPKERNEL); out = kmalloc(POLY1305DIGESTSIZE, GFPKERNEL); memcpy(data, testdata, POLY1305KEYSIZE - 1); cryptoshashtfmdigest(tfm, data, POLY1305KEYSIZE - 1, out);

kfree(data); kfree(out); return 0; }

void deinit(void) { }

moduleinit(init) moduleexit(deinit) MODULELICENSE("GPL");

The root cause of the bug sits in neonpoly1305blocks. The logic neonpoly1305blocks() performed is that if it was called with both s[] and r[] uninitialized, it will first try to initialize them with the data from the first "block" that it believed to be 32 bytes in length. First 16 bytes are used as the key and the next 16 bytes for s[]. This would lead to the aforementioned read out-of-bound. However, after calling poly1305initarch(), only 16 bytes were deducted from the input and s[] is initialized yet again with the following 16 bytes. The second initialization of s[] is certainly redundent which indicates that the first initialization should be for r[] only.

This patch fixes the issue by calling poly1305initarm64() instead o ---truncated---

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

ALSA: bcd2000: Fix a UAF bug on the error path of probing

When the driver fails in sndcardregister() at probe time, it will free the 'bcd2k->midiouturb' before killing it, which may cause a UAF bug.

The following log can reveal it:

[ 50.727020] BUG: KASAN: use-after-free in bcd2000inputcomplete+0x1f1/0x2e0 [sndbcd2000] [ 50.727623] Read of size 8 at addr ffff88810fab0e88 by task swapper/4/0 [ 50.729530] Call Trace: [ 50.732899] bcd2000inputcomplete+0x1f1/0x2e0 [sndbcd2000]

Fix this by adding usbkillurb() before usbfreeurb().

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

KVM: x86/xen: Initialize Xen timer only once

Add a check for existing xen timers before initializing a new one.

Currently kvmxeninittimer() is called on every KVMXENVCPUATTRTYPETIMER, which is causing the following ODEBUG crash when vcpu->arch.xen.timer is already set.

ODEBUG: init active (active state 0) object type: hrtimer hint: xentimercallbac0 RIP: 0010:debugprintobject+0x16e/0x250 lib/debugobjects.c:502 Call Trace: debugobjectinit debughrtimerinit debuginit hrtimerinit kvmxeninittimer kvmxenvcpusetattr kvmarchvcpuioctl kvmvcpuioctl vfsioctl

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

usbnet: Fix linkwatch use-after-free on disconnect

usbnet uses the work usbnetdeferredkevent() to perform tasks which may sleep. On disconnect, completion of the work was originally awaited in ->ndostop(). But in 2003, that was moved to ->disconnect() by historic commit "[PATCH] USB: usbnet, prevent exotic rtnl deadlock":

https://git.kernel.org/tglx/history/c/0f138bbfd83c

The change was made because back then, the kernel's workqueue implementation did not allow waiting for a single work. One had to wait for completion of all work by calling flushscheduledwork(), and that could deadlock when waiting for usbnetdeferredkevent() with rtnlmutex held in ->ndostop().

The commit solved one problem but created another: It causes a use-after-free in USB Ethernet drivers aqc111.c, asixdevices.c, ax88179178a.c, ch9200.c and smsc75xx.c:

If the drivers receive a link change interrupt immediately before disconnect, they raise EVENTLINKRESET in their (non-sleepable) ->status() callback and schedule usbnetdeferredkevent(). usbnetdeferredkevent() invokes the driver's ->linkreset() callback, which calls netifcarrier{on,off}(). That in turn schedules the work linkwatchevent().

Because usbnetdeferredkevent() is awaited after unregisternetdev(), netifcarrier{on,off}() may operate on an unregistered netdev and linkwatchevent() may run after freenetdev(), causing a use-after-free.

In 2010, usbnet was changed to only wait for a single instance of usbnetdeferredkevent() instead of all work by commit 23f333a2bfaf ("drivers/net: don't use flushscheduledwork()").

Unfortunately the commit neglected to move the wait back to ->ndostop(). Rectify that omission at long last.

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

bpf: Fix KASAN use-after-free Read in computeeffectiveprogs

Syzbot found a Use After Free bug in computeeffectiveprogs(). The reproducer creates a number of BPF links, and causes a fault injected alloc to fail, while calling bpflinkdetach on them. Link detach triggers the link to be freed by bpflinkfree(), which calls cgroupbpfdetach() and updateeffectiveprogs(). If the memory allocation in this function fails, the function restores the pointer to the bpfcgrouplink on the cgroup list, but the memory gets freed just after it returns. After this, every subsequent call to updateeffectiveprogs() causes this already deallocated pointer to be dereferenced in proglistlength(), and triggers KASAN UAF error.

To fix this issue don't preserve the pointer to the prog or link in the list, but remove it and replace it with a dummy prog without shrinking the table. The subsequent call to cgroupbpfdetach() or cgroupbpfdetach() will correct it.