The Linux Kernel, the operating system core itself.

Security Fix(es):

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

tun: avoid double free in tunfreenetdev

Avoid double free in tunfreenetdev() by moving the dev->tstats and tun->security allocs to a new ndoinit routine (tunnetinit()) that will be called by registernetdevice(). ndoinit is paired with the desctructor (tunfreenetdev()), so if there's an error in registernetdevice() the destructor will handle the frees.

BUG: KASAN: double-free or invalid-free in selinuxtundevfreesecurity+0x1a/0x20 security/selinux/hooks.c:5605

CPU: 0 PID: 25750 Comm: syz-executor416 Not tainted 5.16.0-rc2-syzk #1 Hardware name: Red Hat KVM, BIOS Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x89/0xb5 lib/dumpstack.c:106 printaddressdescription.constprop.9+0x28/0x160 mm/kasan/report.c:247 kasanreportinvalidfree+0x55/0x80 mm/kasan/report.c:372 kasanslabfree mm/kasan/common.c:346 [inline] _kasanslabfree+0x107/0x120 mm/kasan/common.c:374 kasanslabfree include/linux/kasan.h:235 [inline] slabfreehook mm/slub.c:1723 [inline] slabfreefreelisthook mm/slub.c:1749 [inline] slabfree mm/slub.c:3513 [inline] kfree+0xac/0x2d0 mm/slub.c:4561 selinuxtundevfreesecurity+0x1a/0x20 security/selinux/hooks.c:5605 securitytundevfreesecurity+0x4f/0x90 security/security.c:2342 tunfreenetdev+0xe6/0x150 drivers/net/tun.c:2215 netdevruntodo+0x4df/0x840 net/core/dev.c:10627 rtnlunlock+0x13/0x20 net/core/rtnetlink.c:112 _tunchrioctl+0x80c/0x2870 drivers/net/tun.c:3302 tunchrioctl+0x2f/0x40 drivers/net/tun.c:3311 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:874 [inline] _sesysioctl fs/ioctl.c:860 [inline] _x64sysioctl+0x19d/0x220 fs/ioctl.c:860 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x3a/0x80 arch/x86/entry/common.c:80 entrySYSCALL64after_hwframe+0x44/0xae(CVE-2021-47082)

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

x86/kvm: Disable kvmclock on all CPUs on shutdown

Currenly, we disable kvmclock from machine_shutdown() hook and this only happens for boot CPU. We need to disable it for all CPUs to guard against memory corruption e.g. on restore from hibernate.

Note, writing '0' to kvmclock MSR doesn't clear memory location, it just prevents hypervisor from updating the location so for the short while after write and while CPU is still alive, the clock remains usable and correct so we don't need to switch to some other clocksource.(CVE-2021-47110)

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

i40e: Fix NULL ptr dereference on VSI filter sync

Remove the reason of null pointer dereference in sync VSI filters. Added new I40EVSIRELEASING flag to signalize deleting and releasing of VSI resources to sync this thread with sync filters subtask. Without this patch it is possible to start update the VSI filter list after VSI is removed, that's causing a kernel oops.(CVE-2021-47184)

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

erofs: fix pcluster use-after-free on UP platforms

During stress testing with CONFIG_SMP disabled, KASAN reports as below:

================================================================== BUG: KASAN: use-after-free in _mutexlock+0xe5/0xc30 Read of size 8 at addr ffff8881094223f8 by task stress/7789

CPU: 0 PID: 7789 Comm: stress Not tainted 6.0.0-rc1-00002-g0d53d2e882f9 #3 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 Call Trace: <TASK> .. _mutexlock+0xe5/0xc30 .. zerofsdoreadpage+0x8ce/0x1560 .. zerofsreadahead+0x31c/0x580 .. Freed by task 7787 kasansavestack+0x1e/0x40 kasansettrack+0x20/0x30 kasansetfreeinfo+0x20/0x40 _kasanslabfree+0x10c/0x190 kmemcachefree+0xed/0x380 rcucore+0x3d5/0xc90 _do_softirq+0x12d/0x389

Last potentially related work creation: kasansavestack+0x1e/0x40 _kasanrecordauxstack+0x97/0xb0 callrcu+0x3d/0x3f0 erofsshrinkworkstation+0x11f/0x210 erofsshrinkscan+0xdc/0x170 shrinkslab.constprop.0+0x296/0x530 dropslab+0x1c/0x70 dropcachessysctlhandler+0x70/0x80 procsyscallhandler+0x20a/0x2f0 vfswrite+0x555/0x6c0 ksyswrite+0xbe/0x160 dosyscall_64+0x3b/0x90

The root cause is that erofsworkgroupunfreeze() doesn't reset to orig_val thus it causes a race that the pcluster reuses unexpectedly before freeing.

Since UP platforms are quite rare now, such path becomes unnecessary. Let's drop such specific-designed path directly instead.(CVE-2022-48674)

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

hwrng: core - Fix page fault dead lock on mmap-ed hwrng

There is a dead-lock in the hwrng device read path. This triggers when the user reads from /dev/hwrng into memory also mmap-ed from /dev/hwrng. The resulting page fault triggers a recursive read which then dead-locks.

Fix this by using a stack buffer when calling copytouser.(CVE-2023-52615)

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

netfilter: nf_tables: disallow timeout for anonymous sets

Never used from userspace, disallow these parameters.(CVE-2023-52620)

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

SUNRPC: Fix a suspicious RCU usage warning

I received the following warning while running cthon against an ontap server running pNFS:

[ 57.202521] ============================= [ 57.202522] WARNING: suspicious RCU usage [ 57.202523] 6.7.0-rc3-g2cc14f52aeb7 #41492 Not tainted [ 57.202525] ----------------------------- [ 57.202525] net/sunrpc/xprtmultipath.c:349 RCU-list traversed in non-reader section!! [ 57.202527] other info that might help us debug this:

[ 57.202528] rcuscheduleractive = 2, debuglocks = 1 [ 57.202529] no locks held by test5/3567. [ 57.202530] stack backtrace: [ 57.202532] CPU: 0 PID: 3567 Comm: test5 Not tainted 6.7.0-rc3-g2cc14f52aeb7 #41492 5b09971b4965c0aceba19f3eea324a4a806e227e [ 57.202534] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 2/2/2022 [ 57.202536] Call Trace: [ 57.202537] <TASK> [ 57.202540] dumpstacklvl+0x77/0xb0 [ 57.202551] lockdeprcususpicious+0x154/0x1a0 [ 57.202556] rpcxprtswitchhasaddr+0x17c/0x190 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202596] rpcclntsetuptestandaddxprt+0x50/0x180 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202621] ? rpcclntaddxprt+0x254/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202646] rpcclntaddxprt+0x27a/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202671] ? _pfxrpcclntsetuptestandaddxprt+0x10/0x10 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202696] nfs4pnfsdsconnect+0x345/0x760 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202728] ? _pfxnfs4testsessiontrunk+0x10/0x10 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202754] nfs4flprepareds+0x75/0xc0 [nfslayoutnfsv41files e3a4187f18ae8a27b630f9feae6831b584a9360a] [ 57.202760] filelayoutwritepagelist+0x4a/0x200 [nfslayoutnfsv41files e3a4187f18ae8a27b630f9feae6831b584a9360a] [ 57.202765] pnfsgenericpgwritepages+0xbe/0x230 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202788] _nfspageioaddrequest+0x3fd/0x520 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202813] nfspageioaddrequest+0x18b/0x390 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202831] nfsdowritepage+0x116/0x1e0 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202849] nfswritepagescallback+0x13/0x30 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202866] writecachepages+0x265/0x450 [ 57.202870] ? _pfxnfswritepagescallback+0x10/0x10 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202891] nfswritepages+0x141/0x230 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202913] dowritepages+0xd2/0x230 [ 57.202917] ? filemapfdatawritewbc+0x5c/0x80 [ 57.202921] filemapfdatawritewbc+0x67/0x80 [ 57.202924] filemapwriteandwaitrange+0xd9/0x170 [ 57.202930] nfswball+0x49/0x180 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202947] nfs4fileflush+0x72/0xb0 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202969] _sesysclose+0x46/0xd0 [ 57.202972] dosyscall64+0x68/0x100 [ 57.202975] ? dosyscall64+0x77/0x100 [ 57.202976] ? dosyscall64+0x77/0x100 [ 57.202979] entrySYSCALL64afterhwframe+0x6e/0x76 [ 57.202982] RIP: 0033:0x7fe2b12e4a94 [ 57.202985] Code: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 80 3d d5 18 0e 00 00 74 13 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 44 c3 0f 1f 00 48 83 ec 18 89 7c 24 0c e8 c3 [ 57.202987] RSP: 002b:00007ffe857ddb38 EFLAGS: 00000202 ORIGRAX: 0000000000000003 [ 57.202989] RAX: ffffffffffffffda RBX: 00007ffe857dfd68 RCX: 00007fe2b12e4a94 [ 57.202991] RDX: 0000000000002000 RSI: 00007ffe857ddc40 RDI: 0000000000000003 [ 57.202992] RBP: 00007ffe857dfc50 R08: 7fffffffffffffff R09: 0000000065650f49 [ 57.202993] R10: 00007f ---truncated---(CVE-2023-52623)

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

sh: push-switch: Reorder cleanup operations to avoid use-after-free bug

The original code puts flushwork() before timershutdownsync() in switchdrvremove(). Although we use flushwork() to stop the worker, it could be rescheduled in switch_timer(). As a result, a use-after-free bug can occur. The details are shown below:

  (cpu 0)                    |      (cpu 1)

switchdrvremove() | flushwork() | ... | switchtimer // timer | schedulework(&psw->work) timershutdownsync() | ... | switchwork_handler // worker kfree(psw) // free | | psw->state = 0 // use

This patch puts timershutdownsync() before flush_work() to mitigate the bugs. As a result, the worker and timer will be stopped safely before the deallocate operations.(CVE-2023-52629)

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

PM / devfreq: Synchronize devfreqmonitor[start/stop]

There is a chance if a frequent switch of the governor done in a loop result in timer list corruption where timer cancel being done from two place one from canceldelayedworksync() and followed by expiretimers() can be seen from the traces[1].

while true do echo "simple_ondemand" > /sys/class/devfreq/1d84000.ufshc/governor echo "performance" > /sys/class/devfreq/1d84000.ufshc/governor done

It looks to be issue with devfreq driver where devicemonitor[start/stop] need to synchronized so that delayed work should get corrupted while it is either being queued or running or being cancelled.

Let's use polling flag and devfreq lock to synchronize the queueing the timer instance twice and work data being corrupted.

[1] ... .. <idle>-0 [003] 9436.209662: timercancel timer=0xffffff80444f0428 <idle>-0 [003] 9436.209664: timerexpireentry timer=0xffffff80444f0428 now=0x10022da1c function=typeidZTSFvP10timerlistEglobaladdr baseclk=0x10022da1c <idle>-0 [003] 9436.209718: timerexpireexit timer=0xffffff80444f0428 kworker/u16:6-14217 [003] 9436.209863: timerstart timer=0xffffff80444f0428 function=typeidZTSFvP10timerlistEglobaladdr expires=0x10022da2b now=0x10022da1c flags=182452227 vendor.xxxyyy.ha-1593 [004] 9436.209888: timercancel timer=0xffffff80444f0428 vendor.xxxyyy.ha-1593 [004] 9436.216390: timerinit timer=0xffffff80444f0428 vendor.xxxyyy.ha-1593 [004] 9436.216392: timerstart timer=0xffffff80444f0428 function=typeidZTSFvP10timerlistEglobaladdr expires=0x10022da2c now=0x10022da1d flags=186646532 vendor.xxxyyy.ha-1593 [005] 9436.220992: timercancel timer=0xffffff80444f0428 xxxyyyTraceManag-7795 [004] 9436.261641: timercancel timer=0xffffff80444f0428

[2]

9436.261653][ C4] Unable to handle kernel paging request at virtual address dead00000000012a [ 9436.261664][ C4] Mem abort info: [ 9436.261666][ C4] ESR = 0x96000044 [ 9436.261669][ C4] EC = 0x25: DABT (current EL), IL = 32 bits [ 9436.261671][ C4] SET = 0, FnV = 0 [ 9436.261673][ C4] EA = 0, S1PTW = 0 [ 9436.261675][ C4] Data abort info: [ 9436.261677][ C4] ISV = 0, ISS = 0x00000044 [ 9436.261680][ C4] CM = 0, WnR = 1 [ 9436.261682][ C4] [dead00000000012a] address between user and kernel address ranges [ 9436.261685][ C4] Internal error: Oops: 96000044 [#1] PREEMPT SMP [ 9436.261701][ C4] Skip md ftrace buffer dump for: 0x3a982d0 ...

[ 9436.262138][ C4] CPU: 4 PID: 7795 Comm: TraceManag Tainted: G S W O 5.10.149-android12-9-o-g17f915d29d0c #1 [ 9436.262141][ C4] Hardware name: Qualcomm Technologies, Inc. (DT) [ 9436.262144][ C4] pstate: 22400085 (nzCv daIf +PAN -UAO +TCO BTYPE=--) [ 9436.262161][ C4] pc : expiretimers+0x9c/0x438 [ 9436.262164][ C4] lr : expiretimers+0x2a4/0x438 [ 9436.262168][ C4] sp : ffffffc010023dd0 [ 9436.262171][ C4] x29: ffffffc010023df0 x28: ffffffd0636fdc18 [ 9436.262178][ C4] x27: ffffffd063569dd0 x26: ffffffd063536008 [ 9436.262182][ C4] x25: 0000000000000001 x24: ffffff88f7c69280 [ 9436.262185][ C4] x23: 00000000000000e0 x22: dead000000000122 [ 9436.262188][ C4] x21: 000000010022da29 x20: ffffff8af72b4e80 [ 9436.262191][ C4] x19: ffffffc010023e50 x18: ffffffc010025038 [ 9436.262195][ C4] x17: 0000000000000240 x16: 0000000000000201 [ 9436.262199][ C4] x15: ffffffffffffffff x14: ffffff889f3c3100 [ 9436.262203][ C4] x13: ffffff889f3c3100 x12: 00000000049f56b8 [ 9436.262207][ C4] x11: 00000000049f56b8 x10: 00000000ffffffff [ 9436.262212][ C4] x9 : ffffffc010023e50 x8 : dead000000000122 [ 9436.262216][ C4] x7 : ffffffffffffffff x6 : ffffffc0100239d8 [ 9436.262220][ C4] x5 : 0000000000000000 x4 : 0000000000000101 [ 9436.262223][ C4] x3 : 0000000000000080 x2 : ffffff8 ---truncated---(CVE-2023-52635)

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

can: j1939: Fix UAF in j1939skmatchfilter during setsockopt(SOJ1939_FILTER)

Lock jsk->sk to prevent UAF when setsockopt(..., SOJ1939FILTER, ...) modifies jsk->filters while receiving packets.

Following trace was seen on affected system: ================================================================== BUG: KASAN: slab-use-after-free in j1939skrecvmatchone+0x1af/0x2d0 [can_j1939] Read of size 4 at addr ffff888012144014 by task j1939/350

CPU: 0 PID: 350 Comm: j1939 Tainted: G W OE 6.5.0-rc5 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: printreport+0xd3/0x620 ? kasancompletemodereportinfo+0x7d/0x200 ? j1939skrecvmatchone+0x1af/0x2d0 [canj1939] kasanreport+0xc2/0x100 ? j1939skrecvmatchone+0x1af/0x2d0 [canj1939] asanload4+0x84/0xb0 j1939skrecvmatchone+0x1af/0x2d0 [canj1939] j1939skrecv+0x20b/0x320 [canj1939] ? _kasancheckwrite+0x18/0x20 ? _pfxj1939skrecv+0x10/0x10 [canj1939] ? j1939simplerecv+0x69/0x280 [canj1939] ? j1939acrecv+0x5e/0x310 [canj1939] j1939canrecv+0x43f/0x580 [canj1939] ? _pfxj1939canrecv+0x10/0x10 [canj1939] ? rawrcv+0x42/0x3c0 [canraw] ? _pfxj1939canrecv+0x10/0x10 [canj1939] canrcvfilter+0x11f/0x350 [can] canreceive+0x12f/0x190 [can] ? _pfxcanrcv+0x10/0x10 [can] canrcv+0xdd/0x130 [can] ? _pfxcanrcv+0x10/0x10 [can] _netifreceiveskbonecore+0x13d/0x150 ? _pfxnetifreceiveskbonecore+0x10/0x10 ? kasancheckwrite+0x18/0x20 ? _rawspinlockirq+0x8c/0xe0 _netifreceiveskb+0x23/0xb0 processbacklog+0x107/0x260 _napipoll+0x69/0x310 netrxaction+0x2a1/0x580 ? _pfxnetrxaction+0x10/0x10 ? _pfxrawspinlock+0x10/0x10 ? handleirqevent+0x7d/0xa0 _dosoftirq+0xf3/0x3f8 dosoftirq+0x53/0x80 </IRQ> <TASK> _localbhenableip+0x6e/0x70 netifrx+0x16b/0x180 cansend+0x32b/0x520 [can] ? _pfxcansend+0x10/0x10 [can] ? _checkobjectsize+0x299/0x410 rawsendmsg+0x572/0x6d0 [canraw] ? _pfxrawsendmsg+0x10/0x10 [canraw] ? apparmorsocketsendmsg+0x2f/0x40 ? _pfxrawsendmsg+0x10/0x10 [canraw] socksendmsg+0xef/0x100 sockwriteiter+0x162/0x220 ? _pfxsockwriteiter+0x10/0x10 ? _rtnlunlock+0x47/0x80 ? securityfilepermission+0x54/0x320 vfswrite+0x6ba/0x750 ? _pfxvfswrite+0x10/0x10 ? _fgetlight+0x1ca/0x1f0 ? _rcureadunlock+0x5b/0x280 ksyswrite+0x143/0x170 ? _pfxksyswrite+0x10/0x10 ? _kasancheckread+0x15/0x20 ? fpregsassertstateconsistent+0x62/0x70 _x64syswrite+0x47/0x60 dosyscall64+0x60/0x90 ? dosyscall64+0x6d/0x90 ? irqentryexit+0x3f/0x50 ? excpagefault+0x79/0xf0 entrySYSCALL64afterhwframe+0x6e/0xd8

Allocated by task 348: kasansavestack+0x2a/0x50 kasansettrack+0x29/0x40 kasansaveallocinfo+0x1f/0x30 _kasankmalloc+0xb5/0xc0 _kmallocnodetrackcaller+0x67/0x160 j1939sksetsockopt+0x284/0x450 [canj1939] _syssetsockopt+0x15c/0x2f0 _x64syssetsockopt+0x6b/0x80 dosyscall64+0x60/0x90 entrySYSCALL64after_hwframe+0x6e/0xd8

Freed by task 349: kasansavestack+0x2a/0x50 kasansettrack+0x29/0x40 kasansavefreeinfo+0x2f/0x50 _kasanslabfree+0x12e/0x1c0 _kmemcachefree+0x1b9/0x380 kfree+0x7a/0x120 j1939sksetsockopt+0x3b2/0x450 [canj1939] _syssetsockopt+0x15c/0x2f0 _x64syssetsockopt+0x6b/0x80 dosyscall64+0x60/0x90 entrySYSCALL64after_hwframe+0x6e/0xd8(CVE-2023-52637)

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

can: j1939: prevent deadlock by changing j1939sockslock to rwlock

The following 3 locks would race against each other, causing the deadlock situation in the Syzbot bug report:

• j1939sockslock
• activesessionlist_lock
• sksessionqueue_lock

A reasonable fix is to change j1939sockslock to an rwlock, since in the rare situations where a write lock is required for the linked list that j1939sockslock is protecting, the code does not attempt to acquire any more locks. This would break the circular lock dependency, where, for example, the current thread already locks j1939sockslock and attempts to acquire sksessionqueuelock, and at the same time, another thread attempts to acquire j1939sockslock while holding sksessionqueuelock.

NOTE: This patch along does not fix the unregister_netdevice bug reported by Syzbot; instead, it solves a deadlock situation to prepare for one or more further patches to actually fix the Syzbot bug, which appears to be a reference counting problem within the j1939 codebase.

mkl: remove unrelated newline change

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

KVM: s390: vsie: fix race during shadow creation

Right now it is possible to see gmap->private being zero in kvms390vsiegmapnotifier resulting in a crash. This is due to the fact that we add gmap->private == kvm after creation:

static int acquiregmapshadow(struct kvmvcpu *vcpu, struct vsiepage *vsiepage) { [...] gmap = gmapshadow(vcpu->arch.gmap, asce, edat); if (ISERR(gmap)) return PTRERR(gmap); gmap->private = vcpu->kvm;

Let children inherit the private field of the parent.(CVE-2023-52639)

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

media: rc: bpf attach/detach requires write permission

Note that bpf attach/detach also requires CAPNETADMIN.(CVE-2023-52642)

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

wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled

When QoS is disabled, the queue priority value will not map to the correct ieee80211 queue since there is only one queue. Stop/wake queue 0 when QoS is disabled to prevent trying to stop/wake a non-existent queue and failing to stop/wake the actual queue instantiated.

Log of issue before change (with kernel parameter qos=0): [ +5.112651] ------------[ cut here ]------------ [ +0.000005] WARNING: CPU: 7 PID: 25513 at net/mac80211/util.c:449 ieee80211wakequeue+0xd5/0x180 [mac80211] [ +0.000067] Modules linked in: b43(O) sndseqdummy sndhrtimer sndseq sndseqdevice nftchainnat xtMASQUERADE nfnat xfrmuser xfrmalgo xtaddrtype overlay ccm afpacket amdgpu sndhdacodeccirrus sndhdacodecgeneric ledtrigaudio drmexec amdxcp gpusched xtconntrack nfconntrack nfdefragipv6 nfdefragipv4 ip6trpfilter iptrpfilter xtpkttype xtLOG nflogsyslog xttcpudp nftcompat nftables nfnetlink schfqcodel btusb uinput iTCOwdt ctr btrtl intelpmcbxt i915 intelraplmsr meihdcp meipxp joydev at24 watchdog btintel atkbd libps2 serio radeon btbcm vivaldifmap btmtk intelraplcommon sndhdacodechdmi bluetooth uvcvideo nlsiso88591 applesmc nlscp437 x86pkgtempthermal sndhdaintel intelpowerclamp vfat videobuf2vmalloc coretemp fat sndinteldspcfg crc32pclmul uvc polyvalclmulni sndintelsdwacpi loop videobuf2memops sndhdacodec tun drmsuballochelper polyvalgeneric drmttmhelper drmbuddy tap ecdhgeneric videobuf2v4l2 gf128mul macvlan ttm ghashclmulniintel ecc tg3 [ +0.000044] videodev bridge sndhdacore rapl crc16 drmdisplayhelper cec mousedev sndhwdep evdev intelcstate bcm5974 hidappleir videobuf2common stp machid libphy sndpcm drmkmshelper acpials meime inteluncore llc mc sndtimer intelgtt industrialiotriggeredbuffer applemfifastcharge i2ci801 mei snd lpcich agpgart ptp i2csmbus thunderbolt applegmux i2calgobit kfifobuf video industrialio soundcore ppscore wmi tinypowerbutton sbs sbshc button ac cordic bcma mac80211 cfg80211 ssb rfkill libarc4 kvmintel kvm drm irqbypass fuse backlight firmwareclass efipstore configfs efivarfs dmisysfs iptables xtables autofs4 dmcrypt cbc encryptedkeys trusted asn1encoder tee tpm rngcore inputleds hidapple ledclass hidgeneric usbhid hid sdmod t10pi crc64rocksoft crc64 crct10dif crct10difgeneric ahci libahci libata uhcihcd ehcipci ehcihcd crct10difpclmul crct10difcommon sha512ssse3 sha512generic sha256ssse3 sha1ssse3 aesniintel usbcore scsimod libaes cryptosimd cryptd scsicommon [ +0.000055] usbcommon rtccmos btrfs blake2bgeneric libcrc32c crc32cgeneric crc32cintel xor raid6pq dmsnapshot dmbufio dmmod dax [last unloaded: b43(O)] [ +0.000009] CPU: 7 PID: 25513 Comm: irq/17-b43 Tainted: G W O 6.6.7 #1-NixOS [ +0.000003] Hardware name: Apple Inc. MacBookPro8,3/Mac-942459F5819B171B, BIOS 87.0.0.0.0 06/13/2019 [ +0.000001] RIP: 0010:ieee80211wake_queue+0xd5/0x180 [mac80211] [ +0.000046] Code: 00 45 85 e4 0f 85 9b 00 00 00 48 8d bd 40 09 00 00 f0 48 0f ba ad 48 09 00 00 00 72 0f 5b 5d 41 5c 41 5d 41 5e e9 cb 6d 3c d0 <0f> 0b 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8d b4 16 94 00 00 [ +0.000002] RSP: 0018:ffffc90003c77d60 EFLAGS: 00010097 [ +0.000001] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000 [ +0.000001] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88820b924900 [ +0.000002] RBP: ffff88820b924900 R08: ffffc90003c77d90 R09: 000000000003bfd0 [ +0.000001] R10: ffff88820b924900 R11: ffffc90003c77c68 R12: 0000000000000000 [ +0.000001] R13: 0000000000000000 R14: ffffc90003c77d90 R15: ffffffffc0fa6f40 [ +0.000001] FS: 0000000000000000(0000) GS:ffff88846fb80000(0000) knlGS:0000000000000000 [ +0.000001] CS: 0010 DS: 0 ---truncated---(CVE-2023-52644)

A flaw was found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmdcfgpkts() function improperly updates the refcnt on struct net_device, and a use-after-free can be triggered by racing between the free on the struct and the access through the skbtxq global queue. This could lead to a denial of service condition or potential code execution.(CVE-2023-6270)

A race condition was found in the Linux kernel's net/bluetooth in {conn,adv}{min,max}interval_set() function. This can result in I2cap connection or broadcast abnormality issue, possibly leading to denial of service.

(CVE-2024-24858)

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

tcp: make sure init the accept_queue's spinlocks once

When I run syz's reproduction C program locally, it causes the following issue: pvqspinlock: lock 0xffff9d181cd5c660 has corrupted value 0x0! WARNING: CPU: 19 PID: 21160 at pvqueuedspinunlockslowpath (kernel/locking/qspinlockparavirt.h:508) Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:pvqueuedspinunlockslowpath (kernel/locking/qspinlockparavirt.h:508) Code: 73 56 3a ff 90 c3 cc cc cc cc 8b 05 bb 1f 48 01 85 c0 74 05 c3 cc cc cc cc 8b 17 48 89 fe 48 c7 c7 30 20 ce 8f e8 ad 56 42 ff <0f> 0b c3 cc cc cc cc 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffa8d200604cb8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9d1ef60e0908 RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9d1ef60e0900 RBP: ffff9d181cd5c280 R08: 0000000000000000 R09: 00000000ffff7fff R10: ffffa8d200604b68 R11: ffffffff907dcdc8 R12: 0000000000000000 R13: ffff9d181cd5c660 R14: ffff9d1813a3f330 R15: 0000000000001000 FS: 00007fa110184640(0000) GS:ffff9d1ef60c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000000 CR3: 000000011f65e000 CR4: 00000000000006f0 Call Trace: <IRQ> rawspinunlock (kernel/locking/spinlock.c:186) inetcskreqskqueueadd (net/ipv4/inetconnectionsock.c:1321) inetcskcompletehashdance (net/ipv4/inetconnectionsock.c:1358) tcpcheckreq (net/ipv4/tcpminisocks.c:868) tcpv4rcv (net/ipv4/tcpipv4.c:2260) ipprotocoldeliverrcu (net/ipv4/ipinput.c:205) iplocaldeliverfinish (net/ipv4/ipinput.c:234) _netifreceiveskbonecore (net/core/dev.c:5529) processbacklog (./include/linux/rcupdate.h:779) _napipoll (net/core/dev.c:6533) netrxaction (net/core/dev.c:6604) _dosoftirq (./arch/x86/include/asm/jumplabel.h:27) dosoftirq (kernel/softirq.c:454 kernel/softirq.c:441) </IRQ> <TASK> _localbhenableip (kernel/softirq.c:381) _devqueuexmit (net/core/dev.c:4374) ipfinishoutput2 (./include/net/neighbour.h:540 net/ipv4/ipoutput.c:235) _ipqueuexmit (net/ipv4/ipoutput.c:535) _tcptransmitskb (net/ipv4/tcpoutput.c:1462) tcprcvsynsentstateprocess (net/ipv4/tcpinput.c:6469) tcprcvstateprocess (net/ipv4/tcpinput.c:6657) tcpv4dorcv (net/ipv4/tcpipv4.c:1929) _releasesock (./include/net/sock.h:1121 net/core/sock.c:2968) releasesock (net/core/sock.c:3536) inetwaitforconnect (net/ipv4/afinet.c:609) _inetstreamconnect (net/ipv4/afinet.c:702) inetstreamconnect (net/ipv4/afinet.c:748) _sysconnect (./include/linux/file.h:45 net/socket.c:2064) _x64sysconnect (net/socket.c:2073 net/socket.c:2070 net/socket.c:2070) dosyscall64 (arch/x86/entry/common.c:51 arch/x86/entry/common.c:82) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:129) RIP: 0033:0x7fa10ff05a3d Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ab a3 0e 00 f7 d8 64 89 01 48 RSP: 002b:00007fa110183de8 EFLAGS: 00000202 ORIGRAX: 000000000000002a RAX: ffffffffffffffda RBX: 0000000020000054 RCX: 00007fa10ff05a3d RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003 RBP: 00007fa110183e20 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00007fa110184640 R13: 0000000000000000 R14: 00007fa10fe8b060 R15: 00007fff73e23b20 </TASK>

The issue triggering process is analyzed as follows: Thread A Thread B tcpv4rcv //receive ack TCP packet inetshutdown tcpcheckreq tcpdisconnect //disconnect sock ... tcpsetstate(sk, TCPCLOSE) inetcskcompletehashdance ... inetcskreqskqueueadd
---truncated---(CVE-2024-26614)

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

netfilter: nf_tables: disallow anonymous set with timeout flag

Anonymous sets are never used with timeout from userspace, reject this. Exception to this rule is NFTSETEVAL to ensure legacy meters still work.(CVE-2024-26642)

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

tracing: Ensure visibility when inserting an element into tracing_map

Running the following two commands in parallel on a multi-processor AArch64 machine can sporadically produce an unexpected warning about duplicate histogram entries:

$ while true; do echo hist:key=id.syscall:val=hitcount > \ /sys/kernel/debug/tracing/events/rawsyscalls/sysenter/trigger cat /sys/kernel/debug/tracing/events/rawsyscalls/sysenter/hist sleep 0.001 done $ stress-ng --sysbadaddr $(nproc)

The warning looks as follows:

[ 2911.172474] ------------[ cut here ]------------ [ 2911.173111] Duplicates detected: 1 [ 2911.173574] WARNING: CPU: 2 PID: 12247 at kernel/trace/tracingmap.c:983 tracingmapsortentries+0x3e0/0x408 [ 2911.174702] Modules linked in: iscsiibft(E) iscsibootsysfs(E) rfkill(E) afpacket(E) nlsiso88591(E) nlscp437(E) vfat(E) fat(E) ena(E) tinypowerbutton(E) qemufwcfg(E) button(E) fuse(E) efipstore(E) iptables(E) xtables(E) xfs(E) libcrc32c(E) aesceblk(E) aescecipher(E) crct10difce(E) polyvalce(E) polyvalgeneric(E) ghashce(E) gf128mul(E) sm4cegcm(E) sm4ceccm(E) sm4ce(E) sm4cecipher(E) sm4(E) sm3ce(E) sm3(E) sha3ce(E) sha512ce(E) sha512arm64(E) sha2ce(E) sha256arm64(E) nvme(E) sha1ce(E) nvmecore(E) nvmeauth(E) t10pi(E) sg(E) scsimod(E) scsicommon(E) efivarfs(E) [ 2911.174738] Unloaded tainted modules: cppccpufreq(E):1 [ 2911.180985] CPU: 2 PID: 12247 Comm: cat Kdump: loaded Tainted: G E 6.7.0-default #2 1b58bbb22c97e4399dc09f92d309344f69c44a01 [ 2911.182398] Hardware name: Amazon EC2 c7g.8xlarge/, BIOS 1.0 11/1/2018 [ 2911.183208] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2911.184038] pc : tracingmapsortentries+0x3e0/0x408 [ 2911.184667] lr : tracingmapsortentries+0x3e0/0x408 [ 2911.185310] sp : ffff8000a1513900 [ 2911.185750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27: 0000000000000001 [ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 0000000000000008 [ 2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180 [ 2911.188310] x20: ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff [ 2911.189160] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000a15134b8 [ 2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12: 5b5d313131333731 [ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c [ 2911.191716] x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 000000000057ffa8 [ 2911.192554] x5 : ffff0012f6c24ec0 x4 : 0000000000000000 x3 : ffff2e5b72b5d000 [ 2911.193404] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0003ff254480 [ 2911.194259] Call trace: [ 2911.194626] tracingmapsortentries+0x3e0/0x408 [ 2911.195220] histshow+0x124/0x800 [ 2911.195692] seqreaditer+0x1d4/0x4e8 [ 2911.196193] seqread+0xe8/0x138 [ 2911.196638] vfsread+0xc8/0x300 [ 2911.197078] ksysread+0x70/0x108 [ 2911.197534] _arm64sysread+0x24/0x38 [ 2911.198046] invokesyscall+0x78/0x108 [ 2911.198553] el0svccommon.constprop.0+0xd0/0xf8 [ 2911.199157] doel0svc+0x28/0x40 [ 2911.199613] el0svc+0x40/0x178 [ 2911.200048] el0t64synchandler+0x13c/0x158 [ 2911.200621] el0t64_sync+0x1a8/0x1b0 [ 2911.201115] ---[ end trace 0000000000000000 ]---

The problem appears to be caused by CPU reordering of writes issued from _tracingmap_insert().

The check for the presence of an element with a given key in this function is:

val = READONCE(entry->val); if (val && keysmatch(key, val->key, map->key_size)) ...

The write of a new entry is:

elt = getfreeelt(map); memcpy(elt->key, key, map->key_size); entry->val = elt;

The "memcpy(elt->key, key, map->key_size);" and "entry->val = elt;" stores may become visible in the reversed order on another CPU. This second CPU might then incorrectly determine that a new key doesn't match an already present val->key and subse ---truncated---(CVE-2024-26645)

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

netfilter: nft_limit: reject configurations that cause integer overflow

Reject bogus configs where internal token counter wraps around. This only occurs with very very large requests, such as 17gbyte/s.

Its better to reject this rather than having incorrect ratelimit.(CVE-2024-26668)

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

blk-mq: fix IO hang from sbitmap wakeup race

In blkmqmarktagwait(), _addwaitqueue() may be re-ordered with the following blkmqgetdriver_tag() in case of getting driver tag failure.

Then in _sbitmapqueuewakeup(), waitqueueactive() may not observe the added waiter in blkmqmarktagwait() and wake up nothing, meantime blkmqmarktag_wait() can't get driver tag successfully.

This issue can be reproduced by running the following test in loop, and fio hang can be observed in < 30min when running it on my test VM in laptop.

modprobe -r scsi_debug
modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4
dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename`
fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --iodepth=1 \
        --runtime=100 --numjobs=40 --time_based --name=test \
        --ioengine=libaio

Fix the issue by adding one explicit barrier in blkmqmarktagwait(), which is just fine in case of running out of tag.(CVE-2024-26671)

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

ppp_async: limit MRU to 64K

syzbot triggered a warning [1] in _allocpages():

WARNONONCEGFP(order > MAXPAGE_ORDER, gfp)

Willem fixed a similar issue in commit c0a2a1b0d631 ("ppp: limit MRU to 64K")

Adopt the same sanity check for pppasyncioctl(PPPIOCSMRU)

[1]:

WARNING: CPU: 1 PID: 11 at mm/pagealloc.c:4543 _allocpages+0x308/0x698 mm/pagealloc.c:4543 Modules linked in: CPU: 1 PID: 11 Comm: kworker/u4:0 Not tainted 6.8.0-rc2-syzkaller-g41bccc98fb79 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 Workqueue: eventsunbound flushtoldisc pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : _allocpages+0x308/0x698 mm/pagealloc.c:4543 lr : _allocpages+0xc8/0x698 mm/pagealloc.c:4537 sp : ffff800093967580 x29: ffff800093967660 x28: ffff8000939675a0 x27: dfff800000000000 x26: ffff70001272ceb4 x25: 0000000000000000 x24: ffff8000939675c0 x23: 0000000000000000 x22: 0000000000060820 x21: 1ffff0001272ceb8 x20: ffff8000939675e0 x19: 0000000000000010 x18: ffff800093967120 x17: ffff800083bded5c x16: ffff80008ac97500 x15: 0000000000000005 x14: 1ffff0001272cebc x13: 0000000000000000 x12: 0000000000000000 x11: ffff70001272cec1 x10: 1ffff0001272cec0 x9 : 0000000000000001 x8 : ffff800091c91000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 00000000ffffffff x4 : 0000000000000000 x3 : 0000000000000020 x2 : 0000000000000008 x1 : 0000000000000000 x0 : ffff8000939675e0 Call trace: _allocpages+0x308/0x698 mm/pagealloc.c:4543 _allocpagesnode include/linux/gfp.h:238 [inline] allocpagesnode include/linux/gfp.h:261 [inline] _kmalloclargenode+0xbc/0x1fc mm/slub.c:3926 _dokmallocnode mm/slub.c:3969 [inline] _kmallocnodetrackcaller+0x418/0x620 mm/slub.c:4001 kmallocreserve+0x17c/0x23c net/core/skbuff.c:590 _allocskb+0x1c8/0x3d8 net/core/skbuff.c:651 _netdevallocskb+0xb8/0x3e8 net/core/skbuff.c:715 netdevallocskb include/linux/skbuff.h:3235 [inline] devallocskb include/linux/skbuff.h:3248 [inline] pppasyncinput drivers/net/ppp/pppasync.c:863 [inline] pppasyncttyreceive+0x588/0x186c drivers/net/ppp/pppasync.c:341 ttyldiscreceivebuf+0x12c/0x15c drivers/tty/ttybuffer.c:390 ttyportdefaultreceivebuf+0x74/0xac drivers/tty/ttyport.c:37 receivebuf drivers/tty/ttybuffer.c:444 [inline] flushtoldisc+0x284/0x6e4 drivers/tty/ttybuffer.c:494 processonework+0x694/0x1204 kernel/workqueue.c:2633 processscheduledworks kernel/workqueue.c:2706 [inline] workerthread+0x938/0xef4 kernel/workqueue.c:2787 kthread+0x288/0x310 kernel/kthread.c:388 retfromfork+0x10/0x20 arch/arm64/kernel/entry.S:860(CVE-2024-26675)

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

inet: read sk->skfamily once in inetrecv_error()

inetrecverror() is called without holding the socket lock.

IPv6 socket could mutate to IPv4 with IPV6_ADDRFORM socket option and trigger a KCSAN warning.(CVE-2024-26679)

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

nilfs2: fix potential bug in endbufferasync_write

According to a syzbot report, endbufferasyncwrite(), which handles the completion of block device writes, may detect abnormal condition of the buffer asyncwrite flag and cause a BUG_ON failure when using nilfs2.

Nilfs2 itself does not use endbufferasyncwrite(). But, the asyncwrite flag is now used as a marker by commit 7f42ec394156 ("nilfs2: fix issue with race condition of competition between segments for dirty blocks") as a means of resolving double list insertion of dirty blocks in nilfslookupdirtydatabuffers() and nilfslookupnode_buffers() and the resulting crash.

This modification is safe as long as it is used for file data and b-tree node blocks where the page caches are independent. However, it was irrelevant and redundant to also introduce asyncwrite for segment summary and super root blocks that share buffers with the backing device. This led to the possibility that the BUGON check in endbufferasync_write would fail as described above, if independent writebacks of the backing device occurred in parallel.

The use of async_write for segment summary buffers has already been removed in a previous change.

Fix this issue by removing the manipulation of the async_write flag for the remaining super root block buffer.(CVE-2024-26685)

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

fs/proc: dotaskstat: use sig->stats_lock to gather the threads/children stats

locktasksighand() can trigger a hard lockup. If NRCPUS threads call dotaskstat() at the same time and the process has NRTHREADS, it will spin with irqs disabled O(NRCPUS * NRTHREADS) time.

Change dotaskstat() to use sig->stats_lock to gather the statistics outside of ->siglock protected section, in the likely case this code will run lockless.(CVE-2024-26686)

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

nilfs2: fix data corruption in dsync block recovery for small block sizes

The helper function nilfsrecoverycopyblock() of nilfsrecoverydsyncblocks(), which recovers data from logs created by data sync writes during a mount after an unclean shutdown, incorrectly calculates the on-page offset when copying repair data to the file's page cache. In environments where the block size is smaller than the page size, this flaw can cause data corruption and leak uninitialized memory bytes during the recovery process.

Fix these issues by correcting this byte offset calculation on the page.(CVE-2024-26697)

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

mm/writeback: fix possible divide-by-zero in wbdirtylimits(), again

(struct dirtythrottlecontrol *)->thresh is an unsigned long, but is passed as the u32 divisor argument to div_u64(). On architectures where unsigned long is 64 bytes, the argument will be implicitly truncated.

Use div64u64() instead of divu64() so that the value used in the "is this a safe division" check is the same as the divisor.

Also, remove redundant cast of the numerator to u64, as that should happen implicitly.

This would be difficult to exploit in memcg domain, given the ratio-based arithmetic domaindritylimits() uses, but is much easier in global writeback domain with a BDICAPSTRICTLIMIT-backing device, using e.g. vm.dirtybytes=(1<<32)*PAGESIZE so that dtc->thresh == (1<<32)(CVE-2024-26720)

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

btrfs: don't drop extent_map for free space inode on write error

While running the CI for an unrelated change I hit the following panic with generic/648 on btrfsholesspacecache.

assertion failed: blockstart != EXTENTMAPHOLE, in fs/btrfs/extentio.c:1385 ------------[ cut here ]------------ kernel BUG at fs/btrfs/extentio.c:1385! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G W 6.8.0-rc2+ #1 RIP: 0010:extentwritepageio.constprop.0+0x4c1/0x5c0 Call Trace: <TASK> extentwritecachepages+0x2ac/0x8f0 extentwritepages+0x87/0x110 dowritepages+0xd5/0x1f0 filemapfdatawritewbc+0x63/0x90 _filemapfdatawriterange+0x5c/0x80 btrfsfdatawriterange+0x1f/0x50 btrfswriteoutcache+0x507/0x560 btrfswritedirtyblockgroups+0x32a/0x420 commitcowonlyroots+0x21b/0x290 btrfscommittransaction+0x813/0x1360 btrfssyncfile+0x51a/0x640 _x64sysfdatasync+0x52/0x90 dosyscall64+0x9c/0x190 entrySYSCALL64after_hwframe+0x6e/0x76

This happens because we fail to write out the free space cache in one instance, come back around and attempt to write it again. However on the second pass through we go to call btrfsgetextent() on the inode to get the extent mapping. Because this is a new block group, and with the free space inode we always search the commit root to avoid deadlocking with the tree, we find nothing and return a EXTENTMAPHOLE for the requested range.

This happens because the first time we try to write the space cache out we hit an error, and on an error we drop the extent mapping. This is normal for normal files, but the free space cache inode is special. We always expect the extent map to be correct. Thus the second time through we end up with a bogus extent map.

Since we're deprecating this feature, the most straightforward way to fix this is to simply skip dropping the extent map range for this failed range.

I shortened the test by using error injection to stress the area to make it easier to reproduce. With this patch in place we no longer panic with my error injection test.(CVE-2024-26726)

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

arp: Prevent overflow in arpreqget().

syzkaller reported an overflown write in arpreqget(). [0]

When ioctl(SIOCGARP) is issued, arpreqget() looks up an neighbour entry and copies neigh->ha to struct arpreq.arpha.sadata.

The arpha here is struct sockaddr, not struct sockaddrstorage, so the sa_data buffer is just 14 bytes.

In the splat below, 2 bytes are overflown to the next int field, arp_flags. We initialise the field just after the memcpy(), so it's not a problem.

However, when dev->addrlen is greater than 22 (e.g. MAXADDRLEN), arpnetmask is overwritten, which could be set as htonl(0xFFFFFFFFUL) in arpioctl() before calling arpreq_get().

To avoid the overflow, let's limit the max length of memcpy().

Note that commit b5f0de6df6dc ("net: dev: Convert sa_data to flexible array in struct sockaddr") just silenced syzkaller.

WARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arpreqget+0x411/0x4a0 net/ipv4/arp.c:1128 Modules linked in: CPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014 RIP: 0010:arpreqget+0x411/0x4a0 net/ipv4/arp.c:1128 Code: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb <0f> 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6 RSP: 0018:ffffc900050b7998 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88803a815000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001 RBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000 R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010 FS: 00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> arpioctl+0x33f/0x4b0 net/ipv4/arp.c:1261 inetioctl+0x314/0x3a0 net/ipv4/afinet.c:981 sockdoioctl+0xdf/0x260 net/socket.c:1204 sockioctl+0x3ef/0x650 net/socket.c:1321 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:870 [inline] _sesysioctl fs/ioctl.c:856 [inline] _x64sysioctl+0x18e/0x220 fs/ioctl.c:856 dosyscallx64 arch/x86/entry/common.c:51 [inline] dosyscall64+0x37/0x90 arch/x86/entry/common.c:81 entrySYSCALL64afterhwframe+0x64/0xce RIP: 0033:0x7f172b262b8d Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f172bf300b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f172b3abf80 RCX: 00007f172b262b8d RDX: 0000000020000000 RSI: 0000000000008954 RDI: 0000000000000003 RBP: 00007f172b2d3493 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000 </TASK>(CVE-2024-26733)

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

ipv6: sr: fix possible use-after-free and null-ptr-deref

The pernet operations structure for the subsystem must be registered before registering the generic netlink family.(CVE-2024-26735)

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

net/sched: act_mirred: don't override retval if we already lost the skb

If we're redirecting the skb, and haven't called tcfmirredforward(), yet, we need to tell the core to drop the skb by setting the retcode to SHOT. If we have called tcfmirredforward(), however, the skb is out of our hands and returning SHOT will lead to UaF.

Move the retval override to the error path which actually need it.(CVE-2024-26739)

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

net/sched: act_mirred: use the backlog for mirred ingress

The test Davide added in commit ca22da2fbd69 ("actmirred: use the backlog for nested calls to mirred ingress") hangs our testing VMs every 10 or so runs, with the familiar tcpv4rcv -> tcpv4_rcv deadlock reported by lockdep.

The problem as previously described by Davide (see Link) is that if we reverse flow of traffic with the redirect (egress -> ingress) we may reach the same socket which generated the packet. And we may still be holding its socket lock. The common solution to such deadlocks is to put the packet in the Rx backlog, rather than run the Rx path inline. Do that for all egress -> ingress reversals, not just once we started to nest mirred calls.

In the past there was a concern that the backlog indirection will lead to loss of error reporting / less accurate stats. But the current workaround does not seem to address the issue.(CVE-2024-26740)

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

RDMA/qedr: Fix qedrcreateuser_qp error flow

Avoid the following warning by making sure to free the allocated resources in case that qedrinituser_queue() fail.

-----------[ cut here ]----------- WARNING: CPU: 0 PID: 143192 at drivers/infiniband/core/rdmacore.c:874 uverbsdestroyufilehw+0xcf/0xf0 [ibuverbs] Modules linked in: tls targetcoreuser uio targetcorepscsi targetcorefile targetcoreiblock ibsrpt ibsrp scsitransportsrp nfsd nfsacl rpcsecgsskrb5 authrpcgss nfsv4 dnsresolver nfs lockd grace fscache netfs 8021q garp mrp stp llc ext4 mbcache jbd2 opavnic ibumad ibipoib sunrpc rdmaucm ibisert iscsitargetmod targetcoremod ibiser libiscsi scsitransportiscsi rdmacm iwcm ibcm hfi1 intelraplmsr intelraplcommon mgag200 qedr sbedac drmshmemhelper rdmavt x86pkgtempthermal drmkmshelper intelpowerclamp ibuverbs coretemp i2calgobit kvmintel dellwmidescriptor ipmissif sparsekeymap kvm ibcore rfkill syscopyarea sysfillrect video sysimgblt irqbypass ipmisi ipmidevintf fbsysfops rapl iTCOwdt mxmwmi iTCOvendorsupport intelcstate pcspkr dcdbas inteluncore ipmimsghandler lpcich acpipowermeter meime mei fuse drm xfs libcrc32c qede sdmod ahci libahci t10pi sg crct10difpclmul crc32pclmul crc32cintel qed libata tg3 ghashclmulniintel megaraidsas crc8 wmi [last unloaded: ibsrpt] CPU: 0 PID: 143192 Comm: firdmtaggedp Kdump: loaded Not tainted 5.14.0-408.el9.x8664 #1 Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.14.0 01/25/2022 RIP: 0010:uverbsdestroyufilehw+0xcf/0xf0 [ibuverbs] Code: 5d 41 5c 41 5d 41 5e e9 0f 26 1b dd 48 89 df e8 67 6a ff ff 49 8b 86 10 01 00 00 48 85 c0 74 9c 4c 89 e7 e8 83 c0 cb dd eb 92 <0f> 0b eb be 0f 0b be 04 00 00 00 48 89 df e8 8e f5 ff ff e9 6d ff RSP: 0018:ffffb7c6cadfbc60 EFLAGS: 00010286 RAX: ffff8f0889ee3f60 RBX: ffff8f088c1a5200 RCX: 00000000802a0016 RDX: 00000000802a0017 RSI: 0000000000000001 RDI: ffff8f0880042600 RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8f11fffd5000 R11: 0000000000039000 R12: ffff8f0d5b36cd80 R13: ffff8f088c1a5250 R14: ffff8f1206d91000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8f11d7c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000147069200e20 CR3: 00000001c7210002 CR4: 00000000001706f0 Call Trace: <TASK> ? showtraceloglvl+0x1c4/0x2df ? showtraceloglvl+0x1c4/0x2df ? ibuverbsclose+0x1f/0xb0 [ibuverbs] ? uverbsdestroyufilehw+0xcf/0xf0 [ibuverbs] ? _warn+0x81/0x110 ? uverbsdestroyufilehw+0xcf/0xf0 [ibuverbs] ? reportbug+0x10a/0x140 ? handlebug+0x3c/0x70 ? excinvalidop+0x14/0x70 ? asmexcinvalidop+0x16/0x20 ? uverbsdestroyufilehw+0xcf/0xf0 [ibuverbs] ibuverbsclose+0x1f/0xb0 [ibuverbs] _fput+0x94/0x250 taskworkrun+0x5c/0x90 doexit+0x270/0x4a0 dogroupexit+0x2d/0x90 getsignal+0x87c/0x8c0 archdosignalorrestart+0x25/0x100 ? ibuverbsioctl+0xc2/0x110 [ibuverbs] exittousermodeloop+0x9c/0x130 exittousermodeprepare+0xb6/0x100 syscallexittousermode+0x12/0x40 dosyscall64+0x69/0x90 ? syscallexitwork+0x103/0x130 ? syscallexittousermode+0x22/0x40 ? dosyscall64+0x69/0x90 ? syscallexitwork+0x103/0x130 ? syscallexittousermode+0x22/0x40 ? dosyscall64+0x69/0x90 ? dosyscall64+0x69/0x90 ? commoninterrupt+0x43/0xa0 entrySYSCALL64afterhwframe+0x72/0xdc RIP: 0033:0x1470abe3ec6b Code: Unable to access opcode bytes at RIP 0x1470abe3ec41. RSP: 002b:00007fff13ce9108 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: fffffffffffffffc RBX: 00007fff13ce9218 RCX: 00001470abe3ec6b RDX: 00007fff13ce9200 RSI: 00000000c0181b01 RDI: 0000000000000004 RBP: 00007fff13ce91e0 R08: 0000558d9655da10 R09: 0000558d9655dd00 R10: 00007fff13ce95c0 R11: 0000000000000246 R12: 00007fff13ce9358 R13: 0000000000000013 R14: 0000558d9655db50 R15: 00007fff13ce9470 </TASK> --[ end trace 888a9b92e04c5c97 ]--(CVE-2024-26743)

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

RDMA/srpt: Support specifying the srptserviceguid parameter

Make loading ibsrpt with this parameter set work. The current behavior is that setting that parameter while loading the ibsrpt kernel module triggers the following kernel crash:

BUG: kernel NULL pointer dereference, address: 0000000000000000 Call Trace: <TASK> parseone+0x18c/0x1d0 parseargs+0xe1/0x230 loadmodule+0x8de/0xa60 initmodulefromfile+0x8b/0xd0 idempotentinitmodule+0x181/0x240 _x64sysfinitmodule+0x5a/0xb0 dosyscall64+0x5f/0xe0 entrySYSCALL64afterhwframe+0x6e/0x76(CVE-2024-26744)

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

l2tp: pass correct message length to ip6appenddata

l2tpip6sendmsg needs to avoid accounting for the transport header twice when splicing more data into an already partially-occupied skbuff.

To manage this, we check whether the skbuff contains data using skbqueueempty when deciding how much data to append using ip6appenddata.

However, the code which performed the calculation was incorrect:

 ulen = len + skb_queue_empty(&sk->sk_write_queue) ? transhdrlen : 0;

...due to C operator precedence, this ends up setting ulen to transhdrlen for messages with a non-zero length, which results in corrupted packets on the wire.

Add parentheses to correct the calculation in line with the original intent.(CVE-2024-26752)

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

gtp: fix use-after-free and null-ptr-deref in gtpgenldump_pdp()

The gtpnetops pernet operations structure for the subsystem must be registered before registering the generic netlink family.

Syzkaller hit 'general protection fault in gtpgenldump_pdp' bug:

general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 1 PID: 5826 Comm: gtp Not tainted 6.8.0-rc3-std-def-alt1 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014 RIP: 0010:gtpgenldumppdp+0x1be/0x800 [gtp] Code: c6 89 c6 e8 64 e9 86 df 58 45 85 f6 0f 85 4e 04 00 00 e8 c5 ee 86 df 48 8b 54 24 18 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 de 05 00 00 48 8b 44 24 18 4c 8b 30 4c 39 f0 74 RSP: 0018:ffff888014107220 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff88800fcda588 R14: 0000000000000001 R15: 0000000000000000 FS: 00007f1be4eb05c0(0000) GS:ffff88806ce80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1be4e766cf CR3: 000000000c33e000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? showregs+0x90/0xa0 ? dieaddr+0x50/0xd0 ? excgeneralprotection+0x148/0x220 ? asmexcgeneralprotection+0x22/0x30 ? gtpgenldumppdp+0x1be/0x800 [gtp] ? allocskb+0x1dd/0x350 ? _pfxallocskb+0x10/0x10 genldumpit+0x11d/0x230 netlinkdump+0x5b9/0xce0 ? lockdephardirqsonprepare+0x253/0x430 ? _pfxnetlinkdump+0x10/0x10 ? kasansavetrack+0x10/0x40 ? _kasankmalloc+0x9b/0xa0 ? genlstart+0x675/0x970 _netlinkdumpstart+0x6fc/0x9f0 genlfamilyrcvmsgdumpit+0x1bb/0x2d0 ? _pfxgenlfamilyrcvmsgdumpit+0x10/0x10 ? genlopfromsmall+0x2a/0x440 ? capcapable+0x1d0/0x240 ? _pfxgenlstart+0x10/0x10 ? _pfxgenldumpit+0x10/0x10 ? _pfxgenldone+0x10/0x10 ? security_capable+0x9d/0xe0(CVE-2024-26754)

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

dm-crypt: don't modify the data when using authenticated encryption

It was said that authenticated encryption could produce invalid tag when the data that is being encrypted is modified [1]. So, fix this problem by copying the data into the clone bio first and then encrypt them inside the clone bio.

This may reduce performance, but it is needed to prevent the user from corrupting the device by writing data with O_DIRECT and modifying them at the same time.

[1] https://lore.kernel.org/all/20240207004723.GA35324@sol.localdomain/T/(CVE-2024-26763)

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

btrfs: dev-replace: properly validate device names

There's a syzbot report that device name buffers passed to device replace are not properly checked for string termination which could lead to a read out of bounds in getname_kernel().

Add a helper that validates both source and target device name buffers. For devid as the source initialize the buffer to empty string in case something tries to read it later.

This was originally analyzed and fixed in a different way by Edward Adam Davis (see links).(CVE-2024-26791)

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

gtp: fix use-after-free and null-ptr-deref in gtp_newlink()

The gtplinkops operations structure for the subsystem must be registered after registering the gtpnetops pernet operations structure.

Syzkaller hit 'general protection fault in gtpgenldump_pdp' bug:

[ 1010.702740] gtp: GTP module unloaded [ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI [ 1010.715888] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] [ 1010.715895] CPU: 1 PID: 128616 Comm: a.out Not tainted 6.8.0-rc6-std-def-alt1 #1 [ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014 [ 1010.715908] RIP: 0010:gtpnewlink+0x4d7/0x9c0 [gtp] [ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00 [ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203 [ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000000 [ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282 [ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000 [ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80 [ 1010.715947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000400 [ 1010.715953] FS: 00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000 [ 1010.715958] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0 [ 1010.715968] PKRU: 55555554 [ 1010.715972] Call Trace: [ 1010.715985] ? diebody.cold+0x1a/0x1f [ 1010.715995] ? dieaddr+0x43/0x70 [ 1010.716002] ? excgeneralprotection+0x199/0x2f0 [ 1010.716016] ? asmexcgeneralprotection+0x1e/0x30 [ 1010.716026] ? gtpnewlink+0x4d7/0x9c0 [gtp] [ 1010.716034] ? gtpnetexit+0x150/0x150 [gtp] [ 1010.716042] _rtnlnewlink+0x1063/0x1700 [ 1010.716051] ? rtnlsetlink+0x3c0/0x3c0 [ 1010.716063] ? isbpftextaddress+0xc0/0x1f0 [ 1010.716070] ? kerneltextaddress.part.0+0xbb/0xd0 [ 1010.716076] ? _kerneltextaddress+0x56/0xa0 [ 1010.716084] ? unwindgetreturnaddress+0x5a/0xa0 [ 1010.716091] ? createprofcpumask+0x30/0x30 [ 1010.716098] ? archstackwalk+0x9e/0xf0 [ 1010.716106] ? stacktracesave+0x91/0xd0 [ 1010.716113] ? stacktraceconsumeentry+0x170/0x170 [ 1010.716121] ? _lockacquire+0x15c5/0x5380 [ 1010.716139] ? markheldlocks+0x9e/0xe0 [ 1010.716148] ? kmemcachealloctrace+0x35f/0x3c0 [ 1010.716155] ? _rtnlnewlink+0x1700/0x1700 [ 1010.716160] rtnlnewlink+0x69/0xa0 [ 1010.716166] rtnetlinkrcvmsg+0x43b/0xc50 [ 1010.716172] ? rtnlfdbdump+0x9f0/0x9f0 [ 1010.716179] ? lockacquire+0x1fe/0x560 [ 1010.716188] ? netlinkdelivertap+0x12f/0xd50 [ 1010.716196] netlinkrcvskb+0x14d/0x440 [ 1010.716202] ? rtnlfdbdump+0x9f0/0x9f0 [ 1010.716208] ? netlinkack+0xab0/0xab0 [ 1010.716213] ? netlinkdelivertap+0x202/0xd50 [ 1010.716220] ? netlinkdelivertap+0x218/0xd50 [ 1010.716226] ? _virtaddrvalid+0x30b/0x590 [ 1010.716233] netlinkunicast+0x54b/0x800 [ 1010.716240] ? netlinkattachskb+0x870/0x870 [ 1010.716248] ? _checkobjectsize+0x2de/0x3b0 [ 1010.716254] netlinksendmsg+0x938/0xe40 [ 1010.716261] ? netlinkunicast+0x800/0x800 [ 1010.716269] ? _importiovec+0x292/0x510 [ 1010.716276] ? netlinkunicast+0x800/0x800 [ 1010.716284] _socksendmsg+0x159/0x190 [ 1010.716290] syssendmsg+0x712/0x880 [ 1010.716297] ? sockwriteiter+0x3d0/0x3d0 [ 1010.716304] ? ia32sysrecvmmsg+0x270/0x270 [ 1010.716309] ? lockacquire+0x1fe/0x560 [ 1010.716315] ? drainarraylocked+0x90/0x90 [ 1010.716324] syssendmsg+0xf8/0x170 [ 1010.716331] ? sendmsgcopymsghdr+0x170/0x170 [ 1010.716337] ? lockdepinitmap ---truncated---(CVE-2024-26793)

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

Bluetooth: Avoid potential use-after-free in hcierrorreset

While handling the HCIEVHARDWAREERROR event, if the underlying BT controller is not responding, the GPIO reset mechanism would free the hcidev and lead to a use-after-free in hcierrorreset.

Here's the call trace observed on a ChromeOS device with Intel AX201: queueworkon+0x3e/0x6c _hcicmdsyncsk+0x2ee/0x4c0 [bluetooth <HASH:3b4a6>] ? initwaitentry+0x31/0x31 _hcicmdsync+0x16/0x20 [bluetooth <HASH:3b4a 6>] hcierrorreset+0x4f/0xa4 [bluetooth <HASH:3b4a 6>] processonework+0x1d8/0x33f workerthread+0x21b/0x373 kthread+0x13a/0x152 ? prcontwork+0x54/0x54 ? kthreadblkcg+0x31/0x31 retfrom_fork+0x1f/0x30

This patch holds the reference count on the hcidev while processing a HCIEVHARDWAREERROR event to avoid potential crash.(CVE-2024-26801)

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

net: ip_tunnel: prevent perpetual headroom growth

syzkaller triggered following kasan splat: BUG: KASAN: use-after-free in skbflowdissect+0x19d1/0x7a50 net/core/flowdissector.c:1170 Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191 [..] kasanreport+0xda/0x110 mm/kasan/report.c:588 _skbflowdissect+0x19d1/0x7a50 net/core/flowdissector.c:1170 skbflowdissectflowkeys include/linux/skbuff.h:1514 [inline] skbgethash net/core/flowdissector.c:1791 [inline] _skbgethash+0xc7/0x540 net/core/flowdissector.c:1856 skbgethash include/linux/skbuff.h:1556 [inline] iptunnelxmit+0x1855/0x33c0 net/ipv4/iptunnel.c:748 ipiptunnelxmit+0x3cc/0x4e0 net/ipv4/ipip.c:308 _netdevstartxmit include/linux/netdevice.h:4940 [inline] netdevstartxmit include/linux/netdevice.h:4954 [inline] xmitone net/core/dev.c:3548 [inline] devhardstartxmit+0x13d/0x6d0 net/core/dev.c:3564 _devqueuexmit+0x7c1/0x3d60 net/core/dev.c:4349 devqueuexmit include/linux/netdevice.h:3134 [inline] neighconnectedoutput+0x42c/0x5d0 net/core/neighbour.c:1592 ... ipfinishoutput2+0x833/0x2550 net/ipv4/ipoutput.c:235 ipfinishoutput+0x31/0x310 net/ipv4/ipoutput.c:323 .. iptunnelxmit+0x5b4/0x9b0 net/ipv4/iptunnelcore.c:82 iptunnelxmit+0x1dbc/0x33c0 net/ipv4/iptunnel.c:831 ipgrexmit+0x4a1/0x980 net/ipv4/ipgre.c:665 _netdevstartxmit include/linux/netdevice.h:4940 [inline] netdevstartxmit include/linux/netdevice.h:4954 [inline] xmitone net/core/dev.c:3548 [inline] devhardstartxmit+0x13d/0x6d0 net/core/dev.c:3564 ...

The splat occurs because skb->data points past skb->head allocated area. This is because neigh layer does: _skbpull(skb, skbnetworkoffset(skb));

... but skbnetworkoffset() returns a negative offset and _skbpull() arg is unsigned. IOW, we skb->data gets "adjusted" by a huge value.

The negative value is returned because skb->head and skb->data distance is more than 64k and skb->network_header (u16) has wrapped around.

The bug is in the iptunnel infrastructure, which can cause dev->neededheadroom to increment ad infinitum.

The syzkaller reproducer consists of packets getting routed via a gre tunnel, and route of gre encapsulated packets pointing at another (ipip) tunnel. The ipip encapsulation finds gre0 as next output device.

This results in the following pattern:

1). First packet is to be sent out via gre0. Route lookup found an output device, ipip0.

2). iptunnelxmit for gre0 bumps gre0->neededheadroom based on the future output device, rt.dev->neededheadroom (ipip0).

3). ip output / start_xmit moves skb on to ipip0. which runs the same code path again (xmit recursion).

4). Routing step for the post-gre0-encap packet finds gre0 as output device to use for ipip0 encapsulated packet.

tunl0->needed_headroom is then incremented based on the (already bumped) gre0 device headroom.

This repeats for every future packet:

gre0->neededheadroom gets inflated because previous packets' ipip0 step incremented rt->dev (gre0) headroom, and ipip0 incremented because gre0 neededheadroom was increased.

For each subsequent packet, gre/ipip0->needed_headroom grows until post-expand-head reallocations result in a skb->head/data distance of more than 64k.

Once that happens, skb->networkheader (u16) wraps around when pskbexpandhead tries to make sure that skbnetwork_offset() is unchanged after the headroom expansion/reallocation.

After this skbnetworkoffset(skb) returns a different (and negative) result post headroom expansion.

The next trip to neigh layer (or anything else that would _skbpull the network header) makes skb->data point to a memory location outside skb->head area.

v2: Cap the needed_headroom update to an arbitarily chosen upperlimit to prevent perpetual increase instead of dropping the headroom increment completely.(CVE-2024-26804)

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

netlink: Fix kernel-infoleak-after-free in _skbdatagram_iter

syzbot reported the following uninit-value access issue [1]:

netlinktofullskb() creates a new skb and puts the skb->data passed as a 1st arg of netlinktofullskb() onto new skb. The data size is specified as len and passed to skbputdata(). This len is based on skb->end that is not data offset but buffer offset. The skb->end contains data and tailroom. Since the tailroom is not initialized when the new skb created, KMSAN detects uninitialized memory area when copying the data.

This patch resolved this issue by correct the len from skb->end to skb->len, which is the actual data offset.

BUG: KMSAN: kernel-infoleak-after-free in instrumentcopytouser include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak-after-free in copytouseriter lib/ioviter.c:24 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterateubuf include/linux/ioviter.h:29 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterateandadvance2 include/linux/ioviter.h:245 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterateandadvance include/linux/ioviter.h:271 [inline] BUG: KMSAN: kernel-infoleak-after-free in _copytoiter+0x364/0x2520 lib/ioviter.c:186 instrumentcopytouser include/linux/instrumented.h:114 [inline] copytouseriter lib/ioviter.c:24 [inline] iterateubuf include/linux/ioviter.h:29 [inline] iterateandadvance2 include/linux/ioviter.h:245 [inline] iterateandadvance include/linux/ioviter.h:271 [inline] _copytoiter+0x364/0x2520 lib/ioviter.c:186 copytoiter include/linux/uio.h:197 [inline] simplecopytoiter+0x68/0xa0 net/core/datagram.c:532 _skbdatagramiter+0x123/0xdc0 net/core/datagram.c:420 skbcopydatagramiter+0x5c/0x200 net/core/datagram.c:546 skbcopydatagrammsg include/linux/skbuff.h:3960 [inline] packetrecvmsg+0xd9c/0x2000 net/packet/afpacket.c:3482 sockrecvmsgnosec net/socket.c:1044 [inline] sockrecvmsg net/socket.c:1066 [inline] sockreaditer+0x467/0x580 net/socket.c:1136 callreaditer include/linux/fs.h:2014 [inline] newsyncread fs/readwrite.c:389 [inline] vfsread+0x8f6/0xe00 fs/readwrite.c:470 ksysread+0x20f/0x4c0 fs/readwrite.c:613 _dosysread fs/readwrite.c:623 [inline] _sesysread fs/readwrite.c:621 [inline] _x64sysread+0x93/0xd0 fs/readwrite.c:621 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x44/0x110 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b

Uninit was stored to memory at: skbputdata include/linux/skbuff.h:2622 [inline] netlinktofullskb net/netlink/afnetlink.c:181 [inline] netlinkdelivertapskb net/netlink/afnetlink.c:298 [inline] _netlinkdelivertap+0x5be/0xc90 net/netlink/afnetlink.c:325 netlinkdelivertap net/netlink/afnetlink.c:338 [inline] netlinkdelivertapkernel net/netlink/afnetlink.c:347 [inline] netlinkunicastkernel net/netlink/afnetlink.c:1341 [inline] netlinkunicast+0x10f1/0x1250 net/netlink/afnetlink.c:1368 netlinksendmsg+0x1238/0x13d0 net/netlink/afnetlink.c:1910 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg net/socket.c:745 [inline] syssendmsg+0x9c2/0xd60 net/socket.c:2584 _syssendmsg+0x28d/0x3c0 net/socket.c:2638 _syssendmsg net/socket.c:2667 [inline] _dosyssendmsg net/socket.c:2676 [inline] _sesyssendmsg net/socket.c:2674 [inline] _x64syssendmsg+0x307/0x490 net/socket.c:2674 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x44/0x110 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x63/0x6b

Uninit was created at: freepagesprepare mm/pagealloc.c:1087 [inline] freeunrefpageprepare+0xb0/0xa40 mm/pagealloc.c:2347 freeunrefpagelist+0xeb/0x1100 mm/pagealloc.c:2533 releasepages+0x23d3/0x2410 mm/swap.c:1042 freepagesandswapcache+0xd9/0xf0 mm/swapstate.c:316 tlbbatch_pages ---truncated---(CVE-2024-26805)

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

vfio/pci: Create persistent INTx handler

A vulnerability exists where the eventfd for INTx signaling can be deconfigured, which unregisters the IRQ handler but still allows eventfds to be signaled with a NULL context through the SET_IRQS ioctl or through unmask irqfd if the device interrupt is pending.

Ideally this could be solved with some additional locking; the igate mutex serializes the ioctl and config space accesses, and the interrupt handler is unregistered relative to the trigger, but the irqfd path runs asynchronous to those. The igate mutex cannot be acquired from the atomic context of the eventfd wake function. Disabling the irqfd relative to the eventfd registration is potentially incompatible with existing userspace.

As a result, the solution implemented here moves configuration of the INTx interrupt handler to track the lifetime of the INTx context object and irqtype configuration, rather than registration of a particular trigger eventfd. Synchronization is added between the ioctl path and eventfdsignal() wrapper such that the eventfd trigger can be dynamically updated relative to in-flight interrupts or irqfd callbacks.(CVE-2024-26812)

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

vfio/platform: Create persistent IRQ handlers

The vfio-platform SET_IRQS ioctl currently allows loopback triggering of an interrupt before a signaling eventfd has been configured by the user, which thereby allows a NULL pointer dereference.

Rather than register the IRQ relative to a valid trigger, register all IRQs in a disabled state in the device open path. This allows mask operations on the IRQ to nest within the overall enable state governed by a valid eventfd signal. This decouples @masked, protected by the @locked spinlock from @trigger, protected via the @igate mutex.

In doing so, it's guaranteed that changes to @trigger cannot race the IRQ handlers because the IRQ handler is synchronously disabled before modifying the trigger, and loopback triggering of the IRQ via ioctl is safe due to serialization with trigger changes via igate.

For compatibility, requestirq() failures are maintained to be local to the SETIRQS ioctl rather than a fatal error in the open device path. This allows, for example, a userspace driver with polling mode support to continue to work regardless of moving the requestirq() call site. This necessarily blocks all SETIRQS access to the failed index.(CVE-2024-26813)

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

amdkfd: use calloc instead of kzalloc to avoid integer overflow

This uses calloc instead of doing the multiplication which might overflow.(CVE-2024-26817)

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

cifs: fix underflow in parseserverinterfaces()

In this loop, we step through the buffer and after each item we check if the sizeleft is greater than the minimum size we need. However, the problem is that "bytesleft" is type ssizet while sizeof() is type sizet. That means that because of type promotion, the comparison is done as an unsigned and if we have negative bytes left the loop continues instead of ending.(CVE-2024-26828)

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

IB/hfi1: Fix a memleak in initcreditreturn

When dmaalloccoherent fails to allocate dd->crbase[i].va, initcreditreturn should deallocate dd->crbase and dd->cr_base[i] that allocated before. Or those resources would be never freed and a memleak is triggered.(CVE-2024-26839)

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

cachefiles: fix memory leak in cachefilesaddcache()

The following memory leak was reported after unbinding /dev/cachefiles:

================================================================== unreferenced object 0xffff9b674176e3c0 (size 192): comm "cachefilesd2", pid 680, jiffies 4294881224 hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc ea38a44b): [<ffffffff8eb8a1a5>] kmemcachealloc+0x2d5/0x370 [<ffffffff8e917f86>] preparecreds+0x26/0x2e0 [<ffffffffc002eeef>] cachefilesdeterminecachesecurity+0x1f/0x120 [<ffffffffc00243ec>] cachefilesaddcache+0x13c/0x3a0 [<ffffffffc0025216>] cachefilesdaemonwrite+0x146/0x1c0 [<ffffffff8ebc4a3b>] vfswrite+0xcb/0x520 [<ffffffff8ebc5069>] ksyswrite+0x69/0xf0 [<ffffffff8f6d4662>] dosyscall64+0x72/0x140

[<ffffffff8f8000aa>] entrySYSCALL64afterhwframe+0x6e/0x76

Put the reference count of cachecred in cachefilesdaemonunbind() to fix the problem. And also put cachecred in cachefilesaddcache() error branch to avoid memory leaks.(CVE-2024-26840)

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

nvme-fc: do not wait in vain when unloading module

The module exit path has race between deleting all controllers and freeing 'left over IDs'. To prevent double free a synchronization between nvmedeletectrl and ida_destroy has been added by the initial commit.

There is some logic around trying to prevent from hanging forever in waitforcompletion, though it does not handling all cases. E.g. blktests is able to reproduce the situation where the module unload hangs forever.

If we completely rely on the cleanup code executed from the nvmedeletectrl path, all IDs will be freed eventually. This makes calling idadestroy unnecessary. We only have to ensure that all nvmedeletectrl code has been executed before we leave nvmefcexitmodule. This is done by flushing the nvmedeletewq workqueue.

While at it, remove the unused nvmefcwq workqueue too.(CVE-2024-26846)

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

net/ipv6: avoid possible UAF in ip6routempath_notify()

syzbot found another use-after-free in ip6routempath_notify() [1]

Commit f7225172f25a ("net/ipv6: prevent use after free in ip6routempath_notify") was not able to fix the root cause.

We need to defer the fib6inforelease() calls after ip6routempath_notify(), in the cleanup phase.

[1] BUG: KASAN: slab-use-after-free in rt6fillnode+0x1460/0x1ac0 Read of size 4 at addr ffff88809a07fc64 by task syz-executor.2/23037

CPU: 0 PID: 23037 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-01035-gea7f3cfaa588 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x1e7/0x2e0 lib/dumpstack.c:106 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0x167/0x540 mm/kasan/report.c:488 kasanreport+0x142/0x180 mm/kasan/report.c:601 rt6fillnode+0x1460/0x1ac0 inet6rtnotify+0x13b/0x290 net/ipv6/route.c:6184 ip6routempathnotify net/ipv6/route.c:5198 [inline] ip6routemultipathadd net/ipv6/route.c:5404 [inline] inet6rtmnewroute+0x1d0f/0x2300 net/ipv6/route.c:5517 rtnetlinkrcvmsg+0x885/0x1040 net/core/rtnetlink.c:6597 netlinkrcvskb+0x1e3/0x430 net/netlink/afnetlink.c:2543 netlinkunicastkernel net/netlink/afnetlink.c:1341 [inline] netlinkunicast+0x7ea/0x980 net/netlink/afnetlink.c:1367 netlinksendmsg+0xa3b/0xd70 net/netlink/afnetlink.c:1908 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg+0x221/0x270 net/socket.c:745 _syssendmsg+0x525/0x7d0 net/socket.c:2584 _syssendmsg net/socket.c:2638 [inline] _syssendmsg+0x2b0/0x3a0 net/socket.c:2667 dosyscall64+0xf9/0x240 entrySYSCALL64afterhwframe+0x6f/0x77 RIP: 0033:0x7f73dd87dda9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f73de6550c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f73dd9ac050 RCX: 00007f73dd87dda9 RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000005 RBP: 00007f73dd8ca47a R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000006e R14: 00007f73dd9ac050 R15: 00007ffdbdeb7858 </TASK>

Allocated by task 23037: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 poisonkmallocredzone mm/kasan/common.c:372 [inline] kasankmalloc+0x98/0xb0 mm/kasan/common.c:389 kasankmalloc include/linux/kasan.h:211 [inline] _dokmallocnode mm/slub.c:3981 [inline] _kmalloc+0x22e/0x490 mm/slub.c:3994 kmalloc include/linux/slab.h:594 [inline] kzalloc include/linux/slab.h:711 [inline] fib6infoalloc+0x2e/0xf0 net/ipv6/ip6fib.c:155 ip6routeinfocreate+0x445/0x12b0 net/ipv6/route.c:3758 ip6routemultipathadd net/ipv6/route.c:5298 [inline] inet6rtmnewroute+0x744/0x2300 net/ipv6/route.c:5517 rtnetlinkrcvmsg+0x885/0x1040 net/core/rtnetlink.c:6597 netlinkrcvskb+0x1e3/0x430 net/netlink/afnetlink.c:2543 netlinkunicastkernel net/netlink/afnetlink.c:1341 [inline] netlinkunicast+0x7ea/0x980 net/netlink/afnetlink.c:1367 netlinksendmsg+0xa3b/0xd70 net/netlink/afnetlink.c:1908 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg+0x221/0x270 net/socket.c:745 _syssendmsg+0x525/0x7d0 net/socket.c:2584 _syssendmsg net/socket.c:2638 [inline] _syssendmsg+0x2b0/0x3a0 net/socket.c:2667 dosyscall64+0xf9/0x240 entrySYSCALL64afterhwframe+0x6f/0x77

Freed by task 16: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 kasansavefreeinfo+0x4e/0x60 mm/kasan/generic.c:640 poisonslab_object+0xa6/0xe0 m ---truncated---(CVE-2024-26852)

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

geneve: make sure to pull inner header in geneve_rx()

syzbot triggered a bug in geneve_rx() [1]

Issue is similar to the one I fixed in commit 8d975c15c0cd ("ip6tunnel: make sure to pull inner header in _ip6tnlrcv()")

We have to save skb->networkheader in a temporary variable in order to be able to recompute the networkheader pointer after a pskbinetmay_pull() call.

pskbinetmay_pull() makes sure the needed headers are in skb->head.

[1] BUG: KMSAN: uninit-value in IPECNdecapsulate include/net/inetecn.h:302 [inline] BUG: KMSAN: uninit-value in geneverx drivers/net/geneve.c:279 [inline] BUG: KMSAN: uninit-value in geneveudpencaprecv+0x36f9/0x3c10 drivers/net/geneve.c:391 IPECNdecapsulate include/net/inetecn.h:302 [inline] geneverx drivers/net/geneve.c:279 [inline] geneveudpencaprecv+0x36f9/0x3c10 drivers/net/geneve.c:391 udpqueuercvoneskb+0x1d39/0x1f20 net/ipv4/udp.c:2108 udpqueuercvskb+0x6ae/0x6e0 net/ipv4/udp.c:2186 udpunicastrcvskb+0x184/0x4b0 net/ipv4/udp.c:2346 _udp4librcv+0x1c6b/0x3010 net/ipv4/udp.c:2422 udprcv+0x7d/0xa0 net/ipv4/udp.c:2604 ipprotocoldeliverrcu+0x264/0x1300 net/ipv4/ipinput.c:205 iplocaldeliverfinish+0x2b8/0x440 net/ipv4/ipinput.c:233 NFHOOK include/linux/netfilter.h:314 [inline] iplocaldeliver+0x21f/0x490 net/ipv4/ipinput.c:254 dstinput include/net/dst.h:461 [inline] iprcvfinish net/ipv4/ipinput.c:449 [inline] NFHOOK include/linux/netfilter.h:314 [inline] iprcv+0x46f/0x760 net/ipv4/ipinput.c:569 _netifreceiveskbonecore net/core/dev.c:5534 [inline] _netifreceiveskb+0x1a6/0x5a0 net/core/dev.c:5648 processbacklog+0x480/0x8b0 net/core/dev.c:5976 _napipoll+0xe3/0x980 net/core/dev.c:6576 napipoll net/core/dev.c:6645 [inline] netrxaction+0x8b8/0x1870 net/core/dev.c:6778 _dosoftirq+0x1b7/0x7c5 kernel/softirq.c:553 dosoftirq+0x9a/0xf0 kernel/softirq.c:454 _localbhenableip+0x9b/0xa0 kernel/softirq.c:381 localbhenable include/linux/bottomhalf.h:33 [inline] rcureadunlockbh include/linux/rcupdate.h:820 [inline] _devqueuexmit+0x2768/0x51c0 net/core/dev.c:4378 devqueuexmit include/linux/netdevice.h:3171 [inline] packetxmit+0x9c/0x6b0 net/packet/afpacket.c:276 packetsnd net/packet/afpacket.c:3081 [inline] packetsendmsg+0x8aef/0x9f10 net/packet/afpacket.c:3113 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg net/socket.c:745 [inline] _syssendto+0x735/0xa10 net/socket.c:2191 _dosyssendto net/socket.c:2203 [inline] _sesyssendto net/socket.c:2199 [inline] _x64syssendto+0x125/0x1c0 net/socket.c:2199 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcf/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b

Uninit was created at: slabpostallochook mm/slub.c:3819 [inline] slaballocnode mm/slub.c:3860 [inline] kmemcacheallocnode+0x5cb/0xbc0 mm/slub.c:3903 kmallocreserve+0x13d/0x4a0 net/core/skbuff.c:560 _allocskb+0x352/0x790 net/core/skbuff.c:651 allocskb include/linux/skbuff.h:1296 [inline] allocskbwithfrags+0xc8/0xbd0 net/core/skbuff.c:6394 sockallocsendpskb+0xa80/0xbf0 net/core/sock.c:2783 packetallocskb net/packet/afpacket.c:2930 [inline] packetsnd net/packet/afpacket.c:3024 [inline] packetsendmsg+0x70c2/0x9f10 net/packet/afpacket.c:3113 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg net/socket.c:745 [inline] _syssendto+0x735/0xa10 net/socket.c:2191 _dosyssendto net/socket.c:2203 [inline] _sesyssendto net/socket.c:2199 [inline] _x64syssendto+0x125/0x1c0 net/socket.c:2199 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcf/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b(CVE-2024-26857)

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

net/bnx2x: Prevent access to a freed page in page_pool

Fix race condition leading to system crash during EEH error handling

During EEH error recovery, the bnx2x driver's transmit timeout logic could cause a race condition when handling reset tasks. The bnx2xtxtimeout() schedules reset tasks via bnx2xsprtnltask(), which ultimately leads to bnx2xnicunload(). In bnx2xnicunload() SGEs are freed using bnx2xfreerxsgerange(). However, this could overlap with the EEH driver's attempt to reset the device using bnx2xioslotreset(), which also tries to free SGEs. This race condition can result in system crashes due to accessing freed memory locations in bnx2xfreerx_sge()

799 static inline void bnx2xfreerxsge(struct bnx2x *bp, 800 struct bnx2xfastpath *fp, u16 index) 801 { 802 struct swrxpage *swbuf = &fp->rxpagering[index]; 803 struct page *page = swbuf->page; .... where swbuf was set to NULL after the call to dmaunmap_page() by the preceding thread.

EEH: Beginning: 'slot_reset'
PCI 0011:01:00.0#10000: EEH: Invoking bnx2x->slot_reset()
bnx2x: [bnx2x_io_slot_reset:14228(eth1)]IO slot reset initializing...
bnx2x 0011:01:00.0: enabling device (0140 -> 0142)
bnx2x: [bnx2x_io_slot_reset:14244(eth1)]IO slot reset --> driver unload
Kernel attempted to read user page (0) - exploit attempt? (uid: 0)
BUG: Kernel NULL pointer dereference on read at 0x00000000
Faulting instruction address: 0xc0080000025065fc
Oops: Kernel access of bad area, sig: 11 [#1]
.....
Call Trace:
[c000000003c67a20] [c00800000250658c] bnx2x_io_slot_reset+0x204/0x610 [bnx2x] (unreliable)
[c000000003c67af0] [c0000000000518a8] eeh_report_reset+0xb8/0xf0
[c000000003c67b60] [c000000000052130] eeh_pe_report+0x180/0x550
[c000000003c67c70] [c00000000005318c] eeh_handle_normal_event+0x84c/0xa60
[c000000003c67d50] [c000000000053a84] eeh_event_handler+0xf4/0x170
[c000000003c67da0] [c000000000194c58] kthread+0x1c8/0x1d0
[c000000003c67e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64

To solve this issue, we need to verify page pool allocations before freeing.(CVE-2024-26859)

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

hsr: Fix uninit-value access in hsrgetnode()

KMSAN reported the following uninit-value access issue [1]:

===================================================== BUG: KMSAN: uninit-value in hsrgetnode+0xa2e/0xa40 net/hsr/hsrframereg.c:246 hsrgetnode+0xa2e/0xa40 net/hsr/hsrframereg.c:246 fillframeinfo net/hsr/hsrforward.c:577 [inline] hsrforwardskb+0xe12/0x30e0 net/hsr/hsrforward.c:615 hsrdevxmit+0x1a1/0x270 net/hsr/hsrdevice.c:223 _netdevstartxmit include/linux/netdevice.h:4940 [inline] netdevstartxmit include/linux/netdevice.h:4954 [inline] xmitone net/core/dev.c:3548 [inline] devhardstartxmit+0x247/0xa10 net/core/dev.c:3564 _devqueuexmit+0x33b8/0x5130 net/core/dev.c:4349 devqueuexmit include/linux/netdevice.h:3134 [inline] packetxmit+0x9c/0x6b0 net/packet/afpacket.c:276 packetsnd net/packet/afpacket.c:3087 [inline] packetsendmsg+0x8b1d/0x9f30 net/packet/afpacket.c:3119 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg net/socket.c:745 [inline] _syssendto+0x735/0xa10 net/socket.c:2191 _dosyssendto net/socket.c:2203 [inline] _sesyssendto net/socket.c:2199 [inline] _x64syssendto+0x125/0x1c0 net/socket.c:2199 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x6d/0x140 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b

Uninit was created at: slabpostallochook+0x129/0xa70 mm/slab.h:768 slaballocnode mm/slub.c:3478 [inline] kmemcacheallocnode+0x5e9/0xb10 mm/slub.c:3523 kmallocreserve+0x13d/0x4a0 net/core/skbuff.c:560 _allocskb+0x318/0x740 net/core/skbuff.c:651 allocskb include/linux/skbuff.h:1286 [inline] allocskbwithfrags+0xc8/0xbd0 net/core/skbuff.c:6334 sockallocsendpskb+0xa80/0xbf0 net/core/sock.c:2787 packetallocskb net/packet/afpacket.c:2936 [inline] packetsnd net/packet/afpacket.c:3030 [inline] packetsendmsg+0x70e8/0x9f30 net/packet/afpacket.c:3119 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg net/socket.c:745 [inline] _syssendto+0x735/0xa10 net/socket.c:2191 _dosyssendto net/socket.c:2203 [inline] _sesyssendto net/socket.c:2199 [inline] _x64syssendto+0x125/0x1c0 net/socket.c:2199 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x6d/0x140 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b

CPU: 1 PID: 5033 Comm: syz-executor334 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023

If the packet type ID field in the Ethernet header is either ETHPPRP or ETHPHSR, but it is not followed by an HSR tag, hsrgetskbsequencenr() reads an invalid value as a sequence number. This causes the above issue.

This patch fixes the issue by returning NULL if the Ethernet header is not followed by an HSR tag.(CVE-2024-26863)

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

RDMA/srpt: Do not register event handler until srpt device is fully setup

Upon rare occasions, KASAN reports a use-after-free Write in srptrefreshport().

This seems to be because an event handler is registered before the srpt device is fully setup and a race condition upon error may leave a partially setup event handler in place.

Instead, only register the event handler after srpt device initialization is complete.(CVE-2024-26872)

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

media: pvrusb2: fix uaf in pvr2contextset_notify

[Syzbot reported] BUG: KASAN: slab-use-after-free in pvr2contextset_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35 Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26

CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Workqueue: usbhubwq hubevent Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0xd9/0x1b0 lib/dumpstack.c:106 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0xc4/0x620 mm/kasan/report.c:488 kasanreport+0xda/0x110 mm/kasan/report.c:601 pvr2contextsetnotify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35 pvr2contextnotify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline] pvr2contextdisconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272

Freed by task 906: kasansavestack+0x33/0x50 mm/kasan/common.c:47 kasansavetrack+0x14/0x30 mm/kasan/common.c:68 kasansavefreeinfo+0x3f/0x60 mm/kasan/generic.c:640 poisonslabobject mm/kasan/common.c:241 [inline] _kasanslabfree+0x106/0x1b0 mm/kasan/common.c:257 kasanslabfree include/linux/kasan.h:184 [inline] slabfreehook mm/slub.c:2121 [inline] slabfree mm/slub.c:4299 [inline] kfree+0x105/0x340 mm/slub.c:4409 pvr2contextcheck drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline] pvr2contextthreadfunc+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158

[Analyze] Task A set disconnect_flag = !0, which resulted in Task B's condition being met and releasing mp, leading to this issue.

[Fix] Place the disconnectflag assignment operation after all code in pvr2context_disconnect() to avoid this issue.(CVE-2024-26875)

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

drm/bridge: adv7511: fix crash on irq during probe

Moved IRQ registration down to end of adv7511_probe().

If an IRQ already is pending during adv7511probe (before adv7511cecinit) then cecreceivedmsgts could crash using uninitialized data:

Unable to handle kernel read from unreadable memory at virtual address 00000000000003d5
Internal error: Oops: 96000004 [#1] PREEMPT_RT SMP
Call trace:
 cec_received_msg_ts+0x48/0x990 [cec]
 adv7511_cec_irq_process+0x1cc/0x308 [adv7511]
 adv7511_irq_process+0xd8/0x120 [adv7511]
 adv7511_irq_handler+0x1c/0x30 [adv7511]
 irq_thread_fn+0x30/0xa0
 irq_thread+0x14c/0x238
 kthread+0x190/0x1a8(CVE-2024-26876)

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

quota: Fix potential NULL pointer dereference

Below race may cause NULL pointer dereference

P1 P2 dquotfreeinode quotaoff dropdquotref removedquotref dquots = idquot(inode) dquots = idquot(inode) srcureadlock dquots[cnt]) != NULL (1) dquots[type] = NULL (2) spinlock(&dquots[cnt]->dqdqblock) (3) ....

If dquotfreeinode(or other routines) checks inode's quota pointers (1) before quota_off sets it to NULL(2) and use it (3) after that, NULL pointer dereference will be triggered.

So let's fix it by using a temporary pointer to avoid this issue.(CVE-2024-26878)

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

dm: call the resume method on internal suspend

There is this reported crash when experimenting with the lvm2 testsuite. The list corruption is caused by the fact that the postsuspend and resume methods were not paired correctly; there were two consecutive calls to the originpostsuspend function. The second call attempts to remove the "hashlist" entry from a list, while it was already removed by the first call.

Fix _dminternal_resume so that it calls the preresume and resume methods of the table's targets.

If a preresume method of some target fails, we are in a tricky situation. We can't return an error because dminternalresume isn't supposed to return errors. We can't return success, because then the "resume" and "postsuspend" methods would not be paired correctly. So, we set the DMF_SUSPENDED flag and we fake normal suspend - it may confuse userspace tools, but it won't cause a kernel crash.

------------[ cut here ]------------ kernel BUG at lib/listdebug.c:56! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 8343 Comm: dmsetup Not tainted 6.8.0-rc6 #4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 RIP: 0010:listdelentryvalidorreport+0x77/0xc0 <snip> RSP: 0018:ffff8881b831bcc0 EFLAGS: 00010282 RAX: 000000000000004e RBX: ffff888143b6eb80 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffffffff819053d0 RDI: 00000000ffffffff RBP: ffff8881b83a3400 R08: 00000000fffeffff R09: 0000000000000058 R10: 0000000000000000 R11: ffffffff81a24080 R12: 0000000000000001 R13: ffff88814538e000 R14: ffff888143bc6dc0 R15: ffffffffa02e4bb0 FS: 00000000f7c0f780(0000) GS:ffff8893f0a40000(0000) knlGS:0000000000000000 CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 CR2: 0000000057fb5000 CR3: 0000000143474000 CR4: 00000000000006b0 Call Trace: <TASK> ? die+0x2d/0x80 ? dotrap+0xeb/0xf0 ? _listdelentryvalidorreport+0x77/0xc0 ? doerrortrap+0x60/0x80 ? _listdelentryvalidorreport+0x77/0xc0 ? excinvalidop+0x49/0x60 ? _listdelentryvalidorreport+0x77/0xc0 ? asmexcinvalidop+0x16/0x20 ? tabledeps+0x1b0/0x1b0 [dmmod] ? _listdelentryvalidorreport+0x77/0xc0 originpostsuspend+0x1a/0x50 [dmsnapshot] dmtablepostsuspendtargets+0x34/0x50 [dmmod] dmsuspend+0xd8/0xf0 [dmmod] devsuspend+0x1f2/0x2f0 [dmmod] ? tabledeps+0x1b0/0x1b0 [dmmod] ctlioctl+0x300/0x5f0 [dmmod] dmcompatctlioctl+0x7/0x10 [dmmod] _x64compatsysioctl+0x104/0x170 dosyscall64+0x184/0x1b0 entrySYSCALL64afterhwframe+0x46/0x4e RIP: 0033:0xf7e6aead <snip> ---[ end trace 0000000000000000 ]---(CVE-2024-26880)

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

wifi: ath9k: delay all of ath9kwmievent_tasklet() until init is complete

The ath9kwmieventtasklet() used in ath9khtc assumes that all the data structures have been fully initialised by the time it runs. However, because of the order in which things are initialised, this is not guaranteed to be the case, because the device is exposed to the USB subsystem before the ath9k driver initialisation is completed.

We already committed a partial fix for this in commit: 8b3046abc99e ("ath9khtc: fix NULL pointer dereference at ath9khtctxget_packet()")

However, that commit only aborted the WMITXSTATUSEVENTID command in the event tasklet, pairing it with an "initialisation complete" bit in the TX struct. It seems syzbot managed to trigger the race for one of the other commands as well, so let's just move the existing synchronisation bit to cover the whole tasklet (setting it at the end of ath9khtcprobedevice() instead of inside ath9ktx_init()).(CVE-2024-26897)

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

aoe: fix the potential use-after-free problem in aoecmdcfgpkts

This patch is against CVE-2023-6270. The description of cve is:

A flaw was found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmdcfgpkts() function improperly updates the refcnt on struct net_device, and a use-after-free can be triggered by racing between the free on the struct and the access through the skbtxq global queue. This could lead to a denial of service condition or potential code execution.

In aoecmdcfgpkts(), it always calls devput(ifp) when skb initial code is finished. But the netdevice ifp will still be used in later tx()->devqueuexmit() in kthread. Which means that the devput(ifp) should NOT be called in the success path of skb initial code in aoecmdcfgpkts(). Otherwise tx() may run into use-after-free because the netdevice is freed.

This patch removed the devput(ifp) in the success path in aoecmdcfgpkts(), and added devput() after skb xmit in tx().(CVE-2024-26898)

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

drm/amdgpu: Reset IH OVERFLOW_CLEAR bit

Allows us to detect subsequent IH ring buffer overflows as well.(CVE-2024-26915)

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

drm/amdgpu: validate the parameters of bo mapping operations more clearly

Verify the parameters of amdgpuvmbo(map/replacemap/clearing_mappings) in one common place.(CVE-2024-26922)

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

media: go7007: fix a memleak in go7007loadencoder

In go7007loadencoder, bounce(i.e. go->boot_fw), is allocated without a deallocation thereafter. After the following call chain:

saa7134go7007init |-> go7007bootencoder |-> go7007loadencoder |-> kfree(go)

go is freed and thus bounce is leaked.(CVE-2024-27074)