OESA-2024-1567

Source
https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1567
Import Source
https://repo.openeuler.org/security/data/osv/OESA-2024-1567.json
JSON Data
https://api.test.osv.dev/v1/vulns/OESA-2024-1567
Upstream
  • CVE-2021-47123
Published
2024-05-11T11:07:58Z
Modified
2025-08-12T05:35:30.819538Z
Summary
kernel security update
Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

sctp: use call_rcu to free endpoint

This patch is to delay the endpoint free by calling callrcu() to fix another use-after-free issue in sctpsock_dump():

BUG: KASAN: use-after-free in _lockacquire+0x36d9/0x4c20 Call Trace: _lockacquire+0x36d9/0x4c20 kernel/locking/lockdep.c:3218 lockacquire+0x1ed/0x520 kernel/locking/lockdep.c:3844 _rawspinlockbh include/linux/spinlockapismp.h:135 [inline] _rawspinlockbh+0x31/0x40 kernel/locking/spinlock.c:168 spinlockbh include/linux/spinlock.h:334 [inline] _locksock+0x203/0x350 net/core/sock.c:2253 locksocknested+0xfe/0x120 net/core/sock.c:2774 locksock include/net/sock.h:1492 [inline] sctpsockdump+0x122/0xb20 net/sctp/diag.c:324 sctpforeachtransport+0x2b5/0x370 net/sctp/socket.c:5091 sctpdiagdump+0x3ac/0x660 net/sctp/diag.c:527 _inetdiagdump+0xa8/0x140 net/ipv4/inetdiag.c:1049 inetdiagdump+0x9b/0x110 net/ipv4/inetdiag.c:1065 netlinkdump+0x606/0x1080 net/netlink/afnetlink.c:2244 _netlinkdumpstart+0x59a/0x7c0 net/netlink/afnetlink.c:2352 netlinkdumpstart include/linux/netlink.h:216 [inline] inetdiaghandlercmd+0x2ce/0x3f0 net/ipv4/inetdiag.c:1170 _sockdiagcmd net/core/sockdiag.c:232 [inline] sockdiagrcvmsg+0x31d/0x410 net/core/sockdiag.c:263 netlinkrcvskb+0x172/0x440 net/netlink/afnetlink.c:2477 sockdiagrcv+0x2a/0x40 net/core/sock_diag.c:274

This issue occurs when asoc is peeled off and the old sk is freed after getting it by asoc->base.sk and before calling lock_sock(sk).

To prevent the sk free, as a holder of the sk, ep should be alive when calling locksock(). This patch uses callrcu() and moves sockput and ep free into sctpendpointdestroyrcu(), so that it's safe to try to hold the ep under rcureadlock in sctptransporttraverse_process().

If sctpendpointhold() returns true, it means this ep is still alive and we have held it and can continue to dump it; If it returns false, it means this ep is dead and can be freed after rcureadunlock, and we should skip it.

In sctpsockdump(), after locking the sk, if this ep is different from tsp->asoc->ep, it means during this dumping, this asoc was peeled off before calling locksock(), and the sk should be skipped; If this ep is the same with tsp->asoc->ep, it means no peeloff happens on this asoc, and due to locksock, no peeloff will happen either until release_sock.

Note that delaying endpoint free won't delay the port release, as the port release happens in sctpendpointdestroy() before calling callrcu(). Also, freeing endpoint by callrcu() makes it safe to access the sk by asoc->base.sk in sctpassocsseqshow() and sctprcv().

Thanks Jones to bring this issue up.

v1->v2: - improve the changelog. - add kfree(ep) into sctpendpointdestroy_rcu(), as Jakub noticed.(CVE-2021-46929)

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

net: fix use-after-free in twtimerhandler

A real world panic issue was found as follow in Linux 5.4.

BUG: unable to handle page fault for address: ffffde49a863de28
PGD 7e6fe62067 P4D 7e6fe62067 PUD 7e6fe63067 PMD f51e064067 PTE 0
RIP: 0010:tw_timer_handler+0x20/0x40
Call Trace:
 <IRQ>
 call_timer_fn+0x2b/0x120
 run_timer_softirq+0x1ef/0x450
 __do_softirq+0x10d/0x2b8
 irq_exit+0xc7/0xd0
 smp_apic_timer_interrupt+0x68/0x120
 apic_timer_interrupt+0xf/0x20

This issue was also reported since 2017 in the thread [1], unfortunately, the issue was still can be reproduced after fixing DCCP.

The ipv4mibexitnet is called before tcpskexitbatch when a net namespace is destroyed since tcpskops is registered befrore ipv4mibops, which means tcpskops is in the front of ipv4mibops in the list of pernetlist. There will be a use-after-free on net->mib.netstatistics in twtimerhandler after ipv4mibexit_net if there are some inflight time-wait timers.

This bug is not introduced by commit f2bf415cfed7 ("mib: add net to NETADDSTATSBH") since the netstatistics is a global variable instead of dynamic allocation and freeing. Actually, commit 61a7e26028b9 ("mib: put net statistics on struct net") introduces the bug since it put net statistics on struct net and free it when net namespace is destroyed.

Moving initipv4mibs() to the front of tcpinit() to fix this bug and replace prcrit() with panic() since continuing is meaningless when initipv4mibs() fails.

[1] https://groups.google.com/g/syzkaller/c/p1tn-Kc6l4/m/smuLFMAAgAJ?pli=1(CVE-2021-46936)

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

ACPI: custom_method: fix potential use-after-free issue

In cmwrite(), buf is always freed when reaching the end of the function. If the requested count is less than table.length, the allocated buffer will be freed but subsequent calls to cmwrite() will still try to access it.

Remove the unconditional kfree(buf) at the end of the function and set the buf to NULL in the -EINVAL error path to match the rest of function.(CVE-2021-46966)

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

tun: avoid double free in tunfreenetdev

Avoid double free in tunfreenetdev() by moving the dev->tstats and tun->security allocs to a new ndoinit routine (tunnetinit()) that will be called by registernetdevice(). ndoinit is paired with the desctructor (tunfreenetdev()), so if there's an error in registernetdevice() the destructor will handle the frees.

BUG: KASAN: double-free or invalid-free in selinuxtundevfreesecurity+0x1a/0x20 security/selinux/hooks.c:5605

CPU: 0 PID: 25750 Comm: syz-executor416 Not tainted 5.16.0-rc2-syzk #1 Hardware name: Red Hat KVM, BIOS Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x89/0xb5 lib/dumpstack.c:106 printaddressdescription.constprop.9+0x28/0x160 mm/kasan/report.c:247 kasanreportinvalidfree+0x55/0x80 mm/kasan/report.c:372 kasanslabfree mm/kasan/common.c:346 [inline] _kasanslabfree+0x107/0x120 mm/kasan/common.c:374 kasanslabfree include/linux/kasan.h:235 [inline] slabfreehook mm/slub.c:1723 [inline] slabfreefreelisthook mm/slub.c:1749 [inline] slabfree mm/slub.c:3513 [inline] kfree+0xac/0x2d0 mm/slub.c:4561 selinuxtundevfreesecurity+0x1a/0x20 security/selinux/hooks.c:5605 securitytundevfreesecurity+0x4f/0x90 security/security.c:2342 tunfreenetdev+0xe6/0x150 drivers/net/tun.c:2215 netdevruntodo+0x4df/0x840 net/core/dev.c:10627 rtnlunlock+0x13/0x20 net/core/rtnetlink.c:112 _tunchrioctl+0x80c/0x2870 drivers/net/tun.c:3302 tunchrioctl+0x2f/0x40 drivers/net/tun.c:3311 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:874 [inline] _sesysioctl fs/ioctl.c:860 [inline] _x64sysioctl+0x19d/0x220 fs/ioctl.c:860 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x3a/0x80 arch/x86/entry/common.c:80 entrySYSCALL64after_hwframe+0x44/0xae(CVE-2021-47082)

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

io_uring: fix ltout double free on completion race

Always remove linked timeout on iolinktimeoutfn() from the master request link list, otherwise we may get use-after-free when first iolinktimeoutfn() puts linked timeout in the fail path, and then will be found and put on master's free.(CVE-2021-47123)

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:

tty: ttybuffer: Fix the softlockup issue in flushto_ldisc

When running ltp testcase(ltp/testcases/kernel/pty/pty04.c) with arm64, there is a soft lockup, which look like this one:

Workqueue: eventsunbound flushtoldisc Call trace: dumpbacktrace+0x0/0x1ec showstack+0x24/0x30 dumpstack+0xd0/0x128 panic+0x15c/0x374 watchdogtimerfn+0x2b8/0x304 _runhrtimer+0x88/0x2c0 _hrtimerrunqueues+0xa4/0x120 hrtimerinterrupt+0xfc/0x270 archtimerhandlerphys+0x40/0x50 handlepercpudevidirq+0x94/0x220 _handledomainirq+0x88/0xf0 gichandleirq+0x84/0xfc el1irq+0xc8/0x180 slipunesc+0x80/0x214 [slip] ttyldiscreceivebuf+0x64/0x80 ttyportdefaultreceivebuf+0x50/0x90 flushtoldisc+0xbc/0x110 processonework+0x1d4/0x4b0 worker_thread+0x180/0x430 kthread+0x11c/0x120

In the testcase pty04, The first process call the write syscall to send data to the pty master. At the same time, the workqueue will do the flushtoldisc to pop data in a loop until there is no more data left. When the sender and workqueue running in different core, the sender sends data fastly in full time which will result in workqueue doing work in loop for a long time and occuring softlockup in flushtoldisc with kernel configured without preempt. So I add needresched check and condresched in the flushtoldisc loop to avoid it.(CVE-2021-47185)

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:

crypto: scomp - fix req->dst buffer overflow

The req->dst buffer size should be checked before copying from the scomp_scratch->dst to avoid req->dst buffer overflow problem.(CVE-2023-52612)

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(&amp;sk-&gt;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)

Database specific
{
    "severity": "High"
}
References

Affected packages

openEuler:20.03-LTS-SP1 / kernel

Package

Name
kernel
Purl
pkg:rpm/openEuler/kernel&distro=openEuler-20.03-LTS-SP1

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
4.19.90-2405.1.0.0248.oe1

Ecosystem specific

{
    "x86_64": [
        "kernel-debuginfo-4.19.90-2405.1.0.0248.oe1.x86_64.rpm",
        "kernel-tools-debuginfo-4.19.90-2405.1.0.0248.oe1.x86_64.rpm",
        "python2-perf-4.19.90-2405.1.0.0248.oe1.x86_64.rpm",
        "kernel-tools-4.19.90-2405.1.0.0248.oe1.x86_64.rpm",
        "python3-perf-debuginfo-4.19.90-2405.1.0.0248.oe1.x86_64.rpm",
        "python3-perf-4.19.90-2405.1.0.0248.oe1.x86_64.rpm",
        "kernel-source-4.19.90-2405.1.0.0248.oe1.x86_64.rpm",
        "perf-debuginfo-4.19.90-2405.1.0.0248.oe1.x86_64.rpm",
        "kernel-4.19.90-2405.1.0.0248.oe1.x86_64.rpm",
        "python2-perf-debuginfo-4.19.90-2405.1.0.0248.oe1.x86_64.rpm",
        "kernel-debugsource-4.19.90-2405.1.0.0248.oe1.x86_64.rpm",
        "kernel-devel-4.19.90-2405.1.0.0248.oe1.x86_64.rpm",
        "kernel-tools-devel-4.19.90-2405.1.0.0248.oe1.x86_64.rpm",
        "bpftool-debuginfo-4.19.90-2405.1.0.0248.oe1.x86_64.rpm",
        "perf-4.19.90-2405.1.0.0248.oe1.x86_64.rpm",
        "bpftool-4.19.90-2405.1.0.0248.oe1.x86_64.rpm"
    ],
    "src": [
        "kernel-4.19.90-2405.1.0.0248.oe1.src.rpm"
    ],
    "aarch64": [
        "python2-perf-debuginfo-4.19.90-2405.1.0.0248.oe1.aarch64.rpm",
        "kernel-debugsource-4.19.90-2405.1.0.0248.oe1.aarch64.rpm",
        "python3-perf-4.19.90-2405.1.0.0248.oe1.aarch64.rpm",
        "kernel-source-4.19.90-2405.1.0.0248.oe1.aarch64.rpm",
        "kernel-tools-debuginfo-4.19.90-2405.1.0.0248.oe1.aarch64.rpm",
        "bpftool-debuginfo-4.19.90-2405.1.0.0248.oe1.aarch64.rpm",
        "python2-perf-4.19.90-2405.1.0.0248.oe1.aarch64.rpm",
        "kernel-debuginfo-4.19.90-2405.1.0.0248.oe1.aarch64.rpm",
        "kernel-tools-devel-4.19.90-2405.1.0.0248.oe1.aarch64.rpm",
        "kernel-tools-4.19.90-2405.1.0.0248.oe1.aarch64.rpm",
        "perf-debuginfo-4.19.90-2405.1.0.0248.oe1.aarch64.rpm",
        "python3-perf-debuginfo-4.19.90-2405.1.0.0248.oe1.aarch64.rpm",
        "kernel-devel-4.19.90-2405.1.0.0248.oe1.aarch64.rpm",
        "bpftool-4.19.90-2405.1.0.0248.oe1.aarch64.rpm",
        "perf-4.19.90-2405.1.0.0248.oe1.aarch64.rpm",
        "kernel-4.19.90-2405.1.0.0248.oe1.aarch64.rpm"
    ]
}