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

wifi: ath11k: mhi: fix potential memory leak in ath11kmhiregister()

mhialloccontroller() allocates a memory space for mhictrl. When gets some error, mhictrl should be freed with mhifreecontroller(). But when ath11kmhireadaddrfromdt() fails, the function returns without calling mhifreecontroller(), which will lead to a memory leak.

We can fix it by calling mhifreecontroller() when ath11kmhireadaddrfromdt() fails.

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

crypto: hisilicon/qm - increase the memory of local variables

Increase the buffer to prevent stack overflow by fuzz test. The maximum length of the qos configuration buffer is 256 bytes. Currently, the value of the 'val buffer' is only 32 bytes. The sscanf does not check the dest memory length. So the 'val buffer' may stack overflow.

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

orangefs: Fix kmemleak in orangefssysfsinit()

When insert and remove the orangefs module, there are kobjects memory leaked as below:

unreferenced object 0xffff88810f95af00 (size 64): comm "insmod", pid 783, jiffies 4294813439 (age 65.512s) hex dump (first 32 bytes): a0 83 af 01 81 88 ff ff 08 af 95 0f 81 88 ff ff ................ 08 af 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloctrace+0x27/0xa0 [<000000005a6e4dfe>] orangefssysfsinit+0x42/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<000000004232d9f7>] dooneinitcall+0x87/0x2a0 [<0000000054f22384>] doinitmodule+0xdf/0x320 [<000000003263bdea>] loadmodule+0x2f98/0x3330 [<0000000052cd4153>] dosysfinitmodule+0x113/0x1b0 [<00000000250ae02b>] dosyscall64+0x35/0x80 [<00000000f11c03c7>] entrySYSCALL64afterhwframe+0x46/0xb0

unreferenced object 0xffff88810f95ae80 (size 64): comm "insmod", pid 783, jiffies 4294813439 (age 65.512s) hex dump (first 32 bytes): c8 90 0f 02 81 88 ff ff 88 ae 95 0f 81 88 ff ff ................ 88 ae 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloctrace+0x27/0xa0 [<000000001a4841fa>] orangefssysfsinit+0xc7/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<000000004232d9f7>] dooneinitcall+0x87/0x2a0 [<0000000054f22384>] doinitmodule+0xdf/0x320 [<000000003263bdea>] loadmodule+0x2f98/0x3330 [<0000000052cd4153>] dosysfinitmodule+0x113/0x1b0 [<00000000250ae02b>] dosyscall64+0x35/0x80 [<00000000f11c03c7>] entrySYSCALL64afterhwframe+0x46/0xb0

unreferenced object 0xffff88810f95ae00 (size 64): comm "insmod", pid 783, jiffies 4294813440 (age 65.511s) hex dump (first 32 bytes): 60 87 a1 00 81 88 ff ff 08 ae 95 0f 81 88 ff ff ............... 08 ae 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloctrace+0x27/0xa0 [<000000005915e797>] orangefssysfsinit+0x12b/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<000000004232d9f7>] dooneinitcall+0x87/0x2a0 [<0000000054f22384>] doinitmodule+0xdf/0x320 [<000000003263bdea>] loadmodule+0x2f98/0x3330 [<0000000052cd4153>] dosysfinitmodule+0x113/0x1b0 [<00000000250ae02b>] dosyscall64+0x35/0x80 [<00000000f11c03c7>] entrySYSCALL64afterhwframe+0x46/0xb0

unreferenced object 0xffff88810f95ad80 (size 64): comm "insmod", pid 783, jiffies 4294813440 (age 65.511s) hex dump (first 32 bytes): 78 90 0f 02 81 88 ff ff 88 ad 95 0f 81 88 ff ff x............... 88 ad 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloctrace+0x27/0xa0 [<000000007a14eb35>] orangefssysfsinit+0x1ac/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<000000004232d9f7>] dooneinitcall+0x87/0x2a0 [<0000000054f22384>] doinitmodule+0xdf/0x320 [<000000003263bdea>] loadmodule+0x2f98/0x3330 [<0000000052cd4153>] dosysfinitmodule+0x113/0x1b0 [<00000000250ae02b>] dosyscall64+0x35/0x80 [<00000000f11c03c7>] entrySYSCALL64afterhwframe+0x46/0xb0

unreferenced object 0xffff88810f95ac00 (size 64): comm "insmod", pid 783, jiffies 4294813440 (age 65.531s) hex dump (first 32 bytes): e0 ff 67 02 81 88 ff ff 08 ac 95 0f 81 88 ff ff ..g............. 08 ac 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloctrace+0x27/0xa0 [<000000001f38adcb>] orangefssysfsinit+0x291/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<000000004232d9f7>] dooneinitcall+0x87/0x2a0 [<0000000054f22384>] doinitmodule+0xdf/0x320 [<000000003263bdea>] loadmodule+0x2f98/0x3330 [<0000000052cd4153>] dosysfinitmodule+0x113/0x1b0 [<00000000250ae02b>] dosyscall64+0x35/ ---truncated---

ASoC: SOF: Intel: hda-ipc: Do not process IPC reply before firmware boot

btrfs: zoned: clone zoned device info when cloning a device

dlm: prevent NPD when writing a positive value to eventdone

drm/amdkfd: svm range restore work deadlock when process exit

drm/amd/display: Fix by adding FPU protection for dcn30internalvalidatebw

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

net: tap: NULL pointer derefence in devparseheaderprotocol when skb->dev is null

Fixes a NULL pointer derefence bug triggered from tap driver. When tapgetuser calls virtionethdrtoskb the skb->dev is null (in tap.c skb->dev is set after the call to virtionethdrtoskb) virtionethdrtoskb calls devparseheaderprotocol which needs skb->dev field to be valid.

The line that trigers the bug is in devparseheaderprotocol (dev is at offset 0x10 from skb and is stored in RAX register) if (!dev->headerops || !dev->headerops->parseprotocol) 22e1: mov 0x10(%rbx),%rax 22e5: mov 0x230(%rax),%rax

Setting skb->dev before the call in tap.c fixes the issue.

BUG: kernel NULL pointer dereference, address: 0000000000000230 RIP: 0010:virtionethdrtoskb.constprop.0+0x335/0x410 [tap] Code: c0 0f 85 b7 fd ff ff eb d4 41 39 c6 77 cf 29 c6 48 89 df 44 01 f6 e8 7a 79 83 c1 48 85 c0 0f 85 d9 fd ff ff eb b7 48 8b 43 10 <48> 8b 80 30 02 00 00 48 85 c0 74 55 48 8b 40 28 48 85 c0 74 4c 48 RSP: 0018:ffffc90005c27c38 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888298f25300 RCX: 0000000000000010 RDX: 0000000000000005 RSI: ffffc90005c27cb6 RDI: ffff888298f25300 RBP: ffffc90005c27c80 R08: 00000000ffffffea R09: 00000000000007e8 R10: ffff88858ec77458 R11: 0000000000000000 R12: 0000000000000001 R13: 0000000000000014 R14: ffffc90005c27e08 R15: ffffc90005c27cb6 FS: 0000000000000000(0000) GS:ffff88858ec40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000230 CR3: 0000000281408006 CR4: 00000000003706e0 Call Trace: tapgetuser+0x3f1/0x540 [tap] tapsendmsg+0x56/0x362 [tap] ? gettxbufs+0xc2/0x1e0 [vhostnet] handletxcopy+0x114/0x670 [vhostnet] handletx+0xb0/0xe0 [vhostnet] handletxkick+0x15/0x20 [vhostnet] vhostworker+0x7b/0xc0 [vhost] ? vhostvringcallreset+0x40/0x40 [vhost] kthread+0xfa/0x120 ? kthreadcompleteandexit+0x20/0x20 retfromfork+0x1f/0x30

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

ipvs: fix uninit-value for saddr in dooutputroute4

syzbot reports for uninit-value for the saddr argument [1]. commit 4754957f04f5 ("ipvs: do not use random local source address for tunnels") already implies that the input value of saddr should be ignored but the code is still reading it which can prevent to connect the route. Fix it by changing the argument to retsaddr.

[1] BUG: KMSAN: uninit-value in dooutputroute4+0x42c/0x4d0 net/netfilter/ipvs/ipvsxmit.c:147 dooutputroute4+0x42c/0x4d0 net/netfilter/ipvs/ipvsxmit.c:147 ipvsgetoutrt+0x403/0x21d0 net/netfilter/ipvs/ipvsxmit.c:330 ipvstunnelxmit+0x205/0x2380 net/netfilter/ipvs/ipvsxmit.c:1136 ipvsinhook+0x1aa5/0x35b0 net/netfilter/ipvs/ipvscore.c:2063 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xf7/0x400 net/netfilter/core.c:626 nfhook include/linux/netfilter.h:269 [inline] iplocalout+0x758/0x7e0 net/ipv4/ipoutput.c:118 iplocalout net/ipv4/ipoutput.c:127 [inline] ipsendskb+0x6a/0x3c0 net/ipv4/ipoutput.c:1501 udpsendskb+0xfda/0x1b70 net/ipv4/udp.c:1195 udpsendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inetsendmsg+0x1fc/0x280 net/ipv4/afinet.c:851 socksendmsgnosec net/socket.c:712 [inline] socksendmsg+0x267/0x380 net/socket.c:727 syssendmsg+0x91b/0xda0 net/socket.c:2566 syssendmsg+0x28d/0x3c0 net/socket.c:2620 syssendmmsg+0x41d/0x880 net/socket.c:2702 compatsyssendmmsg net/compat.c:360 [inline] docompatsyssendmmsg net/compat.c:367 [inline] secompatsyssendmmsg net/compat.c:364 [inline] ia32compatsyssendmmsg+0xc8/0x140 net/compat.c:364 ia32syscall+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls32.h:346 dosyscall32irqson arch/x86/entry/syscall32.c:83 [inline] dofastsyscall32+0xb0/0x110 arch/x86/entry/syscall32.c:306 dofastsyscall32+0x38/0x80 arch/x86/entry/syscall32.c:331 doSYSENTER32+0x1f/0x30 arch/x86/entry/syscall32.c:369 entrySYSENTERcompatafterhwframe+0x84/0x8e

Uninit was created at: slabpostallochook mm/slub.c:4167 [inline] slaballocnode mm/slub.c:4210 [inline] kmalloccachenoprof+0x8fa/0xe00 mm/slub.c:4367 kmallocnoprof include/linux/slab.h:905 [inline] ipvsdestdstalloc net/netfilter/ipvs/ipvsxmit.c:61 [inline] ipvsgetoutrt+0x35d/0x21d0 net/netfilter/ipvs/ipvsxmit.c:323 ipvstunnelxmit+0x205/0x2380 net/netfilter/ipvs/ipvsxmit.c:1136 ipvsinhook+0x1aa5/0x35b0 net/netfilter/ipvs/ipvscore.c:2063 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xf7/0x400 net/netfilter/core.c:626 nfhook include/linux/netfilter.h:269 [inline] iplocalout+0x758/0x7e0 net/ipv4/ipoutput.c:118 iplocalout net/ipv4/ipoutput.c:127 [inline] ipsendskb+0x6a/0x3c0 net/ipv4/ipoutput.c:1501 udpsendskb+0xfda/0x1b70 net/ipv4/udp.c:1195 udpsendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inetsendmsg+0x1fc/0x280 net/ipv4/afinet.c:851 socksendmsgnosec net/socket.c:712 [inline] socksendmsg+0x267/0x380 net/socket.c:727 syssendmsg+0x91b/0xda0 net/socket.c:2566 syssendmsg+0x28d/0x3c0 net/socket.c:2620 syssendmmsg+0x41d/0x880 net/socket.c:2702 compatsyssendmmsg net/compat.c:360 [inline] docompatsyssendmmsg net/compat.c:367 [inline] secompatsyssendmmsg net/compat.c:364 [inline] ia32compatsyssendmmsg+0xc8/0x140 net/compat.c:364 ia32syscall+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls32.h:346 dosyscall32irqson arch/x86/entry/syscall32.c:83 [inline] dofastsyscall32+0xb0/0x110 arch/x86/entry/syscall32.c:306 dofastsyscall32+0x38/0x80 arch/x86/entry/syscall32.c:331 doSYSENTER32+0x1f/0x30 arch/x86/entry/syscall32.c:369 entrySYSENTERcompatafterhwframe+0x84/0x8e

CPU: 0 UID: 0 PID: 22408 Comm: syz.4.5165 Not tainted 6.15.0-rc3-syzkaller-00019-gbc3372351d0c #0 PREEMPT(undef) Hardware name: Google Google Compute Engi ---truncated---

drm/amdkfd: debugfs hanghws skip GPU with MES

drm/amdgpu: handle amdgpucgscreatedevice() errors in amdpowerplaycreate()

block: fix resource leak in blkregisterqueue() error path

bpf: Fix deadlock between rcutaskstrace and eventmutex.

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

perf/core: Fix WARNON(!ctx) in freeevent() for partial init

Move the getctx(childctx) call and the childevent->ctx assignment to occur immediately after the child event is allocated. Ensure that childevent->ctx is non-NULL before any subsequent error path within inheritevent calls freeevent(), satisfying the assumptions of the cleanup code.

Details:

There's no clear Fixes tag, because this bug is a side-effect of multiple interacting commits over time (up to 15 years old), not a single regression.

The code initially incremented refcount then assigned context immediately after the childevent was created. Later, an early validity check for childevent was added before the refcount/assignment. Even later, a WARNONONCE() cleanup check was added, assuming event->ctx is valid if the pmuctx is valid. The problem is that the WARNONONCE() could trigger after the initial check passed but before childevent->ctx was assigned, violating its precondition. The solution is to assign childevent->ctx right after its initial validation. This ensures the context exists for any subsequent checks or cleanup routines, resolving the WARNONONCE().

To resolve it, defer the refcount update and childevent->ctx assignment directly after childevent->pmuctx is set but before checking if the parent event is orphaned. The cleanup routine depends on event->pmuctx being non-NULL before it verifies event->ctx is non-NULL. This also maintains the author's original intent of passing in childctx to findgetpmucontext before its refcount/assignment.

[ mingo: Expanded the changelog from another email by Gabriel Shahrouzi. ]

dm-raid: really frozen syncthread during suspend

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

x86/sgx: Prevent attempts to reclaim poisoned pages

TL;DR: SGX page reclaim touches the page to copy its contents to secondary storage. SGX instructions do not gracefully handle machine checks. Despite this, the existing SGX code will try to reclaim pages that it knows are poisoned. Avoid even trying to reclaim poisoned pages.

The longer story:

Pages used by an enclave only get epcpage->poison set in archmemoryfailure() but they currently stay on sgxactivepagelist until sgxenclrelease(), with the SGXEPCPAGERECLAIMERTRACKED flag untouched.

epcpage->poison is not checked in the reclaimer logic meaning that, if other conditions are met, an attempt will be made to reclaim an EPC page that was poisoned. This is bad because 1. we don't want that page to end up added to another enclave and 2. it is likely to cause one core to shut down and the kernel to panic.

Specifically, reclaiming uses microcode operations including "EWB" which accesses the EPC page contents to encrypt and write them out to non-SGX memory. Those operations cannot handle MCEs in their accesses other than by putting the executing core into a special shutdown state (affecting both threads with HT.) The kernel will subsequently panic on the remaining cores seeing the core didn't enter MCE handler(s) in time.

Call sgxunmarkpagereclaimable() to remove the affected EPC page from sgxactivepagelist on memory error to stop it being considered for reclaiming.

Testing epcpage->poison in sgxreclaimpages() would also work but I assume it's better to add code in the less likely paths.

The affected EPC page is not added to &node->sgxpoisonpagelist until later in sgxenclrelease()->sgxfreeepcpage() when it is EREMOVEd. Membership on other lists doesn't change to avoid changing any of the lists' semantics except for sgxactivepagelist. There's a "TBD" comment in archmemoryfailure() about pre-emptive actions, the goal here is not to address everything that it may imply.

This also doesn't completely close the time window when a memory error notification will be fatal (for a not previously poisoned EPC page) -- the MCE can happen after sgxreclaimpages() has selected its candidates or even inside a microcode operation (actually easy to trigger due to the amount of time spent in them.)

The spinlock in sgxunmarkpagereclaimable() is safe because memoryfailure() runs in process context and no spinlocks are held, explicitly noted in a mm/memory-failure.c comment.

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

ksm: use range-walk function to jump over holes in scangetnextrmapitem

Currently, scangetnextrmapitem() walks every page address in a VMA to locate mergeable pages. This becomes highly inefficient when scanning large virtual memory areas that contain mostly unmapped regions, causing ksmd to use large amount of cpu without deduplicating much pages.

This patch replaces the per-address lookup with a range walk using walkpagerange(). The range walker allows KSM to skip over entire unmapped holes in a VMA, avoiding unnecessary lookups. This problem was previously discussed in [1].

Consider the following test program which creates a 32 TiB mapping in the virtual address space but only populates a single page:

#include <unistd.h> #include <stdio.h> #include <sys/mman.h>

/ 32 TiB / const sizet size = 32ul 1024 1024 1024 1024;

int main() { char area = mmap(NULL, size, PROTREAD | PROTWRITE, MAPNORESERVE | MAPPRIVATE | MAPANON, -1, 0);

if (area == MAPFAILED) { perror("mmap() failed\n"); return -1; }

/ Populate a single page such that we get an anonvma. / area = 0;

/ Enable KSM. / madvise(area, size, MADVMERGEABLE); pause(); return 0; }

$ ./ksm-sparse & $ echo 1 > /sys/kernel/mm/ksm/run

Without this patch ksmd uses 100% of the cpu for a long time (more then 1 hour in my test machine) scanning all the 32 TiB virtual address space that contain only one mapped page. This makes ksmd essentially deadlocked not able to deduplicate anything of value. With this patch ksmd walks only the one mapped page and skips the rest of the 32 TiB virtual address space, making the scan fast using little cpu.

A race condidition in systemd-coredump allows a local attacker to crash a SUID program and gain read access to the resulting core dump

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

KEYS: trusted: Fix a memory leak in tpm2loadcmd

'tpm2loadcmd' allocates a tempoary blob indirectly via 'tpm2keydecode' but it is not freed in the failure paths. Address this by wrapping the blob into with a cleanup helper.

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

net: mscc: ocelot: Fix crash when adding interface under a lag

Commit 15faa1f67ab4 ("lan966x: Fix crash when adding interface under a lag") fixed a similar issue in the lan966x driver caused by a NULL pointer dereference. The ocelotsetaggrpgids() function in the ocelot driver has similar logic and is susceptible to the same crash.

This issue specifically affects the ocelotvsc7514.c frontend, which leaves unused ports as NULL pointers. The felixvsc9959.c frontend is unaffected as it uses the DSA framework which registers all ports.

Fix this by checking if the port pointer is valid before accessing it.

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

net: sock: fix hardened usercopy panic in sockrecverrqueue

skbufffclonecache was created without defining a usercopy region, [1] unlike skbuffheadcache which properly whitelists the cb[] field. [2] This causes a usercopy BUG() when CONFIGHARDENEDUSERCOPY is enabled and the kernel attempts to copy skbuff.cb data to userspace via sockrecverrqueue() -> putcmsg().

The crash occurs when: 1. TCP allocates an skb using allocskbfclone() (from skbufffclonecache) [1] 2. The skb is cloned via skbclone() using the pre-allocated fclone [3] 3. The cloned skb is queued to skerrorqueue for timestamp reporting 4. Userspace reads the error queue via recvmsg(MSGERRQUEUE) 5. sockrecverrqueue() calls putcmsg() to copy serr->ee from skb->cb [4] 6. checkheapobject() fails because skbufffclonecache has no usercopy whitelist [5]

When cloned skbs allocated from skbufffclonecache are used in the socket error queue, accessing the sockexterrskb structure in skb->cb via putcmsg() triggers a usercopy hardening violation:

[ 5.379589] usercopy: Kernel memory exposure attempt detected from SLUB object 'skbufffclonecache' (offset 296, size 16)! [ 5.382796] kernel BUG at mm/usercopy.c:102! [ 5.383923] Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI [ 5.384903] CPU: 1 UID: 0 PID: 138 Comm: pocputcmsg Not tainted 6.12.57 #7 [ 5.384903] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 5.384903] RIP: 0010:usercopyabort+0x6c/0x80 [ 5.384903] Code: 1a 86 51 48 c7 c2 40 15 1a 86 41 52 48 c7 c7 c0 15 1a 86 48 0f 45 d6 48 c7 c6 80 15 1a 86 48 89 c1 49 0f 45 f3 e8 84 27 88 ff <0f> 0b 490 [ 5.384903] RSP: 0018:ffffc900006f77a8 EFLAGS: 00010246 [ 5.384903] RAX: 000000000000006f RBX: ffff88800f0ad2a8 RCX: 1ffffffff0f72e74 [ 5.384903] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff87b973a0 [ 5.384903] RBP: 0000000000000010 R08: 0000000000000000 R09: fffffbfff0f72e74 [ 5.384903] R10: 0000000000000003 R11: 79706f6372657375 R12: 0000000000000001 [ 5.384903] R13: ffff88800f0ad2b8 R14: ffffea00003c2b40 R15: ffffea00003c2b00 [ 5.384903] FS: 0000000011bc4380(0000) GS:ffff8880bf100000(0000) knlGS:0000000000000000 [ 5.384903] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 5.384903] CR2: 000056aa3b8e5fe4 CR3: 000000000ea26004 CR4: 0000000000770ef0 [ 5.384903] PKRU: 55555554 [ 5.384903] Call Trace: [ 5.384903] <TASK> [ 5.384903] checkheapobject+0x9a/0xd0 [ 5.384903] checkobjectsize+0x46c/0x690 [ 5.384903] putcmsg+0x129/0x5e0 [ 5.384903] sockrecverrqueue+0x22f/0x380 [ 5.384903] tlsswrecvmsg+0x7ed/0x1960 [ 5.384903] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 5.384903] ? schedule+0x6d/0x270 [ 5.384903] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 5.384903] ? mutexunlock+0x81/0xd0 [ 5.384903] ? pfxmutexunlock+0x10/0x10 [ 5.384903] ? pfxtlsswrecvmsg+0x10/0x10 [ 5.384903] ? rawspinlockirqsave+0x8f/0xf0 [ 5.384903] ? rawreadunlockirqrestore+0x20/0x40 [ 5.384903] ? srsoaliasreturnthunk+0x5/0xfbef5

The crash offset 296 corresponds to skb2->cb within skbufffclones: - sizeof(struct skbuff) = 232 - offsetof(struct skbuff, cb) = 40 - offset of skb2.cb in fclones = 232 + 40 = 272 - crash offset 296 = 272 + 24 (inside sockexterrskb.ee)

This patch uses a local stack variable as a bounce buffer to avoid the hardened usercopy check failure.

[1] https://elixir.bootlin.com/linux/v6.12.62/source/net/ipv4/tcp.c#L885 [2] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5104 [3] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5566 [4] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5491 [5] https://elixir.bootlin.com/linux/v6.12.62/source/mm/slub.c#L5719

dmaengine: idxd: fix device leaks on compat bind and unbind

bpf: Do not let BPF test infra emit invalid GSO types to stack

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

x86/vmscape: Add conditional IBPB mitigation

VMSCAPE is a vulnerability that exploits insufficient branch predictor isolation between a guest and a userspace hypervisor (like QEMU). Existing mitigations already protect kernel/KVM from a malicious guest. Userspace can additionally be protected by flushing the branch predictors after a VMexit.

Since it is the userspace that consumes the poisoned branch predictors, conditionally issue an IBPB after a VMexit and before returning to userspace. Workloads that frequently switch between hypervisor and userspace will incur the most overhead from the new IBPB.

This new IBPB is not integrated with the existing IBPB sites. For instance, a task can use the existing speculation control prctl() to get an IBPB at context switch time. With this implementation, the IBPB is doubled up: one at context switch and another before running userspace.

The intent is to integrate and optimize these cases post-embargo.

[ dhansen: elaborate on suboptimal IBPB solution ]

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

x86/mm/64: define ARCHPAGETABLESYNCMASK and archsynckernelmappings()

Define ARCHPAGETABLESYNCMASK and archsynckernelmappings() to ensure page tables are properly synchronized when calling pdpopulatekernel().

For 5-level paging, synchronization is performed via pgdpopulatekernel(). In 4-level paging, pgdpopulate() is a no-op, so synchronization is instead performed at the P4D level via p4dpopulatekernel().

This fixes intermittent boot failures on systems using 4-level paging and a large amount of persistent memory:

BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:initsinglepage+0x9/0x6d Call Trace: <TASK> initzonedevicepage+0x17/0x5d memmapinitzonedevice+0x154/0x1bb pagemaprange+0x2e0/0x40f memremappages+0x10b/0x2f0 devmmemremappages+0x1e/0x60 devdaxprobe+0xce/0x2ec [devicedax] daxbusprobe+0x6d/0xc9 [... snip ...] </TASK>

It also fixes a crash in vmemmapsetpmd() caused by accessing vmemmap before syncglobalpgds() [1]:

BUG: unable to handle page fault for address: ffffeb3ff1200000 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 0 P4D 0 Oops: Oops: 0002 [#1] PREEMPT SMP NOPTI Tainted: [W]=WARN RIP: 0010:vmemmapsetpmd+0xff/0x230 <TASK> vmemmappopulatehugepages+0x176/0x180 vmemmappopulate+0x34/0x80 populatesectionmemmap+0x41/0x90 sparseaddsection+0x121/0x3e0 addpages+0xba/0x150 addpages+0x1d/0x70 memremappages+0x3dc/0x810 devmmemremappages+0x1c/0x60 xedevmadd+0x8b/0x100 [xe] xetileinitnoalloc+0x6a/0x70 [xe] xedeviceprobe+0x48c/0x740 [xe] [... snip ...]

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

net: bridge: fix soft lockup in brmulticastqueryexpired()

When set multicastqueryinterval to a large value, the local variable 'time' in brmulticastsendquery() may overflow. If the time is smaller than jiffies, the timer will expire immediately, and then call modtimer() again, which creates a loop and may trigger the following soft lockup issue.

watchdog: BUG: soft lockup - CPU#1 stuck for 221s! [rbconsumer:66] CPU: 1 UID: 0 PID: 66 Comm: rbconsumer Not tainted 6.16.0+ #259 PREEMPT(none) Call Trace: <IRQ> netdevallocskb+0x2e/0x3a0 brip6multicastallocquery+0x212/0x1b70 brmulticastsendquery+0x376/0xac0 brmulticastsendquery+0x299/0x510 brmulticastqueryexpired.constprop.0+0x16d/0x1b0 calltimerfn+0x3b/0x2a0 runtimers+0x619/0x950 runtimersoftirq+0x11c/0x220 handlesoftirqs+0x18e/0x560 irqexitrcu+0x158/0x1a0 sysvecapictimerinterrupt+0x76/0x90 </IRQ>

This issue can be reproduced with: ip link add br0 type bridge echo 1 > /sys/class/net/br0/bridge/multicastquerier echo 0xffffffffffffffff > /sys/class/net/br0/bridge/multicastqueryinterval ip link set dev br0 up

The multicaststartupqueryinterval can also cause this issue. Similar to the commit 99b40610956a ("net: bridge: mcast: add and enforce query interval minimum"), add check for the query interval maximum to fix this issue.

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

jbd2: prevent softlockup in jbd2logdocheckpoint()

Both jbd2logdocheckpoint() and jbd2journalshrinkcheckpointlist() periodically release jlistlock after processing a batch of buffers to avoid long hold times on the jlistlock. However, since both functions contend for jlistlock, the combined time spent waiting and processing can be significant.

jbd2journalshrinkcheckpointlist() explicitly calls condresched() when needresched() is true to avoid softlockups during prolonged operations. But jbd2logdocheckpoint() only exits its loop when needresched() is true, relying on potentially sleeping functions like flushbatch() or waitonbuffer() to trigger rescheduling. If those functions do not sleep, the kernel may hit a softlockup.

watchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373] CPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10 Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017 Workqueue: writeback wbworkfn (flush-7:2) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : nativequeuedspinlockslowpath+0x358/0x418 lr : jbd2logdocheckpoint+0x31c/0x438 [jbd2] Call trace: nativequeuedspinlockslowpath+0x358/0x418 jbd2logdocheckpoint+0x31c/0x438 [jbd2] jbd2logwaitforspace+0xfc/0x2f8 [jbd2] addtransactioncredits+0x3bc/0x418 [jbd2] startthishandle+0xf8/0x560 [jbd2] jbd2journalstart+0x118/0x228 [jbd2] ext4journalstartsb+0x110/0x188 [ext4] ext4dowritepages+0x3dc/0x740 [ext4] ext4writepages+0xa4/0x190 [ext4] dowritepages+0x94/0x228 writebacksingleinode+0x48/0x318 writebacksbinodes+0x204/0x590 writebackinodeswb+0x54/0xf8 wbwriteback+0x2cc/0x3d8 wbdowriteback+0x2e0/0x2f8 wbworkfn+0x80/0x2a8 processonework+0x178/0x3e8 workerthread+0x234/0x3b8 kthread+0xf0/0x108 retfromfork+0x10/0x20

So explicitly call condresched() in jbd2logdocheckpoint() to avoid softlockup.

block: avoid possible overflow for chunksectors check in blkstacklimits()

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

netfilter: ctnetlink: remove refcounting in expectation dumpers

Same pattern as previous patch: do not keep the expectation object alive via refcount, only store a cookie value and then use that as the skip hint for dump resumption.

AFAICS this has the same issue as the one resolved in the conntrack dumper, when we do if (!refcountincnotzero(&exp->use))

to increment the refcount, there is a chance that exp == last, which causes a double-increment of the refcount and subsequent memory leak.