OESA-2024-2589

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

iouring/io-wq: Use setbit() and test_bit() at worker->flags

Utilize setbit() and testbit() on worker->flags within io_uring/io-wq to address potential data races.

The structure ioworker->flags may be accessed through various data paths, leading to concurrency issues. When KCSAN is enabled, it reveals data races occurring in ioworkerhandlework and iowqactivatefreeworker functions.

 BUG: KCSAN: data-race in io_worker_handle_work / io_wq_activate_free_worker
 write to 0xffff8885c4246404 of 4 bytes by task 49071 on cpu 28:
 io_worker_handle_work (io_uring/io-wq.c:434 io_uring/io-wq.c:569)
 io_wq_worker (io_uring/io-wq.c:?)

<snip>

 read to 0xffff8885c4246404 of 4 bytes by task 49024 on cpu 5:
 io_wq_activate_free_worker (io_uring/io-wq.c:? io_uring/io-wq.c:285)
 io_wq_enqueue (io_uring/io-wq.c:947)
 io_queue_iowq (io_uring/io_uring.c:524)
 io_req_task_submit (io_uring/io_uring.c:1511)
 io_handle_tw_list (io_uring/io_uring.c:1198)

<snip>

Line numbers against commit 18daea77cca6 ("Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm").

These races involve writes and reads to the same memory location by different tasks running on different CPUs. To mitigate this, refactor the code to use atomic operations such as setbit(), testbit(), and clear_bit() instead of basic "and" and "or" operations. This ensures thread-safe manipulation of worker flags.

Also, move create_index to avoid holes in the structure.(CVE-2024-39508)

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

btrfs: fix qgroup reserve leaks in cowfilerange

In the buffered write path, the dirty page owns the qgroup reserve until it creates an ordered_extent.

Therefore, any errors that occur before the orderedextent is created must free that reservation, or else the space is leaked. The fstest generic/475 exercises various IO error paths, and is able to trigger errors in cowfile_range where we fail to get to allocating the ordered extent. Note that because we do clear delalloc, we are likely to remove the inode from the delalloc list, so the inodes/pages to not have invalidate/launder called on them in the commit abort path.

This results in failures at the unmount stage of the test that look like:

BTRFS: error (device dm-8 state EA) in cleanuptransaction:2018: errno=-5 IO failure BTRFS: error (device dm-8 state EA) in btrfsreplacefileextents:2416: errno=-5 IO failure BTRFS warning (device dm-8 state EA): qgroup 0/5 has unreleased space, type 0 rsv 28672 ------------[ cut here ]------------ WARNING: CPU: 3 PID: 22588 at fs/btrfs/disk-io.c:4333 closectree+0x222/0x4d0 [btrfs] Modules linked in: btrfs blake2bgeneric libcrc32c xor zstdcompress raid6pq CPU: 3 PID: 22588 Comm: umount Kdump: loaded Tainted: G W 6.10.0-rc7-gab56fde445b8 #21 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 RIP: 0010:closectree+0x222/0x4d0 [btrfs] RSP: 0018:ffffb4465283be00 EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffffa1a1818e1000 RCX: 0000000000000001 RDX: 0000000000000000 RSI: ffffb4465283bbe0 RDI: ffffa1a19374fcb8 RBP: ffffa1a1818e13c0 R08: 0000000100028b16 R09: 0000000000000000 R10: 0000000000000003 R11: 0000000000000003 R12: ffffa1a18ad7972c R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f9168312b80(0000) GS:ffffa1a4afcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f91683c9140 CR3: 000000010acaa000 CR4: 00000000000006f0 Call Trace: <TASK> ? closectree+0x222/0x4d0 [btrfs] ? _warn.cold+0x8e/0xea ? closectree+0x222/0x4d0 [btrfs] ? reportbug+0xff/0x140 ? handlebug+0x3b/0x70 ? excinvalidop+0x17/0x70 ? asmexcinvalidop+0x1a/0x20 ? closectree+0x222/0x4d0 [btrfs] genericshutdownsuper+0x70/0x160 killanonsuper+0x11/0x40 btrfskillsuper+0x11/0x20 [btrfs] deactivatelockedsuper+0x2e/0xa0 cleanupmnt+0xb5/0x150 taskworkrun+0x57/0x80 syscallexittousermode+0x121/0x130 dosyscall64+0xab/0x1a0 entrySYSCALL64after_hwframe+0x77/0x7f RIP: 0033:0x7f916847a887 ---[ end trace 0000000000000000 ]--- BTRFS error (device dm-8 state EA): qgroup reserved space leaked

Cases 2 and 3 in the outreserve path both pertain to this type of leak and must free the reserved qgroup data. Because it is already an error path, I opted not to handle the possible errors in btrfsfreeqgroupdata.(CVE-2024-46733)

(CVE-2024-50194)

In the Linux kernel, the following vulnerability has been resolved: ocfs2: pass u64 to ocfs2truncateinline maybe overflow Syzbot reported a kernel BUG in ocfs2truncateinline. There are two reasons for this: first, the parameter value passed is greater than ocfs2maxinlinedatawithxattr, second, the start and end parameters of ocfs2truncateinline are "unsigned int". So, we need to add a sanity check for bytestart and bytelen right before ocfs2truncateinline() in ocfs2removeinoderange(), if they are greater than ocfs2maxinlinedatawith_xattr return -EINVAL.(CVE-2024-50218)

In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix use-after-free of network namespace. Recently, we got a customer report that CIFS triggers oops while reconnecting to a server. [0] The workload runs on Kubernetes, and some pods mount CIFS servers in non-root network namespaces. The problem rarely happened, but it was always while the pod was dying. The root cause is wrong reference counting for network namespace. CIFS uses kernel sockets, which do not hold refcnt of the netns that the socket belongs to. That means CIFS must ensure the socket is always freed before its netns; otherwise, use-after-free happens. The repro steps are roughly: 1. mount CIFS in a non-root netns 2. drop packets from the netns 3. destroy the netns 4. unmount CIFS We can reproduce the issue quickly with the script [1] below and see the splat [2] if CONFIGNETNSREFCNTTRACKER is enabled. When the socket is TCP, it is hard to guarantee the netns lifetime without holding refcnt due to async timers. Let's hold netns refcnt for each socket as done for SMC in commit 9744d2bf1976 ("smc: Fix use-after-free in tcpwritetimerhandler()."). Note that we need to move putnet() from cifsputtcpsession() to cleandemultiplexinfo(); otherwise, _sockcreate() still could touch a freed netns while cifsd tries to reconnect from cifsdemultiplexthread(). Also, maybegetnet() cannot be put just before _sockcreate() because the code is not under RCU and there is a small chance that the same address happened to be reallocated to another netns. [0]: CIFS: VFS: \XXXXXXXXXXX has not responded in 15 seconds. Reconnecting... CIFS: Serverclose failed 4 times, giving up Unable to handle kernel paging request at virtual address 14de99e461f84a07 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 [14de99e461f84a07] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: clsbpf schingress nlsutf8 cifs cifsarc4 cifsmd4 dnsresolver tcpdiag inetdiag veth xtstate xtconnmark nfconntracknetlink xtnat xtstatistic xtMASQUERADE xtmark xtaddrtype iptREJECT nfrejectipv4 nftchainnat nfnat xtconntrack nfconntrack nfdefragipv6 nfdefragipv4 xtcomment nftcompat nftables nfnetlink overlay nlsascii nlscp437 sunrpc vfat fat aesceblk aescecipher ghashce sm4cecipher sm4 sm3ce sm3 sha3ce sha512ce sha512arm64 sha1ce ena button schfqcodel loop fuse configfs dmisysfs sha2ce sha256arm64 dmmirror dmregionhash dmlog dmmod dax efivarfs CPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1 Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : fibruleslookup+0x44/0x238 lr : _fiblookup+0x64/0xbc sp : ffff8000265db790 x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01 x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580 x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500 x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002 x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294 x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0 x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500 Call trace: fibruleslookup+0x44/0x238 _fiblookup+0x64/0xbc iprouteoutputkeyhashrcu+0x2c4/0x398 iprouteoutputkeyhash+0x60/0x8c tcpv4connect+0x290/0x488 _inetstreamconnect+0x108/0x3d0 inetstreamconnect+0x50/0x78 kernelconnect+0x6c/0xac genericipconne ---truncated---(CVE-2024-53095)