CVSS: 2.3EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47073 – platform/x86: dell-smbios-wmi: Fix oops on rmmod dell_smbios
https://notcve.org/view.php?id=CVE-2021-47073
In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-smbios-wmi: Fix oops on rmmod dell_smbios init_dell_smbios_wmi() only registers the dell_smbios_wmi_driver on systems where the Dell WMI interface is supported. While exit_dell_smbios_wmi() unregisters it unconditionally, this leads to the following oops: [ 175.722921] ------------[ cut here ]------------ [ 175.722925] Unexpected driver unregister! [ 175.722939] WARNING: CPU: 1 PID: 3630 at drivers/base/driver.c:194 driver_unregister+0x38/0x40 ... [ 175.723089] Call Trace: [ 175.723094] cleanup_module+0x5/0xedd [dell_smbios] ... [ 175.723148] ---[ end trace 064c34e1ad49509d ]--- Make the unregister happen on the same condition the register happens to fix this. • https://git.kernel.org/stable/c/1a258e670434f404a4500b65ba1afea2c2b29bba https://git.kernel.org/stable/c/75cfc833da4a2111106d4c134e93e0c7f41e35e7 https://git.kernel.org/stable/c/6fa78a6b9a3beb676a010dc489c1257f7e432525 https://git.kernel.org/stable/c/0cf036a0d325200e6c27b90908e51195bbc557b1 https://git.kernel.org/stable/c/8d746ea7c687bab060a2c05a35c449302406cd52 https://git.kernel.org/stable/c/3a53587423d25c87af4b4126a806a0575104b45e https://access.redhat.com/security/cve/CVE-2021-47073 https://bugzilla.redhat.com/show_bug.cgi?id=2267518 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47072 – btrfs: fix removed dentries still existing after log is synced
https://notcve.org/view.php?id=CVE-2021-47072
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix removed dentries still existing after log is synced When we move one inode from one directory to another and both the inode and its previous parent directory were logged before, we are not supposed to have the dentry for the old parent if we have a power failure after the log is synced. Only the new dentry is supposed to exist. Generally this works correctly, however there is a scenario where this is not currently working, because the old parent of the file/directory that was moved is not authoritative for a range that includes the dir index and dir item keys of the old dentry. This case is better explained with the following example and reproducer: # The test requires a very specific layout of keys and items in the # fs/subvolume btree to trigger the bug. So we want to make sure that # on whatever platform we are, we have the same leaf/node size. # # Currently in btrfs the node/leaf size can not be smaller than the page # size (but it can be greater than the page size). So use the largest # supported node/leaf size (64K). $ mkfs.btrfs -f -n 65536 /dev/sdc $ mount /dev/sdc /mnt # "testdir" is inode 257. $ mkdir /mnt/testdir $ chmod 755 /mnt/testdir # Create several empty files to have the directory "testdir" with its # items spread over several leaves (7 in this case). $ for ((i = 1; i <= 1200; i++)); do echo -n > /mnt/testdir/file$i done # Create our test directory "dira", inode number 1458, which gets all # its items in leaf 7. # # The BTRFS_DIR_ITEM_KEY item for inode 257 ("testdir") that points to # the entry named "dira" is in leaf 2, while the BTRFS_DIR_INDEX_KEY # item that points to that entry is in leaf 3. # # For this particular filesystem node size (64K), file count and file # names, we endup with the directory entry items from inode 257 in # leaves 2 and 3, as previously mentioned - what matters for triggering # the bug exercised by this test case is that those items are not placed # in leaf 1, they must be placed in a leaf different from the one # containing the inode item for inode 257. # # The corresponding BTRFS_DIR_ITEM_KEY and BTRFS_DIR_INDEX_KEY items for # the parent inode (257) are the following: # # item 460 key (257 DIR_ITEM 3724298081) itemoff 48344 itemsize 34 # location key (1458 INODE_ITEM 0) type DIR # transid 6 data_len 0 name_len 4 # name: dira # # and: # # item 771 key (257 DIR_INDEX 1202) itemoff 36673 itemsize 34 # location key (1458 INODE_ITEM 0) type DIR # transid 6 data_len 0 name_len 4 # name: dira $ mkdir /mnt/testdir/dira # Make sure everything done so far is durably persisted. $ sync # Now do a change to inode 257 ("testdir") that does not result in # COWing leaves 2 and 3 - the leaves that contain the directory items # pointing to inode 1458 (directory "dira"). # # Changing permissions, the owner/group, updating or adding a xattr, # etc, will not change (COW) leaves 2 and 3. • https://git.kernel.org/stable/c/64d6b281ba4db044c946158387c74e1149b9487e https://git.kernel.org/stable/c/6d0924c5b742036b4f20a0ffdf2b6cf3f963f5f6 https://git.kernel.org/stable/c/54a40fc3a1da21b52dbf19f72fdc27a2ec740760 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47071 – uio_hv_generic: Fix a memory leak in error handling paths
https://notcve.org/view.php?id=CVE-2021-47071
In the Linux kernel, the following vulnerability has been resolved: uio_hv_generic: Fix a memory leak in error handling paths If 'vmbus_establish_gpadl()' fails, the (recv|send)_gpadl will not be updated and 'hv_uio_cleanup()' in the error handling path will not be able to free the corresponding buffer. In such a case, we need to free the buffer explicitly. • https://git.kernel.org/stable/c/cdfa835c6e5e87d145f9f632b58843de97509f2b https://git.kernel.org/stable/c/cdd91637d4ef33e2be19a8e16e72e7d00c996d76 https://git.kernel.org/stable/c/d84b5e912212b05f6b5bde9f682046accfbe0354 https://git.kernel.org/stable/c/53486c467e356e06aa37047c984fccd64d78c827 https://git.kernel.org/stable/c/3ee098f96b8b6c1a98f7f97915f8873164e6af9d •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47070 – uio_hv_generic: Fix another memory leak in error handling paths
https://notcve.org/view.php?id=CVE-2021-47070
In the Linux kernel, the following vulnerability has been resolved: uio_hv_generic: Fix another memory leak in error handling paths Memory allocated by 'vmbus_alloc_ring()' at the beginning of the probe function is never freed in the error handling path. Add the missing 'vmbus_free_ring()' call. Note that it is already freed in the .remove function. • https://git.kernel.org/stable/c/cdfa835c6e5e87d145f9f632b58843de97509f2b https://git.kernel.org/stable/c/5f59240cf25b2f7a0fdffc2701482a70310fec07 https://git.kernel.org/stable/c/0b0226be3a52dadd965644bc52a807961c2c26df •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47069 – ipc/mqueue, msg, sem: avoid relying on a stack reference past its expiry
https://notcve.org/view.php?id=CVE-2021-47069
In the Linux kernel, the following vulnerability has been resolved: ipc/mqueue, msg, sem: avoid relying on a stack reference past its expiry do_mq_timedreceive calls wq_sleep with a stack local address. The sender (do_mq_timedsend) uses this address to later call pipelined_send. This leads to a very hard to trigger race where a do_mq_timedreceive call might return and leave do_mq_timedsend to rely on an invalid address, causing the following crash: RIP: 0010:wake_q_add_safe+0x13/0x60 Call Trace: __x64_sys_mq_timedsend+0x2a9/0x490 do_syscall_64+0x80/0x680 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f5928e40343 The race occurs as: 1. do_mq_timedreceive calls wq_sleep with the address of `struct ext_wait_queue` on function stack (aliased as `ewq_addr` here) - it holds a valid `struct ext_wait_queue *` as long as the stack has not been overwritten. 2. `ewq_addr` gets added to info->e_wait_q[RECV].list in wq_add, and do_mq_timedsend receives it via wq_get_first_waiter(info, RECV) to call __pipelined_op. 3. Sender calls __pipelined_op::smp_store_release(&this->state, STATE_READY). Here is where the race window begins. • https://git.kernel.org/stable/c/0d97a82ba830d89a1e541cc9cd11f1e38c28e416 https://git.kernel.org/stable/c/4528c0c323085e645b8765913b4a7fd42cf49b65 https://git.kernel.org/stable/c/807fa14536b26803b858da878b643be72952a097 https://git.kernel.org/stable/c/a11ddb37bf367e6b5239b95ca759e5389bb46048 https://access.redhat.com/security/cve/CVE-2021-47069 https://bugzilla.redhat.com/show_bug.cgi?id=2267513 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •