CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-43834 – xdp: fix invalid wait context of page_pool_destroy()
https://notcve.org/view.php?id=CVE-2024-43834
In the Linux kernel, the following vulnerability has been resolved: xdp: fix invalid wait context of page_pool_destroy() If the driver uses a page pool, it creates a page pool with page_pool_create(). The reference count of page pool is 1 as default. A page pool will be destroyed only when a reference count reaches 0. page_pool_destroy() is used to destroy page pool, it decreases a reference count. When a page pool is destroyed, ->disconnect() is called, which is mem_allocator_disconnect(). This function internally acquires mutex_lock(). If the driver uses XDP, it registers a memory model with xdp_rxq_info_reg_mem_model(). The xdp_rxq_info_reg_mem_model() internally increases a page pool reference count if a memory model is a page pool. Now the reference count is 2. To destroy a page pool, the driver should call both page_pool_destroy() and xdp_unreg_mem_model(). The xdp_unreg_mem_model() internally calls page_pool_destroy(). Only page_pool_destroy() decreases a reference count. If a driver calls page_pool_destroy() then xdp_unreg_mem_model(), we will face an invalid wait context warning. Because xdp_unreg_mem_model() calls page_pool_destroy() with rcu_read_lock(). The page_pool_destroy() internally acquires mutex_lock(). Splat looks like: ============================= [ BUG: Invalid wait context ] 6.10.0-rc6+ #4 Tainted: G W ----------------------------- ethtool/1806 is trying to lock: ffffffff90387b90 (mem_id_lock){+.+.}-{4:4}, at: mem_allocator_disconnect+0x73/0x150 other info that might help us debug this: context-{5:5} 3 locks held by ethtool/1806: stack backtrace: CPU: 0 PID: 1806 Comm: ethtool Tainted: G W 6.10.0-rc6+ #4 f916f41f172891c800f2fed Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021 Call Trace: <TASK> dump_stack_lvl+0x7e/0xc0 __lock_acquire+0x1681/0x4de0 ? _printk+0x64/0xe0 ? __pfx_mark_lock.part.0+0x10/0x10 ? __pfx___lock_acquire+0x10/0x10 lock_acquire+0x1b3/0x580 ? mem_allocator_disconnect+0x73/0x150 ? • https://git.kernel.org/stable/c/c3f812cea0d7006469d1cf33a4a9f0a12bb4b3a3 https://git.kernel.org/stable/c/bf22306d92ca59c59dc4aa3bab14768948193d56 https://git.kernel.org/stable/c/05f646cb2174d1a4e032b60b99097f5c4b522616 https://git.kernel.org/stable/c/be9d08ff102df3ac4f66e826ea935cf3af63a4bd https://git.kernel.org/stable/c/6c390ef198aa69795427a5cb5fd7cb4bc7e6cd7a https://git.kernel.org/stable/c/3fc1be360b99baeea15cdee3cf94252cd3a72d26 https://git.kernel.org/stable/c/bf0ce5aa5f2525ed1b921ba36de96e458e77f482 https://git.kernel.org/stable/c/12144069209eec7f2090ce9afa15acdcc •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-43833 – media: v4l: async: Fix NULL pointer dereference in adding ancillary links
https://notcve.org/view.php?id=CVE-2024-43833
In the Linux kernel, the following vulnerability has been resolved: media: v4l: async: Fix NULL pointer dereference in adding ancillary links In v4l2_async_create_ancillary_links(), ancillary links are created for lens and flash sub-devices. These are sub-device to sub-device links and if the async notifier is related to a V4L2 device, the source sub-device of the ancillary link is NULL, leading to a NULL pointer dereference. Check the notifier's sd field is non-NULL in v4l2_async_create_ancillary_links(). [Sakari Ailus: Reword the subject and commit messages slightly.] • https://git.kernel.org/stable/c/aa4faf6eb27132532d5a133d9241254c16d4bafa https://git.kernel.org/stable/c/fe0f92fd5320b393e44ca210805e653ea90cc982 https://git.kernel.org/stable/c/249212ceb4187783af3801c57b92a5a25d410621 https://git.kernel.org/stable/c/b87e28050d9b0959de24574d587825cfab2f13fb https://git.kernel.org/stable/c/9b4667ea67854f0b116fe22ad11ef5628c5b5b5f •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-43832 – s390/uv: Don't call folio_wait_writeback() without a folio reference
https://notcve.org/view.php?id=CVE-2024-43832
In the Linux kernel, the following vulnerability has been resolved: s390/uv: Don't call folio_wait_writeback() without a folio reference folio_wait_writeback() requires that no spinlocks are held and that a folio reference is held, as documented. After we dropped the PTL, the folio could get freed concurrently. So grab a temporary reference. • https://git.kernel.org/stable/c/214d9bbcd3a67230b932f6cea83c078ab34d9e70 https://git.kernel.org/stable/c/1a1eb2f3fc453dcd52726d13e863938561489cb7 https://git.kernel.org/stable/c/8736604ef53359a718c246087cd21dcec232d2fb https://git.kernel.org/stable/c/b21aba72aadd94bdac275deab021fc84d6c72b16 https://git.kernel.org/stable/c/3f29f6537f54d74e64bac0a390fb2e26da25800d •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-43831 – media: mediatek: vcodec: Handle invalid decoder vsi
https://notcve.org/view.php?id=CVE-2024-43831
In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Handle invalid decoder vsi Handle an invalid decoder vsi in vpu_dec_init to ensure the decoder vsi is valid for future use. • https://git.kernel.org/stable/c/590577a4e5257ac3ed72999a94666ad6ba8f24bc https://git.kernel.org/stable/c/1c109f23b271a02b9bb195c173fab41e3285a8db https://git.kernel.org/stable/c/cdf05ae76198c513836bde4eb55f099c44773280 https://git.kernel.org/stable/c/59d438f8e02ca641c58d77e1feffa000ff809e9f •
CVSS: 6.6EPSS: 0%CPEs: 8EXPL: 0CVE-2024-43830 – leds: trigger: Unregister sysfs attributes before calling deactivate()
https://notcve.org/view.php?id=CVE-2024-43830
In the Linux kernel, the following vulnerability has been resolved: leds: trigger: Unregister sysfs attributes before calling deactivate() Triggers which have trigger specific sysfs attributes typically store related data in trigger-data allocated by the activate() callback and freed by the deactivate() callback. Calling device_remove_groups() after calling deactivate() leaves a window where the sysfs attributes show/store functions could be called after deactivation and then operate on the just freed trigger-data. Move the device_remove_groups() call to before deactivate() to close this race window. This also makes the deactivation path properly do things in reverse order of the activation path which calls the activate() callback before calling device_add_groups(). • https://git.kernel.org/stable/c/a7e7a3156300a7e1982b03cc9cb8fb0c86434c49 https://git.kernel.org/stable/c/c3b7a650c8717aa89df318364609c86cbc040156 https://git.kernel.org/stable/c/d1415125b701ef13370e2761f691ec632a5eb93a https://git.kernel.org/stable/c/09c1583f0e10c918855d6e7540a79461a353e5d6 https://git.kernel.org/stable/c/3fb6a9d67cfd812a547ac73ec02e1077c26c640d https://git.kernel.org/stable/c/734ba6437e80dfc780e9ee9d95f912392d12b5ea https://git.kernel.org/stable/c/cb8aa9d2a4c8a15d6a43ccf901ef3d094aa60374 https://git.kernel.org/stable/c/0788a6f3523d3686a9eed5ea1e6fcce68 • CWE-416: Use After Free •