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 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48724 – iommu/vt-d: Fix potential memory leak in intel_setup_irq_remapping()
https://notcve.org/view.php?id=CVE-2022-48724
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix potential memory leak in intel_setup_irq_remapping() After commit e3beca48a45b ("irqdomain/treewide: Keep firmware node unconditionally allocated"). For tear down scenario, fn is only freed after fail to allocate ir_domain, though it also should be freed in case dmar_enable_qi returns error. Besides free fn, irq_domain and ir_msi_domain need to be removed as well if intel_setup_irq_remapping fails to enable queued invalidation. Improve the rewinding path by add out_free_ir_domain and out_free_fwnode lables per Baolu's suggestion. • https://git.kernel.org/stable/c/03992c88d71ba79d956f2ed54e370e630b8750f4 https://git.kernel.org/stable/c/c0c489e5430530a7021f4c889cd5931597e4b200 https://git.kernel.org/stable/c/36f7355545725c5e9400520ae33e6ee16cf78c0e https://git.kernel.org/stable/c/e3beca48a45b5e0e6e6a4e0124276b8248dcc9bb https://git.kernel.org/stable/c/b4198ecddb87cd955aa9e024dd656af5ceaf6196 https://git.kernel.org/stable/c/a0c685ba99961b1dd894b2e470e692a539770f6d https://git.kernel.org/stable/c/a31cb1f0fb6caf46ffe88c41252b6b7a4ee062d9 https://git.kernel.org/stable/c/5c43d46daa0d2928234dd2792ebebc35d •