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

net: enetc: allocate vfstate during PF probes

In the previous implementation, vfstate is allocated memory only when VF is enabled. However, netdeviceops::ndosetvfmac() may be called before VF is enabled to configure the MAC address of VF. If this is the case, enetcpfsetvfmac() will access vfstate, resulting in access to a null pointer. The simplified error log is as follows.

root@ls1028ardb:~# ip link set eno0 vf 1 mac 00:0c:e7:66:77:89 [ 173.543315] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 [ 173.637254] pc : enetcpfsetvfmac+0x3c/0x80 Message from sy [ 173.641973] lr : dosetlink+0x4a8/0xec8 [ 173.732292] Call trace: [ 173.734740] enetcpfsetvfmac+0x3c/0x80 [ 173.738847] rtnlnewlink+0x530/0x89c [ 173.742692] rtnlnewlink+0x50/0x7c [ 173.746189] rtnetlinkrcvmsg+0x128/0x390 [ 173.750298] netlinkrcvskb+0x60/0x130 [ 173.754145] rtnetlinkrcv+0x18/0x24 [ 173.757731] netlinkunicast+0x318/0x380 [ 173.761665] netlinksendmsg+0x17c/0x3c8

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

net: dsa: improve shutdown sequence

Alexander Sverdlin presents 2 problems during shutdown with the lan9303 driver. One is specific to lan9303 and the other just happens to reproduce there.

The first problem is that lan9303 is unique among DSA drivers in that it calls devgetdrvdata() at "arbitrary runtime" (not probe, not shutdown, not remove):

phystatemachine() -> ... -> dsauserphyread() -> ds->ops->phyread() -> lan9303phyread() -> chip->ops->phyread() -> lan9303mdiophyread() -> devgetdrvdata()

But we never stop the phystatemachine(), so it may continue to run after dsaswitchshutdown(). Our common pattern in all DSA drivers is to set drvdata to NULL to suppress the remove() method that may come afterwards. But in this case it will result in an NPD.

The second problem is that the way in which we set dp->conduit->dsaptr = NULL; is concurrent with receive packet processing. dsaswitchrcv() checks once whether dev->dsaptr is NULL, but afterwards, rather than continuing to use that non-NULL value, dev->dsaptr is dereferenced again and again without NULL checks: dsaconduitfinduser() and many other places. In between dereferences, there is no locking to ensure that what was valid once continues to be valid.

Both problems have the common aspect that closing the conduit interface solves them.

In the first case, devclose(conduit) triggers the NETDEVGOINGDOWN event in dsausernetdeviceevent() which closes user ports as well. dsaportdisablert() calls phylinkstop(), which synchronously stops the phylink state machine, and ds->ops->phyread() will thus no longer call into the driver after this point.

In the second case, devclose(conduit) should do this, as per Documentation/networking/driver.rst:

| Quiescence | ---------- | | After the ndostop routine has been called, the hardware must | not receive or transmit any data. All in flight packets must | be aborted. If necessary, poll or wait for completion of | any reset commands.

So it should be sufficient to ensure that later, when we zeroize conduit->dsaptr, there will be no concurrent dsaswitchrcv() call on this conduit.

The addition of the netifdevicedetach() function is to ensure that ioctls, rtnetlinks and ethtool requests on the user ports no longer propagate down to the driver - we're no longer prepared to handle them.

The race condition actually did not exist when commit 0650bf52b31f ("net: dsa: be compatible with masters which unregister on shutdown") first introduced dsaswitchshutdown(). It was created later, when we stopped unregistering the user interfaces from a bad spot, and we just replaced that sequence with a racy zeroization of conduit->dsaptr (one which doesn't ensure that the interfaces aren't up).

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

net: fix data-races around sk->skforwardalloc

Syzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/afinet.c:156 inetsockdestruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inetsockdestruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? warn+0x88/0x130 ? inetsockdestruct+0x1c5/0x1e0 ? reportbug+0x18e/0x1a0 ? handlebug+0x53/0x90 ? excinvalidop+0x18/0x70 ? asmexcinvalidop+0x1a/0x20 ? inetsockdestruct+0x1c5/0x1e0 skdestruct+0x2a/0x200 rcudobatch+0x1aa/0x530 ? rcudobatch+0x13b/0x530 rcucore+0x159/0x2f0 handlesoftirqs+0xd3/0x2b0 ? pfxsmpbootthreadfn+0x10/0x10 runksoftirqd+0x25/0x30 smpbootthreadfn+0xdd/0x1d0 kthread+0xd3/0x100 ? pfxkthread+0x10/0x10 retfromfork+0x34/0x50 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK> ---[ end trace 0000000000000000 ]---

Its possible that two threads call tcpv6dorcv()/skforwardallocadd() concurrently when sk->skstate == TCPLISTEN with sk->sklock unlocked, which triggers a data-race around sk->skforwardalloc: tcpv6rcv tcpv6dorcv skbcloneandcharger skrmemschedule skmemschedule skforwardallocadd() skbsetownerr skmemcharge skforwardallocadd() kfreeskb skbreleaseall skbreleaseheadstate sockrfree skmemuncharge skforwardallocadd() skmemreclaim // set local var reclaimable skmemreclaim skforwardallocadd()

In this syzkaller testcase, two threads call tcpv6dorcv() with skb->truesize=768, the skforwardalloc changes like this: (cpu 1) | (cpu 2) | skforwardalloc ... | ... | 0 skmemschedule() | | +4096 = 4096 | skmemschedule() | +4096 = 8192 skmemcharge() | | -768 = 7424 | skmemcharge() | -768 = 6656 ... | ... | skmemuncharge() | | +768 = 7424 reclaimable=7424 | | | skmemuncharge() | +768 = 8192 | reclaimable=8192 | skmemreclaim() | | -4096 = 4096 | skmemreclaim() | -8192 = -4096 != 0

The skbcloneandcharger() should not be called in tcpv6dorcv() when sk->skstate is TCPLISTEN, it happens later in tcpv6synrecvsock(). Fix the same issue in dccpv6dorcv().

bpf: Fix overloading of MEMUNINIT's meaning

HID: core: zero-initialize the report buffer

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

vsock/virtio: Initialization of the dangling pointer occurring in vsk->trans

During loopback communication, a dangling pointer can be created in vsk->trans, potentially leading to a Use-After-Free condition. This issue is resolved by initializing vsk->trans to NULL.

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

drm/mediatek: Fix potential NULL dereference in mtkcrtcdestroy()

In mtkcrtccreate(), if the call to mboxrequestchannel() fails then we set the "mtkcrtc->cmdqclient.chan" pointer to NULL. In that situation, we do not call cmdqpktcreate().

During the cleanup, we need to check if the "mtkcrtc->cmdqclient.chan" is NULL first before calling cmdqpktdestroy(). Calling cmdqpktdestroy() is unnecessary if we didn't call cmdqpktcreate() and it will result in a NULL pointer dereference.

Bluetooth: hcicore: Disable works on hciunregisterdev

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

net/sched: stop qdisctreereducebacklog on TCHROOT

In qdisctreereducebacklog, Qdiscs with major handle ffff: are assumed to be either root or ingress. This assumption is bogus since it's valid to create egress qdiscs with major handle ffff: Budimir Markovic found that for qdiscs like DRR that maintain an active class list, it will cause a UAF with a dangling class pointer.

In 066a3b5b2346, the concern was to avoid iterating over the ingress qdisc since its parent is itself. The proper fix is to stop when parent TCHROOT is reached because the only way to retrieve ingress is when a hierarchy which does not contain a ffff: major handle call into qdisclookup with TCHMAJ(TCHROOT).

In the scenario where major ffff: is an egress qdisc in any of the tree levels, the updates will also propagate to TCHROOT, which then the iteration must stop.

net/sched/schapi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

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

nvme-multipath: defer partition scanning

We need to suppress the partition scan from occuring within the controller's scanwork context. If a path error occurs here, the IO will wait until a path becomes available or all paths are torn down, but that action also occurs within scanwork, so it would deadlock. Defer the partion scan to a different context that does not block scanwork.

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

hvsock: Initializing vsk->trans to NULL to prevent a dangling pointer

When hvs is released, there is a possibility that vsk->trans may not be initialized to NULL, which could lead to a dangling pointer. This issue is resolved by initializing vsk->trans to NULL.

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

Bluetooth: hcievent: Align BR/EDR JUSTWORKS paring with LE

This aligned BR/EDR JUSTWORKS method with LE which since 92516cd97fd4 ("Bluetooth: Always request for user confirmation for Just Works") always request user confirmation with confirmhint set since the likes of bluetoothd have dedicated policy around JUSTWORKS method (e.g. main.conf:JustWorksRepairing).

CVE: CVE-2024-8805

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

udf: fix uninit-value use in udfgetfileshortad

Check for overflow when computing alen in udfcurrentaext to mitigate later uninit-value use in udfgetfileshortad KMSAN bug[1]. After applying the patch reproducer did not trigger any issue[2].

[1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df [2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000

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

posix-clock: Fix missing timespec64 check in pcclocksettime()

As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tvsec and tvnsec range before calling ptp->info->settime64().

As the man manual of clocksettime() said, if tp.tvsec is negative or tp.tvnsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64valid(). As Thomas suggested, timespec64valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64validstrict() in pcclocksettime() and return -EINVAL if not valid.

There are some drivers that use tp->tvsec and tp->tvnsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclgeptpsettime(), igbptpsettimei210(), rcargen4ptpsettime(), and some drivers can remove the checks of itself.

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

nilfs2: propagate directory read errors from nilfsfindentry()

Syzbot reported that a task hang occurs in vcsopen() during a fuzzing test for nilfs2.

The root cause of this problem is that in nilfsfindentry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfsgetfolio() fails.

If the filesystem images is corrupted, and the isize of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfscheckfolio() may continue to spit out error messages in bursts.

Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfsfindentry().

The current interface of nilfsfindentry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfsfindentry(), so fix it together.

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

mm/swapfile: skip HugeTLB pages for unusevma

I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps:

1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message:

mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7)

We can tell that pudclearbad is called by pudnoneorclearbad in unusepudrange() by ftrace. And therefore the HugeTLB pages will never be freed because we lost it from page table. We can skip HugeTLB pages for unusevma to fix it.

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

pinctrl: ocelot: fix system hang on level based interrupts

The current implementation only calls chainedirqenter() and chainedirqexit() if it detects pending interrupts.

for (i = 0; i < info->stride; i++) { uregmapread(info->map, idreg + 4 i, &reg); if (!reg) continue;

chainedirqenter(parentchip, desc);

However, in case of GPIO pin configured in level mode and the parent controller configured in edge mode, GPIO interrupt might be lowered by the hardware. In the result, if the interrupt is short enough, the parent interrupt is still pending while the GPIO interrupt is cleared; chainedirqenter() never gets called and the system hangs trying to service the parent interrupt.

Moving chainedirqenter() and chainedirqexit() outside the for loop ensures that they are called even when GPIO interrupt is lowered by the hardware.

The similar code with chainedirqenter() / chainedirqexit() functions wrapping interrupt checking loop may be found in many other drivers: grep -r -A 10 chainedirqenter drivers/pinctrl

fs/ntfs3: Check if more than chunk-size bytes are written

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

netfilter: nfrejectipv6: fix potential crash in nfsendreset6()

I got a syzbot report without a repro [1] crashing in nfsendreset6()

I think the issue is that dev->hardheaderlen is zero, and we attempt later to push an Ethernet header.

Use LLMAXHEADER, as other functions in net/ipv6/netfilter/nfrejectipv6.c.

[1]

skbuff: skbunderpanic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syztun kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skbpanic net/core/skbuff.c:206 [inline] RIP: 0010:skbunderpanic+0x14b/0x150 net/core/skbuff.c:216 Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc900045269b0 EFLAGS: 00010282 RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800 RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000 RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4ccc R10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140 R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003c FS: 00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> skbpush+0xe5/0x100 net/core/skbuff.c:2636 ethheader+0x38/0x1f0 net/ethernet/eth.c:83 devhardheader include/linux/netdevice.h:3208 [inline] nfsendreset6+0xce6/0x1270 net/ipv6/netfilter/nfrejectipv6.c:358 nftrejectineteval+0x3b9/0x690 net/netfilter/nftrejectinet.c:48 exprcallopseval net/netfilter/nftablescore.c:240 [inline] nftdochain+0x4ad/0x1da0 net/netfilter/nftablescore.c:288 nftdochaininet+0x418/0x6b0 net/netfilter/nftchainfilter.c:161 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xc3/0x220 net/netfilter/core.c:626 nfhook include/linux/netfilter.h:269 [inline] NFHOOK include/linux/netfilter.h:312 [inline] brnfpreroutingipv6+0x63e/0x770 net/bridge/brnetfilteripv6.c:184 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookbridgepre net/bridge/brinput.c:277 [inline] brhandleframe+0x9fd/0x1530 net/bridge/brinput.c:424 netifreceiveskbcore+0x13e8/0x4570 net/core/dev.c:5562 netifreceiveskbonecore net/core/dev.c:5666 [inline] netifreceiveskb+0x12f/0x650 net/core/dev.c:5781 netifreceiveskbinternal net/core/dev.c:5867 [inline] netifreceiveskb+0x1e8/0x890 net/core/dev.c:5926 tunrxbatched+0x1b7/0x8f0 drivers/net/tun.c:1550 tungetuser+0x3056/0x47e0 drivers/net/tun.c:2007 tunchrwriteiter+0x10d/0x1f0 drivers/net/tun.c:2053 newsyncwrite fs/readwrite.c:590 [inline] vfswrite+0xa6d/0xc90 fs/readwrite.c:683 ksyswrite+0x183/0x2b0 fs/readwrite.c:736 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7fdbeeb7d1ff Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48 RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIGRAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ff RDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8 RBP: 00007fdbeebf12be R08: 0000000 ---truncated---

iio: adc: ad7124: fix division by zero in ad7124setchannelodr()

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

ocfs2: pass u64 to ocfs2truncateinline maybe overflow

Syzbot reported a kernel BUG in ocfs2truncateinline. There are two reasons for this: first, the parameter value passed is greater than ocfs2maxinlinedatawithxattr, second, the start and end parameters of ocfs2truncateinline are "unsigned int".

So, we need to add a sanity check for bytestart and bytelen right before ocfs2truncateinline() in ocfs2removeinoderange(), if they are greater than ocfs2maxinlinedatawithxattr return -EINVAL.

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

wifi: mac80211: do not pass a stopped vif to the driver in .gettxpower

Avoid potentially crashing in the driver because of uninitialized private data

bpf: Fix out-of-bounds write in triegetnextkey()

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

media: av7110: fix a spectre vulnerability

As warned by smatch: drivers/staging/media/av7110/av7110ca.c:270 dvbcaioctl() warn: potential spectre issue 'av7110->cislot' [w] (local cap)

There is a spectre-related vulnerability at the code. Fix it.

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

USB: serial: ioedgeport: fix use after free in debug printk

The "devdbg(&urb->dev->dev, ..." which happens after usbfreeurb(urb) is a use after free of the "urb" pointer. Store the "dev" pointer at the start of the function to avoid this issue.

drm/amdgpu: add missing size check in amdgpudebugfsgprwaveread()

filemap: Fix bounds checking in filemapread()

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

media: v4l2-tpg: prevent the risk of a division by zero

As reported by Coverity, the logic at tpgprecalculateline() blindly rescales the buffer even when scaledwitdh is equal to zero. If this ever happens, this will cause a division by zero.

Instead, add a WARNONONCE() to trigger such cases and return without doing any precalculation.

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

ipv4: iptunnel: Fix suspicious RCU usage warning in iptunnelfind()

The per-netns IP tunnel hash table is protected by the RTNL mutex and iptunnelfind() is only called from the control path where the mutex is taken.

Add a lockdep expression to hlistforeachentryrcu() in iptunnelfind() in order to validate that the mutex is held and to silence the suspicious RCU usage warning [1].

[1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted ----------------------------- net/ipv4/iptunnel.c:221 RCU-list traversed in non-reader section!!

other info that might help us debug this:

rcuscheduleractive = 2, debuglocks = 1 1 lock held by ip/362: #0: ffffffff86fc7cb0 (rtnlmutex){+.+.}-{3:3}, at: rtnetlinkrcvmsg+0x377/0xf60

stack backtrace: CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: <TASK> dumpstacklvl+0xba/0x110 lockdeprcususpicious.cold+0x4f/0xd6 iptunnelfind+0x435/0x4d0 iptunnelnewlink+0x517/0x7a0 ipgrenewlink+0x14c/0x170 rtnlnewlink+0x1173/0x19c0 rtnlnewlink+0x6c/0xa0 rtnetlinkrcvmsg+0x3cc/0xf60 netlinkrcvskb+0x171/0x450 netlinkunicast+0x539/0x7f0 netlinksendmsg+0x8c1/0xd80 syssendmsg+0x8f9/0xc20 syssendmsg+0x197/0x1e0 syssendmsg+0x122/0x1f0 dosyscall64+0xbb/0x1d0 entrySYSCALL64afterhwframe+0x77/0x7f

firmware: armscmi: Fix slab-use-after-free in scmibusnotifier()