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

Bluetooth: btmtk: validate WMT event SKB length before struct access

btmtkusbhciwmtsync() casts the WMT event response SKB data to struct btmtkhciwmtevt (7 bytes) and struct btmtkhciwmtevtfuncc (9 bytes) without first checking that the SKB contains enough data. A short firmware response causes out-of-bounds reads from SKB tailroom.

Use skbpulldata() to validate and advance past the base WMT event header. For the FUNCCTRL case, pull the additional status field bytes before accessing them.

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

drm/amdgpu: Fix memory leak in amdgpuacpienumeratexcc()

In amdgpuacpienumeratexcc(), if amdgpuacpidevinit() returns -ENOMEM, the function returns directly without releasing the allocated xccinfo, resulting in a memory leak.

Fix this by ensuring that xccinfo is properly freed in the error paths.

Compile tested only. Issue found using a prototype static analysis tool and code review.

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.

bnxten: Fix NULL pointer dereference

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

HID: magicmouse: Do not crash on missing msc->input

Fake USB devices can send their own report descriptors for which the inputmapping() hook does not get called. In this case, msc->input stays NULL, leading to a crash at a later time.

Detect this condition in the inputconfigured() hook and reject the device.

This is not supposed to happen with actual magic mouse devices, but can be provoked by imposing as a magic mouse USB device.

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:

btrfs: do not ASSERT() when the fs flips RO inside btrfsrepairiofailure()

[BUG] There is a bug report that when btrfs hits ENOSPC error in a critical path, btrfs flips RO (this part is expected, although the ENOSPC bug still needs to be addressed).

The problem is after the RO flip, if there is a read repair pending, we can hit the ASSERT() inside btrfsrepairiofailure() like the following:

BTRFS info (device vdc): relocating block group 30408704 flags metadata|raid1 ------------[ cut here ]------------ BTRFS: Transaction aborted (error -28) WARNING: fs/btrfs/extent-tree.c:3235 at btrfsfreeextent.isra.0+0x453/0xfd0, CPU#1: btrfs/383844 Modules linked in: kvmintel kvm irqbypass [...] ---[ end trace 0000000000000000 ]--- BTRFS info (device vdc state EA): 2 enospc errors during balance BTRFS info (device vdc state EA): balance: ended with status: -30 BTRFS error (device vdc state EA): parent transid verify failed on logical 30556160 mirror 2 wanted 8 found 6 BTRFS error (device vdc state EA): bdev /dev/nvme0n1 errs: wr 0, rd 0, flush 0, corrupt 10, gen 0 [...] assertion failed: !(fsinfo->sb->sflags & SBRDONLY) :: 0, in fs/btrfs/bio.c:938 ------------[ cut here ]------------ assertion failed: !(fsinfo->sb->sflags & SBRDONLY) :: 0, in fs/btrfs/bio.c:938 kernel BUG at fs/btrfs/bio.c:938! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 868 Comm: kworker/u8:13 Tainted: G W N 6.19.0-rc6+ #4788 PREEMPT(full) Tainted: [W]=WARN, [N]=TEST Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 Workqueue: btrfs-endio simpleendiowork RIP: 0010:btrfsrepairiofailure.cold+0xb2/0x120 RSP: 0000:ffffc90001d2bcf0 EFLAGS: 00010246 RAX: 0000000000000051 RBX: 0000000000001000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8305cf42 RDI: 00000000ffffffff RBP: 0000000000000002 R08: 00000000fffeffff R09: ffffffff837fa988 R10: ffffffff8327a9e0 R11: 6f69747265737361 R12: ffff88813018d310 R13: ffff888168b8a000 R14: ffffc90001d2bd90 R15: ffff88810a169000 FS: 0000000000000000(0000) GS:ffff8885e752c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 ------------[ cut here ]------------

[CAUSE] The cause of -ENOSPC error during the test case btrfs/124 is still unknown, although it's known that we still have cases where metadata can be over-committed but can not be fulfilled correctly, thus if we hit such ENOSPC error inside a critical path, we have no choice but abort the current transaction.

This will mark the fs read-only.

The problem is inside the btrfsrepairiofailure() path that we require the fs not to be mount read-only. This is normally fine, but if we are doing a read-repair meanwhile the fs flips RO due to a critical error, we can enter btrfsrepairiofailure() with super block set to read-only, thus triggering the above crash.

[FIX] Just replace the ASSERT() with a proper return if the fs is already read-only.

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:

nvme-pci: ensure we're polling a polled queue

A user can change the polled queue count at run time. There's a brief window during a reset where a hipri task may try to poll that queue before the block layer has updated the queue maps, which would race with the now interrupt driven queue and may cause double completions.

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:

drm/amdgpu/userq: Do not allow userspace to trivially triger kernel warnings

Userspace can either deliberately pass in the too small numfences, or the required number can legitimately grow between the two calls to the userq wait ioctl. In both cases we do not want the emit the kernel warning backtrace since nothing is wrong with the kernel and userspace will simply get an errno reported back. So lets simply drop the WARNONs.

(cherry picked from commit 2c333ea579de6cc20ea7bc50e9595ef72863e65c)

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.