CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48735 – ALSA: hda: Fix UAF of leds class devs at unbinding
https://notcve.org/view.php?id=CVE-2022-48735
In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: Fix UAF of leds class devs at unbinding The LED class devices that are created by HD-audio codec drivers are registered via devm_led_classdev_register() and associated with the HD-audio codec device. Unfortunately, it turned out that the devres release doesn't work for this case; namely, since the codec resource release happens before the devm call chain, it triggers a NULL dereference or a UAF for a stale set_brightness_delay callback. For fixing the bug, this patch changes the LED class device register and unregister in a manual manner without devres, keeping the instances in hda_gen_spec. • https://git.kernel.org/stable/c/a7de1002135cf94367748ffc695a29812d7633b5 https://git.kernel.org/stable/c/0e629052f013eeb61494d4df2f1f647c2a9aef47 https://git.kernel.org/stable/c/813e9f3e06d22e29872d4fd51b54992d89cf66c8 https://git.kernel.org/stable/c/549f8ffc7b2f7561bea7f90930b6c5104318e87b •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2022-48734 – btrfs: fix deadlock between quota disable and qgroup rescan worker
https://notcve.org/view.php?id=CVE-2022-48734
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix deadlock between quota disable and qgroup rescan worker Quota disable ioctl starts a transaction before waiting for the qgroup rescan worker completes. However, this wait can be infinite and results in deadlock because of circular dependency among the quota disable ioctl, the qgroup rescan worker and the other task with transaction such as block group relocation task. The deadlock happens with the steps following: 1) Task A calls ioctl to disable quota. It starts a transaction and waits for qgroup rescan worker completes. 2) Task B such as block group relocation task starts a transaction and joins to the transaction that task A started. Then task B commits to the transaction. In this commit, task B waits for a commit by task A. 3) Task C as the qgroup rescan worker starts its job and starts a transaction. • https://git.kernel.org/stable/c/26b3901d20bf9da2c6a00cb1fb48932166f80a45 https://git.kernel.org/stable/c/32747e01436aac8ef93fe85b5b523b4f3b52f040 https://git.kernel.org/stable/c/89d4cca583fc9594ee7d1a0bc986886d6fb587e6 https://git.kernel.org/stable/c/31198e58c09e21d4f65c49d2361f76b87aca4c3f https://git.kernel.org/stable/c/e804861bd4e69cc5fe1053eedcb024982dde8e48 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48733 – btrfs: fix use-after-free after failure to create a snapshot
https://notcve.org/view.php?id=CVE-2022-48733
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free after failure to create a snapshot At ioctl.c:create_snapshot(), we allocate a pending snapshot structure and then attach it to the transaction's list of pending snapshots. After that we call btrfs_commit_transaction(), and if that returns an error we jump to 'fail' label, where we kfree() the pending snapshot structure. This can result in a later use-after-free of the pending snapshot: 1) We allocated the pending snapshot and added it to the transaction's list of pending snapshots; 2) We call btrfs_commit_transaction(), and it fails either at the first call to btrfs_run_delayed_refs() or btrfs_start_dirty_block_groups(). In both cases, we don't abort the transaction and we release our transaction handle. We jump to the 'fail' label and free the pending snapshot structure. We return with the pending snapshot still in the transaction's list; 3) Another task commits the transaction. • https://git.kernel.org/stable/c/7e4c72dbaf62f8978af8321a24dbd35566d3a78a https://git.kernel.org/stable/c/a7b717fa15165d3d9245614680bebc48a52ac05d https://git.kernel.org/stable/c/9372fa1d73da5f1673921e365d0cd2c27ec7adc2 https://git.kernel.org/stable/c/28b21c558a3753171097193b6f6602a94169093a •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2022-48731 – mm/kmemleak: avoid scanning potential huge holes
https://notcve.org/view.php?id=CVE-2022-48731
In the Linux kernel, the following vulnerability has been resolved: mm/kmemleak: avoid scanning potential huge holes When using devm_request_free_mem_region() and devm_memremap_pages() to add ZONE_DEVICE memory, if requested free mem region's end pfn were huge(e.g., 0x400000000), the node_end_pfn() will be also huge (see move_pfn_range_to_zone()). Thus it creates a huge hole between node_start_pfn() and node_end_pfn(). We found on some AMD APUs, amdkfd requested such a free mem region and created a huge hole. In such a case, following code snippet was just doing busy test_bit() looping on the huge hole. for (pfn = start_pfn; pfn < end_pfn; pfn++) { struct page *page = pfn_to_online_page(pfn); if (!page) continue; ... } So we got a soft lockup: watchdog: BUG: soft lockup - CPU#6 stuck for 26s! [bash:1221] CPU: 6 PID: 1221 Comm: bash Not tainted 5.15.0-custom #1 RIP: 0010:pfn_to_online_page+0x5/0xd0 Call Trace: ? • https://git.kernel.org/stable/c/d3533ee20e9a0e2e8f60384da7450d43d1c63d1a https://git.kernel.org/stable/c/352715593e81b917ce1b321e794549815b850134 https://git.kernel.org/stable/c/a5389c80992f0001ee505838fe6a8b20897ce96e https://git.kernel.org/stable/c/cebb0aceb21ad91429617a40e3a17444fabf1529 https://git.kernel.org/stable/c/c10a0f877fe007021d70f9cada240f42adc2b5db •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48712 – ext4: fix error handling in ext4_fc_record_modified_inode()
https://notcve.org/view.php?id=CVE-2022-48712
In the Linux kernel, the following vulnerability has been resolved: ext4: fix error handling in ext4_fc_record_modified_inode() Current code does not fully takes care of krealloc() error case, which could lead to silent memory corruption or a kernel bug. This patch fixes that. Also it cleans up some duplicated error handling logic from various functions in fast_commit.c file. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ext4: corrige el manejo de errores en ext4_fc_record_modified_inode() El código actual no soluciona completamente el caso de error de krealloc(), lo que podría provocar una corrupción silenciosa de la memoria o un error del kernel. Este parche soluciona eso. También limpia alguna lógica de manejo de errores duplicada de varias funciones en el archivo fast_commit.c. • https://git.kernel.org/stable/c/62e46e0ffc02daa8fcfc02f7a932cc8a19601b19 https://git.kernel.org/stable/c/1b6762ecdf3cf12113772427c904aa3c420a1802 https://git.kernel.org/stable/c/14aa3f49c7fc6424763f4323bfbc3a807b0727dc https://git.kernel.org/stable/c/cdce59a1549190b66f8e3fe465c2b2f714b98a94 •