OESA-2024-1766

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

tpmtisspi: Account for SPI header when allocating TPM SPI xfer buffer

The TPM SPI transfer mechanism uses MAXSPIFRAMESIZE for computing the maximum transfer length and the size of the transfer buffer. As such, it does not account for the 4 bytes of header that prepends the SPI data frame. This can result in out-of-bounds accesses and was confirmed with KASAN.

Introduce SPI_HDRSIZE to account for the header and use to allocate the transfer buffer.(CVE-2024-36477)

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

net: fix out-of-bounds access in ops_init

netallocgeneric is called by netalloc, which is called without any locking. It reads maxgenptrs, which is changed under pernetops_rwsem. It is read twice, first to allocate an array, then to set s.len, which is later used to limit the bounds of the array access.

It is possible that the array is allocated and another thread is registering a new pernet ops, increments maxgenptrs, which is then used to set s.len with a larger than allocated length for the variable array.

Fix it by reading maxgenptrs only once in netallocgeneric. If maxgenptrs is later incremented, it will be caught in netassigngeneric.(CVE-2024-36883)

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

gpiolib: cdev: fix uninitialised kfifo

If a line is requested with debounce, and that results in debouncing in software, and the line is subsequently reconfigured to enable edge detection then the allocation of the kfifo to contain edge events is overlooked. This results in events being written to and read from an uninitialised kfifo. Read events are returned to userspace.

Initialise the kfifo in the case where the software debounce is already active.(CVE-2024-36898)

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

ipv6: fib6rules: avoid possible NULL dereference in fib6rule_action()

syzbot is able to trigger the following crash [1], caused by unsafe ip6dstidev() use.

Indeed ip6dstidev() can return NULL, and must always be checked.

[1]

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:_fib6ruleaction net/ipv6/fib6rules.c:237 [inline] RIP: 0010:fib6ruleaction+0x241/0x7b0 net/ipv6/fib6rules.c:267 Code: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 <42> 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4c RSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700 RDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760 RBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bd R10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000 R13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00 FS: 00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> fibruleslookup+0x62c/0xdb0 net/core/fibrules.c:317 fib6rulelookup+0x1fd/0x790 net/ipv6/fib6rules.c:108 ip6routeoutputflagsnoref net/ipv6/route.c:2637 [inline] ip6routeoutputflags+0x38e/0x610 net/ipv6/route.c:2649 ip6routeoutput include/net/ip6route.h:93 [inline] ip6dstlookuptail+0x189/0x11a0 net/ipv6/ip6output.c:1120 ip6dstlookupflow+0xb9/0x180 net/ipv6/ip6output.c:1250 sctpv6getdst+0x792/0x1e20 net/sctp/ipv6.c:326 sctptransportroute+0x12c/0x2e0 net/sctp/transport.c:455 sctpassocaddpeer+0x614/0x15c0 net/sctp/associola.c:662 sctpconnectnewasoc+0x31d/0x6c0 net/sctp/socket.c:1099 _sctpconnect+0x66d/0xe30 net/sctp/socket.c:1197 sctpconnect net/sctp/socket.c:4819 [inline] sctpinetconnect+0x149/0x1f0 net/sctp/socket.c:4834 _sysconnectfile net/socket.c:2048 [inline] _sysconnect+0x2df/0x310 net/socket.c:2065 _dosysconnect net/socket.c:2075 [inline] _sesysconnect net/socket.c:2072 [inline] _x64sysconnect+0x7a/0x90 net/socket.c:2072 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf5/0x240 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f(CVE-2024-36902)

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

ipv6: Fix potential uninit-value access in _ip6make_skb()

As it was done in commit fc1092f51567 ("ipv4: Fix uninit-value access in _ipmakeskb()") for IPv4, check FLOWIFLAGKNOWNNH on fl6->flowi6_flags instead of testing HDRINCL on the socket to avoid a race condition which causes uninit-value access.(CVE-2024-36903)

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

tcp: defer shutdown(SENDSHUTDOWN) for TCPSYN_RECV sockets

TCPSYNRECV state is really special, it is only used by cross-syn connections, mostly used by fuzzers.

In the following crash [1], syzbot managed to trigger a divide by zero in tcprcvspace_adjust()

A socket makes the following state transitions, without ever calling tcpinittransfer(), meaning tcpinitbuffer_space() is also not called.

     TCP_CLOSE

connect() TCPSYNSENT TCPSYNRECV shutdown() -> tcpshutdown(sk, SENDSHUTDOWN) TCPFINWAIT1

To fix this issue, change tcpshutdown() to not perform a TCPSYNRECV -> TCPFIN_WAIT1 transition, which makes no sense anyway.

When tcprcvstateprocess() later changes socket state from TCPSYNRECV to TCPESTABLISH, then look at sk->skshutdown to finally enter TCPFIN_WAIT1 state, and send a FIN packet from a sane socket state.

This means tcpsendfin() can now be called from BH context, and must use GFP_ATOMIC allocations.

[1] divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:tcprcvspaceadjust+0x2df/0x890 net/ipv4/tcpinput.c:767 Code: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 <48> f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48 RSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246 RAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7 R10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30 R13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da FS: 00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0 Call Trace: <TASK> tcprecvmsglocked+0x106d/0x25a0 net/ipv4/tcp.c:2513 tcprecvmsg+0x25d/0x920 net/ipv4/tcp.c:2578 inet6recvmsg+0x16a/0x730 net/ipv6/afinet6.c:680 sockrecvmsgnosec net/socket.c:1046 [inline] sockrecvmsg+0x109/0x280 net/socket.c:1068 _sysrecvmsg+0x1db/0x470 net/socket.c:2803 sysrecvmsg net/socket.c:2845 [inline] dorecvmmsg+0x474/0xae0 net/socket.c:2939 _sysrecvmmsg net/socket.c:3018 [inline] _dosysrecvmmsg net/socket.c:3041 [inline] _sesysrecvmmsg net/socket.c:3034 [inline] _x64sysrecvmmsg+0x199/0x250 net/socket.c:3034 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf5/0x240 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7faeb6363db9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012b RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9 RDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005 RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c R10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001(CVE-2024-36905)

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

scsi: bnx2fc: Remove spinlockbh while releasing resources after upload

The session resources are used by FW and driver when session is offloaded, once session is uploaded these resources are not used. The lock is not required as these fields won't be used any longer. The offload and upload calls are sequential, hence lock is not required.

This will suppress following BUG_ON():

[ 449.843143] ------------[ cut here ]------------ [ 449.848302] kernel BUG at mm/vmalloc.c:2727! [ 449.853072] invalid opcode: 0000 [#1] PREEMPT SMP PTI [ 449.858712] CPU: 5 PID: 1996 Comm: kworker/u24:2 Not tainted 5.14.0-118.el9.x8664 #1 Rebooting. [ 449.867454] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.3.4 11/08/2016 [ 449.876966] Workqueue: fcrporteq fcrportwork [libfc] [ 449.882910] RIP: 0010:vunmap+0x2e/0x30 [ 449.887098] Code: 00 65 8b 05 14 a2 f0 4a a9 00 ff ff 00 75 1b 55 48 89 fd e8 34 36 79 00 48 85 ed 74 0b 48 89 ef 31 f6 5d e9 14 fc ff ff 5d c3 <0f> 0b 0f 1f 44 00 00 41 57 41 56 49 89 ce 41 55 49 89 fd 41 54 41 [ 449.908054] RSP: 0018:ffffb83d878b3d68 EFLAGS: 00010206 [ 449.913887] RAX: 0000000080000201 RBX: ffff8f4355133550 RCX: 000000000d400005 [ 449.921843] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb83da53f5000 [ 449.929808] RBP: ffff8f4ac6675800 R08: ffffb83d878b3d30 R09: 00000000000efbdf [ 449.937774] R10: 0000000000000003 R11: ffff8f434573e000 R12: 0000000000001000 [ 449.945736] R13: 0000000000001000 R14: ffffb83da53f5000 R15: ffff8f43d4ea3ae0 [ 449.953701] FS: 0000000000000000(0000) GS:ffff8f529fc80000(0000) knlGS:0000000000000000 [ 449.962732] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 449.969138] CR2: 00007f8cf993e150 CR3: 0000000efbe10003 CR4: 00000000003706e0 [ 449.977102] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 449.985065] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 449.993028] Call Trace: [ 449.995756] _iommudmafree+0x96/0x100 [ 450.000139] bnx2fcfreesessionresc+0x67/0x240 [bnx2fc] [ 450.006171] bnx2fcuploadsession+0xce/0x100 [bnx2fc] [ 450.011910] bnx2fcrporteventhandler+0x9f/0x240 [bnx2fc] [ 450.018136] fcrportwork+0x103/0x5b0 [libfc] [ 450.023103] processonework+0x1e8/0x3c0 [ 450.027581] workerthread+0x50/0x3b0 [ 450.031669] ? rescuerthread+0x370/0x370 [ 450.036143] kthread+0x149/0x170 [ 450.039744] ? setkthreadstruct+0x40/0x40 [ 450.044411] retfromfork+0x22/0x30 [ 450.048404] Modules linked in: vfat msdos fat xfs nfslayoutnfsv41files rpcsecgsskrb5 authrpcgss nfsv4 dnsresolver dmservicetime qedf qed crc8 bnx2fc libfcoe libfc scsitransportfc intelraplmsr intelraplcommon x86pkgtempthermal intelpowerclamp dcdbas rapl intelcstate inteluncore meime pcspkr mei ipmissif lpcich ipmisi fuse zram ext4 mbcache jbd2 loop nfsv3 nfsacl nfs lockd grace fscache netfs irdma ice sdmod t10pi sg ibuverbs ibcore 8021q garp mrp stp llc mgag200 i2calgobit drmkmshelper syscopyarea sysfillrect sysimgblt mxmwmi fbsysfops cec crct10difpclmul ahci crc32pclmul bnx2x drm ghashclmulniintel libahci rfkill i40e libata megaraidsas mdio wmi sunrpc lrw dmcrypt dmroundrobin dmmultipath dmsnapshot dmbufio dmmirror dmregionhash dmlog dmzero dmmod linear raid10 raid456 asyncraid6recov asyncmemcpy asyncpq asyncxor asynctx raid6pq libcrc32c crc32cintel raid1 raid0 iscsiibft squashfs be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls [ 450.048497] libcxgbi libcxgb qla4xxx iscsibootsysfs iscsitcp libiscsitcp libiscsi scsitransportiscsi edd ipmidevintf ipmi_msghandler [ 450.159753] ---[ end trace 712de2c57c64abc8 ]---(CVE-2024-36919)

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

s390/qeth: Fix kernel panic after setting hsuid

Symptom: When the hsuid attribute is set for the first time on an IQD Layer3 device while the corresponding network interface is already UP, the kernel will try to execute a napi function pointer that is NULL.

Example:

[ 2057.572696] illegal operation: 0001 ilc:1 [#1] SMP [ 2057.572702] Modules linked in: afiucv qethl3 zfcp scsitransportfc sunrpc nftfibinet nftfibipv4 nftfibipv6 nftfib nftrejectinet nfrejectipv4 nfrejectipv6 nftreject nftct nftablesset nftchainnat nfnat nfconntrack nfdefragipv6 nfdefragipv4 ipset nftables libcrc32c nfnetlink ghashs390 prng xts aess390 dess390 de sgeneric sha3512s390 sha3256s390 sha512s390 vfioccw vfiomdev mdev vfioiommutype1 eadmsch vfio ext4 mbcache jbd2 qethl2 bridge stp llc dasdeckdmod qeth dasdmod qdio ccwgroup pkey zcrypt [ 2057.572739] CPU: 6 PID: 60182 Comm: stressclient Kdump: loaded Not tainted 4.18.0-541.el8.s390x #1 [ 2057.572742] Hardware name: IBM 3931 A01 704 (LPAR) [ 2057.572744] Krnl PSW : 0704f00180000000 0000000000000002 (0x2) [ 2057.572748] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 [ 2057.572751] Krnl GPRS: 0000000000000004 0000000000000000 00000000a3b008d8 0000000000000000 [ 2057.572754] 00000000a3b008d8 cb923a29c779abc5 0000000000000000 00000000814cfd80 [ 2057.572756] 000000000000012c 0000000000000000 00000000a3b008d8 00000000a3b008d8 [ 2057.572758] 00000000bab6d500 00000000814cfd80 0000000091317e46 00000000814cfc68 [ 2057.572762] Krnl Code:#0000000000000000: 0000 illegal >0000000000000002: 0000 illegal 0000000000000004: 0000 illegal 0000000000000006: 0000 illegal 0000000000000008: 0000 illegal 000000000000000a: 0000 illegal 000000000000000c: 0000 illegal 000000000000000e: 0000 illegal [ 2057.572800] Call Trace: [ 2057.572801] ([<00000000ec639700>] 0xec639700) [ 2057.572803] [<00000000913183e2>] netrxaction+0x2ba/0x398 [ 2057.572809] [<0000000091515f76>] _dosoftirq+0x11e/0x3a0 [ 2057.572813] [<0000000090ce160c>] dosoftirqownstack+0x3c/0x58 [ 2057.572817] ([<0000000090d2cbd6>] dosoftirq.part.1+0x56/0x60) [ 2057.572822] [<0000000090d2cc60>] _localbhenableip+0x80/0x98 [ 2057.572825] [<0000000091314706>] _devqueuexmit+0x2be/0xd70 [ 2057.572827] [<000003ff803dd6d6>] afiucvhssend+0x24e/0x300 [afiucv] [ 2057.572830] [<000003ff803dd88a>] iucvsendctrl+0x102/0x138 [afiucv] [ 2057.572833] [<000003ff803de72a>] iucvsockconnect+0x37a/0x468 [afiucv] [ 2057.572835] [<00000000912e7e90>] _sysconnect+0xa0/0xd8 [ 2057.572839] [<00000000912e9580>] syssocketcall+0x228/0x348 [ 2057.572841] [<0000000091514e1a>] systemcall+0x2a6/0x2c8 [ 2057.572843] Last Breaking-Event-Address: [ 2057.572844] [<0000000091317e44>] _napipoll+0x4c/0x1d8 [ 2057.572846]

[ 2057.572847] Kernel panic - not syncing: Fatal exception in interrupt

Analysis: There is one napi structure per outq: card->qdio.outqs[i].napi The napi.poll functions are set during qeth_open().

Since commit 1cfef80d4c2b ("s390/qeth: Don't call devclose/devopen (DOWN/UP)") qethsetoffline()/qethsetonline() no longer call devclose()/ devopen(). So if qethfreeqdioqueues() cleared card->qdio.outqs[i].napi.poll while the network interface was UP and the card was offline, they are not set again.

Reproduction: chzdev -e $devno layer2=0 ip link set dev $network_interface up echo 0 > /sys/bus/ccw ---truncated---(CVE-2024-36928)

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

Bluetooth: L2CAP: Fix div-by-zero in l2capleflowctl_init()

l2capleflowctlinit() can cause both div-by-zero and an integer overflow since hdev->lemtu may not fall in the valid range.

Move MTU from hcidev to hciconn to validate MTU and stop the connection process earlier if MTU is invalid. Also, add a missing validation in readbuffersize() and make it return an error value if the validation fails. Now hciconnadd() returns ERR_PTR() as it can fail due to the both a kzalloc failure and invalid MTU value.

divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G W 6.9.0-rc5+ #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci0 hcirxwork RIP: 0010:l2capleflowctlinit+0x19e/0x3f0 net/bluetooth/l2capcore.c:547 Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c 89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 <66> f7 f3 89 c3 ff c3 4d 8d b7 88 00 00 00 4c 89 f0 48 c1 e8 03 42 RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246 RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66f RBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaa R10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084 R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000 FS: 0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <TASK> l2capleconnectreq net/bluetooth/l2capcore.c:4902 [inline] l2caplesigcmd net/bluetooth/l2capcore.c:5420 [inline] l2caplesigchannel net/bluetooth/l2capcore.c:5486 [inline] l2caprecvframe+0xe59d/0x11710 net/bluetooth/l2capcore.c:6809 l2caprecvacldata+0x544/0x10a0 net/bluetooth/l2capcore.c:7506 hciacldatapacket net/bluetooth/hcicore.c:3939 [inline] hcirxwork+0x5e5/0xb20 net/bluetooth/hcicore.c:4176 processonework kernel/workqueue.c:3254 [inline] processscheduledworks+0x90f/0x1530 kernel/workqueue.c:3335 workerthread+0x926/0xe70 kernel/workqueue.c:3416 kthread+0x2e3/0x380 kernel/kthread.c:388 retfromfork+0x5c/0x90 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]---(CVE-2024-36968)

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

net/sched: taprio: always validate TCATAPRIOATTR_PRIOMAP

If one TCATAPRIOATTRPRIOMAP attribute has been provided, taprioparsemqprioopt() must validate it, or userspace can inject arbitrary data to the kernel, the second time taprio_change() is called.

First call (with valid attributes) sets dev->num_tc to a non zero value.

Second call (with arbitrary mqprio attributes) returns early from taprioparsemqprio_opt() and bad things can happen.(CVE-2024-36974)

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

KEYS: trusted: Do not use WARN when encode fails

When asn1encodesequence() fails, WARN is not the correct solution.

1. asn1encodesequence() is not an internal function (located in lib/asn1_encode.c).
2. Location is known, which makes the stack trace useless.
3. Results a crash if paniconwarn is set.

It is also noteworthy that the use of WARN is undocumented, and it should be avoided unless there is a carefully considered rationale to use it.

Replace WARN with pr_err, and print the return value instead, which is only useful piece of information.(CVE-2024-36975)

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

usb: dwc3: Wait unconditionally after issuing EndXfer command

Currently all controller IP/revisions except DWC3usb3 >= 310a wait 1ms unconditionally for ENDXFER completion when IOC is not set. This is because DWCusb3 controller revisions >= 3.10a supports GUCTL2[14: Rst_actbitlater] bit which allows polling CMDACT bit to know whether ENDXFER command is completed.

Consider a case where an IN request was queued, and parallelly softdisconnect was called (due to ffsepfilerelease). This eventually calls stopactivetransfer with IOC cleared, hence sendgadgetepcmd() skips waiting for CMDACT cleared during EndXfer. For DWC3 controllers with revisions >= 310a, we don't forcefully wait for 1ms either, and we proceed by unmapping the requests. If ENDXFER didn't complete by this time, it leads to SMMU faults since the controller would still be accessing those requests.

Fix this by ensuring ENDXFER completion by adding 1ms delay in _dwc3stopactivetransfer() unconditionally.(CVE-2024-36977)

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

net: sched: schmultiq: fix possible OOB write in multiqtune()

q->bands will be assigned to qopt->bands to execute subsequent code logic after kmalloc. So the old q->bands should not be used in kmalloc. Otherwise, an out-of-bounds write will occur.(CVE-2024-36978)

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

net: bridge: xmit: make sure we have at least eth header len bytes

syzbot triggered an uninit value[1] error in bridge device's xmit path by sending a short (less than ETH_HLEN bytes) skb. To fix it check if we can actually pull that amount instead of assuming.

Tested with dropwatch: drop at: brdevxmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3) origin: software timestamp: Mon May 13 11:31:53 2024 778214037 nsec protocol: 0x88a8 length: 2 original length: 2 drop reason: PKTTOOSMALL

[1] BUG: KMSAN: uninit-value in brdevxmit+0x61d/0x1cb0 net/bridge/brdevice.c:65 brdevxmit+0x61d/0x1cb0 net/bridge/brdevice.c:65 netdevstartxmit include/linux/netdevice.h:4903 [inline] netdevstartxmit include/linux/netdevice.h:4917 [inline] xmitone net/core/dev.c:3531 [inline] devhardstartxmit+0x247/0xa20 net/core/dev.c:3547 _devqueuexmit+0x34db/0x5350 net/core/dev.c:4341 devqueuexmit include/linux/netdevice.h:3091 [inline] _bpftxskb net/core/filter.c:2136 [inline] _bpfredirectcommon net/core/filter.c:2180 [inline] _bpfredirect+0x14a6/0x1620 net/core/filter.c:2187 _bpfcloneredirect net/core/filter.c:2460 [inline] bpfcloneredirect+0x328/0x470 net/core/filter.c:2432 _bpfprogrun+0x13fe/0xe0f0 kernel/bpf/core.c:1997 _bpfprogrun512+0xb5/0xe0 kernel/bpf/core.c:2238 bpfdispatchernopfunc include/linux/bpf.h:1234 [inline] _bpfprogrun include/linux/filter.h:657 [inline] bpfprogrun include/linux/filter.h:664 [inline] bpftestrun+0x499/0xc30 net/bpf/testrun.c:425 bpfprogtestrunskb+0x14ea/0x1f20 net/bpf/testrun.c:1058 bpfprogtestrun+0x6b7/0xad0 kernel/bpf/syscall.c:4269 _sysbpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678 _dosysbpf kernel/bpf/syscall.c:5767 [inline] _sesysbpf kernel/bpf/syscall.c:5765 [inline] _x64sysbpf+0xa0/0xe0 kernel/bpf/syscall.c:5765 x64syscall+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls64.h:322 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcf/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f(CVE-2024-38538)

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

of: module: add buffer overflow check in of_modalias()

In of_modalias(), if the buffer happens to be too small even for the 1st snprintf() call, the len parameter will become negative and str parameter (if not NULL initially) will point beyond the buffer's end. Add the buffer overflow check after the 1st snprintf() call and fix such check after the strlen() call (accounting for the terminating NUL char).(CVE-2024-38541)

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

drm/mediatek: Add 0 size check to mtkdrmgem_obj

Add a check to mtkdrmgem_init if we attempt to allocate a GEM object of 0 bytes. Currently, no such check exists and the kernel will panic if a userspace application attempts to allocate a 0x0 GBM buffer.

Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 and verifying that we now return EINVAL.(CVE-2024-38549)

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

speakup: Fix sizeof() vs ARRAY_SIZE() bug

The "buf" pointer is an array of u16 values. This code should be using ARRAY_SIZE() (which is 256) instead of sizeof() (which is 512), otherwise it can the still got out of bounds.(CVE-2024-38587)

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

afunix: Fix data races in unixreleasesock/unixstream_sendmsg

A data-race condition has been identified in afunix. In one data path, the write function unixreleasesock() atomically writes to sk->skshutdown using WRITEONCE. However, on the reader side, unixstream_sendmsg() does not read it atomically. Consequently, this issue is causing the following KCSAN splat to occur:

BUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg

write (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28:
unix_release_sock (net/unix/af_unix.c:640)
unix_release (net/unix/af_unix.c:1050)
sock_close (net/socket.c:659 net/socket.c:1421)
__fput (fs/file_table.c:422)
__fput_sync (fs/file_table.c:508)
__se_sys_close (fs/open.c:1559 fs/open.c:1541)
__x64_sys_close (fs/open.c:1541)
x64_sys_call (arch/x86/entry/syscall_64.c:33)
do_syscall_64 (arch/x86/entry/common.c:?)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)

read to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14:
unix_stream_sendmsg (net/unix/af_unix.c:2273)
__sock_sendmsg (net/socket.c:730 net/socket.c:745)
____sys_sendmsg (net/socket.c:2584)
__sys_sendmmsg (net/socket.c:2638 net/socket.c:2724)
__x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750)
x64_sys_call (arch/x86/entry/syscall_64.c:33)
do_syscall_64 (arch/x86/entry/common.c:?)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)

value changed: 0x01 -> 0x03

The line numbers are related to commit dd5a440a31fa ("Linux 6.9-rc7").

Commit e1d09c2c2f57 ("afunix: Fix data races around sk->skshutdown.") addressed a comparable issue in the past regarding sk->skshutdown. However, it overlooked resolving this particular data path. This patch only offending unixstreamsendmsg() function, since the other reads seem to be protected by unixstate_lock() as discussed in(CVE-2024-38596)

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

ring-buffer: Fix a race between readers and resize checks

The reader code in rbgetreader_page() swaps a new reader page into the ring buffer by doing cmpxchg on old->list.prev->next to point it to the new page. Following that, if the operation is successful, old->list.next->prev gets updated too. This means the underlying doubly-linked list is temporarily inconsistent, page->prev->next or page->next->prev might not be equal back to page for some page in the ring buffer.

The resize operation in ringbufferresize() can be invoked in parallel. It calls rbcheckpages() which can detect the described inconsistency and stop further tracing:

[ 190.271762] ------------[ cut here ]------------ [ 190.271771] WARNING: CPU: 1 PID: 6186 at kernel/trace/ringbuffer.c:1467 rbcheckpages.isra.0+0x6a/0xa0 [ 190.271789] Modules linked in: [...] [ 190.271991] Unloaded tainted modules: inteluncorefrequency(E):1 skxedac(E):1 [ 190.272002] CPU: 1 PID: 6186 Comm: cmd.sh Kdump: loaded Tainted: G E 6.9.0-rc6-default #5 158d3e1e6d0b091c34c3b96bfd99a1c58306d79f [ 190.272011] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552c-rebuilt.opensuse.org 04/01/2014 [ 190.272015] RIP: 0010:rbcheckpages.isra.0+0x6a/0xa0 [ 190.272023] Code: [...] [ 190.272028] RSP: 0018:ffff9c37463abb70 EFLAGS: 00010206 [ 190.272034] RAX: ffff8eba04b6cb80 RBX: 0000000000000007 RCX: ffff8eba01f13d80 [ 190.272038] RDX: ffff8eba01f130c0 RSI: ffff8eba04b6cd00 RDI: ffff8eba0004c700 [ 190.272042] RBP: ffff8eba0004c700 R08: 0000000000010002 R09: 0000000000000000 [ 190.272045] R10: 00000000ffff7f52 R11: ffff8eba7f600000 R12: ffff8eba0004c720 [ 190.272049] R13: ffff8eba00223a00 R14: 0000000000000008 R15: ffff8eba067a8000 [ 190.272053] FS: 00007f1bd64752c0(0000) GS:ffff8eba7f680000(0000) knlGS:0000000000000000 [ 190.272057] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 190.272061] CR2: 00007f1bd6662590 CR3: 000000010291e001 CR4: 0000000000370ef0 [ 190.272070] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 190.272073] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 190.272077] Call Trace: [ 190.272098] <TASK> [ 190.272189] ringbufferresize+0x2ab/0x460 [ 190.272199] _tracingresizeringbuffer.part.0+0x23/0xa0 [ 190.272206] tracingresizeringbuffer+0x65/0x90 [ 190.272216] tracingentrieswrite+0x74/0xc0 [ 190.272225] vfswrite+0xf5/0x420 [ 190.272248] ksyswrite+0x67/0xe0 [ 190.272256] dosyscall64+0x82/0x170 [ 190.272363] entrySYSCALL64afterhwframe+0x76/0x7e [ 190.272373] RIP: 0033:0x7f1bd657d263 [ 190.272381] Code: [...] [ 190.272385] RSP: 002b:00007ffe72b643f8 EFLAGS: 00000246 ORIGRAX: 0000000000000001 [ 190.272391] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f1bd657d263 [ 190.272395] RDX: 0000000000000002 RSI: 0000555a6eb538e0 RDI: 0000000000000001 [ 190.272398] RBP: 0000555a6eb538e0 R08: 000000000000000a R09: 0000000000000000 [ 190.272401] R10: 0000555a6eb55190 R11: 0000000000000246 R12: 00007f1bd6662500 [ 190.272404] R13: 0000000000000002 R14: 00007f1bd6667c00 R15: 0000000000000002 [ 190.272412] </TASK> [ 190.272414] ---[ end trace 0000000000000000 ]---

Note that ringbufferresize() calls rbcheckpages() only if the parent trace_buffer has recording disabled. Recent commit d78ab792705c ("tracing: Stop current tracer when resizing buffer") causes that it is now always the case which makes it more likely to experience this issue.

The window to hit this race is nonetheless very small. To help reproducing it, one can add a delay loop in rbgetreader_page():

ret = rbheadpagereplace(reader, cpubuffer->readerpage); if (!ret) goto spin; for (unsigned i = 0; i < 1U << 26; i++) /* inserted delay loop */ asm volatile ("" : : : "memory"); rblisthead(reader->list.next)->prev = &cpubuffer->reader_page->list;

.. ---truncated---(CVE-2024-38601)

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

ALSA: core: Fix NULL module pointer assignment at card init

The commit 81033c6b584b ("ALSA: core: Warn on empty module") introduced a WARNON() for a NULL module pointer passed at sndcard object creation, and it also wraps the code around it with '#ifdef MODULE'. This works in most cases, but the devils are always in details. "MODULE" is defined when the target code (i.e. the sound core) is built as a module; but this doesn't mean that the caller is also built-in or not. Namely, when only the sound core is built-in (CONFIGSND=y) while the driver is a module (CONFIGSNDUSBAUDIO=m), the passed module pointer is ignored even if it's non-NULL, and card->module remains as NULL. This would result in the missing module reference up/down at the device open/close, leading to a race with the code execution after the module removal.

For addressing the bug, move the assignment of card->module again out of ifdef. The WARN_ON() is still wrapped with ifdef because the module can be really NULL when all sound drivers are built-in.

Note that we keep 'ifdef MODULE' for WARNON(), otherwise it would lead to a false-positive NULL module check. Admittedly it won't catch perfectly, i.e. no check is performed when CONFIGSND=y. But, it's no real problem as it's only for debugging, and the condition is pretty rare.(CVE-2024-38605)

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

f2fs: multidev: fix to recognize valid zero block address

As reported by Yi Zhang in mailing list [1], kernel warning was catched during zbd/010 test as below:

./check zbd/010 zbd/010 (test gap zone support with F2FS) [failed] runtime ... 3.752s something found in dmesg: [ 4378.146781] run blktests zbd/010 at 2024-02-18 11:31:13 [ 4378.192349] nullblk: module loaded [ 4378.209860] nullblk: disk nullb0 created [ 4378.413285] scsidebug:sdebugdriverprobe: scsidebug: trim pollqueues to 0. pollq/nrhw = (0/1) [ 4378.422334] scsi host15: scsidebug: version 0191 [20210520] devsizemb=1024, opts=0x0, submitqueues=1, statistics=0 [ 4378.434922] scsi 15:0:0:0: Direct-Access-ZBC Linux scsidebug 0191 PQ: 0 ANSI: 7 [ 4378.443343] scsi 15:0:0:0: Power-on or device reset occurred [ 4378.449371] sd 15:0:0:0: Attached scsi generic sg5 type 20 [ 4378.449418] sd 15:0:0:0: [sdf] Host-managed zoned block device ... (See '/mnt/tests/gitlab.com/api/v4/projects/19168116/repository/archive.zip/storage/blktests/blk/blktests/results/nodev/zbd/010.dmesg'

WARNING: CPU: 22 PID: 44011 at fs/iomap/iter.c:51 CPU: 22 PID: 44011 Comm: fio Not tainted 6.8.0-rc3+ #1 RIP: 0010:iomapiter+0x32b/0x350 Call Trace: <TASK> _iomapdiorw+0x1df/0x830 f2fsfilereaditer+0x156/0x3d0 [f2fs] aioread+0x138/0x210 iosubmitone+0x188/0x8c0 _x64sysiosubmit+0x8c/0x1a0 dosyscall64+0x86/0x170 entrySYSCALL64afterhwframe+0x6e/0x76

Shinichiro Kawasaki helps to analyse this issue and proposes a potential fixing patch in [2].

Quoted from reply of Shinichiro Kawasaki:

"I confirmed that the trigger commit is dbf8e63f48af as Yi reported. I took a look in the commit, but it looks fine to me. So I thought the cause is not in the commit diff.

I found the WARN is printed when the f2fs is set up with multiple devices, and read requests are mapped to the very first block of the second device in the direct read path. In this case, f2fsmapblocks() and f2fsmapblockscached() modify map->mpblk as the physical block address from each block device. It becomes zero when it is mapped to the first block of the device. However, f2fsiomapbegin() assumes that map->mpblk is the physical block address of the whole f2fs, across the all block devices. It compares map->mpblk against NULL_ADDR == 0, then go into the unexpected branch and sets the invalid iomap->length. The WARN catches the invalid iomap->length.

This WARN is printed even for non-zoned block devices, by following steps.

• Create two (non-zoned) nullblk devices memory backed with 128MB size each: nullb0 and nullb1. # mkfs.f2fs /dev/nullb0 -c /dev/nullb1 # mount -t f2fs /dev/nullb0 "${mountdir}" # dd if=/dev/zero of="${mountdir}/test.dat" bs=1M count=192 # dd if="${mountdir}/test.dat" of=/dev/null bs=1M count=192 iflag=direct

..."

So, the root cause of this issue is: when multi-devices feature is on, f2fsmapblocks() may return zero blkaddr in non-primary device, which is a verified valid block address, however, f2fsiomapbegin() treats it as an invalid block address, and then it triggers the warning in iomap framework code.

Finally, as discussed, we decide to use a more simple and direct way that checking (map.mflags & F2FSMAPMAPPED) condition instead of (map.mpblk != NULL_ADDR) to fix this issue.

Thanks a lot for the effort of Yi Zhang and Shinichiro Kawasaki on this issue.

[1] https://lore.kernel.org/linux-f2fs-devel/CAHj4cs-kfojYC9i0G73PRkYzcxCTex=-vugRFeP40g_URGvnfQ@mail.gmail.com/ [2] https://lore.kernel.org/linux-f2fs-devel/gngdj77k4picagsfdtiaa7gpgnup6fsgwzsltx6milmhegmjff@iax2n4wvrqye/(CVE-2024-38636)