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: 8EXPL: 0CVE-2022-48732 – drm/nouveau: fix off by one in BIOS boundary checking
https://notcve.org/view.php?id=CVE-2022-48732
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix off by one in BIOS boundary checking Bounds checking when parsing init scripts embedded in the BIOS reject access to the last byte. This causes driver initialization to fail on Apple eMac's with GeForce 2 MX GPUs, leaving the system with no working console. This is probably only seen on OpenFirmware machines like PowerPC Macs because the BIOS image provided by OF is only the used parts of the ROM, not a power-of-two blocks read from PCI directly so PCs always have empty bytes at the end that are never accessed. • https://git.kernel.org/stable/c/4d4e9907ff572bb1d1c0f6913ad6e3d6d4525077 https://git.kernel.org/stable/c/d4b746e60fd8eaa8016e144223abe91158edcdad https://git.kernel.org/stable/c/909d3ec1bf9f0ec534bfc081b77c0836fea7b0e2 https://git.kernel.org/stable/c/b2a21669ee98aafc41c6d42ef15af4dab9e6e882 https://git.kernel.org/stable/c/acc887ba88333f5fec49631f12d8cc7ebd95781c https://git.kernel.org/stable/c/f071d9fa857582d7bd77f4906691f73d3edeab73 https://git.kernel.org/stable/c/d877e814a62b7de9069aeff8bc1d979dfc996e06 https://git.kernel.org/stable/c/e7c36fa8a1e63b08312162179c78a0c77 •
CVSS: 5.5EPSS: 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 •