dmaengine: idxd: fix device leaks on compat bind and unbind
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: usb: rtl8150: fix memory leak on usbsubmiturb() failure
In asyncsetregisters(), when usbsubmiturb() fails, the allocated asyncreq structure and URB are not freed, causing a memory leak.
The completion callback asyncsetregcb() is responsible for freeing these allocations, but it is only called after the URB is successfully submitted and completes (successfully or with error). If submission fails, the callback never runs and the memory is leaked.
Fix this by freeing both the URB and the request structure in the error path when usbsubmiturb() fails.
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: 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
In the Linux kernel, the following vulnerability has been resolved:
net/sched: schqfq: Fix NULL deref when deactivating inactive aggregate in qfqreset
qfqclass->leafqdisc->q.qlen > 0 does not imply that the class itself is active.
Two qfqclass objects may point to the same leafqdisc. This happens when:
1. one QFQ qdisc is attached to the dev as the root qdisc, and
2. another QFQ qdisc is temporarily referenced (e.g., via qdiscget() / qdiscput()) and is pending to be destroyed, as in function tcnewtfilter.
When packets are enqueued through the root QFQ qdisc, the shared leafqdisc->q.qlen increases. At the same time, the second QFQ qdisc triggers qdiscput and qdiscdestroy: the qdisc enters qfqreset() with its own q->q.qlen == 0, but its class's leaf qdisc->q.qlen > 0. Therefore, the qfqreset would wrongly deactivate an inactive aggregate and trigger a null-deref in qfqdeactivateagg:
[ 0.903172] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 0.903571] #PF: supervisor write access in kernel mode [ 0.903860] #PF: errorcode(0x0002) - not-present page [ 0.904177] PGD 10299b067 P4D 10299b067 PUD 10299c067 PMD 0 [ 0.904502] Oops: Oops: 0002 [#1] SMP NOPTI [ 0.904737] CPU: 0 UID: 0 PID: 135 Comm: exploit Not tainted 6.19.0-rc3+ #2 NONE [ 0.905157] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 0.905754] RIP: 0010:qfqdeactivateagg (include/linux/list.h:992 (discriminator 2) include/linux/list.h:1006 (discriminator 2) net/sched/schqfq.c:1367 (discriminator 2) net/sched/schqfq.c:1393 (discriminator 2)) [ 0.906046] Code: 0f 84 4d 01 00 00 48 89 70 18 8b 4b 10 48 c7 c2 ff ff ff ff 48 8b 78 08 48 d3 e2 48 21 f2 48 2b 13 48 8b 30 48 d3 ea 8b 4b 18 0
Code starting with the faulting instruction =========================================== 0: 0f 84 4d 01 00 00 je 0x153 6: 48 89 70 18 mov %rsi,0x18(%rax) a: 8b 4b 10 mov 0x10(%rbx),%ecx d: 48 c7 c2 ff ff ff ff mov $0xffffffffffffffff,%rdx 14: 48 8b 78 08 mov 0x8(%rax),%rdi 18: 48 d3 e2 shl %cl,%rdx 1b: 48 21 f2 and %rsi,%rdx 1e: 48 2b 13 sub (%rbx),%rdx 21: 48 8b 30 mov (%rax),%rsi 24: 48 d3 ea shr %cl,%rdx 27: 8b 4b 18 mov 0x18(%rbx),%ecx ... [ 0.907095] RSP: 0018:ffffc900004a39a0 EFLAGS: 00010246 [ 0.907368] RAX: ffff8881043a0880 RBX: ffff888102953340 RCX: 0000000000000000 [ 0.907723] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 0.908100] RBP: ffff888102952180 R08: 0000000000000000 R09: 0000000000000000 [ 0.908451] R10: ffff8881043a0000 R11: 0000000000000000 R12: ffff888102952000 [ 0.908804] R13: ffff888102952180 R14: ffff8881043a0ad8 R15: ffff8881043a0880 [ 0.909179] FS: 000000002a1a0380(0000) GS:ffff888196d8d000(0000) knlGS:0000000000000000 [ 0.909572] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.909857] CR2: 0000000000000000 CR3: 0000000102993002 CR4: 0000000000772ef0 [ 0.910247] PKRU: 55555554 [ 0.910391] Call Trace: [ 0.910527] <TASK> [ 0.910638] qfqresetqdisc (net/sched/schqfq.c:357 net/sched/schqfq.c:1485) [ 0.910826] qdiscreset (include/linux/skbuff.h:2195 include/linux/skbuff.h:2501 include/linux/skbuff.h:3424 include/linux/skbuff.h:3430 net/sched/schgeneric.c:1036) [ 0.911040] qdiscdestroy (net/sched/schgeneric.c:1076) [ 0.911236] tcnewtfilter (net/sched/clsapi.c:2447) [ 0.911447] rtnetlinkrcvmsg (net/core/rtnetlink.c:6958) [ 0.911663] ? pfxrtnetlinkrcvmsg (net/core/rtnetlink.c:6861) [ 0.911894] netlinkrcvskb (net/netlink/afnetlink.c:2550) [ 0.912100] netlinkunicast (net/netlink/afnetlink.c:1319 net/netlink/afnetlink.c:1344) [ 0.912296] ? allocskb (net/core/skbuff.c:706) [ 0.912484] netlinksendmsg (net/netlink/af ---truncated---
bpf: Do not let BPF test infra emit invalid GSO types to stack
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.
In the Linux kernel, the following vulnerability has been resolved:
usbnet: Fix using smpprocessorid() in preemptible code warnings
Syzbot reported the following warning:
BUG: using smpprocessorid() in preemptible [00000000] code: dhcpcd/2879 caller is usbnetskbreturn+0x74/0x490 drivers/net/usb/usbnet.c:331 CPU: 1 UID: 0 PID: 2879 Comm: dhcpcd Not tainted 6.15.0-rc4-syzkaller-00098-g615dca38c2ea #0 PREEMPT(voluntary) Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x16c/0x1f0 lib/dumpstack.c:120 checkpreemptiondisabled+0xd0/0xe0 lib/smpprocessorid.c:49 usbnetskbreturn+0x74/0x490 drivers/net/usb/usbnet.c:331 usbnetresumerx+0x4b/0x170 drivers/net/usb/usbnet.c:708 usbnetchangemtu+0x1be/0x220 drivers/net/usb/usbnet.c:417 devsetmtu net/core/dev.c:9443 [inline] netifsetmtuext+0x369/0x5c0 net/core/dev.c:9496 netifsetmtu+0xb0/0x160 net/core/dev.c:9520 devsetmtu+0xae/0x170 net/core/devapi.c:247 devifsioc+0xa31/0x18d0 net/core/devioctl.c:572 devioctl+0x223/0x10e0 net/core/devioctl.c:821 sockdoioctl+0x19d/0x280 net/socket.c:1204 sockioctl+0x42f/0x6a0 net/socket.c:1311 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:906 [inline] sesysioctl fs/ioctl.c:892 [inline] x64sysioctl+0x190/0x200 fs/ioctl.c:892 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xcd/0x260 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f
For historical and portability reasons, the netifrx() is usually run in the softirq or interrupt context, this commit therefore add localbhdisable/enable() protection in the usbnetresumerx().
dmaengine: qcom: bamdma: Fix DT error handling for num-channels/ees
bpf: Tell memcg to use allowspinning=false path in bpftimerinit()
In the Linux kernel, the following vulnerability has been resolved:
ppp: fix memory leak in padcompressskb
If allocskb() fails in padcompressskb(), it returns NULL without releasing the old skb. The caller does:
skb = padcompressskb(ppp, skb); if (!skb) goto drop;
drop: kfreeskb(skb);
When padcompressskb() returns NULL, the reference to the old skb is lost and kfreeskb(skb) ends up doing nothing, leading to a memory leak.
Align padcompressskb() semantics with realloc(): only free the old skb if allocation and compression succeed. At the call site, use the newskb variable so the original skb is not lost when padcompressskb() fails.
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:
mm: move page table sync declarations to linux/pgtable.h
During our internal testing, we started observing intermittent boot failures when the machine uses 4-level paging and has 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 turns out that the kernel panics while initializing vmemmap (struct page array) when the vmemmap region spans two PGD entries, because the new PGD entry is only installed in initmm.pgd, but not in the page tables of other tasks.
And looking at populatesectionmemmap(): if (vmemmapcanoptimize(altmap, pgmap)) // does not sync top level page tables r = vmemmappopulatecompoundpages(pfn, start, end, nid, pgmap); else // sync top level page tables in x86 r = vmemmappopulate(start, end, nid, altmap);
In the normal path, vmemmappopulate() in arch/x86/mm/init64.c synchronizes the top level page table (See commit 9b861528a801 ("x86-64, mem: Update all PGDs for direct mapping and vmemmap mapping changes")) so that all tasks in the system can see the new vmemmap area.
However, when vmemmapcanoptimize() returns true, the optimized path skips synchronization of top-level page tables. This is because vmemmappopulatecompoundpages() is implemented in core MM code, which does not handle synchronization of the top-level page tables. Instead, the core MM has historically relied on each architecture to perform this synchronization manually.
We're not the first party to encounter a crash caused by not-sync'd top level page tables: earlier this year, Gwan-gyeong Mun attempted to address the issue [1] [2] after hitting a kernel panic when x86 code accessed the vmemmap area before the corresponding top-level entries were synced. At that time, the issue was believed to be triggered only when struct page was enlarged for debugging purposes, and the patch did not get further updates.
It turns out that current approach of relying on each arch to handle the page table sync manually is fragile because 1) it's easy to forget to sync the top level page table, and 2) it's also easy to overlook that the kernel should not access the vmemmap and direct mapping areas before the sync.
The solution: Make page table sync more code robust and harder to miss
To address this, Dave Hansen suggested [3] [4] introducing {pgd,p4d}populatekernel() for updating kernel portion of the page tables and allow each architecture to explicitly perform synchronization when installing top-level entries. With this approach, we no longer need to worry about missing the sync step, reducing the risk of future regressions.
The new interface reuses existing ARCHPAGETABLESYNCMASK, PGTBLPDMODIFIED and archsynckernelmappings() facility used by vmalloc and ioremap to synchronize page tables.
pgdpopulatekernel() looks like this: static inline void pgdpopulatekernel(unsigned long addr, pgdt pgd, p4dt p4d) { pgdpopulate(&initmm, pgd, p4d); if (ARCHPAGETABLESYNCMASK & PGTBLPGDMODIFIED) archsynckernelmappings(addr, addr); }
It is worth noting that vmalloc() and applytorange() carefully synchronizes page tables by calling pdalloctrack() and archsynckernelmappings(), and thus they are not affected by ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
f2fs: don't reset unchangable mount option in f2fsremount()
syzbot reports a bug as below:
general protection fault, probably for non-canonical address 0xdffffc0000000009: 0000 [#1] PREEMPT SMP KASAN RIP: 0010:lockacquire+0x69/0x2000 kernel/locking/lockdep.c:4942 Call Trace: lockacquire+0x1e3/0x520 kernel/locking/lockdep.c:5691 rawwritelock include/linux/rwlockapismp.h:209 [inline] rawwritelock+0x2e/0x40 kernel/locking/spinlock.c:300 dropextenttree+0x3ac/0x660 fs/f2fs/extentcache.c:1100 f2fsdropextenttree+0x17/0x30 fs/f2fs/extentcache.c:1116 f2fsinsertrange+0x2d5/0x3c0 fs/f2fs/file.c:1664 f2fsfallocate+0x4e4/0x6d0 fs/f2fs/file.c:1838 vfsfallocate+0x54b/0x6b0 fs/open.c:324 ksysfallocate fs/open.c:347 [inline] dosysfallocate fs/open.c:355 [inline] sesysfallocate fs/open.c:353 [inline] x64sysfallocate+0xbd/0x100 fs/open.c:353 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x41/0xc0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd
The root cause is race condition as below: - since it tries to remount rw filesystem, so that doremount won't call sbprepareremountreadonly to block fallocate, there may be race condition in between remount and fallocate. - in f2fsremount(), defaultoptions() will reset mount option to default one, and then update it based on result of parseoptions(), so there is a hole which race condition can happen.
Thread A Thread B - f2fsfillsuper - parseoptions - clearopt(READEXTENTCACHE)
- f2fsremount - defaultoptions - setopt(READEXTENTCACHE) - f2fsfallocate - f2fsinsertrange - f2fsdropextenttree - dropextenttree - mayextenttree - testopt(READEXTENTCACHE) return true - writelock(&et->lock) access NULL pointer - parseoptions - clearopt(READEXTENTCACHE)
In the Linux kernel, the following vulnerability has been resolved:
x86/MCE: Always save CS register on AMD Zen IF Poison errors
The Instruction Fetch (IF) units on current AMD Zen-based systems do not guarantee a synchronous #MC is delivered for poison consumption errors. Therefore, MCGSTATUS[EIPV|RIPV] will not be set. However, the microarchitecture does guarantee that the exception is delivered within the same context. In other words, the exact rIP is not known, but the context is known to not have changed.
There is no architecturally-defined method to determine this behavior.
The Code Segment (CS) register is always valid on such IF unit poison errors regardless of the value of MCGSTATUS[EIPV|RIPV].
Add a quirk to save the CS register for poison consumption from the IF unit banks.
This is needed to properly determine the context of the error. Otherwise, the severity grading function will assume the context is INKERNEL due to the m->cs value being 0 (the initialized value). This leads to unnecessary kernel panics on data poison errors due to the kernel believing the poison consumption occurred in kernel context.
In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: fix ofiomap memory leak
Smatch reports: drivers/clk/mediatek/clk-mtk.c:583 mtkclksimpleprobe() warn: 'base' from ofiomap() not released on lines: 496.
This problem was also found in linux-next. In mtkclksimpleprobe(), base is not released when handling errors if clkdata is not existed, which may cause a leak. So freebase should be added here to release base.
In the Linux kernel, the following vulnerability has been resolved:
blk-cgroup: Reinit blkgiostatset after clearing in blkcgresetstats()
When blkgalloc() is called to allocate a blkcggq structure with the associated blkgiostatset's, there are 2 fields within blkgiostatset that requires proper initialization - blkg & sync. The former field was introduced by commit 3b8cc6298724 ("blk-cgroup: Optimize blkcgrstatflush()") while the later one was introduced by commit f73316482977 ("blk-cgroup: reimplement basic IO stats using cgroup rstat").
Unfortunately those fields in the blkgiostatset's are not properly re-initialized when they are cleared in v1's blkcgresetstats(). This can lead to a kernel panic due to NULL pointer access of the blkg pointer. The missing initialization of sync is less problematic and can be a problem in a debug kernel due to missing lockdep initialization.
Fix these problems by re-initializing them after memory clearing.
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:
USB: ULPI: fix memory leak with using debugfslookup()
When calling debugfslookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfslookupandremove() instead which handles all of the logic at once.
In the Linux kernel, the following vulnerability has been resolved:
mm: kmem: fix a NULL pointer dereference in objstockflushrequired()
KCSAN found an issue in objstockflushrequired(): stock->cachedobjcg can be reset between the check and dereference:
================================================================== BUG: KCSAN: data-race in drainallstock / drainobjstock
write to 0xffff888237c2a2f8 of 8 bytes by task 19625 on cpu 0: drainobjstock+0x408/0x4e0 mm/memcontrol.c:3306 refillobjstock+0x9c/0x1e0 mm/memcontrol.c:3340 objcgroupuncharge+0xe/0x10 mm/memcontrol.c:3408 memcgslabfreehook mm/slab.h:587 [inline] cachefree mm/slab.c:3373 [inline] dokmemcachefree mm/slab.c:3577 [inline] kmemcachefree+0x105/0x280 mm/slab.c:3602 dfree fs/dcache.c:298 [inline] dentryfree fs/dcache.c:375 [inline] dentrykill+0x422/0x4a0 fs/dcache.c:621 dentrykill+0x8d/0x1e0 dput+0x118/0x1f0 fs/dcache.c:913 fput+0x3bf/0x570 fs/filetable.c:329 fput+0x15/0x20 fs/filetable.c:349 taskworkrun+0x123/0x160 kernel/taskwork.c:179 resumeusermodework include/linux/resumeusermode.h:49 [inline] exittousermodeloop+0xcf/0xe0 kernel/entry/common.c:171 exittousermodeprepare+0x6a/0xa0 kernel/entry/common.c:203 syscallexittousermodework kernel/entry/common.c:285 [inline] syscallexittousermode+0x26/0x140 kernel/entry/common.c:296 dosyscall64+0x4d/0xc0 arch/x86/entry/common.c:86 entrySYSCALL64afterhwframe+0x63/0xcd
read to 0xffff888237c2a2f8 of 8 bytes by task 19632 on cpu 1: objstockflushrequired mm/memcontrol.c:3319 [inline] drainallstock+0x174/0x2a0 mm/memcontrol.c:2361 trychargememcg+0x6d0/0xd10 mm/memcontrol.c:2703 trycharge mm/memcontrol.c:2837 [inline] memcgroupchargeskmem+0x51/0x140 mm/memcontrol.c:7290 sockreservememory+0xb1/0x390 net/core/sock.c:1025 sksetsockopt+0x800/0x1e70 net/core/sock.c:1525 udplibsetsockopt+0x99/0x6c0 net/ipv4/udp.c:2692 udpsetsockopt+0x73/0xa0 net/ipv4/udp.c:2817 sockcommonsetsockopt+0x61/0x70 net/core/sock.c:3668 syssetsockopt+0x1c3/0x230 net/socket.c:2271 dosyssetsockopt net/socket.c:2282 [inline] sesyssetsockopt net/socket.c:2279 [inline] x64syssetsockopt+0x66/0x80 net/socket.c:2279 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x41/0xc0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd
value changed: 0xffff8881382d52c0 -> 0xffff888138893740
Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 19632 Comm: syz-executor.0 Not tainted 6.3.0-rc2-syzkaller-00387-g534293368afa #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023
Fix it by using READONCE()/WRITEONCE() for all accesses to stock->cachedobjcg.
In the Linux kernel, the following vulnerability has been resolved:
irqchip/gicv3: Workaround for NVIDIA erratum T241-FABRIC-4
The T241 platform suffers from the T241-FABRIC-4 erratum which causes unexpected behavior in the GIC when multiple transactions are received simultaneously from different sources. This hardware issue impacts NVIDIA server platforms that use more than two T241 chips interconnected. Each chip has support for 320 {E}SPIs.
This issue occurs when multiple packets from different GICs are incorrectly interleaved at the target chip. The erratum text below specifies exactly what can cause multiple transfer packets susceptible to interleaving and GIC state corruption. GIC state corruption can lead to a range of problems, including kernel panics, and unexpected behavior.
From the erratum text: "In some cases, inter-socket AXI4 Stream packets with multiple transfers, may be interleaved by the fabric when presented to ARM Generic Interrupt Controller. GIC expects all transfers of a packet to be delivered without any interleaving.
The following GICv3 commands may result in multiple transfer packets over inter-socket AXI4 Stream interface: - Register reads from GICDI and GICDN - Register writes to 64-bit GICD registers other than GICDIROUTERn - ITS command MOVALL
Multiple commands in GICv4+ utilize multiple transfer packets, including VMOVP, VMOVI, VMAPP, and 64-bit register accesses."
This issue impacts system configurations with more than 2 sockets, that require multi-transfer packets to be sent over inter-socket AXI4 Stream interface between GIC instances on different sockets. GICv4 cannot be supported. GICv3 SW model can only be supported with the workaround. Single and Dual socket configurations are not impacted by this issue and support GICv3 and GICv4."
Writing to the chip alias region of the GICDIn{E} registers except GICDICENABLERn has an equivalent effect as writing to the global distributor. The SPI interrupt deactivate path is not impacted by the erratum.
To fix this problem, implement a workaround that ensures read accesses to the GICDIn{E} registers are directed to the chip that owns the SPI, and disable GICv4.x features. To simplify code changes, the gicconfigureirq() function uses the same alias region for both read and write operations to GICDICFGR.
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix memory leak in mes self test
The fences associated with mes queue have to be freed up during amdgpuringfini.
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: fix memory leak in mlx5efsttredirectanycreate
The memory pointed to by the fs->any pointer is not freed in the error path of mlx5efsttredirectanycreate, which can lead to a memory leak. Fix by freeing the memory in the error path, thereby making the error path identical to mlx5efsttredirectanydestroy().
In the Linux kernel, the following vulnerability has been resolved:
drm/ttm: fix undefined behavior in bit shift for TTMTTFLAGPRIVPOPULATED
Shifting signed 32-bit value by 31 bits is undefined, so changing significant bit to unsigned. The UBSAN warning calltrace like below:
UBSAN: shift-out-of-bounds in ./include/drm/ttm/ttmtt.h:122:26 left shift of 1 by 31 places cannot be represented in type 'int' Call Trace: <TASK> dumpstacklvl+0x7d/0xa5 dumpstack+0x15/0x1b ubsanepilogue+0xe/0x4e ubsanhandleshiftoutofbounds+0x1e7/0x20c ttmbomovememcpy+0x3b4/0x460 [ttm] bodrivermove+0x32/0x40 [drmvramhelper] ttmbohandlemovemem+0x118/0x200 [ttm] ttmbovalidate+0xfa/0x220 [ttm] drmgemvrampinlocked+0x70/0x1b0 [drmvramhelper] drmgemvrampin+0x48/0xb0 [drmvramhelper] drmgemvramplanehelperpreparefb+0x53/0xe0 [drmvramhelper] drmgemvramsimpledisplaypipepreparefb+0x26/0x30 [drmvramhelper] drmsimplekmsplanepreparefb+0x4d/0xe0 [drmkmshelper] drmatomichelperprepareplanes+0xda/0x210 [drmkmshelper] drmatomichelpercommit+0xc3/0x1e0 [drmkmshelper] drmatomiccommit+0x9c/0x160 [drm] drmclientmodesetcommitatomic+0x33a/0x380 [drm] drmclientmodesetcommitlocked+0x77/0x220 [drm] drmclientmodesetcommit+0x31/0x60 [drm] drmfbhelperrestorefbdevmodeunlocked+0xa7/0x170 [drmkmshelper] drmfbhelpersetpar+0x51/0x90 [drmkmshelper] fbconinit+0x316/0x790 visualinit+0x113/0x1d0 dobindcondriver+0x2a3/0x5c0 dotakeoverconsole+0xa9/0x270 dofbcontakeover+0xa1/0x170 dofbregistered+0x2a8/0x340 fbconfbregistered+0x47/0xe0 registerframebuffer+0x294/0x4a0 drmfbhelperinitialconfigandunlock+0x43c/0x880 [drmkmshelper] drmfbhelperinitialconfig+0x52/0x80 [drmkmshelper] drmfbdevclienthotplug+0x156/0x1b0 [drmkmshelper] drmfbdevgenericsetup+0xfc/0x290 [drmkmshelper] bochspciprobe+0x6ca/0x772 [bochs] localpciprobe+0x4d/0xb0 pcideviceprobe+0x119/0x320 reallyprobe+0x181/0x550 driverprobedevice+0xc6/0x220 driverprobedevice+0x32/0x100 driverattach+0x195/0x200 busforeachdev+0xbb/0x120 driverattach+0x27/0x30 busadddriver+0x22e/0x2f0 driverregister+0xa9/0x190 pciregisterdriver+0x90/0xa0 bochspcidriverinit+0x52/0x1000 [bochs] dooneinitcall+0x76/0x430 doinitmodule+0x61/0x28a loadmodule+0x1f82/0x2e50 dosysfinitmodule+0xf8/0x190 x64sysfinitmodule+0x23/0x30 dosyscall64+0x58/0x80 entrySYSCALL64afterhwframe+0x63/0xcd </TASK>
In the Linux kernel, the following vulnerability has been resolved:
accel/habanalabs: fix mem leak in capture user mappings
This commit fixes a memory leak caused when clearing the usermappings info when a new context is opened immediately after usermapping is captured and a hard reset is performed.
In the Linux kernel, the following vulnerability has been resolved:
block: be a bit more careful in checking for NULL bdev while polling
Wei reports a crash with an application using polled IO:
PGD 14265e067 P4D 14265e067 PUD 47ec50067 PMD 0 Oops: 0000 [#1] SMP CPU: 0 PID: 21915 Comm: iocore0 Kdump: loaded Tainted: G S 5.12.0-0fbk12clang7346g1bb6f2e7058f #1 Hardware name: Wiwynn Delta Lake MP T8/Delta Lake-Class2, BIOS Y3DLM08 04/10/2022 RIP: 0010:biopoll+0x25/0x200 Code: 0f 1f 44 00 00 0f 1f 44 00 00 55 41 57 41 56 41 55 41 54 53 48 83 ec 28 65 48 8b 04 25 28 00 00 00 48 89 44 24 20 48 8b 47 08 <48> 8b 80 70 02 00 00 4c 8b 70 50 8b 6f 34 31 db 83 fd ff 75 25 65 RSP: 0018:ffffc90005fafdf8 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 74b43cd65dd66600 RDX: 0000000000000003 RSI: ffffc90005fafe78 RDI: ffff8884b614e140 RBP: ffff88849964df78 R08: 0000000000000000 R09: 0000000000000008 R10: 0000000000000000 R11: 0000000000000000 R12: ffff88849964df00 R13: ffffc90005fafe78 R14: ffff888137d3c378 R15: 0000000000000001 FS: 00007fd195000640(0000) GS:ffff88903f400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000270 CR3: 0000000466121001 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: iocbbioiopoll+0x1d/0x30 iodoiopoll+0xac/0x250 sesysiouringenter+0x3c5/0x5a0 ? x64syswrite+0x89/0xd0 dosyscall64+0x2d/0x40 entrySYSCALL64afterhwframe+0x44/0xae RIP: 0033:0x94f225d Code: 24 cc 00 00 00 41 8b 84 24 d0 00 00 00 c1 e0 04 83 e0 10 41 09 c2 8b 33 8b 53 04 4c 8b 43 18 4c 63 4b 0c b8 aa 01 00 00 0f 05 <85> c0 0f 88 85 00 00 00 29 03 45 84 f6 0f 84 88 00 00 00 41 f6 c7 RSP: 002b:00007fd194ffcd88 EFLAGS: 00000202 ORIGRAX: 00000000000001aa RAX: ffffffffffffffda RBX: 00007fd194ffcdc0 RCX: 00000000094f225d RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000007 RBP: 00007fd194ffcdb0 R08: 0000000000000000 R09: 0000000000000008 R10: 0000000000000001 R11: 0000000000000202 R12: 00007fd269d68030 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000000
which is due to bio->bibdev being NULL. This can happen if we have two tasks doing polled IO, and task B ends up completing IO from task A if they are sharing a poll queue. If task B completes the IO and puts the bio into our cache, then it can allocate that bio again before task A is done polling for it. As that would necessitate a preempt between the two tasks, it's enough to just be a bit more careful in checking for whether or not bio->bibdev is NULL.
In the Linux kernel, the following vulnerability has been resolved:
staging: pi433: fix memory leak with using debugfslookup()
When calling debugfslookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfslookupandremove() instead which handles all of the logic at once. This requires saving off the root directory dentry to make creation of individual device subdirectories easier.
In the Linux kernel, the following vulnerability has been resolved:
accel/habanalabs: postpone memmgr IDR destruction to hprivrelease()
The memory manager IDR is currently destroyed when user releases the file descriptor. However, at this point the user context might be still held, and memory buffers might be still in use. Later on, calls to release those buffers will fail due to not finding their handles in the IDR, leading to a memory leak. To avoid this leak, split the IDR destruction from the memory manager fini, and postpone it to hprivrelease() when there is no user context and no buffers are used.