CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-41067 – btrfs: scrub: handle RST lookup error correctly
https://notcve.org/view.php?id=CVE-2024-41067
In the Linux kernel, the following vulnerability has been resolved: btrfs: scrub: handle RST lookup error correctly [BUG] When running btrfs/060 with forced RST feature, it would crash the following ASSERT() inside scrub_read_endio(): ASSERT(sector_nr < stripe->nr_sectors); Before that, we would have tree dump from btrfs_get_raid_extent_offset(), as we failed to find the RST entry for the range. [CAUSE] Inside scrub_submit_extent_sector_read() every time we allocated a new bbio we immediately called btrfs_map_block() to make sure there was some RST range covering the scrub target. But if btrfs_map_block() fails, we immediately call endio for the bbio, while the bbio is newly allocated, it's completely empty. Then inside scrub_read_endio(), we go through the bvecs to find the sector number (as bi_sector is no longer reliable if the bio is submitted to lower layers). And since the bio is empty, such bvecs iteration would not find any sector matching the sector, and return sector_nr == stripe->nr_sectors, triggering the ASSERT(). [FIX] Instead of calling btrfs_map_block() after allocating a new bbio, call btrfs_map_block() first. Since our only objective of calling btrfs_map_block() is only to update stripe_len, there is really no need to do that after btrfs_alloc_bio(). This new timing would avoid the problem of handling empty bbio completely, and in fact fixes a possible race window for the old code, where if the submission thread is the only owner of the pending_io, the scrub would never finish (since we didn't decrease the pending_io counter). Although the root cause of RST lookup failure still needs to be addressed. • https://git.kernel.org/stable/c/17d1fd302a53d7e456a7412da74be74a0cf63a72 https://git.kernel.org/stable/c/2c49908634a2b97b1c3abe0589be2739ac5e7fd5 •
CVSS: 6.4EPSS: 0%CPEs: 4EXPL: 0CVE-2024-41066 – ibmvnic: Add tx check to prevent skb leak
https://notcve.org/view.php?id=CVE-2024-41066
In the Linux kernel, the following vulnerability has been resolved: ibmvnic: Add tx check to prevent skb leak Below is a summary of how the driver stores a reference to an skb during transmit: tx_buff[free_map[consumer_index]]->skb = new_skb; free_map[consumer_index] = IBMVNIC_INVALID_MAP; consumer_index ++; Where variable data looks like this: free_map == [4, IBMVNIC_INVALID_MAP, IBMVNIC_INVALID_MAP, 0, 3] consumer_index^ tx_buff == [skb=null, skb=<ptr>, skb=<ptr>, skb=null, skb=null] The driver has checks to ensure that free_map[consumer_index] pointed to a valid index but there was no check to ensure that this index pointed to an unused/null skb address. So, if, by some chance, our free_map and tx_buff lists become out of sync then we were previously risking an skb memory leak. This could then cause tcp congestion control to stop sending packets, eventually leading to ETIMEDOUT. Therefore, add a conditional to ensure that the skb address is null. If not then warn the user (because this is still a bug that should be patched) and free the old pointer to prevent memleak/tcp problems. • https://git.kernel.org/stable/c/16ad1557cae582e79bb82dddd612d9bdfaa11d4c https://git.kernel.org/stable/c/267c61c4afed0ff9a2e83462abad3f41d8ca1f06 https://git.kernel.org/stable/c/e7b75def33eae61ddaad6cb616c517dc3882eb2a https://git.kernel.org/stable/c/0983d288caf984de0202c66641577b739caad561 https://access.redhat.com/security/cve/CVE-2024-41066 https://bugzilla.redhat.com/show_bug.cgi?id=2300442 • CWE-200: Exposure of Sensitive Information to an Unauthorized Actor •
CVSS: 4.4EPSS: 0%CPEs: 7EXPL: 0CVE-2024-41065 – powerpc/pseries: Whitelist dtl slub object for copying to userspace
https://notcve.org/view.php?id=CVE-2024-41065
In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Whitelist dtl slub object for copying to userspace Reading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-* results in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled as shown below. kernel BUG at mm/usercopy.c:102! Oops: Exception in kernel mode, sig: 5 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries Modules linked in: xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc scsi_transport_fc ibmveth pseries_wdt dm_multipath dm_mirror dm_region_hash dm_log dm_mod fuse CPU: 27 PID: 1815 Comm: python3 Not tainted 6.10.0-rc3 #85 Hardware name: IBM,9040-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_042) hv:phyp pSeries NIP: c0000000005d23d4 LR: c0000000005d23d0 CTR: 00000000006ee6f8 REGS: c000000120c078c0 TRAP: 0700 Not tainted (6.10.0-rc3) MSR: 8000000000029033 <SF,EE,ME,IR,DR,RI,LE> CR: 2828220f XER: 0000000e CFAR: c0000000001fdc80 IRQMASK: 0 [ ... GPRs omitted ... ] NIP [c0000000005d23d4] usercopy_abort+0x78/0xb0 LR [c0000000005d23d0] usercopy_abort+0x74/0xb0 Call Trace: usercopy_abort+0x74/0xb0 (unreliable) __check_heap_object+0xf8/0x120 check_heap_object+0x218/0x240 __check_object_size+0x84/0x1a4 dtl_file_read+0x17c/0x2c4 full_proxy_read+0x8c/0x110 vfs_read+0xdc/0x3a0 ksys_read+0x84/0x144 system_call_exception+0x124/0x330 system_call_vectored_common+0x15c/0x2ec --- interrupt: 3000 at 0x7fff81f3ab34 Commit 6d07d1cd300f ("usercopy: Restrict non-usercopy caches to size 0") requires that only whitelisted areas in slab/slub objects can be copied to userspace when usercopy hardening is enabled using CONFIG_HARDENED_USERCOPY. Dtl contains hypervisor dispatch events which are expected to be read by privileged users. Hence mark this safe for user access. Specify useroffset=0 and usersize=DISPATCH_LOG_BYTES to whitelist the entire object. • https://git.kernel.org/stable/c/a7b952941ce07e1e7a2cafd08c64a98e14f553e6 https://git.kernel.org/stable/c/6b16098148ea58a67430d90e20476be2377c3acd https://git.kernel.org/stable/c/e59822f9d700349cd17968d22c979db23a2d347f https://git.kernel.org/stable/c/1ee68686d1e2a5da35d5650be0be1ce06fe2ceb2 https://git.kernel.org/stable/c/e512a59b472684d8585125101ab03b86c2c1348a https://git.kernel.org/stable/c/0f5892212c27be31792ef1daa89c8dac1b3047e4 https://git.kernel.org/stable/c/1a14150e1656f7a332a943154fc486504db4d586 https://access.redhat.com/security/cve/CVE-2024-41065 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-41064 – powerpc/eeh: avoid possible crash when edev->pdev changes
https://notcve.org/view.php?id=CVE-2024-41064
In the Linux kernel, the following vulnerability has been resolved: powerpc/eeh: avoid possible crash when edev->pdev changes If a PCI device is removed during eeh_pe_report_edev(), edev->pdev will change and can cause a crash, hold the PCI rescan/remove lock while taking a copy of edev->pdev->bus. • https://git.kernel.org/stable/c/8836e1bf5838ac6c08760e0a2dd7cf6410aa7ff3 https://git.kernel.org/stable/c/033c51dfdbb6b79ab43fb3587276fa82d0a329e1 https://git.kernel.org/stable/c/4fad7fef847b6028475dd7b4c14fcb82b3e51274 https://git.kernel.org/stable/c/4bc246d2d60d071314842fa448faa4ed39082aff https://git.kernel.org/stable/c/f23c3d1ca9c4b2d626242a4e7e1ec1770447f7b5 https://git.kernel.org/stable/c/428d940a8b6b3350b282c14d3f63350bde65c48b https://git.kernel.org/stable/c/a1216e62d039bf63a539bbe718536ec789a853dd https://access.redhat.com/security/cve/CVE-2024-41064 • CWE-413: Improper Resource Locking •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-41063 – Bluetooth: hci_core: cancel all works upon hci_unregister_dev()
https://notcve.org/view.php?id=CVE-2024-41063
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: cancel all works upon hci_unregister_dev() syzbot is reporting that calling hci_release_dev() from hci_error_reset() due to hci_dev_put() from hci_error_reset() can cause deadlock at destroy_workqueue(), for hci_error_reset() is called from hdev->req_workqueue which destroy_workqueue() needs to flush. We need to make sure that hdev->{rx_work,cmd_work,tx_work} which are queued into hdev->workqueue and hdev->{power_on,error_reset} which are queued into hdev->req_workqueue are no longer running by the moment destroy_workqueue(hdev->workqueue); destroy_workqueue(hdev->req_workqueue); are called from hci_release_dev(). Call cancel_work_sync() on these work items from hci_unregister_dev() as soon as hdev->list is removed from hci_dev_list. • https://git.kernel.org/stable/c/48542881997e17b49dc16b93fe910e0cfcf7a9f9 https://git.kernel.org/stable/c/9cfc84b1d464cc024286f42a090718f9067b80ed https://git.kernel.org/stable/c/ddeda6ca5f218b668b560d90fc31ae469adbfd92 https://git.kernel.org/stable/c/d2ce562a5aff1dcd0c50d9808ea825ef90da909f https://git.kernel.org/stable/c/96600c2e5ee8213dbab5df1617293d8e847bb4fa https://git.kernel.org/stable/c/d6cbce18370641a21dd889e8613d8153df15eb39 https://git.kernel.org/stable/c/3f939bd73fed12dddc2a32a76116c19ca47c7678 https://git.kernel.org/stable/c/0d151a103775dd9645c78c97f77d6e2a5 •