In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix use-after-free warning in btrfsgetorcreatedelayednode()
Previously, btrfsgetorcreatedelayednode() set the delayednode's refcount before acquiring the root->delayednodes lock. Commit e8513c012de7 ("btrfs: implement reftracker for delayednodes") moved refcountset inside the critical section, which means there is no longer a memory barrier between setting the refcount and setting btrfsinode->delayednode.
Without that barrier, the stores to node->refs and btrfsinode->delayednode may become visible out of order. Another thread can then read btrfsinode->delayednode and attempt to increment a refcount that hasn't been set yet, leading to a refcounting bug and a use-after-free warning.
The fix is to move refcountset back to where it was to take advantage of the implicit memory barrier provided by lock acquisition.
Because the allocations now happen outside of the lock's critical section, they can use GFPNOFS instead of GFPATOMIC.
In the Linux kernel, the following vulnerability has been resolved:
RDMA/irdma: Fix data race on CQP request done
KCSAN detects a data race on cqprequest->requestdone memory location which is accessed locklessly in irdmahandlecqpop while being updated in irdmacqpcehandler.
Annotate lockless intent with READONCE/WRITEONCE to avoid any compiler optimizations like load fusing and/or KCSAN warning.
[222808.417128] BUG: KCSAN: data-race in irdmacqpcehandler [irdma] / irdmawaitevent [irdma]
[222808.417532] write to 0xffff8e44107019dc of 1 bytes by task 29658 on cpu 5: [222808.417610] irdmacqpcehandler+0x21e/0x270 [irdma] [222808.417725] cqpcomplworker+0x1b/0x20 [irdma] [222808.417827] processonework+0x4d1/0xa40 [222808.417835] workerthread+0x319/0x700 [222808.417842] kthread+0x180/0x1b0 [222808.417852] retfromfork+0x22/0x30
[222808.417918] read to 0xffff8e44107019dc of 1 bytes by task 29688 on cpu 1: [222808.417995] irdmawaitevent+0x1e2/0x2c0 [irdma] [222808.418099] irdmahandlecqpop+0xae/0x170 [irdma] [222808.418202] irdmacqpcqdestroycmd+0x70/0x90 [irdma] [222808.418308] irdmapudadelersrc+0x46d/0x4d0 [irdma] [222808.418411] irdmartdeinithw+0x179/0x1d0 [irdma] [222808.418514] irdmaibdeallocdevice+0x11/0x40 [irdma] [222808.418618] ibdeallocdevice+0x2a/0x120 [ibcore] [222808.418823] ibunregisterdevice+0xde/0x100 [ibcore] [222808.418981] ibunregisterdevice+0x22/0x40 [ibcore] [222808.419142] irdmaibunregisterdevice+0x70/0x90 [irdma] [222808.419248] i40iwclose+0x6f/0xc0 [irdma] [222808.419352] i40eclientdeviceunregister+0x14a/0x180 [i40e] [222808.419450] i40iwremove+0x21/0x30 [irdma] [222808.419554] auxiliarybusremove+0x31/0x50 [222808.419563] deviceremove+0x69/0xb0 [222808.419572] devicereleasedriverinternal+0x293/0x360 [222808.419582] driverdetach+0x7c/0xf0 [222808.419592] busremovedriver+0x8c/0x150 [222808.419600] driverunregister+0x45/0x70 [222808.419610] auxiliarydriverunregister+0x16/0x30 [222808.419618] irdmaexitmodule+0x18/0x1e [irdma] [222808.419733] dosysdeletemodule.constprop.0+0x1e2/0x310 [222808.419745] x64sysdeletemodule+0x1b/0x30 [222808.419755] dosyscall64+0x39/0x90 [222808.419763] entrySYSCALL64afterhwframe+0x63/0xcd
[222808.419829] value changed: 0x01 -> 0x03
In the Linux kernel, the following vulnerability has been resolved:
cifs: fix potential oops in cifsoplockbreak
With deferred close we can have closes that race with lease breaks, and so with the current checks for whether to send the lease response, oplockresponse(), this can mean that an unmount (killsb) can occur just before we were checking if the tcon->ses is valid. See below:
[Fri Aug 4 04:12:50 2023] RIP: 0010:cifsoplockbreak+0x1f7/0x5b0 [cifs] [Fri Aug 4 04:12:50 2023] Code: 7d a8 48 8b 7d c0 c0 e9 02 48 89 45 b8 41 89 cf e8 3e f5 ff ff 4c 89 f7 41 83 e7 01 e8 82 b3 03 f2 49 8b 45 50 48 85 c0 74 5e <48> 83 78 60 00 74 57 45 84 ff 75 52 48 8b 43 98 48 83 eb 68 48 39 [Fri Aug 4 04:12:50 2023] RSP: 0018:ffffb30607ddbdf8 EFLAGS: 00010206 [Fri Aug 4 04:12:50 2023] RAX: 632d223d32612022 RBX: ffff97136944b1e0 RCX: 0000000080100009 [Fri Aug 4 04:12:50 2023] RDX: 0000000000000001 RSI: 0000000080100009 RDI: ffff97136944b188 [Fri Aug 4 04:12:50 2023] RBP: ffffb30607ddbe58 R08: 0000000000000001 R09: ffffffffc08e0900 [Fri Aug 4 04:12:50 2023] R10: 0000000000000001 R11: 000000000000000f R12: ffff97136944b138 [Fri Aug 4 04:12:50 2023] R13: ffff97149147c000 R14: ffff97136944b188 R15: 0000000000000000 [Fri Aug 4 04:12:50 2023] FS: 0000000000000000(0000) GS:ffff9714f7c00000(0000) knlGS:0000000000000000 [Fri Aug 4 04:12:50 2023] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [Fri Aug 4 04:12:50 2023] CR2: 00007fd8de9c7590 CR3: 000000011228e000 CR4: 0000000000350ef0 [Fri Aug 4 04:12:50 2023] Call Trace: [Fri Aug 4 04:12:50 2023] <TASK> [Fri Aug 4 04:12:50 2023] processonework+0x225/0x3d0 [Fri Aug 4 04:12:50 2023] workerthread+0x4d/0x3e0 [Fri Aug 4 04:12:50 2023] ? processonework+0x3d0/0x3d0 [Fri Aug 4 04:12:50 2023] kthread+0x12a/0x150 [Fri Aug 4 04:12:50 2023] ? setkthreadstruct+0x50/0x50 [Fri Aug 4 04:12:50 2023] retfromfork+0x22/0x30 [Fri Aug 4 04:12:50 2023] </TASK>
To fix this change the ordering of the checks before sending the oplockresponse to first check if the openFileList is empty.
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix improper freeing of purex item
In qla2xxxprocesspurlsiocb(), an item is allocated via qla27xxcopymultiplepkt(), which internally calls qla24xxallocpurexitem().
The qla24xxallocpurexitem() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc().
An error handling path in qla2xxxprocesspurlsiocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption.
Fix this by using the correct deallocation function, qla24xxfreepurexitem(), which properly handles both dynamically allocated and pre-allocated items.