OESA-2024-1649

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

binder: fix race between mmput() and do_exit()

Task A calls binderupdatepagerange() to allocate and insert pages on a remote address space from Task B. For this, Task A pins the remote mm via mmgetnotzero() first. This can race with Task B doexit() and the final mmput() refcount decrement will come from Task A.

Task A | Task B ------------------+------------------ mmgetnotzero() | | doexit() | exitmm() | mmput() mmput() | exitmmap() | removevma() | fput() |

In this case, the work of _fput() from Task B is queued up in Task A as TWARESUME. So in theory, Task A returns to userspace and the cleanup work gets executed. However, Task A instead sleep, waiting for a reply from Task B that never comes (it's dead).

This means the binderdeferredrelease() is blocked until an unrelated binder event forces Task A to go back to userspace. All the associated death notifications will also be delayed until then.

In order to fix this use mmputasync() that will schedule the work in the corresponding mm->asyncput_work WQ instead of Task A.(CVE-2023-52609)

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:

crypto: lib/mpi - Fix unexpected pointer access in mpiecinit

When the mpiecctx structure is initialized, some fields are not cleared, causing a crash when referencing the field when the structure was released. Initially, this issue was ignored because memory for mpiecctx is allocated with the _GFPZERO flag. For example, this error will be triggered when calculating the Za value for SM2 separately.(CVE-2023-52616)

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

bpf: Check rcureadlocktraceheld() before calling bpf map helpers

These three bpfmap{lookup,update,delete}elem() helpers are also available for sleepable bpf program, so add the corresponding lock assertion for sleepable bpf program, otherwise the following warning will be reported when a sleepable bpf program manipulates bpf map under interpreter mode (aka bpfjit_enable=0):

WARNING: CPU: 3 PID: 4985 at kernel/bpf/helpers.c:40 ...... CPU: 3 PID: 4985 Comm: testprogs Not tainted 6.6.0+ #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ...... RIP: 0010:bpfmaplookupelem+0x54/0x60 ...... Call Trace: <TASK> ? warn+0xa5/0x240 ? bpfmaplookupelem+0x54/0x60 ? reportbug+0x1ba/0x1f0 ? handlebug+0x40/0x80 ? excinvalidop+0x18/0x50 ? asmexcinvalidop+0x1b/0x20 ? _pfxbpfmaplookupelem+0x10/0x10 ? rculockdepcurrentcpuonline+0x65/0xb0 ? rcuiswatching+0x23/0x50 ? bpfmaplookupelem+0x54/0x60 ? _pfxbpfmaplookupelem+0x10/0x10 _bpfprogrun+0x513/0x3b70 _bpfprogrun32+0x9d/0xd0 ? _bpfprogentersleepablerecur+0xad/0x120 ? _bpfprogentersleepablerecur+0x3e/0x120 bpftrampoline6442580665+0x4d/0x1000 _x64sysgetpgid+0x5/0x30 ? dosyscall64+0x36/0xb0 entrySYSCALL64after_hwframe+0x6e/0x76 </TASK>(CVE-2023-52621)

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)

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2023-52630)

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

um: time-travel: fix time corruption

In 'basic' time-travel mode (without =inf-cpu or =ext), we still get timer interrupts. These can happen at arbitrary points in time, i.e. while in timer_read(), which pushes time forward just a little bit. Then, if we happen to get the interrupt after calculating the new time to push to, but before actually finishing that, the interrupt will set the time to a value that's incompatible with the forward, and we'll crash because time goes backwards when we do the forwarding.

Fix this by reading the timetraveltime, calculating the adjustment, and doing the adjustment all with interrupts disabled.(CVE-2023-52633)

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:

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:

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)

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

powerpc/imc-pmu: Add a null pointer check in updateeventsin_group()

kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure.(CVE-2023-52675)

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

bpf: Guard stack limits against 32bit overflow

This patch promotes the arithmetic around checking stack bounds to be done in the 64-bit domain, instead of the current 32bit. The arithmetic implies adding together a 64-bit register with a int offset. The register was checked to be below 1<<29 when it was variable, but not when it was fixed. The offset either comes from an instruction (in which case it is 16 bit), from another register (in which case the caller checked it to be below 1<<29 [1]), or from the size of an argument to a kfunc (in which case it can be a u32 [2]). Between the register being inconsistently checked to be below 1<<29, and the offset being up to an u32, it appears that we were open to overflowing the ints which were currently used for arithmetic.

[1] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L7494-L7498 [2] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L11904(CVE-2023-52676)

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

pstore: ramcore: fix possible overflow in persistentraminitecc()

In persistentraminitecc(), on 64-bit arches DIVROUNDUP() will return 64-bit value since persistentramzone::buffersize has type sizet which is derived from the 64-bit *unsigned long*, while the eccblocks variable this value gets assigned to has (always 32-bit) int type. Even if that value fits into int type, an overflow is still possible when calculating the sizet typed ecctotal variable further below since there's no cast to any 64-bit type before multiplication. Declaring the eccblocks variable as *sizet* should fix this mess...

Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.(CVE-2023-52685)

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

powerpc/powernv: Add a null pointer check to scomdebuginit_one()

kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Add a null pointer check, and release 'ent' to avoid memory leaks.(CVE-2023-52690)

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

drm/bridge: tpd12s015: Drop buggy __exit annotation for remove function

With tpd12s015remove() marked with _exit this function is discarded when the driver is compiled as a built-in. The result is that when the driver unbinds there is no cleanup done which results in resource leakage or worse.(CVE-2023-52694)

A race condition was found in the Linux kernel's bluetooth device driver in {min,max}keysize_set() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.

(CVE-2024-24860)

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

wifi: iwlwifi: fix a memory corruption

iwlfwinitriggertlv::data is a pointer to a _le32, which means that if we copy to iwlfwinitrigger_tlv::data + offset while offset is in bytes, we'll write past the buffer.(CVE-2024-26610)

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

ip6tunnel: fix NEXTHDRFRAGMENT handling in ip6tnlparsetlvenc_lim()

syzbot pointed out [1] that NEXTHDR_FRAGMENT handling is broken.

Reading frag_off can only be done if we pulled enough bytes to skb->head. Currently we might access garbage.

[1] BUG: KMSAN: uninit-value in ip6tnlparsetlvenclim+0x94f/0xbb0 ip6tnlparsetlvenclim+0x94f/0xbb0 ipxip6tnlxmit net/ipv6/ip6tunnel.c:1326 [inline] ip6tnlstartxmit+0xab2/0x1a70 net/ipv6/ip6tunnel.c:1432 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] neighconnectedoutput+0x569/0x660 net/core/neighbour.c:1592 neighoutput include/net/neighbour.h:542 [inline] ip6finishoutput2+0x23a9/0x2b30 net/ipv6/ip6output.c:137 ip6finishoutput+0x855/0x12b0 net/ipv6/ip6output.c:222 NFHOOKCOND include/linux/netfilter.h:303 [inline] ip6output+0x323/0x610 net/ipv6/ip6output.c:243 dstoutput include/net/dst.h:451 [inline] ip6localout+0xe9/0x140 net/ipv6/outputcore.c:155 ip6sendskb net/ipv6/ip6output.c:1952 [inline] ip6pushpendingframes+0x1f9/0x560 net/ipv6/ip6output.c:1972 rawv6pushpendingframes+0xbe8/0xdf0 net/ipv6/raw.c:582 rawv6sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920 inetsendmsg+0x105/0x190 net/ipv4/afinet.c:847 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: slabpostallochook+0x129/0xa70 mm/slab.h:768 slaballocnode mm/slub.c:3478 [inline] kmemcacheallocnode+0x5c9/0x970 mm/slub.c:3517 _dokmallocnode mm/slabcommon.c:1006 [inline] _kmallocnodetrackcaller+0x118/0x3c0 mm/slabcommon.c:1027 kmallocreserve+0x249/0x4a0 net/core/skbuff.c:582 pskbexpandhead+0x226/0x1a00 net/core/skbuff.c:2098 _pskbpulltail+0x13b/0x2310 net/core/skbuff.c:2655 pskbmaypullreason include/linux/skbuff.h:2673 [inline] pskbmaypull include/linux/skbuff.h:2681 [inline] ip6tnlparsetlvenclim+0x901/0xbb0 net/ipv6/ip6tunnel.c:408 ipxip6tnlxmit net/ipv6/ip6tunnel.c:1326 [inline] ip6tnlstartxmit+0xab2/0x1a70 net/ipv6/ip6tunnel.c:1432 _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] neighconnectedoutput+0x569/0x660 net/core/neighbour.c:1592 neighoutput include/net/neighbour.h:542 [inline] ip6finishoutput2+0x23a9/0x2b30 net/ipv6/ip6output.c:137 ip6finishoutput+0x855/0x12b0 net/ipv6/ip6output.c:222 NFHOOKCOND include/linux/netfilter.h:303 [inline] ip6output+0x323/0x610 net/ipv6/ip6output.c:243 dstoutput include/net/dst.h:451 [inline] ip6localout+0xe9/0x140 net/ipv6/outputcore.c:155 ip6sendskb net/ipv6/ip6output.c:1952 [inline] ip6pushpendingframes+0x1f9/0x560 net/ipv6/ip6output.c:1972 rawv6pushpendingframes+0xbe8/0xdf0 net/ipv6/raw.c:582 rawv6sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920 inetsendmsg+0x105/0x190 net/ipv4/afinet.c:847 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] _dosys_sendms ---truncated---(CVE-2024-26633)

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

llc: Drop support for ETHPTR8022.

syzbot reported an uninit-value bug below. [0]

llc supports ETHP8022 (0x0004) and used to support ETHPTR802_2 (0x0011), and syzbot abused the latter to trigger the bug.

write$tun(r0, &(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, ')', "90e5dd"}}}}, 0x16)

llcconnhandler() initialises local variables {saddr,daddr}.mac based on skb in llcpdudecodesa()/llcpdudecodeda() and passes them to _llclookup().

However, the initialisation is done only when skb->protocol is htons(ETHP8022), otherwise, _llclookupestablished() and _llclookup_listener() will read garbage.

The missing initialisation existed prior to commit 211ed865108e ("net: delete all instances of special processing for token ring").

It removed the part to kick out the token ring stuff but forgot to close the door allowing ETHPTR8022 packets to sneak into llc_rcv().

Let's remove llctrpacket_type and complete the deprecation.

_llclookupestablished+0xe9d/0xf90 _llclookup net/llc/llcconn.c:611 [inline] llcconnhandler+0x4bd/0x1360 net/llc/llcconn.c:791 llcrcv+0xfbb/0x14a0 net/llc/llcinput.c:206 _netifreceiveskbonecore net/core/dev.c:5527 [inline] _netifreceiveskb+0x1a6/0x5a0 net/core/dev.c:5641 netifreceiveskbinternal net/core/dev.c:5727 [inline] netifreceiveskb+0x58/0x660 net/core/dev.c:5786 tunrxbatched+0x3ee/0x980 drivers/net/tun.c:1555 tungetuser+0x53af/0x66d0 drivers/net/tun.c:2002 tunchrwriteiter+0x3af/0x5d0 drivers/net/tun.c:2048 callwriteiter include/linux/fs.h:2020 [inline] newsyncwrite fs/readwrite.c:491 [inline] vfswrite+0x8ef/0x1490 fs/readwrite.c:584 ksyswrite+0x20f/0x4c0 fs/readwrite.c:637 _dosyswrite fs/readwrite.c:649 [inline] _sesyswrite fs/readwrite.c:646 [inline] _x64syswrite+0x93/0xd0 fs/readwrite.c:646 dosyscallx64 arch/x86/entry/common.c:51 [inline] dosyscall64+0x44/0x110 arch/x86/entry/common.c:82 entrySYSCALL64afterhwframe+0x63/0x6b

Local variable daddr created at: llcconnhandler+0x53/0x1360 net/llc/llcconn.c:783 llcrcv+0xfbb/0x14a0 net/llc/llc_input.c:206

CPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023(CVE-2024-26635)

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

llc: make llcuisendmsg() more robust against bonding changes

syzbot was able to trick llcuisendmsg(), allocating an skb with no headroom, but subsequently trying to push 14 bytes of Ethernet header [1]

Like some others, llcuisendmsg() releases the socket lock before calling sockallocsend_skb(). Then it acquires it again, but does not redo all the sanity checks that were performed.

This fix:

• Uses LLRESERVEDSPACE() to reserve space.
• Check all conditions again after socket lock is held again.
• Do not account Ethernet header for mtu limitation.

[1]

skbuff: skbunderpanic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0

kernel BUG at net/core/skbuff.c:193 ! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skbpanic net/core/skbuff.c:189 [inline] pc : skbunderpanic+0x13c/0x140 net/core/skbuff.c:203 lr : skbpanic net/core/skbuff.c:189 [inline] lr : skbunderpanic+0x13c/0x140 net/core/skbuff.c:203 sp : ffff800096f97000 x29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000 x26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2 x23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0 x20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce x17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001 x14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400 x8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000 x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714 x2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089 Call trace: skbpanic net/core/skbuff.c:189 [inline] skbunderpanic+0x13c/0x140 net/core/skbuff.c:203 skbpush+0xf0/0x108 net/core/skbuff.c:2451 ethheader+0x44/0x1f8 net/ethernet/eth.c:83 devhardheader include/linux/netdevice.h:3188 [inline] llcmachdrinit+0x110/0x17c net/llc/llcoutput.c:33 llcsapactionsendxidc+0x170/0x344 net/llc/llcsac.c:85 llcexecsaptransactions net/llc/llcsap.c:153 [inline] llcsapnextstate net/llc/llcsap.c:182 [inline] llcsapstateprocess+0x1ec/0x774 net/llc/llcsap.c:209 llcbuildandsendxidpkt+0x12c/0x1c0 net/llc/llcsap.c:270 llcuisendmsg+0x7bc/0xb1c net/llc/afllc.c:997 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg net/socket.c:745 [inline] socksendmsg+0x194/0x274 net/socket.c:767 splicetosocket+0x7cc/0xd58 fs/splice.c:881 dosplicefrom fs/splice.c:933 [inline] directspliceactor+0xe4/0x1c0 fs/splice.c:1142 splicedirecttoactor+0x2a0/0x7e4 fs/splice.c:1088 dosplicedirect+0x20c/0x348 fs/splice.c:1194 dosendfile+0x4bc/0xc70 fs/readwrite.c:1254 _dosyssendfile64 fs/readwrite.c:1322 [inline] _sesyssendfile64 fs/readwrite.c:1308 [inline] _arm64syssendfile64+0x160/0x3b4 fs/readwrite.c:1308 _invokesyscall arch/arm64/kernel/syscall.c:37 [inline] invokesyscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51 el0svccommon+0x130/0x23c arch/arm64/kernel/syscall.c:136 doel0svc+0x48/0x58 arch/arm64/kernel/syscall.c:155 el0svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678 el0t64synchandler+0x84/0xfc arch/arm64/kernel/entry-common.c:696 el0t64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595 Code: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000)(CVE-2024-26636)

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

tcp: add sanity checks to rx zerocopy

TCP rx zerocopy intent is to map pages initially allocated from NIC drivers, not pages owned by a fs.

This patch adds to canmapfrag() these additional checks:

• Page must not be a compound one.
• page->mapping must be NULL.

This fixes the panic reported by ZhangPeng.

syzbot was able to loopback packets built with sendfile(), mapping pages owned by an ext4 file to TCP rx zerocopy.

r3 = socket$inettcp(0x2, 0x1, 0x0) mmap(&(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0) r4 = socket$inettcp(0x2, 0x1, 0x0) bind$inet(r4, &(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10) connect$inet(r4, &(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10) r5 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00', 0x181e42, 0x0) fallocate(r5, 0x0, 0x0, 0x85b8) sendfile(r4, r5, 0x0, 0x8ba0) getsockopt$inettcpTCPZEROCOPYRECEIVE(r4, 0x6, 0x23, &(0x7f00000001c0)={&(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, &(0x7f0000000440)=0x40) r6 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00', 0x181e42, 0x0)(CVE-2024-26640)

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

ip6tunnel: make sure to pull inner header in _ip6tnlrcv()

syzbot found _ip6tnl_rcv() could access unitiliazed data [1].

Call pskbinetmay_pull() to fix this, and initialize ipv6h variable after this call as it can change skb->head.

[1] BUG: KMSAN: uninit-value in _INETECNdecapsulate include/net/inetecn.h:253 [inline] BUG: KMSAN: uninit-value in INETECNdecapsulate include/net/inetecn.h:275 [inline] BUG: KMSAN: uninit-value in IP6ECNdecapsulate+0x7df/0x1e50 include/net/inetecn.h:321 _INETECNdecapsulate include/net/inetecn.h:253 [inline] INETECNdecapsulate include/net/inetecn.h:275 [inline] IP6ECNdecapsulate+0x7df/0x1e50 include/net/inetecn.h:321 ip6ip6dscpecndecapsulate+0x178/0x1b0 net/ipv6/ip6tunnel.c:727 _ip6tnlrcv+0xd4e/0x1590 net/ipv6/ip6tunnel.c:845 ip6tnlrcv+0xce/0x100 net/ipv6/ip6tunnel.c:888 grercv+0x143f/0x1870 ip6protocoldeliverrcu+0xda6/0x2a60 net/ipv6/ip6input.c:438 ip6inputfinish net/ipv6/ip6input.c:483 [inline] NFHOOK include/linux/netfilter.h:314 [inline] ip6input+0x15d/0x430 net/ipv6/ip6input.c:492 ip6mcinput+0xa7e/0xc80 net/ipv6/ip6input.c:586 dstinput include/net/dst.h:461 [inline] ip6rcvfinish+0x5db/0x870 net/ipv6/ip6input.c:79 NFHOOK include/linux/netfilter.h:314 [inline] ipv6rcv+0xda/0x390 net/ipv6/ip6input.c:310 _netifreceiveskbonecore net/core/dev.c:5532 [inline] _netifreceiveskb+0x1a6/0x5a0 net/core/dev.c:5646 netifreceiveskbinternal net/core/dev.c:5732 [inline] netifreceiveskb+0x58/0x660 net/core/dev.c:5791 tunrxbatched+0x3ee/0x980 drivers/net/tun.c:1555 tungetuser+0x53af/0x66d0 drivers/net/tun.c:2002 tunchrwriteiter+0x3af/0x5d0 drivers/net/tun.c:2048 callwriteiter include/linux/fs.h:2084 [inline] newsyncwrite fs/readwrite.c:497 [inline] vfswrite+0x786/0x1200 fs/readwrite.c:590 ksyswrite+0x20f/0x4c0 fs/readwrite.c:643 _dosyswrite fs/readwrite.c:655 [inline] _sesyswrite fs/readwrite.c:652 [inline] _x64syswrite+0x93/0xd0 fs/readwrite.c:652 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x6d/0x140 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+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 tunallocskb drivers/net/tun.c:1531 [inline] tungetuser+0x1e8a/0x66d0 drivers/net/tun.c:1846 tunchrwriteiter+0x3af/0x5d0 drivers/net/tun.c:2048 callwriteiter include/linux/fs.h:2084 [inline] newsyncwrite fs/readwrite.c:497 [inline] vfswrite+0x786/0x1200 fs/readwrite.c:590 ksyswrite+0x20f/0x4c0 fs/readwrite.c:643 _dosyswrite fs/readwrite.c:655 [inline] _sesyswrite fs/readwrite.c:652 [inline] _x64syswrite+0x93/0xd0 fs/readwrite.c:652 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x6d/0x140 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b

CPU: 0 PID: 5034 Comm: syz-executor331 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023(CVE-2024-26641)

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:

drm/amd/display: Add NULL test for 'timing generator' in 'dcn21setpipe()'

In "u32 otginst = pipectx->streamres.tg->inst;" pipectx->stream_res.tg could be NULL, it is relying on the caller to ensure the tg is not NULL.(CVE-2024-26661)

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

tunnels: fix out of bounds access when building IPv6 PMTU error

If the ICMPv6 error is built from a non-linear skb we get the following splat,

BUG: KASAN: slab-out-of-bounds in docsum+0x220/0x240 Read of size 4 at addr ffff88811d402c80 by task netperf/820 CPU: 0 PID: 820 Comm: netperf Not tainted 6.8.0-rc1+ #543 ... kasanreport+0xd8/0x110 docsum+0x220/0x240 csumpartial+0xc/0x20 skbtunnelcheckpmtu+0xeb9/0x3280 vxlanxmitone+0x14c2/0x4080 vxlanxmit+0xf61/0x5c00 devhardstartxmit+0xfb/0x510 _devqueuexmit+0x7cd/0x32a0 brdevqueuepushxmit+0x39d/0x6a0

Use skbchecksum instead of csumpartial who cannot deal with non-linear SKBs.(CVE-2024-26665)

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:

net: stmmac: xgmac: fix handling of DPP safety error for DMA channels

Commit 56e58d6c8a56 ("net: stmmac: Implement Safety Features in XGMAC core") checks and reports safety errors, but leaves the Data Path Parity Errors for each channel in DMA unhandled at all, lead to a storm of interrupt. Fix it by checking and clearing the DMADPPInterrupt_Status register.(CVE-2024-26684)

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:

iio: magnetometer: rm3100: add boundary check for the value read from RM3100REGTMRC

Recently, we encounter kernel crash in function rm3100commonprobe caused by out of bound access of array rm3100samprates (because of underlying hardware failures). Add boundary check to prevent out of bound access.(CVE-2024-26702)

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

parisc: Fix random data corruption from exception handler

The current exception handler implementation, which assists when accessing user space memory, may exhibit random data corruption if the compiler decides to use a different register than the specified register %r29 (defined in ASMEXCEPTIONTABLEREG) for the error code. If the compiler choose another register, the fault handler will nevertheless store -EFAULT into %r29 and thus trash whatever this register is used for. Looking at the assembly I found that this happens sometimes in emulate_ldd().

To solve the issue, the easiest solution would be if it somehow is possible to tell the fault handler which register is used to hold the error code. Using %0 or %1 in the inline assembly is not posssible as it will show up as e.g. %r29 (with the "%r" prefix), which the GNU assembler can not convert to an integer.

This patch takes another, better and more flexible approach: We extend the _extable (which is out of the execution path) by one 32-word. In this word we tell the compiler to insert the assembler instruction "or %r0,%r0,%reg", where %reg references the register which the compiler choosed for the error return code. In case of an access failure, the fault handler finds the _extable entry and can examine the opcode. The used register is encoded in the lowest 5 bits, and the fault handler can then store -EFAULT into this register.

Since we extend the _extable to 3 words we can't use the BUILDTIMETABLESORT config option any longer.(CVE-2024-26706)

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

net: hsr: remove WARNONCE() in sendhsrsupervisionframe()

Syzkaller reported [1] hitting a warning after failing to allocate resources for skb in hsrinitskb(). Since a WARNONCE() call will not help much in this case, it might be prudent to switch to netdevwarn_once(). At the very least it will suppress syzkaller reports such as [1].

Just in case, use netdevwarnonce() in sendprpsupervision_frame() for similar reasons.

[1] HSR: Could not send supervision frame WARNING: CPU: 1 PID: 85 at net/hsr/hsrdevice.c:294 sendhsrsupervisionframe+0x60a/0x810 net/hsr/hsrdevice.c:294 RIP: 0010:sendhsrsupervisionframe+0x60a/0x810 net/hsr/hsrdevice.c:294 ... Call Trace: <IRQ> hsrannounce+0x114/0x370 net/hsr/hsrdevice.c:382 calltimerfn+0x193/0x590 kernel/time/timer.c:1700 expiretimers kernel/time/timer.c:1751 [inline] _runtimers+0x764/0xb20 kernel/time/timer.c:2022 runtimersoftirq+0x58/0xd0 kernel/time/timer.c:2035 _dosoftirq+0x21a/0x8de kernel/softirq.c:553 invokesoftirq kernel/softirq.c:427 [inline] _irqexitrcu kernel/softirq.c:632 [inline] irqexitrcu+0xb7/0x120 kernel/softirq.c:644 sysvecapictimerinterrupt+0x95/0xb0 arch/x86/kernel/apic/apic.c:1076 </IRQ> <TASK> asmsysvecapictimer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:649 ...

This issue is also found in older kernels (at least up to 5.10).(CVE-2024-26707)

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

powerpc/kasan: Fix addr error caused by page alignment

In kasaninitregion, when kstart is not page aligned, at the begin of for loop, kcur = kstart & PAGEMASK is less than kstart, and then va = block + k_cur - k_start is less than block, the addr va is invalid, because the memory address space from va to block is not alloced by memblockalloc, which will not be reserved by memblock_reserve later, it will be used by other places.

As a result, memory overwriting occurs.

for example: int _init _weak kasaninitregion(void start, size_t size) { [...] / if say block(dcd97000) kstart(feef7400) kend(feeff3fe) / block = memblock_alloc(k_end - k_start, PAGE_SIZE); [...] for (k_cur = k_start & PAGE_MASK; k_cur < k_end; k_cur += PAGE_SIZE) { / at the begin of for loop * block(dcd97000) va(dcd96c00) kcur(feef7000) kstart(feef7400) * va(dcd96c00) is less than block(dcd97000), va is invalid */ void *va = block + kcur - kstart; [...] } [...] }

Therefore, page alignment is performed on kstart before memblockalloc() to ensure the validity of the VA address.(CVE-2024-26712)

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:

devlink: fix possible use-after-free and memory leaks in devlink_init()

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

Make an unregister in case of unsuccessful registration.(CVE-2024-26734)

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

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:

spi: hisi-sfc-v3xx: Return IRQ_NONE if no interrupts were detected

Return IRQ_NONE from the interrupt handler when no interrupt was detected. Because an empty interrupt will cause a null pointer error:

Unable to handle kernel NULL pointer dereference at virtual

address 0000000000000008 Call trace: complete+0x54/0x100 hisisfcv3xxisr+0x2c/0x40 [spihisisfcv3xx] _handleirqeventpercpu+0x64/0x1e0 handleirqevent+0x7c/0x1cc(CVE-2024-26776)

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

mptcp: fix double-free on socket dismantle

when MPTCP server accepts an incoming connection, it clones its listener socket. However, the pointer to 'inet_opt' for the new socket has the same value as the original one: as a consequence, on program exit it's possible to observe the following splat:

BUG: KASAN: double-free in inetsockdestruct+0x54f/0x8b0 Free of addr ffff888485950880 by task swapper/25/0

CPU: 25 PID: 0 Comm: swapper/25 Kdump: loaded Not tainted 6.8.0-rc1+ #609 Hardware name: Supermicro SYS-6027R-72RF/X9DRH-7TF/7F/iTF/iF, BIOS 3.0 07/26/2013 Call Trace: <IRQ> dumpstacklvl+0x32/0x50 printreport+0xca/0x620 kasanreportinvalidfree+0x64/0x90 _kasanslabfree+0x1aa/0x1f0 kfree+0xed/0x2e0 inetsockdestruct+0x54f/0x8b0 _skdestruct+0x48/0x5b0 rcudobatch+0x34e/0xd90 rcucore+0x559/0xac0 _dosoftirq+0x183/0x5a4 irqexitrcu+0x12d/0x170 sysvecapictimerinterrupt+0x6b/0x80 </IRQ> <TASK> asmsysvecapictimerinterrupt+0x16/0x20 RIP: 0010:cpuidleenterstate+0x175/0x300 Code: 30 00 0f 84 1f 01 00 00 83 e8 01 83 f8 ff 75 e5 48 83 c4 18 44 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc fb 45 85 ed <0f> 89 60 ff ff ff 48 c1 e5 06 48 c7 43 18 00 00 00 00 48 83 44 2b RSP: 0018:ffff888481cf7d90 EFLAGS: 00000202 RAX: 0000000000000000 RBX: ffff88887facddc8 RCX: 0000000000000000 RDX: 1ffff1110ff588b1 RSI: 0000000000000019 RDI: ffff88887fac4588 RBP: 0000000000000004 R08: 0000000000000002 R09: 0000000000043080 R10: 0009b02ea273363f R11: ffff88887fabf42b R12: ffffffff932592e0 R13: 0000000000000004 R14: 0000000000000000 R15: 00000022c880ec80 cpuidleenter+0x4a/0xa0 doidle+0x310/0x410 cpustartupentry+0x51/0x60 startsecondary+0x211/0x270 secondarystartup64noverify+0x184/0x18b </TASK>

Allocated by task 6853: kasansavestack+0x1c/0x40 kasansavetrack+0x10/0x30 _kasankmalloc+0xa6/0xb0 _kmalloc+0x1eb/0x450 cipsov4socksetattr+0x96/0x360 netlblsocksetattr+0x132/0x1f0 selinuxnetlblsocketpostcreate+0x6c/0x110 selinuxsocketpostcreate+0x37b/0x7f0 securitysocketpostcreate+0x63/0xb0 _sockcreate+0x305/0x450 _syssocketcreate.part.23+0xbd/0x130 _syssocket+0x37/0xb0 _x64syssocket+0x6f/0xb0 dosyscall64+0x83/0x160 entrySYSCALL64afterhwframe+0x6e/0x76

Freed by task 6858: kasansavestack+0x1c/0x40 kasansavetrack+0x10/0x30 kasansavefreeinfo+0x3b/0x60 _kasanslabfree+0x12c/0x1f0 kfree+0xed/0x2e0 inetsockdestruct+0x54f/0x8b0 _skdestruct+0x48/0x5b0 subflowulprelease+0x1f0/0x250 tcpcleanupulp+0x6e/0x110 tcpv4destroysock+0x5a/0x3a0 inetcskdestroysock+0x135/0x390 tcpfin+0x416/0x5c0 tcpdataqueue+0x1bc8/0x4310 tcprcvstateprocess+0x15a3/0x47b0 tcpv4dorcv+0x2c1/0x990 tcpv4rcv+0x41fb/0x5ed0 ipprotocoldeliverrcu+0x6d/0x9f0 iplocaldeliverfinish+0x278/0x360 iplocaldeliver+0x182/0x2c0 iprcv+0xb5/0x1c0 _netifreceiveskbonecore+0x16e/0x1b0 processbacklog+0x1e3/0x650 _napipoll+0xa6/0x500 netrxaction+0x740/0xbb0 _dosoftirq+0x183/0x5a4

The buggy address belongs to the object at ffff888485950880 which belongs to the cache kmalloc-64 of size 64 The buggy address is located 0 bytes inside of 64-byte region [ffff888485950880, ffff8884859508c0)

The buggy address belongs to the physical page: page:0000000056d1e95e refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888485950700 pfn:0x485950 flags: 0x57ffffc0000800(slab|node=1|zone=2|lastcpupid=0x1fffff) page_type: 0xffffffff() raw: 0057ffffc0000800 ffff88810004c640 ffffea00121b8ac0 dead000000000006 raw: ffff888485950700 0000000000200019 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffff888485950780: fa fb fb ---truncated---(CVE-2024-26782)

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:

netfilter: nftchainfilter: handle NETDEV_UNREGISTER for inet/ingress basechain

Remove netdevice from inet/ingress basechain in case NETDEV_UNREGISTER event is reported, otherwise a stale reference to netdevice remains in the hook list.(CVE-2024-26808)

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

netfilter: nftsetpipapo: release elements in clone only from destroy path

Clone already always provides a current view of the lookup table, use it to destroy the set, otherwise it is possible to destroy elements twice.

This fix requires:

212ed75dc5fb ("netfilter: nf_tables: integrate pipapo into commit protocol")

which came after:

9827a0e6e23b ("netfilter: nftsetpipapo: release elements in clone from abort path").(CVE-2024-26809)

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

netfilter: nfconntrackh323: Add protection for bmp length out of range

UBSAN load reports an exception of BRK#5515 SHIFT_ISSUE:Bitwise shifts that are out of bounds for their data type.

vmlinux getbitmap(b=75) + 712 <net/netfilter/nfconntrackh323asn1.c:0> vmlinux decodeseq(bs=0xFFFFFFD008037000, f=0xFFFFFFD008037018, level=134443100) + 1956 <net/netfilter/nfconntrackh323asn1.c:592> vmlinux decodechoice(base=0xFFFFFFD0080370F0, level=23843636) + 1216 <net/netfilter/nfconntrackh323asn1.c:814> vmlinux decodeseq(f=0xFFFFFFD0080371A8, level=134443500) + 812 <net/netfilter/nfconntrackh323asn1.c:576> vmlinux decodechoice(base=0xFFFFFFD008037280, level=0) + 1216 <net/netfilter/nfconntrackh323asn1.c:814> vmlinux DecodeRasMessage() + 304 <net/netfilter/nfconntrackh323asn1.c:833> vmlinux rashelp() + 684 <net/netfilter/nfconntrackh323main.c:1728> vmlinux nfconfirm() + 188 <net/netfilter/nfconntrackproto.c:137>

Due to abnormal data in skb->data, the extension bitmap length exceeds 32 when decoding ras message then uses the length to make a shift operation. It will change into negative after several loop. UBSAN load could detect a negative shift as an undefined behaviour and reports exception. So we add the protection to avoid the length exceeding 32. Or else it will return out of range error and stop decoding.(CVE-2024-26851)

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

md: fix kmemleak of rdev->serial

If kobjectadd() is fail in bindrdevtoarray(), 'rdev->serial' will be alloc not be freed, and kmemleak occurs.

unreferenced object 0xffff88815a350000 (size 49152): comm "mdadm", pid 789, jiffies 4294716910 hex dump (first 32 bytes): 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 00 ................ backtrace (crc f773277a): [<0000000058b0a453>] kmemleakalloc+0x61/0xe0 [<00000000366adf14>] _kmalloclargenode+0x15e/0x270 [<000000002e82961b>] _kmallocnode.cold+0x11/0x7f [<00000000f206d60a>] kvmallocnode+0x74/0x150 [<0000000034bf3363>] rdevinitserial+0x67/0x170 [<0000000010e08fe9>] mddevcreateserialpool+0x62/0x220 [<00000000c3837bf0>] bindrdevtoarray+0x2af/0x630 [<0000000073c28560>] mdaddnewdisk+0x400/0x9f0 [<00000000770e30ff>] mdioctl+0x15bf/0x1c10 [<000000006cfab718>] blkdevioctl+0x191/0x3f0 [<0000000085086a11>] vfsioctl+0x22/0x60 [<0000000018b656fe>] _x64sysioctl+0xba/0xe0 [<00000000e54e675e>] dosyscall64+0x71/0x150 [<000000008b0ad622>] entrySYSCALL64afterhwframe+0x6c/0x74(CVE-2024-26900)

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

dosysnametohandle(): use kzalloc() to fix kernel-infoleak

syzbot identified a kernel information leak vulnerability in dosysnametohandle() and issued the following report [1].

[1] "BUG: KMSAN: kernel-infoleak in instrumentcopytouser include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copytouser+0xbc/0x100 lib/usercopy.c:40 instrumentcopytouser include/linux/instrumented.h:114 [inline] copytouser+0xbc/0x100 lib/usercopy.c:40 copytouser include/linux/uaccess.h:191 [inline] dosysnametohandle fs/fhandle.c:73 [inline] _dosysnametohandleat fs/fhandle.c:112 [inline] _sesysnametohandleat+0x949/0xb10 fs/fhandle.c:94 _x64sysnametohandle_at+0xe4/0x140 fs/fhandle.c:94 ...

Uninit was created at: slabpostallochook+0x129/0xa70 mm/slab.h:768 slaballocnode mm/slub.c:3478 [inline] _kmemcacheallocnode+0x5c9/0x970 mm/slub.c:3517 _dokmallocnode mm/slabcommon.c:1006 [inline] _kmalloc+0x121/0x3c0 mm/slabcommon.c:1020 kmalloc include/linux/slab.h:604 [inline] dosysnametohandle fs/fhandle.c:39 [inline] _dosysnametohandleat fs/fhandle.c:112 [inline] _sesysnametohandleat+0x441/0xb10 fs/fhandle.c:94 _x64sysnametohandle_at+0xe4/0x140 fs/fhandle.c:94 ...

Bytes 18-19 of 20 are uninitialized Memory access of size 20 starts at ffff888128a46380 Data copied to user address 0000000020000240"

Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to solve the problem.(CVE-2024-26901)

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

Bluetooth: rfcomm: Fix null-ptr-deref in rfcommchecksecurity

During our fuzz testing of the connection and disconnection process at the RFCOMM layer, we discovered this bug. By comparing the packets from a normal connection and disconnection process with the testcase that triggered a KASAN report. We analyzed the cause of this bug as follows:

1. In the packets captured during a normal connection, the host sends a Read Encryption Key Size type of HCI_CMD packet (Command Opcode: 0x1408) to the controller to inquire the length of encryption key.After receiving this packet, the controller immediately replies with a Command Completepacket (Event Code: 0x0e) to return the Encryption Key Size.

2. In our fuzz test case, the timing of the controller's response to this packet was delayed to an unexpected point: after the RFCOMM and L2CAP layers had disconnected but before the HCI layer had disconnected.

3. After receiving the Encryption Key Size Response at the time described in point 2, the host still called the rfcommchecksecurity function. However, by this time struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn; had already been released, and when the function executed return hci_conn_security(conn->hcon, d->sec_level, auth_type, d->out);, specifically when accessing conn->hcon, a null-ptr-deref error occurred.

To fix this bug, check if sk->sk_state is BTCLOSED before calling rfcommrecvframe in rfcommprocess_rx.(CVE-2024-26903)

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

RDMA/mlx5: Fix fortify source warning while accessing Eth segment

------------[ cut here ]------------ memcpy: detected field-spanning write (size 56) of single field "eseg->inlinehdr.start" at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2) WARNING: CPU: 0 PID: 293779 at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 mlx5ibpostsend+0x191b/0x1a60 [mlx5ib] Modules linked in: 8021q garp mrp stp llc rdmaucm(OE) rdmacm(OE) iwcm(OE) ibipoib(OE) ibcm(OE) ibumad(OE) mlx5ib(OE) ibuverbs(OE) ibcore(OE) mlx5core(OE) pcihypervintf mlxdevm(OE) mlxcompat(OE) tls mlxfw(OE) psample nftfibinet nftfibipv4 nftfibipv6 nftfib nftrejectinet nfrejectipv4 nfrejectipv6 nftreject nftct nftchainnat nfnat nfconntrack nfdefragipv6 nfdefragipv4 ipset nftables libcrc32c nfnetlink mstpciconf(OE) knem(OE) vfiopci vfiopcicore vfioiommutype1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrmuser xfrmalgo ipmidevintf ipmimsghandler binfmtmisc crct10difpclmul crc32pclmul polyvalclmulni polyvalgeneric ghashclmulniintel sha512ssse3 sndpcsp aesniintel cryptosimd cryptd sndpcm sndtimer joydev snd soundcore inputleds serioraw evbug nfsd authrpcgss nfsacl lockd grace schfqcodel sunrpc drm efipstore iptables xtables autofs4 psmouse virtionet netfailover failover floppy [last unloaded: mlxcompat(OE)] CPU: 0 PID: 293779 Comm: ssh Tainted: G OE 6.2.0-32-generic #32~22.04.1-Ubuntu Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:mlx5ibpostsend+0x191b/0x1a60 [mlx5ib] Code: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 c6 05 57 0c 03 00 01 e8 95 4d 93 da <0f> 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7 RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8 R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80 FS: 00007fc03b444c80(0000) GS:ffff963a3dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? showregs+0x72/0x90 ? mlx5ibpostsend+0x191b/0x1a60 [mlx5ib] ? _warn+0x8d/0x160 ? mlx5ibpostsend+0x191b/0x1a60 [mlx5ib] ? reportbug+0x1bb/0x1d0 ? handlebug+0x46/0x90 ? excinvalidop+0x19/0x80 ? asmexcinvalidop+0x1b/0x20 ? mlx5ibpostsend+0x191b/0x1a60 [mlx5ib] mlx5ibpostsendnodrain+0xb/0x20 [mlx5ib] ipoibsend+0x2ec/0x770 [ibipoib] ipoibstartxmit+0x5a0/0x770 [ibipoib] devhardstartxmit+0x8e/0x1e0 ? validatexmitskblist+0x4d/0x80 schdirectxmit+0x116/0x3a0 _devxmitskb+0x1fd/0x580 _devqueuexmit+0x284/0x6b0 ? _rawspinunlockirq+0xe/0x50 ? _flushwork.isra.0+0x20d/0x370 ? pushpseudoheader+0x17/0x40 [ibipoib] neighconnectedoutput+0xcd/0x110 ipfinishoutput2+0x179/0x480 ? _smpcallsinglequeue+0x61/0xa0 _ipfinishoutput+0xc3/0x190 ipfinishoutput+0x2e/0xf0 ipoutput+0x78/0x110 ? _pfxipfinishoutput+0x10/0x10 iplocalout+0x64/0x70 _ipqueuexmit+0x18a/0x460 ipqueuexmit+0x15/0x30 _tcptransmitskb+0x914/0x9c0 tcpwritexmit+0x334/0x8d0 tcppushone+0x3c/0x60 tcpsendmsglocked+0x2e1/0xac0 tcpsendmsg+0x2d/0x50 inetsendmsg+0x43/0x90 socksendmsg+0x68/0x80 sockwriteiter+0x93/0x100 vfswrite+0x326/0x3c0 ksyswrite+0xbd/0xf0 ? dosyscall64+0x69/0x90 _x64syswrite+0x19/0x30 dosyscall_ ---truncated---(CVE-2024-26907)

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-26908)

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

net: openvswitch: Fix Use-After-Free in ovsctexit

Since kfreercu, which is called in the hlistforeachentryrcu traversal of ovsctlimitexit, is not part of the RCU read critical section, it is possible that the RCU grace period will pass during the traversal and the key will be free.

To prevent this, it should be changed to hlistforeachentrysafe.(CVE-2024-27395)

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

net: gtp: Fix Use-After-Free in gtp_dellink

Since callrcu, which is called in the hlistforeachentryrcu traversal of gtpdellink, is not part of the RCU read critical section, it is possible that the RCU grace period will pass during the traversal and the key will be free.

To prevent this, it should be changed to hlistforeachentrysafe.(CVE-2024-27396)

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

cpumap: Zero-initialise xdprxqinfo struct before running XDP program

When running an XDP program that is attached to a cpumap entry, we don't initialise the xdprxqinfo data structure being used in the xdpbuff that backs the XDP program invocation. Tobias noticed that this leads to random values being returned as the xdpmd->rxqueueindex value for XDP programs running in a cpumap.

This means we're basically returning the contents of the uninitialised memory, which is bad. Fix this by zero-initialising the rxq data structure before running the XDP program.(CVE-2024-27431)

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

wifi: iwlwifi: dbg-tlv: ensure NUL termination

The iwlfwinidebuginfo_tlv is used as a string, so we must ensure the string is terminated correctly before using it.(CVE-2024-35845)

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

btrfs: fix information leak in btrfsioctllogicaltoino()

Syzbot reported the following information leak for in btrfsioctllogicaltoino():

BUG: KMSAN: kernel-infoleak in instrumentcopytouser include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copytouser+0xbc/0x110 lib/usercopy.c:40 instrumentcopytouser include/linux/instrumented.h:114 [inline] copytouser+0xbc/0x110 lib/usercopy.c:40 copytouser include/linux/uaccess.h:191 [inline] btrfsioctllogicaltoino+0x440/0x750 fs/btrfs/ioctl.c:3499 btrfsioctl+0x714/0x1260 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:904 [inline] _sesysioctl+0x261/0x450 fs/ioctl.c:890 _x64sysioctl+0x96/0xe0 fs/ioctl.c:890 x64syscall+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls64.h:17 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcf/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f

Uninit was created at: _kmalloclargenode+0x231/0x370 mm/slub.c:3921 _dokmallocnode mm/slub.c:3954 [inline] _kmallocnode+0xb07/0x1060 mm/slub.c:3973 kmallocnode include/linux/slab.h:648 [inline] kvmallocnode+0xc0/0x2d0 mm/util.c:634 kvmalloc include/linux/slab.h:766 [inline] initdatacontainer+0x49/0x1e0 fs/btrfs/backref.c:2779 btrfsioctllogicaltoino+0x17c/0x750 fs/btrfs/ioctl.c:3480 btrfsioctl+0x714/0x1260 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:904 [inline] _sesysioctl+0x261/0x450 fs/ioctl.c:890 _x64sysioctl+0x96/0xe0 fs/ioctl.c:890 x64syscall+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls64.h:17 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcf/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

Bytes 40-65535 of 65536 are uninitialized Memory access of size 65536 starts at ffff888045a40000

This happens, because we're copying a 'struct btrfsdatacontainer' back to user-space. This btrfsdatacontainer is allocated in 'initdatacontainer()' via kvmalloc(), which does not zero-fill the memory.

Fix this by using kvzalloc() which zeroes out the memory on allocation.(CVE-2024-35849)