OESA-2024-1566

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:

net/mlx5e: CT, Fix multiple allocations and memleak of mod acts

CT clear action offload adds additional mod hdr actions to the flow's original mod actions in order to clear the registers which hold ct_state. When such flow also includes encap action, a neigh update event can cause the driver to unoffload the flow and then reoffload it.

Each time this happens, the ct clear handling adds that same set of mod hdr actions to reset ct_state until the max of mod hdr actions is reached.

Also the driver never releases the allocated mod hdr actions and causing a memleak.

Fix above two issues by moving CT clear mod acts allocation into the parsing actions phase and only use it when offloading the rule. The release of mod acts will be done in the normal flow_put().

backtrace: [<000000007316e2f3>] krealloc+0x83/0xd0 [<00000000ef157de1>] mlx5emodhdralloc+0x147/0x300 [mlx5core] [<00000000970ce4ae>] mlx5etcmatchtoregsetandgetid+0xd7/0x240 [mlx5core] [<0000000067c5fa17>] mlx5etcmatchtoregset+0xa/0x20 [mlx5core] [<00000000d032eb98>] mlx5tcctentrysetregisters.isra.0+0x36/0xc0 [mlx5core] [<00000000fd23b869>] mlx5tcctflowoffload+0x272/0x1f10 [mlx5core] [<000000004fc24acc>] mlx5etcoffloadfdbrules.part.0+0x150/0x620 [mlx5core] [<00000000dc741c17>] mlx5etcencapflowsadd+0x489/0x690 [mlx5core] [<00000000e92e49d7>] mlx5erepupdateflows+0x6e4/0x9b0 [mlx5core] [<00000000f60f5602>] mlx5erepneighupdate+0x39a/0x5d0 mlx5core

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:

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:

net/sched: act_ct: fix skb leak and crash on ooo frags

act_ct adds skb->users before defragmentation. If frags arrive in order, the last frag's reference is reset in:

inetfragreasmprepare skbmorph

which is not straightforward.

However when frags arrive out of order, nobody unref the last frag, and all frags are leaked. The situation is even worse, as initiating packet capture can lead to a crash[0] when skb has been cloned and shared at the same time.

Fix the issue by removing skbget() before defragmentation. actct returns TCACTCONSUMED when defrag failed or in progress.

[ 843.809659] kernel BUG at net/core/skbuff.c:2091! [ 843.814516] invalid opcode: 0000 [#1] PREEMPT SMP [ 843.819296] CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G S 6.7.0-rc3 #2 [ 843.824107] Hardware name: XFUSION 1288H V6/BC13MBSBD, BIOS 1.29 11/25/2022 [ 843.828953] RIP: 0010:pskbexpandhead+0x2ac/0x300 [ 843.833805] Code: 8b 70 28 48 85 f6 74 82 48 83 c6 08 bf 01 00 00 00 e8 38 bd ff ff 8b 83 c0 00 00 00 48 03 83 c8 00 00 00 e9 62 ff ff ff 0f 0b <0f> 0b e8 8d d0 ff ff e9 b3 fd ff ff 81 7c 24 14 40 01 00 00 4c 89 [ 843.843698] RSP: 0018:ffffc9000cce07c0 EFLAGS: 00010202 [ 843.848524] RAX: 0000000000000002 RBX: ffff88811a211d00 RCX: 0000000000000820 [ 843.853299] RDX: 0000000000000640 RSI: 0000000000000000 RDI: ffff88811a211d00 [ 843.857974] RBP: ffff888127d39518 R08: 00000000bee97314 R09: 0000000000000000 [ 843.862584] R10: 0000000000000000 R11: ffff8881109f0000 R12: 0000000000000880 [ 843.867147] R13: ffff888127d39580 R14: 0000000000000640 R15: ffff888170f7b900 [ 843.871680] FS: 0000000000000000(0000) GS:ffff889ffffc0000(0000) knlGS:0000000000000000 [ 843.876242] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 843.880778] CR2: 00007fa42affcfb8 CR3: 000000011433a002 CR4: 0000000000770ef0 [ 843.885336] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 843.889809] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 843.894229] PKRU: 55555554 [ 843.898539] Call Trace: [ 843.902772] <IRQ> [ 843.906922] ? _diebody+0x1e/0x60 [ 843.911032] ? die+0x3c/0x60 [ 843.915037] ? dotrap+0xe2/0x110 [ 843.918911] ? pskbexpandhead+0x2ac/0x300 [ 843.922687] ? doerrortrap+0x65/0x80 [ 843.926342] ? pskbexpandhead+0x2ac/0x300 [ 843.929905] ? excinvalidop+0x50/0x60 [ 843.933398] ? pskbexpandhead+0x2ac/0x300 [ 843.936835] ? asmexcinvalidop+0x1a/0x20 [ 843.940226] ? pskbexpandhead+0x2ac/0x300 [ 843.943580] inetfragreasmprepare+0xd1/0x240 [ 843.946904] ipdefrag+0x5d4/0x870 [ 843.950132] nfcthandlefragments+0xec/0x130 [nfconntrack] [ 843.953334] tcfctact+0x252/0xd90 [actct] [ 843.956473] ? tcfmirredact+0x516/0x5a0 [actmirred] [ 843.959657] tcfactionexec+0xa1/0x160 [ 843.962823] flclassify+0x1db/0x1f0 [clsflower] [ 843.966010] ? skbclone+0x53/0xc0 [ 843.969173] tcfclassify+0x24d/0x420 [ 843.972333] tcrun+0x8f/0xf0 [ 843.975465] _netifreceiveskbcore+0x67a/0x1080 [ 843.978634] ? devgroreceive+0x249/0x730 [ 843.981759] _netifreceiveskblistcore+0x12d/0x260 [ 843.984869] netifreceiveskblistinternal+0x1cb/0x2f0 [ 843.987957] ? mlx5ehandlerxcqempwrqrep+0xfa/0x1a0 [mlx5core] [ 843.991170] napicompletedone+0x72/0x1a0 [ 843.994305] mlx5enapipoll+0x28c/0x6d0 [mlx5core] [ 843.997501] _napipoll+0x25/0x1b0 [ 844.000627] netrxaction+0x256/0x330 [ 844.003705] _dosoftirq+0xb3/0x29b [ 844.006718] irqexitrcu+0x9e/0xc0 [ 844.009672] commoninterrupt+0x86/0xa0 [ 844.012537] </IRQ> [ 844.015285] <TASK> [ 844.017937] asmcommoninterrupt+0x26/0x40 [ 844.020591] RIP: 0010:acpisafehalt+0x1b/0x20 [ 844.023247] Code: ff 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 65 48 8b 04 25 00 18 03 00 48 8b 00 a8 08 75 0c 66 90 0f 00 2d 81 d0 44 00 fb ---truncated---(CVE-2023-52610)

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

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

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

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

block/rnbd-srv: Check for unlikely string overflow

Since "devsearchpath" can technically be as large as PATHMAX, there was a risk of truncation when copying it and a second string into "fullpath" since it was also PATH_MAX sized. The W=1 builds were reporting this warning:

drivers/block/rnbd/rnbd-srv.c: In function 'processmsgopen.isra': drivers/block/rnbd/rnbd-srv.c:616:51: warning: '%s' directive output may be truncated writing up to 254 bytes into a region of size between 0 and 4095 [-Wformat-truncation=] 616 | snprintf(fullpath, PATHMAX, "%s/%s", | ^~ In function 'rnbdsrvgetfullpath', inlined from 'processmsgopen.isra' at drivers/block/rnbd/rnbd-srv.c:721:14: drivers/block/rnbd/rnbd-srv.c:616:17: note: 'snprintf' output between 2 and 4351 bytes into a destination of size 4096 616 | snprintf(fullpath, PATHMAX, "%s/%s", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 617 | devsearchpath, dev_name); | ~~~~~~~~~~~~~~~~~~~~~~~~~~

To fix this, unconditionally check for truncation (as was already done for the case where "%SESSNAME%" was present).(CVE-2023-52618)

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

llc: Drop support for ETHPTR8022.

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

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

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

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

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

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

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

Let's remove llctrpacket_type and complete the deprecation.

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

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

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

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

llc: make llcuisendmsg() more robust against bonding changes

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

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

This fix:

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

[1]

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

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

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

tcp: add sanity checks to rx zerocopy

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

This patch adds to canmapfrag() these additional checks:

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

This fixes the panic reported by ZhangPeng.

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

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

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

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

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

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

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

Uninit was created at: slabpostallochook+0x129/0xa70 mm/slab.h:768 slaballocnode mm/slub.c:3478 [inline] kmemcacheallocnode+0x5e9/0xb10 mm/slub.c:3523 kmallocreserve+0x13d/0x4a0 net/core/skbuff.c:560 _allocskb+0x318/0x740 net/core/skbuff.c:651 allocskb include/linux/skbuff.h:1286 [inline] allocskbwithfrags+0xc8/0xbd0 net/core/skbuff.c:6334 sockallocsendpskb+0xa80/0xbf0 net/core/sock.c:2787 tunallocskb drivers/net/tun.c:1531 [inline] tungetuser+0x1e8a/0x66d0 drivers/net/tun.c:1846 tunchrwriteiter+0x3af/0x5d0 drivers/net/tun.c:2048 callwriteiter include/linux/fs.h:2084 [inline] newsyncwrite fs/readwrite.c:497 [inline] vfswrite+0x786/0x1200 fs/readwrite.c:590 ksyswrite+0x20f/0x4c0 fs/readwrite.c:643 _dosyswrite fs/readwrite.c:655 [inline] _sesyswrite fs/readwrite.c:652 [inline] _x64syswrite+0x93/0xd0 fs/readwrite.c:652 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x6d/0x140 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b

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

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

l2tp: pass correct message length to ip6appenddata

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

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

However, the code which performed the calculation was incorrect:

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

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

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

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

IB/hfi1: Fix sdma.h tx->num_descs off-by-one error

Unfortunately the commit fd8958efe877 introduced another error causing the descs array to overflow. This reults in further crashes easily reproducible by sendmsg system call.

[ 1080.836473] general protection fault, probably for non-canonical address 0x400300015528b00a: 0000 [#1] PREEMPT SMP PTI

[ 1080.869326] RIP: 0010:hfi1ipoibbuildibtx_headers.constprop.0+0xe1/0x2b0 [hfi1]

[ 1080.974535] Call Trace: [ 1080.976990] <TASK> [ 1081.021929] hfi1ipoibsenddmacommon+0x7a/0x2e0 [hfi1] [ 1081.027364] hfi1ipoibsenddmalist+0x62/0x270 [hfi1] [ 1081.032633] hfi1ipoibsend+0x112/0x300 [hfi1] [ 1081.042001] ipoibstartxmit+0x2a9/0x2d0 [ib_ipoib]

[ 1081.046978] devhardstart_xmit+0xc4/0x210

[ 1081.148347] _syssendmsg+0x59/0xa0

crash> ipoibtxreq 0xffff9cfeba229f00 struct ipoibtxreq { txreq = { list = { next = 0xffff9cfeba229f00, prev = 0xffff9cfeba229f00 }, descp = 0xffff9cfeba229f40, coalescebuf = 0x0, wait = 0xffff9cfea4e69a48, complete = 0xffffffffc0fe0760 <hfi1ipoibsdmacomplete>, packetlen = 0x46d, tlen = 0x0, numdesc = 0x0, desclimit = 0x6, nextdescqidx = 0x45c, coalesceidx = 0x0, flags = 0x0, descs = {{ qw = {0x8024000120dffb00, 0x4} # SDMADESC0FIRSTDESCFLAG (bit 63) }, { qw = { 0x3800014231b108, 0x4} }, { qw = { 0x310000e4ee0fcf0, 0x8} }, { qw = { 0x3000012e9f8000, 0x8} }, { qw = { 0x59000dfb9d0000, 0x8} }, { qw = { 0x78000e02e40000, 0x8} }} }, sdmahdr = 0x400300015528b000, <<< invalid pointer in the tx request structure sdmastatus = 0x0, SDMADESC0LASTDESCFLAG (bit 62) complete = 0x0, priv = 0x0, txq = 0xffff9cfea4e69880, skb = 0xffff9d099809f400 }

If an SDMA send consists of exactly 6 descriptors and requires dword padding (in the 7th descriptor), the sdmatxreq descriptor array is not properly expanded and the packet will overflow into the container structure. This results in a panic when the send completion runs. The exact panic varies depending on what elements of the container structure get corrupted. The fix is to use the correct expression in _padsdmatxdescs() to test the need to expand the descriptor array.

With this patch the crashes are no longer reproducible and the machine is stable.(CVE-2024-26766)