CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-40986 – dmaengine: xilinx: xdma: Fix data synchronisation in xdma_channel_isr()
https://notcve.org/view.php?id=CVE-2024-40986
In the Linux kernel, the following vulnerability has been resolved: dmaengine: xilinx: xdma: Fix data synchronisation in xdma_channel_isr() Requests the vchan lock before using xdma->stop_request. • https://git.kernel.org/stable/c/6a40fb8245965b481b4dcce011cd63f20bf91ee0 https://git.kernel.org/stable/c/582ce5d734190d74e5ce9cd711cf6e964e1e7b29 https://git.kernel.org/stable/c/8e1f54e4a3f3207c9dc68bb5000603b75802e7f0 https://git.kernel.org/stable/c/462237d2d93fc9e9221d1cf9f773954d27da83c0 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-40985 – net/tcp_ao: Don't leak ao_info on error-path
https://notcve.org/view.php?id=CVE-2024-40985
In the Linux kernel, the following vulnerability has been resolved: net/tcp_ao: Don't leak ao_info on error-path It seems I introduced it together with TCP_AO_CMDF_AO_REQUIRED, on version 5 [1] of TCP-AO patches. Quite frustrative that having all these selftests that I've written, running kmemtest & kcov was always in todo. [1]: https://lore.kernel.org/netdev/20230215183335.800122-5-dima@arista.com/ • https://git.kernel.org/stable/c/0aadc73995d08f6b0dc061c14a564ffa46f5914e https://git.kernel.org/stable/c/ebaa7d3c26332330a48f9a15f8e518d526cc0f21 https://git.kernel.org/stable/c/f9ae848904289ddb16c7c9e4553ed4c64300de49 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-40984 – ACPICA: Revert "ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine."
https://notcve.org/view.php?id=CVE-2024-40984
In the Linux kernel, the following vulnerability has been resolved: ACPICA: Revert "ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine." Undo the modifications made in commit d410ee5109a1 ("ACPICA: avoid "Info: mapping multiple BARs. Your kernel is fine.""). The initial purpose of this commit was to stop memory mappings for operation regions from overlapping page boundaries, as it can trigger warnings if different page attributes are present. However, it was found that when this situation arises, mapping continues until the boundary's end, but there is still an attempt to read/write the entire length of the map, leading to a NULL pointer deference. • https://git.kernel.org/stable/c/d410ee5109a1633a686a5663c6743a92e1181f9b https://git.kernel.org/stable/c/435ecc978c3d5d0c4e172ec5b956dc1904061d98 https://git.kernel.org/stable/c/ae465109d82f4fb03c5adbe85f2d6a6a3d59124c https://git.kernel.org/stable/c/6eca23100e9030725f69c1babacd58803f29ec8d https://git.kernel.org/stable/c/dc5017c57f5eee80020c73ff8b67ba7f9fd08b1f https://git.kernel.org/stable/c/ddc1f5f124479360a1fd43f73be950781d172239 https://git.kernel.org/stable/c/434c6b924e1f4c219aab2d9e05fe79c5364e37d3 https://git.kernel.org/stable/c/e21a4c9129c72fa54dd00f5ebf71219b4 • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-40983 – tipc: force a dst refcount before doing decryption
https://notcve.org/view.php?id=CVE-2024-40983
In the Linux kernel, the following vulnerability has been resolved: tipc: force a dst refcount before doing decryption As it says in commit 3bc07321ccc2 ("xfrm: Force a dst refcount before entering the xfrm type handlers"): "Crypto requests might return asynchronous. In this case we leave the rcu protected region, so force a refcount on the skb's destination entry before we enter the xfrm type input/output handlers." On TIPC decryption path it has the same problem, and skb_dst_force() should be called before doing decryption to avoid a possible crash. Shuang reported this issue when this warning is triggered: [] WARNING: include/net/dst.h:337 tipc_sk_rcv+0x1055/0x1ea0 [tipc] [] Kdump: loaded Tainted: G W --------- - - 4.18.0-496.el8.x86_64+debug [] Workqueue: crypto cryptd_queue_worker [] RIP: 0010:tipc_sk_rcv+0x1055/0x1ea0 [tipc] [] Call Trace: [] tipc_sk_mcast_rcv+0x548/0xea0 [tipc] [] tipc_rcv+0xcf5/0x1060 [tipc] [] tipc_aead_decrypt_done+0x215/0x2e0 [tipc] [] cryptd_aead_crypt+0xdb/0x190 [] cryptd_queue_worker+0xed/0x190 [] process_one_work+0x93d/0x17e0 • https://git.kernel.org/stable/c/fc1b6d6de2208774efd2a20bf0daddb02d18b1e0 https://git.kernel.org/stable/c/3eb1b39627892c4e26cb0162b75725aa5fcc60c8 https://git.kernel.org/stable/c/692803b39a36e63ac73208e0a3769ae6a2f9bc76 https://git.kernel.org/stable/c/623c90d86a61e3780f682b32928af469c66ec4c2 https://git.kernel.org/stable/c/b57a4a2dc8746cea58a922ebe31b6aa629d69d93 https://git.kernel.org/stable/c/6808b41371670c51feea14f63ade211e78100930 https://git.kernel.org/stable/c/2ebe8f840c7450ecbfca9d18ac92e9ce9155e269 https://access.redhat.com/security/cve/CVE-2024-40983 • CWE-911: Improper Update of Reference Count •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-40982 – ssb: Fix potential NULL pointer dereference in ssb_device_uevent()
https://notcve.org/view.php?id=CVE-2024-40982
In the Linux kernel, the following vulnerability has been resolved: ssb: Fix potential NULL pointer dereference in ssb_device_uevent() The ssb_device_uevent() function first attempts to convert the 'dev' pointer to 'struct ssb_device *'. However, it mistakenly dereferences 'dev' before performing the NULL check, potentially leading to a NULL pointer dereference if 'dev' is NULL. To fix this issue, move the NULL check before dereferencing the 'dev' pointer, ensuring that the pointer is valid before attempting to use it. Found by Linux Verification Center (linuxtesting.org) with SVACE. • https://git.kernel.org/stable/c/c5dc2d8eb3981bae261ea7d1060a80868e886813 https://git.kernel.org/stable/c/7d43c8377c6fc846b1812f8df360425c9323dc56 https://git.kernel.org/stable/c/789c17185fb0f39560496c2beab9b57ce1d0cbe7 •