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:

ppp: Fix KMSAN uninit-value warning with bpf

Syzbot caught an "KMSAN: uninit-value" warning [1], which is caused by the ppp driver not initializing a 2-byte header when using socket filter.

The following code can generate a PPP filter BPF program: ''' struct bpfprogram fp; pcapt handle; handle = pcapopendead(DLTPPPPPPD, 65535); pcapcompile(handle, &fp, "ip and outbound", 0, 0); bpfdump(&fp, 1); ''' Its output is: ''' (000) ldh [2] (001) jeq #0x21 jt 2 jf 5 (002) ldb [0] (003) jeq #0x1 jt 4 jf 5 (004) ret #65535 (005) ret #0 ''' Wen can find similar code at the following link: https://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680 The maintainer of this code repository is also the original maintainer of the ppp driver.

As you can see the BPF program skips 2 bytes of data and then reads the 'Protocol' field to determine if it's an IP packet. Then it read the first byte of the first 2 bytes to determine the direction.

The issue is that only the first byte indicating direction is initialized in current ppp driver code while the second byte is not initialized.

For normal BPF programs generated by libpcap, uninitialized data won't be used, so it's not a problem. However, for carefully crafted BPF programs, such as those generated by syzkaller [2], which start reading from offset 0, the uninitialized data will be used and caught by KMSAN.

[1] https://syzkaller.appspot.com/bug?extid=853242d9c9917165d791 [2] https://syzkaller.appspot.com/text?tag=ReproC&x=11994913980000

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

posix-cpu-timers: fix race between handleposixcputimers() and posixcputimerdel()

If an exiting non-autoreaping task has already passed exitnotify() and calls handleposixcputimers() from IRQ, it can be reaped by its parent or debugger right after unlocktasksighand().

If a concurrent posixcputimerdel() runs at that moment, it won't be able to detect timer->it.cpu.firing != 0: cputimertaskrcu() and/or locktasksighand() will fail.

Add the tsk->exitstate check into runposixcputimers() to fix this.

This fix is not needed if CONFIGPOSIXCPUTIMERSTASKWORK=y, because exittaskwork() is called before exitnotify(). But the check still makes sense, taskworkadd(&tsk->posixcputimerswork.work) will fail anyway in this case.

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

bpf: Fix UAF via mismatching bpfprog/attachment RCU flavors

Uprobes always use bpfprogrunarrayuprobe() under tasks-trace-RCU protection. But it is possible to attach a non-sleepable BPF program to a uprobe, and non-sleepable BPF programs are freed via normal RCU (see bpfprogputnoref()). This leads to UAF of the bpfprog because a normal RCU grace period does not imply a tasks-trace-RCU grace period.

Fix it by explicitly waiting for a tasks-trace-RCU grace period after removing the attachment of a bpfprog to a perfevent.

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

fwctl: Fix class init ordering to avoid NULL pointer dereference on device removal

CXL is linked before fwctl in drivers/Makefile. Both use moduleinit, so cxlpcidriverinit() runs first. When cxlpciprobe() calls fwctlregister() and then deviceadd(), fwctlclass is not yet registered because fwctlinit() hasn't run, causing classtosubsys() to return NULL and skip knodeclass initialization.

On device removal, classtosubsys() returns non-NULL, and devicedel() calls klistdel() on the uninitialized knode, triggering a NULL pointer dereference.

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

md/md-bitmap: fix GPF in bitmapgetstats()

The commit message of commit 6ec1f0239485 ("md/md-bitmap: fix stats collection for external bitmaps") states:

Remove the external bitmap check as the statistics should be available regardless of bitmap storage location.

Return -EINVAL only for invalid bitmap with no storage (neither in superblock nor in external file).

But, the code does not adhere to the above, as it does only check for a valid super-block for "internal" bitmaps. Hence, we observe:

Oops: GPF, probably for non-canonical address 0x1cd66f1f40000028 RIP: 0010:bitmapgetstats+0x45/0xd0 Call Trace:

seqreaditer+0x2b9/0x46a seqread+0x12f/0x180 procregread+0x57/0xb0 vfsread+0xf6/0x380 ksysread+0x6d/0xf0 dosyscall64+0x8c/0x1b0 entrySYSCALL64afterhwframe+0x76/0x7e

We fix this by checking the existence of a super-block for both the internal and external case.

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

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

netfs: Fix ceph copy to cache on write-begin

At the end of netfsunlockreadfolio() in which folios are marked appropriately for copying to the cache (either with by being marked dirty and having their private data set or by having PGprivate2 set) and then unlocked, the folioqueue struct has the entry pointing to the folio cleared. This presents a problem for netfspgpriv2writetothecache(), which is used to write folios marked with PGprivate2 to the cache as it expects to be able to trawl the folioqueue list thereafter to find the relevant folios, leading to a hang.

Fix this by not clearing the folioqueue entry if we're going to do the deprecated copy-to-cache. The clearance will be done instead as the folios are written to the cache.

This can be reproduced by starting cachefiles, mounting a ceph filesystem with "-o fsc" and writing to it.

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

powerpc/xive: Fix refcount leak in xivespaprinit

offindcompatiblenode() returns a node pointer with refcount incremented, we should use ofnodeput() on it when done. Add missing ofnodeput() to avoid refcount leak.

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

nfsd: don't ignore the return code of svcprocregister()

Currently, nfsdprocstatinit() ignores the return value of svcprocregister(). If the procfile creation fails, then the kernel will WARN when it tries to remove the entry later.

Fix nfsdprocstatinit() to return the same type of pointer as svcprocregister(), and fix up nfsdnetinit() to check that and fail the nfsdnet construction if it occurs.

svcprocregister() can fail if the dentry can't be allocated, or if an identical dentry already exists. The second case is pretty unlikely in the nfsdnet construction codepath, so if this happens, return -ENOMEM.

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

drm/vkms: Fix use after free and double free on init error

If the driver initialization fails, the vkmsexit() function might access an uninitialized or freed defaultconfig pointer and it might double free it.

Fix both possible errors by initializing defaultconfig only when the driver initialization succeeded.

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

mptcp: Use skdstget() and dstdevrcu() in mptcpactiveenable().

mptcpactiveenable() is called from subflowfinishconnect(), which is icsk->icskafops->skrxdstset() and it's not always under RCU.

Using skdstget(sk)->dev could trigger UAF.

Let's use skdstget() and dstdevrcu().

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

net: sched: sfb: fix null pointer access issue when sfbinit() fails

When the default qdisc is sfb, if the qdisc of devqueue fails to be inited during mqprioinit(), sfbreset() is invoked to clear resources. In this case, the q->qdisc is NULL, and it will cause gpf issue.

The process is as follows: qdisccreatedflt() sfbinit() tcfblockget() --->failed, q->qdisc is NULL ... qdiscput() ... sfbreset() qdiscreset(q->qdisc) --->q->qdisc is NULL ops = qdisc->ops

The following is the Call Trace information: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] RIP: 0010:qdiscreset+0x2b/0x6f0 Call Trace: <TASK> sfbreset+0x37/0xd0 qdiscreset+0xed/0x6f0 qdiscdestroy+0x82/0x4c0 qdiscput+0x9e/0xb0 qdisccreatedflt+0x2c3/0x4a0 mqprioinit+0xa71/0x1760 qdisccreate+0x3eb/0x1000 tcmodifyqdisc+0x408/0x1720 rtnetlinkrcvmsg+0x38e/0xac0 netlinkrcvskb+0x12d/0x3a0 netlinkunicast+0x4a2/0x740 netlinksendmsg+0x826/0xcc0 socksendmsg+0xc5/0x100 syssendmsg+0x583/0x690 syssendmsg+0xe8/0x160 syssendmsg+0xbf/0x160 dosyscall64+0x35/0x80 entrySYSCALL64afterhwframe+0x46/0xb0 RIP: 0033:0x7f2164122d04 </TASK>

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

dmaengine: idxd: Check availability of workqueue allocated by idxd wq driver before using

Running IDXD workloads in a container with the /dev directory mounted can trigger a call trace or even a kernel panic when the parent process of the container is terminated.

This issue occurs because, under certain configurations, Docker does not properly propagate the mount replica back to the original mount point.

In this case, when the user driver detaches, the WQ is destroyed but it still calls destroyworkqueue() attempting to completes all pending work. It's necessary to check wq->wq and skip the drain if it no longer exists.

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:

usb: cdns3: fix role switching during resume

If the role change while we are suspended, the cdns3 driver switches to the new mode during resume. However, switching to host mode in this context causes a NULL pointer dereference.

The host role's start() operation registers a xhci-hcd device, but its probe is deferred while we are in the resume path. The host role's resume() operation assumes the xhci-hcd device is already probed, which is not the case, leading to the dereference. Since the start() operation of the new role is already called, the resume operation can be skipped.

So skip the resume operation for the new role if a role switch occurs during resume. Once the resume sequence is complete, the xhci-hcd device can be probed in case of host mode.

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000208 Mem abort info: ... Data abort info: ... [0000000000000208] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 146 Comm: sh Not tainted 6.19.0-rc7-00013-g6e64f4aabfae-dirty #135 PREEMPT Hardware name: Texas Instruments J7200 EVM (DT) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhcdisprimaryhcd+0x0/0x1c lr : cdnshostresume+0x24/0x5c ... Call trace: usbhcdisprimaryhcd+0x0/0x1c (P) cdnsresume+0x6c/0xbc cdns3controllerresume.isra.0+0xe8/0x17c cdns3platresume+0x18/0x24 platformpmresume+0x2c/0x68 dpmruncallback+0x90/0x248 deviceresume+0x100/0x24c dpmresume+0x190/0x2ec dpmresumeend+0x18/0x34 suspenddevicesandenter+0x2b0/0xa44 pmsuspend+0x16c/0x5fc statestore+0x80/0xec kobjattrstore+0x18/0x2c sysfskfwrite+0x7c/0x94 kernfsfopwriteiter+0x130/0x1dc vfswrite+0x240/0x370 ksyswrite+0x70/0x108 arm64syswrite+0x1c/0x28 invokesyscall+0x48/0x10c el0svccommon.constprop.0+0x40/0xe0 doel0svc+0x1c/0x28 el0svc+0x34/0x108 el0t64synchandler+0xa0/0xe4 el0t64sync+0x198/0x19c Code: 52800003 f9407ca5 d63f00a0 17ffffe4 (f9410401) ---[ end trace 0000000000000000 ]---

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:

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:

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: 3com: 3c59x: fix possible null dereference in vortexprobe1()

pdev can be null and freering: can be called in 1297 with a null pdev.

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

RDMA/cma: Fix hang when cmaneteventcallback fails to queuework

The cited commit fixed a crash when cmaneteventcallback was called for a cmaid while work on that id from a previous call had not yet started. The work item was re-initialized in the second call, which corrupted the work item currently in the work queue.

However, it left a problem when queuework fails (because the item is still pending in the work queue from a previous call). In this case, cmaidput (which is called in the work handler) is therefore not called. This results in a userspace process hang (zombie process).

Fix this by calling cmaidput() if queuework fails.

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

acpi: typec: ucsi: Introduce a ->pollcci method

For the ACPI backend of UCSI the UCSI "registers" are just a memory copy of the register values in an opregion. The ACPI implementation in the BIOS ensures that the opregion contents are synced to the embedded controller and it ensures that the registers (in particular CCI) are synced back to the opregion on notifications. While there is an ACPI call that syncs the actual registers to the opregion there is rarely a need to do this and on some ACPI implementations it actually breaks in various interesting ways.

The only reason to force a sync from the embedded controller is to poll CCI while notifications are disabled. Only the ucsi core knows if this is the case and guessing based on the current command is suboptimal, i.e. leading to the following spurious assertion splat:

WARNING: CPU: 3 PID: 76 at drivers/usb/typec/ucsi/ucsi.c:1388 ucsiresetppm+0x1b4/0x1c0 [typecucsi] CPU: 3 UID: 0 PID: 76 Comm: kworker/3:0 Not tainted 6.12.11-200.fc41.x8664 #1 Hardware name: LENOVO 21D0/LNVNB161216, BIOS J6CN45WW 03/17/2023 Workqueue: eventslong ucsiinitwork [typecucsi] RIP: 0010:ucsiresetppm+0x1b4/0x1c0 [typecucsi] Call Trace: <TASK> ucsiinitwork+0x3c/0xac0 [typecucsi] processonework+0x179/0x330 workerthread+0x252/0x390 kthread+0xd2/0x100 retfromfork+0x34/0x50 retfromforkasm+0x1a/0x30 </TASK>

Thus introduce a ->pollcci() method that works like ->readcci() with an additional forced sync and document that this should be used when polling with notifications disabled. For all other backends that presumably don't have this issue use the same implementation for both methods.

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

sctp: add a refcnt in sctpstreampriorities to avoid a nested loop

With this refcnt added in sctpstreampriorities, we don't need to traverse all streams to check if the prio is used by other streams when freeing one stream's prio in sctpschedpriofreesid(). This can avoid a nested loop (up to 65535 65535), which may cause a stuck as Ying reported:

watchdog: BUG: soft lockup - CPU#23 stuck for 26s! [ksoftirqd/23:136] Call Trace: <TASK> sctpschedpriofreesid+0xab/0x100 [sctp] sctpstreamfreeext+0x64/0xa0 [sctp] sctpstreamfree+0x31/0x50 [sctp] sctpassociationfree+0xa5/0x200 [sctp]

Note that it doesn't need to use refcountt type for this counter, as its accessing is always protected under the sock lock.

v1->v2: - add a check in sctpschedprioset to avoid the possible priohead refcnt overflow.

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

netfilter: nftsetrbtree: fix overlap expiration walk

The lazy gc on insert that should remove timed-out entries fails to release the other half of the interval, if any.

Can be reproduced with tests/shell/testcases/sets/0044intervaloverlap0 in nftables.git and kmemleak enabled kernel.

Second bug is the use of rbeprev vs. prev pointer. If rbeprev() returns NULL after at least one iteration, rbeprev points to element that is not an end interval, hence it should not be removed.

Lastly, check the genmask of the end interval if this is active in the current generation.

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

drm/amdgpu: drop redundant sched job cleanup when cs is aborted

Once command submission failed due to userptr invalidation in amdgpucssubmit, legacy code will perform cleanup of scheduler job. However, it's not needed at all, as former commit has integrated job cleanup stuff into amdgpujobfree. Otherwise, because of double free, a NULL pointer dereference will occur in such scenario.

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2457

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:

kunit: executor: Fix a memory leak on failure in kunitfiltertests

It's possible that memory allocation for 'filtered' will fail, but for the copy of the suite to succeed. In this case, the copy could be leaked.

Properly free 'copy' in the error case for the allocation of 'filtered' failing.

Note that there may also have been a similar issue in kunitfiltersubsuites, before it was removed in "kunit: flatten kunitsuite to kunitsuite in .kunittestsuites".

This was reported by clang-analyzer via the kernel test robot, here: https://lore.kernel.org/all/c8073b8e-7b9e-0830-4177-87c12f16349c@intel.com/

And by smatch via Dan Carpenter and the kernel test robot: https://lore.kernel.org/all/202207101328.ASjx88yj-lkp@intel.com/

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

netfilter: nftables: double hook unregistration in netns path

nftreleasehooks() is called from prenetns exit path which unregisters the hooks, then the NETDEVUNREGISTER event is triggered which unregisters the hooks again.

[ 565.221461] WARNING: CPU: 18 PID: 193 at net/netfilter/core.c:495 nfunregisternethook+0x247/0x270 [...] [ 565.246890] CPU: 18 PID: 193 Comm: kworker/u64:1 Tainted: G E 5.18.0-rc7+ #27 [ 565.253682] Workqueue: netns cleanupnet [ 565.257059] RIP: 0010:nfunregisternethook+0x247/0x270 [...] [ 565.297120] Call Trace: [ 565.300900] <TASK> [ 565.304683] nftablesflowtableevent+0x16a/0x220 [nftables] [ 565.308518] rawnotifiercallchain+0x63/0x80 [ 565.312386] unregisternetdevicemany+0x54f/0xb50

Unregister and destroy netdev hook from netns preexit via kfreercu so the NETDEVUNREGISTER path see unregistered hooks.

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

sched/mmcid: Handle vfork()/CLONEVM correctly

Matthieu and Jiri reported stalls where a task endlessly loops in mmgetcid() when scheduling in.

It turned out that the logic which handles vfork()'ed tasks is broken. It is invoked when the number of tasks associated to a process is smaller than the number of MMCID users. It then walks the task list to find the vfork()'ed task, but accounts all the already processed tasks as well.

If that double processing brings the number of to be handled tasks to 0, the walk stops and the vfork()'ed task's CID is not fixed up. As a consequence a subsequent schedule in fails to acquire a (transitional) CID and the machine stalls.

Cure this by removing the accounting condition and make the fixup always walk the full task list if it could not find the exact number of users in the process' thread list.

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---