OESA-2024-1569

The Linux Kernel, the operating system core itself.

Security Fix(es):

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:

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:

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:

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:

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)