OESA-2024-1650

The Linux Kernel, the operating system core itself.

Security Fix(es):

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:

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:

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:

usb: aqc111: check packet for fixup for true limit

If a device sends a packet that is inbetween 0 and sizeof(u64) the value passed to skb_trim() as length will wrap around ending up as some very large value.

The driver will then proceed to parse the header located at that position, which will either oops or process some random value.

The fix is to check against sizeof(u64) rather than 0, which the driver currently does. The issue exists since the introduction of the driver.(CVE-2023-52655)

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)

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:

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:

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:

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:

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:

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:

nfc: nci: free rxdatareassembly skb on NCI device cleanup

rxdatareassembly skb is stored during NCI data exchange for processing fragmented packets. It is dropped only when the last fragment is processed or when an NTF packet with NCIOPRFDEACTIVATENTF opcode is received. However, the NCI device may be deallocated before that which leads to skb leak.

As by design the rxdatareassembly skb is bound to the NCI device and nothing prevents the device to be freed before the skb is processed in some way and cleaned, free it on the NCI device cleanup.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2024-26825)

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)

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:

af_unix: Fix garbage collector racing against connect()

Garbage collector does not take into account the risk of embryo getting enqueued during the garbage collection. If such embryo has a peer that carries SCMRIGHTS, two consecutive passes of scanchildren() may see a different set of children. Leading to an incorrectly elevated inflight count, and then a dangling pointer within the gcinflightlist.

sockets are AFUNIX/SOCKSTREAM S is an unconnected socket L is a listening in-flight socket bound to addr, not in fdtable V's fd will be passed via sendmsg(), gets inflight count bumped

connect(S, addr) sendmsg(S, [V]); close(V) _unixgc() ---------------- ------------------------- -----------

NS = unixcreate1() skb1 = sockwmalloc(NS) L = unixfindother(addr) unixstatelock(L) unix_peer(S) = NS // V count=1 inflight=0

        NS = unix_peer(S)
        skb2 = sock_alloc()
        skb_queue_tail(NS, skb2[V])

        // V became in-flight
        // V count=2 inflight=1

        close(V)

        // V count=1 inflight=1
        // GC candidate condition met

                    for u in gc_inflight_list:
                      if (total_refs == inflight_refs)
                        add u to gc_candidates

                    // gc_candidates={L, V}

                    for u in gc_candidates:
                      scan_children(u, dec_inflight)

                    // embryo (skb1) was not
                    // reachable from L yet, so V's
                    // inflight remains unchanged

_skbqueuetail(L, skb1) unixstateunlock(L) for u in gccandidates: if (u.inflight) scanchildren(u, incinflightmovetail)

                    // V count=1 inflight=2 (!)

If there is a GC-candidate listening socket, lock/unlock its state. This makes GC wait until the end of any ongoing connect() to that socket. After flipping the lock, a possibly SCM-laden embryo is already enqueued. And if there is another embryo coming, it can not possibly carry SCMRIGHTS. At this point, unixinflight() can not happen because unixgclock is already taken. Inflight graph remains unaffected.(CVE-2024-26923)

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

binder: check offset alignment in bindergetobject()

Commit 6d98eb95b450 ("binder: avoid potential data leakage when copying txn") introduced changes to how binder objects are copied. In doing so, it unintentionally removed an offset alignment check done through calls to binderalloccopyfrombuffer() -> check_buffer().

These calls were replaced in bindergetobject() with copyfromuser(), so now an explicit offset alignment check is needed here. This avoids later complications when unwinding the objects gets harder.

It is worth noting this check existed prior to commit 7a67a39320df ("binder: add function to copy binder object from buffer"), likely removed due to redundancy at the time.(CVE-2024-26926)

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

drm/i915/gt: Reset queuepriorityhint on parking

Originally, with strict in order execution, we could complete execution only when the queue was empty. Preempt-to-busy allows replacement of an active request that may complete before the preemption is processed by HW. If that happens, the request is retired from the queue, but the queuepriorityhint remains set, preventing direct submission until after the next CS interrupt is processed.

This preempt-to-busy race can be triggered by the heartbeat, which will also act as the power-management barrier and upon completion allow us to idle the HW. We may process the completion of the heartbeat, and begin parking the engine before the CS event that restores the queuepriorityhint, causing us to fail the assertion that it is MIN.

<3>[ 166.210729] _enginepark:283 GEMBUGON(engine->schedengine->queuepriorityhint != (-((int)(~0U >> 1)) - 1)) <0>[ 166.210781] Dumping ftrace buffer: <0>[ 166.210795] --------------------------------- ... <0>[ 167.302811] drmfdin-1097 2..s1. 165741070us : traceports: 0000:00:02.0 rcs0: promote { ccid:20 1217:2 prio 0 } <0>[ 167.302861] drmfdin-1097 2d.s2. 165741072us : execlistssubmissiontasklet: 0000:00:02.0 rcs0: preempting last=1217:2, prio=0, hint=2147483646 <0>[ 167.302928] drmfdin-1097 2d.s2. 165741072us : _i915requestunsubmit: 0000:00:02.0 rcs0: fence 1217:2, current 0 <0>[ 167.302992] drmfdin-1097 2d.s2. 165741073us : _i915requestsubmit: 0000:00:02.0 rcs0: fence 3:4660, current 4659 <0>[ 167.303044] drmfdin-1097 2d.s1. 165741076us : execlistssubmissiontasklet: 0000:00:02.0 rcs0: context:3 schedule-in, ccid:40 <0>[ 167.303095] drmfdin-1097 2d.s1. 165741077us : traceports: 0000:00:02.0 rcs0: submit { ccid:40 3:4660* prio 2147483646 } <0>[ 167.303159] kworker/-89 11..... 165741139us : i915requestretire.part.0: 0000:00:02.0 rcs0: fence c90:2, current 2 <0>[ 167.303208] kworker/-89 11..... 165741148us : _intelcontextdounpin: 0000:00:02.0 rcs0: context:c90 unpin <0>[ 167.303272] kworker/-89 11..... 165741159us : i915requestretire.part.0: 0000:00:02.0 rcs0: fence 1217:2, current 2 <0>[ 167.303321] kworker/-89 11..... 165741166us : _intelcontextdounpin: 0000:00:02.0 rcs0: context:1217 unpin <0>[ 167.303384] kworker/-89 11..... 165741170us : i915requestretire.part.0: 0000:00:02.0 rcs0: fence 3:4660, current 4660 <0>[ 167.303434] kworker/-89 11d..1. 165741172us : _intelcontextretire: 0000:00:02.0 rcs0: context:1216 retire runtime: { total:56028ns, avg:56028ns } <0>[ 167.303484] kworker/-89 11..... 165741198us : _enginepark: 0000:00:02.0 rcs0: parked <0>[ 167.303534] <idle>-0 5d.H3. 165741207us : execlistsirqhandler: 0000:00:02.0 rcs0: semaphore yield: 00000040 <0>[ 167.303583] kworker/-89 11..... 165741397us : _intelcontextretire: 0000:00:02.0 rcs0: context:1217 retire runtime: { total:325575ns, avg:0ns } <0>[ 167.303756] kworker/-89 11..... 165741777us : _intelcontextretire: 0000:00:02.0 rcs0: context:c90 retire runtime: { total:0ns, avg:0ns } <0>[ 167.303806] kworker/-89 11..... 165742017us : _enginepark: _enginepark:283 GEMBUGON(engine->schedengine->queuepriorityhint != (-((int)(~0U >> 1)) - 1)) <0>[ 167.303811] --------------------------------- <4>[ 167.304722] ------------[ cut here ]------------ <2>[ 167.304725] kernel BUG at drivers/gpu/drm/i915/gt/intelenginepm.c:283! <4>[ 167.304731] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI <4>[ 167.304734] CPU: 11 PID: 89 Comm: kworker/11:1 Tainted: G W 6.8.0-rc2-CIDRM14193-gc655e0fd2804+ #1 <4>[ 167.304736] Hardware name: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 04/21/2022 <4>[ 167.304738] Workqueue: i915-unordered retirework_handler [i915] <4>[ 16 ---truncated---(CVE-2024-26937)

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:

Bluetooth: Fix use-after-free bugs caused by scosocktimeout

When the sco connection is established and then, the sco socket is releasing, timeoutwork will be scheduled to judge whether the sco disconnection is timeout. The sock will be deallocated later, but it is dereferenced again in scosock_timeout. As a result, the use-after-free bugs will happen. The root cause is shown below:

Cleanup Thread               |      Worker Thread

scosockrelease | scosockclose | _scosockclose | scosocksettimer | scheduledelayedwork | scosockkill | (wait a time) sockput(sk) //FREE | scosocktimeout | sockhold(sk) //USE

The KASAN report triggered by POC is shown below:

[ 95.890016] ================================================================== [ 95.890496] BUG: KASAN: slab-use-after-free in scosocktimeout+0x5e/0x1c0 [ 95.890755] Write of size 4 at addr ffff88800c388080 by task kworker/0:0/7 ... [ 95.890755] Workqueue: events scosocktimeout [ 95.890755] Call Trace: [ 95.890755] <TASK> [ 95.890755] dumpstacklvl+0x45/0x110 [ 95.890755] printaddressdescription+0x78/0x390 [ 95.890755] printreport+0x11b/0x250 [ 95.890755] ? _virtaddrvalid+0xbe/0xf0 [ 95.890755] ? scosocktimeout+0x5e/0x1c0 [ 95.890755] kasanreport+0x139/0x170 [ 95.890755] ? updateloadavg+0xe5/0x9f0 [ 95.890755] ? scosocktimeout+0x5e/0x1c0 [ 95.890755] kasancheckrange+0x2c3/0x2e0 [ 95.890755] scosocktimeout+0x5e/0x1c0 [ 95.890755] processonework+0x561/0xc50 [ 95.890755] workerthread+0xab2/0x13c0 [ 95.890755] ? prcontwork+0x490/0x490 [ 95.890755] kthread+0x279/0x300 [ 95.890755] ? prcontwork+0x490/0x490 [ 95.890755] ? kthreadblkcg+0xa0/0xa0 [ 95.890755] retfromfork+0x34/0x60 [ 95.890755] ? kthreadblkcg+0xa0/0xa0 [ 95.890755] retfromforkasm+0x11/0x20 [ 95.890755] </TASK> [ 95.890755] [ 95.890755] Allocated by task 506: [ 95.890755] kasansavetrack+0x3f/0x70 [ 95.890755] _kasankmalloc+0x86/0x90 [ 95.890755] _kmalloc+0x17f/0x360 [ 95.890755] skprotalloc+0xe1/0x1a0 [ 95.890755] skalloc+0x31/0x4e0 [ 95.890755] btsockalloc+0x2b/0x2a0 [ 95.890755] scosockcreate+0xad/0x320 [ 95.890755] btsockcreate+0x145/0x320 [ 95.890755] _sockcreate+0x2e1/0x650 [ 95.890755] _syssocket+0xd0/0x280 [ 95.890755] _x64syssocket+0x75/0x80 [ 95.890755] dosyscall64+0xc4/0x1b0 [ 95.890755] entrySYSCALL64afterhwframe+0x67/0x6f [ 95.890755] [ 95.890755] Freed by task 506: [ 95.890755] kasansavetrack+0x3f/0x70 [ 95.890755] kasansavefreeinfo+0x40/0x50 [ 95.890755] poisonslabobject+0x118/0x180 [ 95.890755] _kasanslabfree+0x12/0x30 [ 95.890755] kfree+0xb2/0x240 [ 95.890755] _skdestruct+0x317/0x410 [ 95.890755] scosockrelease+0x232/0x280 [ 95.890755] sockclose+0xb2/0x210 [ 95.890755] _fput+0x37f/0x770 [ 95.890755] taskworkrun+0x1ae/0x210 [ 95.890755] getsignal+0xe17/0xf70 [ 95.890755] archdosignalorrestart+0x3f/0x520 [ 95.890755] syscallexittousermode+0x55/0x120 [ 95.890755] dosyscall64+0xd1/0x1b0 [ 95.890755] entrySYSCALL64afterhwframe+0x67/0x6f [ 95.890755] [ 95.890755] The buggy address belongs to the object at ffff88800c388000 [ 95.890755] which belongs to the cache kmalloc-1k of size 1024 [ 95.890755] The buggy address is located 128 bytes inside of [ 95.890755] freed 1024-byte region [ffff88800c388000, ffff88800c388400) [ 95.890755] [ 95.890755] The buggy address belongs to the physical page: [ 95.890755] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88800c38a800 pfn:0xc388 [ 95.890755] head: order:3 entiremapcount:0 nrpagesmapped:0 pincount:0 [ 95.890755] ano ---truncated---(CVE-2024-27398)

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:

KVM: SVM: Flush pages under kvm->lock to fix UAF in svmregisterenc_region()

Do the cache flush of converted pages in svmregisterencregion() before dropping kvm->lock to fix use-after-free issues where region and/or its array of pages could be freed by a different task, e.g. if userspace has _unregisterencregion_locked() already queued up for the region.

Note, the "obvious" alternative of using local variables doesn't fully resolve the bug, as region->pages is also dynamically allocated. I.e. the region structure itself would be fine, but region->pages could be freed.

Flushing multiple pages under kvm->lock is unfortunate, but the entire flow is a rare slow path, and the manual flush is only needed on CPUs that lack coherency for encrypted memory.(CVE-2024-35791)

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)

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

pmdomain: ti: Add a null pointer check to the omapprmdomain_init

devm_kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity.(CVE-2024-35943)