OESA-2024-1568

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

scsi: core: Fix scsimodesense() buffer length handling

Several problems exist with scsimodesense() buffer length handling:

1) The allocation length field of the MODE SENSE(10) command is 16-bits, occupying bytes 7 and 8 of the CDB. With this command, access to mode pages larger than 255 bytes is thus possible. However, the CDB allocation length field is set by assigning len to byte 8 only, thus truncating buffer length larger than 255.

2) If scsimodesense() is called with len smaller than 8 with sdev->use10for_ms set, or smaller than 4 otherwise, the buffer length is increased to 8 and 4 respectively, and the buffer is zero filled with these increased values, thus corrupting the memory following the buffer.

Fix these 2 problems by using putunalignedbe16() to set the allocation length field of MODE SENSE(10) CDB and by returning an error when len is too small.

Furthermore, if len is larger than 255B, always try MODE SENSE(10) first, even if the device driver did not set sdev->use10forms. In case of invalid opcode error for MODE SENSE(10), access to mode pages larger than 255 bytes are not retried using MODE SENSE(6). To avoid buffer length overflows for the MODESENSE(10) case, check that len is smaller than 65535 bytes.

While at it, also fix the folowing:

• Use getunalignedbe16() to retrieve the mode data length and block descriptor length fields of the mode sense reply header instead of using an open coded calculation.

• Fix the kdoc dbd argument explanation: the DBD bit stands for Disable Block Descriptor, which is the opposite of what the dbd argument description was.(CVE-2021-47182)

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

iavf: free qvectors before queues in iavfdisable_vf

iavffreequeues() clears adapter->numactivequeues, which iavffreeqvectors() relies on, so swap the order of these two function calls in iavfdisable_vf(). This resolves a panic encountered when the interface is disabled and then later brought up again after PF communication is restored.(CVE-2021-47201)

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

scsi: lpfc: Fix listadd() corruption in lpfcdrain_txq()

When parsing the txq list in lpfcdraintxq(), the driver attempts to pass the requests to the adapter. If such an attempt fails, a local "fail_msg" string is set and a log message output. The job is then added to a completions list for cancellation.

Processing of any further jobs from the txq list continues, but since "fail_msg" remains set, jobs are added to the completions list regardless of whether a wqe was passed to the adapter. If successfully added to txcmplq, jobs are added to both lists resulting in list corruption.

Fix by clearing the fail_msg string after adding a job to the completions list. This stops the subsequent jobs from being added to the completions list unless they had an appropriate failure.(CVE-2021-47203)

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

ALSA: usb-audio: fix null pointer dereference on pointer cs_desc

The pointer csdesc return from sndusbfindclock_source could be null, so there is a potential null pointer dereference issue. Fix this by adding a null check before dereference.(CVE-2021-47211)

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

scsi: advansys: Fix kernel pointer leak

Pointers should be printed with %p or %px rather than cast to 'unsigned long' and printed with %lx.

Change %lx to %p to print the hashed pointer.(CVE-2021-47216)

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

x86/hyperv: Fix NULL deref in sethvtscchange_cb() if Hyper-V setup fails

Check for a valid hvvpindex array prior to derefencing hvvpindex when setting Hyper-V's TSC change callback. If Hyper-V setup failed in hyperv_init(), the kernel will still report that it's running under Hyper-V, but will have silently disabled nearly all functionality.

BUG: kernel NULL pointer dereference, address: 0000000000000010 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.15.0-rc2+ #75 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:sethvtscchangecb+0x15/0xa0 Code: <8b> 04 82 8b 15 12 17 85 01 48 c1 e0 20 48 0d ee 00 01 00 f6 c6 08 ... Call Trace: kvmarchinit+0x17c/0x280 kvminit+0x31/0x330 vmxinit+0xba/0x13a dooneinitcall+0x41/0x1c0 kernelinitfreeable+0x1f2/0x23b kernelinit+0x16/0x120 retfrom_fork+0x22/0x30(CVE-2021-47217)

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

usb: hub: Guard against accesses to uninitialized BOS descriptors

Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h access fields inside udev->bos without checking if it was allocated and initialized. If usbgetbos_descriptor() fails for whatever reason, udev->bos will be NULL and those accesses will result in a crash:

BUG: kernel NULL pointer dereference, address: 0000000000000018 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1> Hardware name: Google Kindred/Kindred, BIOS GoogleKindred.12672.413.0 02/03/2021 Workqueue: usbhubwq hubevent RIP: 0010:hubportreset+0x193/0x788 Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9 RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310 RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840 RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0 Call Trace: hubevent+0x73f/0x156e ? hubactivate+0x5b7/0x68f processonework+0x1a2/0x487 workerthread+0x11a/0x288 kthread+0x13a/0x152 ? processonework+0x487/0x487 ? kthreadassociateblkcg+0x70/0x70 retfrom_fork+0x1f/0x30

Fall back to a default behavior if the BOS descriptor isn't accessible and skip all the functionalities that depend on it: LPM support checks, Super Speed capabilitiy checks, U1/U2 states setup.(CVE-2023-52477)

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:

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)