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

nvme-pci: Fix race bug in nvmepollirqdisable()

In the following scenario, pdev can be disabled between (1) and (3) by (2). This sets pdev->msixenabled = 0. Then, pciirqvector() will return MSI-X IRQ(>15) for (1) whereas return INTx IRQ(<=15) for (2). This causes IRQ warning because it tries to enable INTx IRQ that has never been disabled before.

To fix this, save IRQ number into a local variable and ensure disableirq() and enableirq() operate on the same IRQ number. Even if pcifreeirqvectors() frees the IRQ concurrently, disableirq() and enableirq() on a stale IRQ number is still valid and safe, and the depth accounting reamins balanced.

task 1: nvmepollirqdisable() disableirq(pciirqvector(pdev, nvmeq->cqvector)) ...(1) enableirq(pciirqvector(pdev, nvmeq->cqvector)) ...(3)

task 2: nvmeresetwork() nvmedevdisable() pdev->msixenable = 0; ...(2)

crash log:

------------[ cut here ]------------ Unbalanced enable for IRQ 10 WARNING: kernel/irq/manage.c:753 at enableirq+0x102/0x190 kernel/irq/manage.c:753, CPU#1: kworker/1:0H/26 Modules linked in: CPU: 1 UID: 0 PID: 26 Comm: kworker/1:0H Not tainted 6.19.0-dirty #9 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blkmqtimeoutwork RIP: 0010:enableirq+0x107/0x190 kernel/irq/manage.c:753 Code: ff df 48 89 fa 48 c1 ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 04 84 d2 75 79 48 8d 3d 2e 7a 3f 05 41 8b 74 24 2c <67> 48 0f b9 3a e8 ef b9 21 00 5b 41 5c 5d e9 46 54 66 03 e8 e1 b9 RSP: 0018:ffffc900001bf550 EFLAGS: 00010046 RAX: 0000000000000007 RBX: 0000000000000000 RCX: ffffffffb20c0e90 RDX: 0000000000000000 RSI: 000000000000000a RDI: ffffffffb74b88f0 RBP: ffffc900001bf560 R08: ffff88800197cf00 R09: 0000000000000001 R10: 0000000000000003 R11: 0000000000000003 R12: ffff8880012a6000 R13: 1ffff92000037eae R14: 000000000000000a R15: 0000000000000293 FS: 0000000000000000(0000) GS:ffff8880b49f7000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555da4a25fa8 CR3: 00000000208e8000 CR4: 00000000000006f0 Call Trace: <TASK> enableirq+0x121/0x1e0 kernel/irq/manage.c:797 nvmepollirqdisable+0x162/0x1c0 drivers/nvme/host/pci.c:1494 nvmetimeout+0x965/0x14b0 drivers/nvme/host/pci.c:1744 blkmqrqtimedout block/blk-mq.c:1653 [inline] blkmqhandleexpired+0x227/0x2d0 block/blk-mq.c:1721 btiter+0x2fc/0x3a0 block/blk-mq-tag.c:292 sbitmapforeachset include/linux/sbitmap.h:269 [inline] sbitmapforeachset include/linux/sbitmap.h:290 [inline] btforeach block/blk-mq-tag.c:324 [inline] blkmqqueuetagbusyiter+0x969/0x1e80 block/blk-mq-tag.c:536 blkmqtimeoutwork+0x627/0x870 block/blk-mq.c:1763 processonework+0x956/0x1aa0 kernel/workqueue.c:3257 processscheduledworks kernel/workqueue.c:3340 [inline] workerthread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 retfromfork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:246 </TASK> irq event stamp: 74478 hardirqs last enabled at (74477): [<ffffffffb5720a9c>] rawspinunlockirq include/linux/spinlockapismp.h:159 [inline] hardirqs last enabled at (74477): [<ffffffffb5720a9c>] rawspinunlockirq+0x2c/0x60 kernel/locking/spinlock.c:202 hardirqs last disabled at (74478): [<ffffffffb57207b5>] rawspinlockirqsave include/linux/spinlockapismp.h:108 [inline] hardirqs last disabled at (74478): [<ffffffffb57207b5>] rawspinlockirqsave+0x85/0xa0 kernel/locking/spinlock.c:162 softirqs last enabled at (74304): [<ffffffffb1e9466c>] dosoftirq kernel/softirq.c:656 [inline] softirqs last enabled at (74304): [<ffffffffb1e9466c>] invokesoftirq kernel/softirq.c:496 [inline] softirqs last enabled at (74304): [<ffffffffb1e9466c>] irqexitrcu+0xdc/0x120 ---truncated---

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

serial: 8250: Fix TX deadlock when using DMA

dmaengineterminateasync does not guarantee that the dmatxcomplete callback will run. The callback is currently the only place where dma->txrunning gets cleared. If the transaction is canceled and the callback never runs, then dma->txrunning will never get cleared and we will never schedule new TX DMA transactions again.

This change makes it so we clear dma->txrunning after we terminate the DMA transaction. This is "safe" because serial8250txdmaflush is holding the UART port lock. The first thing the callback does is also grab the UART port lock, so access to dma->txrunning is serialized.

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

drm: Account property blob allocations to memcg

DRMIOCTLMODECREATEPROPBLOB allows userspace to allocate arbitrary-sized property blobs backed by kernel memory.

Currently, the blob data allocation is not accounted to the allocating process's memory cgroup, allowing unprivileged users to trigger unbounded kernel memory consumption and potentially cause system-wide OOM.

Mark the property blob data allocation with GFPKERNELACCOUNT so that the memory is properly charged to the caller's memcg. This ensures existing cgroup memory limits apply and prevents uncontrolled kernel memory growth without introducing additional policy or per-file limits.

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

net: remove WARNONONCE when accessing forward path array

Although unlikely, recent support for IPIP tunnels increases chances of reaching this WARNONONCE if userspace manages to build a sufficiently long forward path.

Remove it.

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

virtionet: fix xdprxqinfo bug after suspend/resume

The following sequence currently causes a driver bug warning when using virtionet:

# ip link set eth0 up # echo mem > /sys/power/state (or e.g. # rtcwake -s 10 -m mem) <resume> # ip link set eth0 down

Missing register, driver bug WARNING: CPU: 0 PID: 375 at net/core/xdp.c:138 xdprxqinfounreg+0x58/0x60 Call trace: xdprxqinfounreg+0x58/0x60 virtnetclose+0x58/0xac devclosemany+0xac/0x140 devchangeflags+0xd8/0x210 devchangeflags+0x24/0x64 dosetlink+0x230/0xdd0 ...

This happens because virtnetfreeze() frees the receivequeue completely (including struct xdprxqinfo) but does not call xdprxqinfounreg(). Similarly, virtnetrestore() sets up the receivequeue again but does not call xdprxqinforeg().

Actually, parts of virtnetfreezedown() and virtnetrestoreup() are almost identical to virtnetclose() and virtnetopen(): only the calls to xdprxqinfo(un)reg() are missing. This means that we can fix this easily and avoid such problems in the future by just calling virtnetclose()/open() from the freeze/restore handlers.

Aside from adding the missing xdprxqinfo calls the only difference is that the refill work is only cancelled if netifrunning(). However, this should not make any functional difference since the refill work should only be active if the network interface is actually up.

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

bpf: Skip invalid kfunc call in backtrackinsn

The verifier skips invalid kfunc call in checkkfunccall(), which would be captured in fixupkfunccall() if such insn is not eliminated by dead code elimination. However, this can lead to the following warning in backtrackinsn(), also see [1]:

------------[ cut here ]------------ verifier backtracking bug WARNING: CPU: 6 PID: 8646 at kernel/bpf/verifier.c:2756 backtrackinsn kernel/bpf/verifier.c:2756 markchainprecision kernel/bpf/verifier.c:3065 markchainprecision kernel/bpf/verifier.c:3165 adjustregminmaxvals kernel/bpf/verifier.c:10715 checkaluop kernel/bpf/verifier.c:10928 docheck kernel/bpf/verifier.c:13821 [inline] docheckcommon kernel/bpf/verifier.c:16289 [...]

So make backtracking conservative with this by returning ENOTSUPP.

[1] https://lore.kernel.org/bpf/CACkBjsaXNceR8ZjkLG=dT3P=4A8SBsg0Z5h5PWLryF5=ghKq=g@mail.gmail.com/

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

ice: Fix NULL pointer dereference in icevsisetnapiqueues

Add NULL pointer checks in icevsisetnapiqueues() to prevent crashes during resume from suspend when rings[qidx]->qvector is NULL.

Tested adaptor: 60:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller E810-XXV for SFP [8086:159b] (rev 02) Subsystem: Intel Corporation Ethernet Network Adapter E810-XXV-2 [8086:4003]

SR-IOV state: both disabled and enabled can reproduce this issue.

kernel version: v6.18

Reproduce steps: Boot up and execute suspend like systemctl suspend or rtcwake.

Log: <1>[ 231.443607] BUG: kernel NULL pointer dereference, address: 0000000000000040 <1>[ 231.444052] #PF: supervisor read access in kernel mode <1>[ 231.444484] #PF: errorcode(0x0000) - not-present page <6>[ 231.444913] PGD 0 P4D 0 <4>[ 231.445342] Oops: Oops: 0000 [#1] SMP NOPTI <4>[ 231.446635] RIP: 0010:netifqueuesetnapi+0xa/0x170 <4>[ 231.447067] Code: 31 f6 31 ff c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 85 c9 74 0b <48> 83 79 30 00 0f 84 39 01 00 00 55 41 89 d1 49 89 f8 89 f2 48 89 <4>[ 231.447513] RSP: 0018:ffffcc780fc078c0 EFLAGS: 00010202 <4>[ 231.447961] RAX: ffff8b848ca30400 RBX: ffff8b848caf2028 RCX: 0000000000000010 <4>[ 231.448443] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8b848dbd4000 <4>[ 231.448896] RBP: ffffcc780fc078e8 R08: 0000000000000000 R09: 0000000000000000 <4>[ 231.449345] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 <4>[ 231.449817] R13: ffff8b848dbd4000 R14: ffff8b84833390c8 R15: 0000000000000000 <4>[ 231.450265] FS: 00007c7b29e9d740(0000) GS:ffff8b8c068e2000(0000) knlGS:0000000000000000 <4>[ 231.450715] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 231.451179] CR2: 0000000000000040 CR3: 000000030626f004 CR4: 0000000000f72ef0 <4>[ 231.451629] PKRU: 55555554 <4>[ 231.452076] Call Trace: <4>[ 231.452549] <TASK> <4>[ 231.452996] ? icevsisetnapiqueues+0x4d/0x110 [ice] <4>[ 231.453482] iceresume+0xfd/0x220 [ice] <4>[ 231.453977] ? pfxpcipmresume+0x10/0x10 <4>[ 231.454425] pcipmresume+0x8c/0x140 <4>[ 231.454872] ? pfxpcipmresume+0x10/0x10 <4>[ 231.455347] dpmruncallback+0x5f/0x160 <4>[ 231.455796] ? dpmwaitforsuperior+0x107/0x170 <4>[ 231.456244] deviceresume+0x177/0x270 <4>[ 231.456708] dpmresume+0x209/0x2f0 <4>[ 231.457151] dpmresumeend+0x15/0x30 <4>[ 231.457596] suspenddevicesandenter+0x1da/0x2b0 <4>[ 231.458054] enterstate+0x10e/0x570

Add defensive checks for both the ring pointer and its qvector before dereferencing, allowing the system to resume successfully even when qvectors are unmapped.

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

net/mlx5e: Avoid WARNON when configuring MQPRIO with HTB offload enabled

When attempting to enable MQPRIO while HTB offload is already configured, the driver currently returns -EINVAL and triggers a WARNON, leading to an unnecessary call trace.

Update the code to handle this case more gracefully by returning -EOPNOTSUPP instead, while also providing a helpful user message.

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

iouring/tctx: work around xastore() allocation error issue

syzbot triggered the following WARNON:

WARNING: CPU: 0 PID: 16 at iouring/tctx.c:51 iouringfree+0xfa/0x140 iouring/tctx.c:51

which is the

WARNONONCE(!xaempty(&tctx->xa));

sanity check in iouringfree() when a iouringtask is going through its final put. The syzbot test case includes injecting memory allocation failures, and it very much looks like xastore() can fail one of its memory allocations and end up with ->head being non-NULL even though no entries exist in the xarray.

Until this issue gets sorted out, work around it by attempting to iterate entries in our xarray, and WARNONONCE() if one is found.

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

bpf: Fix constant blinding for PROBEMEM32 stores

BPFST | BPFPROBEMEM32 immediate stores are not handled by bpfjitblindinsn(), allowing user-controlled 32-bit immediates to survive unblinded into JIT-compiled native code when bpfjitharden >= 1.

The root cause is that convertctxaccesses() rewrites BPFST|BPFMEM to BPFST|BPFPROBEMEM32 for arena pointer stores during verification, before bpfjitblindconstants() runs during JIT compilation. The blinding switch only matches BPFST|BPFMEM (mode 0x60), not BPFST|BPFPROBEMEM32 (mode 0xa0). The instruction falls through unblinded.

Add BPFST|BPFPROBEMEM32 cases to bpfjitblindinsn() alongside the existing BPFST|BPFMEM cases. The blinding transformation is identical: load the blinded immediate into BPFREGAX via mov+xor, then convert the immediate store to a register store (BPFSTX).

The rewritten STX instruction must preserve the BPFPROBEMEM32 mode so the architecture JIT emits the correct arena addressing (R12-based on x86-64). Cannot use the BPFSTXMEM() macro here because it hardcodes BPFMEM mode; construct the instruction directly instead.

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

kprobes: don't call disarmkprobe() for disabled kprobes

The assumption in disablekprobe() is wrong, and it could try to disarm an already disarmed kprobe and fire the WARNONCE() below. [0] We can easily reproduce this issue.

1. Write 0 to /sys/kernel/debug/kprobes/enabled.

# echo 0 > /sys/kernel/debug/kprobes/enabled

2. Run execsnoop. At this time, one kprobe is disabled.

# /usr/share/bcc/tools/execsnoop & [1] 2460 PCOMM PID PPID RET ARGS

# cat /sys/kernel/debug/kprobes/list ffffffff91345650 r x64sysexecve+0x0 [FTRACE] ffffffff91345650 k x64sysexecve+0x0 [DISABLED][FTRACE]

3. Write 1 to /sys/kernel/debug/kprobes/enabled, which changes kprobesalldisarmed to false but does not arm the disabled kprobe.

# echo 1 > /sys/kernel/debug/kprobes/enabled

# cat /sys/kernel/debug/kprobes/list ffffffff91345650 r x64sysexecve+0x0 [FTRACE] ffffffff91345650 k x64sysexecve+0x0 [DISABLED][FTRACE]

4. Kill execsnoop, when disablekprobe() calls disarmkprobe() for the disabled kprobe and hits the WARNONCE() in disarmkprobeftrace().

# fg /usr/share/bcc/tools/execsnoop ^C

Actually, WARNONCE() is fired twice, and unregisterkprobetop() misses some cleanups and leaves the aggregated kprobe in the hash table. Then, unregistertracekprobe() initialises tk->rp.kp.list and creates an infinite loop like this.

aggregated kprobe.list -> kprobe.list -. ^ | '..'

In this situation, these commands fall into the infinite loop and result in RCU stall or soft lockup.

cat /sys/kernel/debug/kprobes/list : showkprobeaddr() enters into the infinite loop with RCU.

/usr/share/bcc/tools/execsnoop : warnkproberereg() holds kprobemutex, and getvalidkprobe() is stuck in the loop.

To avoid the issue, make sure we don't call disarmkprobe() for disabled kprobes.

[0] Failed to disarm kprobe-ftrace at x64sysexecve+0x0/0x40 (error -2) WARNING: CPU: 6 PID: 2460 at kernel/kprobes.c:1130 disarmkprobeftrace.isra.19 (kernel/kprobes.c:1129) Modules linked in: ena CPU: 6 PID: 2460 Comm: execsnoop Not tainted 5.19.0+ #28 Hardware name: Amazon EC2 c5.2xlarge/, BIOS 1.0 10/16/2017 RIP: 0010:disarmkprobeftrace.isra.19 (kernel/kprobes.c:1129) Code: 24 8b 02 eb c1 80 3d c4 83 f2 01 00 75 d4 48 8b 75 00 89 c2 48 c7 c7 90 fa 0f 92 89 04 24 c6 05 ab 83 01 e8 e4 94 f0 ff <0f> 0b 8b 04 24 eb b1 89 c6 48 c7 c7 60 fa 0f 92 89 04 24 e8 cc 94 RSP: 0018:ffff9e6ec154bd98 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffff930f7b00 RCX: 0000000000000001 RDX: 0000000080000001 RSI: ffffffff921461c5 RDI: 00000000ffffffff RBP: ffff89c504286da8 R08: 0000000000000000 R09: c0000000fffeffff R10: 0000000000000000 R11: ffff9e6ec154bc28 R12: ffff89c502394e40 R13: ffff89c502394c00 R14: ffff9e6ec154bc00 R15: 0000000000000000 FS: 00007fe800398740(0000) GS:ffff89c812d80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c00057f010 CR3: 0000000103b54006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> disablekprobe (kernel/kprobes.c:1716) disablekprobe (kernel/kprobes.c:2392) disabletracekprobe (kernel/trace/tracekprobe.c:340) disabletracekprobe (kernel/trace/tracekprobe.c:429) perftraceeventunreg.isra.2 (./include/linux/tracepoint.h:93 kernel/trace/traceeventperf.c:168) perfkprobedestroy (kernel/trace/traceeventperf.c:295) freeevent (kernel/events/core.c:4971) perfeventreleasekernel (kernel/events/core.c:5176) perfrelease (kernel/events/core.c:5186) fput (fs/filetable.c:321) taskworkrun (./include/linux/ ---truncated---

fbdev: Fix doregisterframebuffer to prevent null-ptr-deref in fbvideomodetovar

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

sched, cpuset: Fix dlcpubusy() panic due to empty cs->cpusallowed

With cgroup v2, the cpuset's cpusallowed mask can be empty indicating that the cpuset will just use the effective CPUs of its parent. So cpusetcanattach() can call taskcanattach() with an empty mask. This can lead to cpumaskanyand() returns nrcpuids causing the call to dlbwof() to crash due to percpu value access of an out of bound CPU value. For example:

[80468.182258] BUG: unable to handle page fault for address: ffffffff8b6648b0 : [80468.191019] RIP: 0010:dlcpubusy+0x30/0x2b0 : [80468.207946] Call Trace: [80468.208947] cpusetcanattach+0xa0/0x140 [80468.209953] cgroupmigrateexecute+0x8c/0x490 [80468.210931] cgroupupdatedflcsses+0x254/0x270 [80468.211898] cgroupsubtreecontrolwrite+0x322/0x400 [80468.212854] kernfsfopwriteiter+0x11c/0x1b0 [80468.213777] newsyncwrite+0x11f/0x1b0 [80468.214689] vfswrite+0x1eb/0x280 [80468.215592] ksyswrite+0x5f/0xe0 [80468.216463] dosyscall64+0x5c/0x80 [80468.224287] entrySYSCALL64afterhwframe+0x44/0xae

Fix that by using effectivecpus instead. For cgroup v1, effectivecpus is the same as cpusallowed. For v2, effectivecpus is the real cpumask to be used by tasks within the cpuset anyway.

Also update taskcanattach()'s 2nd argument name to cseffectivecpus to reflect the change. In addition, a check is added to taskcanattach() to guard against the possibility that cpumaskanyand() may return a value >= nrcpuids.

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

drm/tegra: nvdec: Fix dmaalloccoherent error check

Check for NULL return value with dmaalloccoherent, in line with Robin's fix for vic.c in 'drm/tegra: vic: Fix DMA API misuse'.

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

KVM: x86/xen: Fix eventfd error handling in kvmxeneventfdassign()

Should not call eventfdctxput() in case of error.

[Introduce new goto target instead. - Paolo]

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

net: do not sense pfmemalloc status in skbappendpagefrags()

skbappendpagefrags() is used by afunix and udp sendpage() implementation so far.

In commit 326140063946 ("tcp: TX zerocopy should not sense pfmemalloc status") we explained why we should not sense pfmemalloc status for pages owned by user space.

We should also use skbfillpagedescnoacc() in skbappendpagefrags() to avoid following KCSAN report:

BUG: KCSAN: data-race in lruaddfn / skbappendpagefrags

write to 0xffffea00058fc1c8 of 8 bytes by task 17319 on cpu 0: listadd include/linux/list.h:73 [inline] listadd include/linux/list.h:88 [inline] lruvecaddfolio include/linux/mminline.h:323 [inline] lruaddfn+0x327/0x410 mm/swap.c:228 foliobatchmovelru+0x1e1/0x2a0 mm/swap.c:246 lruadddraincpu+0x73/0x250 mm/swap.c:669 lruadddrain+0x21/0x60 mm/swap.c:773 freepagesandswapcache+0x16/0x70 mm/swapstate.c:311 tlbbatchpagesflush mm/mmugather.c:59 [inline] tlbflushmmufree mm/mmugather.c:256 [inline] tlbflushmmu+0x5b2/0x640 mm/mmugather.c:263 tlbfinishmmu+0x86/0x100 mm/mmugather.c:363 exitmmap+0x190/0x4d0 mm/mmap.c:3098 mmput+0x27/0x1b0 kernel/fork.c:1185 mmput+0x3d/0x50 kernel/fork.c:1207 copyprocess+0x19fc/0x2100 kernel/fork.c:2518 kernelclone+0x166/0x550 kernel/fork.c:2671 dosysclone kernel/fork.c:2812 [inline] sesysclone kernel/fork.c:2796 [inline] x64sysclone+0xc3/0xf0 kernel/fork.c:2796 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x2b/0x70 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd

read to 0xffffea00058fc1c8 of 8 bytes by task 17325 on cpu 1: pageispfmemalloc include/linux/mm.h:1817 [inline] skbfillpagedesc include/linux/skbuff.h:2432 [inline] skbfillpagedesc include/linux/skbuff.h:2453 [inline] skbappendpagefrags+0x210/0x600 net/core/skbuff.c:3974 unixstreamsendpage+0x45e/0x990 net/unix/afunix.c:2338 kernelsendpage+0x184/0x300 net/socket.c:3561 socksendpage+0x5a/0x70 net/socket.c:1054 pipetosendpage+0x128/0x160 fs/splice.c:361 splicefrompipefeed fs/splice.c:415 [inline] splicefrompipe+0x222/0x4d0 fs/splice.c:559 splicefrompipe fs/splice.c:594 [inline] genericsplicesendpage+0x89/0xc0 fs/splice.c:743 dosplicefrom fs/splice.c:764 [inline] directspliceactor+0x80/0xa0 fs/splice.c:931 splicedirecttoactor+0x305/0x620 fs/splice.c:886 dosplicedirect+0xfb/0x180 fs/splice.c:974 dosendfile+0x3bf/0x910 fs/readwrite.c:1255 dosyssendfile64 fs/readwrite.c:1323 [inline] sesyssendfile64 fs/readwrite.c:1309 [inline] x64syssendfile64+0x10c/0x150 fs/readwrite.c:1309 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x2b/0x70 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd

value changed: 0x0000000000000000 -> 0xffffea00058fc188

Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 17325 Comm: syz-executor.0 Not tainted 6.1.0-rc1-syzkaller-00158-g440b7895c990-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022

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

tracing: Do not let histogram values have some modifiers

Histogram values can not be strings, stacktraces, graphs, symbols, syscalls, or grouped in buckets or log. Give an error if a value is set to do so.

Note, the histogram code was not prepared to handle these modifiers for histograms and caused a bug.

Mark Rutland reported:

# echo 'p:copytouser archcopytouser n=$arg2' >> /sys/kernel/tracing/kprobeevents # echo 'hist:keys=n:vals=hitcount.buckets=8:sort=hitcount' > /sys/kernel/tracing/events/kprobes/copytouser/trigger # cat /sys/kernel/tracing/events/kprobes/copytouser/hist [ 143.694628] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 143.695190] Mem abort info: [ 143.695362] ESR = 0x0000000096000004 [ 143.695604] EC = 0x25: DABT (current EL), IL = 32 bits [ 143.695889] SET = 0, FnV = 0 [ 143.696077] EA = 0, S1PTW = 0 [ 143.696302] FSC = 0x04: level 0 translation fault [ 143.702381] Data abort info: [ 143.702614] ISV = 0, ISS = 0x00000004 [ 143.702832] CM = 0, WnR = 0 [ 143.703087] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000448f9000 [ 143.703407] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 143.704137] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 143.704714] Modules linked in: [ 143.705273] CPU: 0 PID: 133 Comm: cat Not tainted 6.2.0-00003-g6fc512c10a7c #3 [ 143.706138] Hardware name: linux,dummy-virt (DT) [ 143.706723] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 143.707120] pc : histfieldname.part.0+0x14/0x140 [ 143.707504] lr : histfieldname.part.0+0x104/0x140 [ 143.707774] sp : ffff800008333a30 [ 143.707952] x29: ffff800008333a30 x28: 0000000000000001 x27: 0000000000400cc0 [ 143.708429] x26: ffffd7a653b20260 x25: 0000000000000000 x24: ffff10d303ee5800 [ 143.708776] x23: ffffd7a6539b27b0 x22: ffff10d303fb8c00 x21: 0000000000000001 [ 143.709127] x20: ffff10d303ec2000 x19: 0000000000000000 x18: 0000000000000000 [ 143.709478] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 143.709824] x14: 0000000000000000 x13: 203a6f666e692072 x12: 6567676972742023 [ 143.710179] x11: 0a230a6d6172676f x10: 000000000000002c x9 : ffffd7a6521e018c [ 143.710584] x8 : 000000000000002c x7 : 7f7f7f7f7f7f7f7f x6 : 000000000000002c [ 143.710915] x5 : ffff10d303b0103e x4 : ffffd7a653b20261 x3 : 000000000000003d [ 143.711239] x2 : 0000000000020001 x1 : 0000000000000001 x0 : 0000000000000000 [ 143.711746] Call trace: [ 143.712115] histfieldname.part.0+0x14/0x140 [ 143.712642] histfieldname.part.0+0x104/0x140 [ 143.712925] histfieldprint+0x28/0x140 [ 143.713125] eventhisttriggerprint+0x174/0x4d0 [ 143.713348] histshow+0xf8/0x980 [ 143.713521] seqreaditer+0x1bc/0x4b0 [ 143.713711] seqread+0x8c/0xc4 [ 143.713876] vfsread+0xc8/0x2a4 [ 143.714043] ksysread+0x70/0xfc [ 143.714218] arm64sysread+0x24/0x30 [ 143.714400] invokesyscall+0x50/0x120 [ 143.714587] el0svccommon.constprop.0+0x4c/0x100 [ 143.714807] doel0svc+0x44/0xd0 [ 143.714970] el0svc+0x2c/0x84 [ 143.715134] el0t64synchandler+0xbc/0x140 [ 143.715334] el0t64sync+0x190/0x194 [ 143.715742] Code: a9bd7bfd 910003fd a90153f3 aa0003f3 (f9400000) [ 143.716510] ---[ end trace 0000000000000000 ]--- Segmentation fault

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

mtd: core: fix possible resource leak in initmtd()

I got the error report while inject fault in initmtd():

sysfs: cannot create duplicate filename '/devices/virtual/bdi/mtd-0' Call Trace: <TASK> dumpstacklvl+0x67/0x83 sysfswarndup+0x60/0x70 sysfscreatedirns+0x109/0x120 kobjectaddinternal+0xce/0x2f0 kobjectadd+0x98/0x110 deviceadd+0x179/0xc00 devicecreategroupsvargs+0xf4/0x100 devicecreate+0x7b/0xb0 bdiregisterva.part.13+0x58/0x2d0 bdiregister+0x9b/0xb0 initmtd+0x62/0x171 [mtd] dooneinitcall+0x6c/0x3c0 doinitmodule+0x58/0x222 loadmodule+0x268e/0x27d0 dosysfinitmodule+0xd5/0x140 dosyscall64+0x37/0x90 entrySYSCALL64afterhwframe+0x63/0xcd </TASK> kobjectaddinternal failed for mtd-0 with -EEXIST, don't try to register things with the same name in the same directory. Error registering mtd class or bdi: -17

If initmtdchar() fails in initmtd(), mtdbdi will not be unregistered, as a result, we can't load the mtd module again, to fix this by calling bdiunregister(mtdbdi) after outprocfs label.

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

scsi: lpfc: Check kzalloc() in lpfcsli4cgnparamsread()

If kzalloc() fails in lpfcsli4cgnparamsread(), then we rely on lpfcreadobject()'s routine to NULL check pdata.

Currently, an early return error is thrown from lpfcreadobject() to protect us from NULL ptr dereference, but the errno code is -ENODEV.

Change the errno code to a more appropriate -ENOMEM.

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

USB: uhci: 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:

drm/xe/userptr: fix EFAULT handling

Currently we treat EFAULT from hmmrangefault() as a non-fatal error when called from xevmuserptrpin() with the idea that we want to avoid killing the entire vm and chucking an error, under the assumption that the user just did an unmap or something, and has no intention of actually touching that memory from the GPU. At this point we have already zapped the PTEs so any access should generate a page fault, and if the pin fails there also it will then become fatal.

However it looks like it's possible for the userptr vma to still be on the rebind list in preemptrebindworkfunc(), if we had to retry the pin again due to something happening in the caller before we did the rebind step, but in the meantime needing to re-validate the userptr and this time hitting the EFAULT.

This explains an internal user report of hitting:

[ 191.738349] WARNING: CPU: 1 PID: 157 at drivers/gpu/drm/xe/xerescursor.h:158 xeptstagebind.constprop.0+0x60a/0x6b0 [xe] [ 191.738551] Workqueue: xe-ordered-wq preemptrebindworkfunc [xe] [ 191.738616] RIP: 0010:xeptstagebind.constprop.0+0x60a/0x6b0 [xe] [ 191.738690] Call Trace: [ 191.738692] <TASK> [ 191.738694] ? showregs+0x69/0x80 [ 191.738698] ? warn+0x93/0x1a0 [ 191.738703] ? xeptstagebind.constprop.0+0x60a/0x6b0 [xe] [ 191.738759] ? reportbug+0x18f/0x1a0 [ 191.738764] ? handlebug+0x63/0xa0 [ 191.738767] ? excinvalidop+0x19/0x70 [ 191.738770] ? asmexcinvalidop+0x1b/0x20 [ 191.738777] ? xeptstagebind.constprop.0+0x60a/0x6b0 [xe] [ 191.738834] ? retfromforkasm+0x1a/0x30 [ 191.738849] bindopprepare+0x105/0x7b0 [xe] [ 191.738906] ? dmaresvreservefences+0x301/0x380 [ 191.738912] xeptupdateopsprepare+0x28c/0x4b0 [xe] [ 191.738966] ? kmemleakalloc+0x4b/0x80 [ 191.738973] opsexecute+0x188/0x9d0 [xe] [ 191.739036] xevmrebind+0x4ce/0x5a0 [xe] [ 191.739098] ? tracehardirqson+0x4d/0x60 [ 191.739112] preemptrebindworkfunc+0x76f/0xd00 [xe]

Followed by NPD, when running some workload, since the sg was never actually populated but the vma is still marked for rebind when it should be skipped for this special EFAULT case. This is confirmed to fix the user report.

v2 (MattB): - Move earlier. v3 (MattB): - Update the commit message to make it clear that this indeed fixes the issue.

(cherry picked from commit 6b93cb98910c826c2e2004942f8b060311e43618)

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

scsi: core: Fix possible memory leak if deviceadd() fails

If deviceadd() returns error, the name allocated by devsetname() needs be freed. As the comment of deviceadd() says, putdevice() should be used to decrease the reference count in the error path. So fix this by calling putdevice(), then the name can be freed in kobjectcleanp().

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

dmaengine: idxd: Fix the error handling path in idxdcdevregister()

If a call to allocchrdevregion() fails, the already allocated resources are leaking.

Add the needed error handling path to fix the leak.

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

cpufreq: qcom: fix writes in read-only memory region

This commit fixes a kernel oops because of a write in some read-only memory:

[ 9.068287] Unable to handle kernel write to read-only memory at virtual address ffff800009240ad8 ..snip.. [ 9.138790] Internal error: Oops: 9600004f [#1] PREEMPT SMP ..snip.. [ 9.269161] Call trace: [ 9.276271] memcpy+0x5c/0x230 [ 9.278531] snprintf+0x58/0x80 [ 9.282002] qcomcpufreqmsm8939nameversion+0xb4/0x190 [ 9.284869] qcomcpufreqprobe+0xc8/0x39c ..snip..

The following line defines a pointer that point to a char buffer stored in read-only memory:

char pvsname = "speedXX-pvsXX-vXX";

This pointer is meant to hold a template "speedXX-pvsXX-vXX" where the XX values get overridden by the qcomcpufreqkraitnameversion function. Since the template is actually stored in read-only memory, when the function executes the following call we get an oops:

snprintf(pvsname, sizeof("speedXX-pvsXX-vXX"), "speed%d-pvs%d-v%d", speed, pvs, pvsver);

To fix this issue, we instead store the template name onto the stack by using the following syntax:

char pvsnamebuffer[] = "speedXX-pvsXX-vXX";

Because the pvsname needs to be able to be assigned to NULL, the template buffer is stored in the pvsnamebuffer and not under the pvsname variable.

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

bpf, sockmap: Check for any of tcpbpfprots when cloning a listener

A listening socket linked to a sockmap has its skprot overridden. It points to one of the struct proto variants in tcpbpfprots. The variant depends on the socket's family and which sockmap programs are attached.

A child socket cloned from a TCP listener initially inherits their skprot. But before cloning is finished, we restore the child's proto to the listener's original non-tcpbpfprots one. This happens in tcpcreateopenreqchild -> tcpbpfclone.

Today, in tcpbpfclone we detect if the child's proto should be restored by checking only for the TCPBPFBASE proto variant. This is not correct. The skprot of listening socket linked to a sockmap can point to to any variant in tcpbpfprots.

If the listeners skprot happens to be not the TCPBPFBASE variant, then the child socket unintentionally is left if the inherited skprot by tcpbpfclone.

This leads to issues like infinite recursion on close [1], because the child state is otherwise not set up for use with tcpbpfprot operations.

Adjust the check in tcpbpfclone to detect all of tcpbpfprots variants.

Note that it wouldn't be sufficient to check the socket state when overriding the skprot in tcpbpfupdateproto in order to always use the TCPBPFBASE variant for listening sockets. Since commit b8b8315e39ff ("bpf, sockmap: Remove unhash handler for BPF sockmap usage") it is possible for a socket to transition to TCPLISTEN state while already linked to a sockmap, e.g. connect() -> insert into map -> connect(AFUNSPEC) -> listen().

[1]: https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/

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

media: cx231xx: set devicecaps for 417

The videodevice for the MPEG encoder did not set devicecaps.

Add this, otherwise the video device can't be registered (you get a WARNON instead).

Not seen before since currently 417 support is disabled, but I found this while experimenting with it.

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

KVM: nSVM: Check instead of asserting on nested TSC scaling support

Check for nested TSC scaling support on nested SVM VMRUN instead of asserting that TSC scaling is exposed to L1 if L1's MSRAMD64TSCRATIO has diverged from KVM's default. Userspace can trigger the WARN at will by writing the MSR and then updating guest CPUID to hide the feature (modifying guest CPUID is allowed anytime before KVMRUN). E.g. hacking KVM's statetest selftest to do

vcpusetmsr(vcpu, MSRAMD64TSCRATIO, 0); vcpuclearcpuidfeature(vcpu, X86FEATURETSCRATEMSR);

after restoring state in a new VM+vCPU yields an endless supply of:

------------[ cut here ]------------ WARNING: CPU: 164 PID: 62565 at arch/x86/kvm/svm/nested.c:699 nestedvmcb02preparecontrol+0x3d6/0x3f0 [kvmamd] Call Trace: <TASK> entersvmguestmode+0x114/0x560 [kvmamd] nestedsvmvmrun+0x260/0x330 [kvmamd] vmruninterception+0x29/0x30 [kvmamd] svminvokeexithandler+0x35/0x100 [kvmamd] svmhandleexit+0xe7/0x180 [kvmamd] kvmarchvcpuioctlrun+0x1eab/0x2570 [kvm] kvmvcpuioctl+0x4c9/0x5b0 [kvm] sesysioctl+0x7a/0xc0 x64sysioctl+0x21/0x30 dosyscall64+0x41/0x90 entrySYSCALL64afterhwframe+0x63/0xcd RIP: 0033:0x45ca1b

Note, the nested #VMEXIT path has the same flaw, but needs a different fix and will be handled separately.

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

tls: fix handling of zero-length records on the rxlist

Each recvmsg() call must process either - only contiguous DATA records (any number of them) - one non-DATA record

If the next record has different type than what has already been processed we break out of the main processing loop. If the record has already been decrypted (which may be the case for TLS 1.3 where we don't know type until decryption) we queue the pending record to the rxlist. Next recvmsg() will pick it up from there.

Queuing the skb to rxlist after zero-copy decrypt is not possible, since in that case we decrypted directly to the user space buffer, and we don't have an skb to queue (darg.skb points to the ciphertext skb for access to metadata like length).

Only data records are allowed zero-copy, and we break the processing loop after each non-data record. So we should never zero-copy and then find out that the record type has changed. The corner case we missed is when the initial record comes from rxlist, and it's zero length.

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

wifi: rsi: fix kthread lifetime race between self-exit and external-stop

RSI driver use both self-exit(kthreadcompleteandexit) and external-stop (kthreadstop) when killing a kthread. Generally, kthreadstop() is called first, and in this case, no particular issues occur.

However, in rare instances where kthreadcompleteandexit() is called first and then kthreadstop() is called, a UAF occurs because the kthread object, which has already exited and been freed, is accessed again.

Therefore, to prevent this with minimal modification, you must remove kthreadstop() and change the code to wait until the self-exit operation is completed.

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

net/sched: actapi: use RCU with deferred freeing for action lifecycle

When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action.

Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER:

0: mutexlock() <-- holds the idr lock 0: rcureadlock() 0: p = idrfind(idr, index) <-- action p is valid (RCU protects IDR) 0: mutexunlock() <-- releases the idr lock 1: refcountdecandmutexlock() <-- refcnt 1->0, mutex held 1: idrremove(idr, index) <-- Action removed from IDR 1: mutexunlock() <-- mutex released allowing us to delete the action 1: tcfactioncleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcountincnotzero(&p->tcfarefcnt) <-- ouch, UAF p points to freed memory

This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcuhead to tcaction used in the deferral and introducing a callrcu() in the delete path to defer the final kfree().

Note: this is a revert of commit d7fb60b9cafb ("netsched: get rid of tcfarcu") but also modernization/simplification to directly use kfreercu().

Let's illustrate the new restored code path:

0: rcureadlock() 1: refcountdecandmutexlock() <-- refcnt 1->0, mutex held 1: idrremove(idr, index) 1: mutexunlock() 1: callrcu(&p->tcfarcu, tcfactionrcufree) <-- defer kfree after grace period 0: p = idrfind(idr, index) 0: refcountincnotzero(&p->tcfarefcnt) <-- fails, refcnt already 0 1: rcureadunlock() <-- release so freeing can run after grace period

After CPU1 calls idrremove(), the object is no longer reachable through the IDR. CPU0's subsequent idrfind() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur.