CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-45018 – netfilter: flowtable: initialise extack before use
https://notcve.org/view.php?id=CVE-2024-45018
In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: initialise extack before use Fix missing initialisation of extack in flow offload. • https://git.kernel.org/stable/c/c29f74e0df7a02b8303bcdce93a7c0132d62577a https://git.kernel.org/stable/c/e5ceff2196dc633c995afb080f6f44a72cff6e1d https://git.kernel.org/stable/c/356beb911b63a8cff34cb57f755c2a2d2ee9dec7 https://git.kernel.org/stable/c/7eafeec6be68ebd6140a830ce9ae68ad5b67ec78 https://git.kernel.org/stable/c/c7b760499f7791352b49b11667ed04b23d7f5b0f https://git.kernel.org/stable/c/119be227bc04f5035efa64cb823b8a5ca5e2d1c1 https://git.kernel.org/stable/c/e9767137308daf906496613fd879808a07f006a2 https://access.redhat.com/security/cve/CVE-2024-45018 • CWE-457: Use of Uninitialized Variable •
CVSS: -EPSS: 0%CPEs: 12EXPL: 0CVE-2024-45016 – netem: fix return value if duplicate enqueue fails
https://notcve.org/view.php?id=CVE-2024-45016
In the Linux kernel, the following vulnerability has been resolved: netem: fix return value if duplicate enqueue fails There is a bug in netem_enqueue() introduced by commit 5845f706388a ("net: netem: fix skb length BUG_ON in __skb_to_sgvec") that can lead to a use-after-free. This commit made netem_enqueue() always return NET_XMIT_SUCCESS when a packet is duplicated, which can cause the parent qdisc's q.qlen to be mistakenly incremented. When this happens qlen_notify() may be skipped on the parent during destruction, leaving a dangling pointer for some classful qdiscs like DRR. There are two ways for the bug happen: - If the duplicated packet is dropped by rootq->enqueue() and then the original packet is also dropped. - If rootq->enqueue() sends the duplicated packet to a different qdisc and the original packet is dropped. In both cases NET_XMIT_SUCCESS is returned even though no packets are enqueued at the netem qdisc. The fix is to defer the enqueue of the duplicate packet until after the original packet has been guaranteed to return NET_XMIT_SUCCESS. • https://git.kernel.org/stable/c/5845f706388a4cde0f6b80f9e5d33527e942b7d9 https://git.kernel.org/stable/c/a550a01b8af856f2684b0f79d552f5119eb5006c https://git.kernel.org/stable/c/009510a90e230bb495f3fe25c7db956679263b07 https://git.kernel.org/stable/c/4de7d30668cb8b06330992e1cd336f91700a2ce7 https://git.kernel.org/stable/c/d1dd2e15c85e890a1cc9bde5ba07ae63331e5c73 https://git.kernel.org/stable/c/0148fe458b5705e2fea7cb88294fed7e36066ca2 https://git.kernel.org/stable/c/759e3e8c4a6a6b4e52ebc4547123a457f0ce90d4 https://git.kernel.org/stable/c/c414000da1c2ea1ba9a5e5bb1a4ba774e •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-45015 – drm/msm/dpu: move dpu_encoder's connector assignment to atomic_enable()
https://notcve.org/view.php?id=CVE-2024-45015
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dpu: move dpu_encoder's connector assignment to atomic_enable() For cases where the crtc's connectors_changed was set without enable/active getting toggled , there is an atomic_enable() call followed by an atomic_disable() but without an atomic_mode_set(). This results in a NULL ptr access for the dpu_encoder_get_drm_fmt() call in the atomic_enable() as the dpu_encoder's connector was cleared in the atomic_disable() but not re-assigned as there was no atomic_mode_set() call. Fix the NULL ptr access by moving the assignment for atomic_enable() and also use drm_atomic_get_new_connector_for_encoder() to get the connector from the atomic_state. Patchwork: https://patchwork.freedesktop.org/patch/606729/ • https://git.kernel.org/stable/c/25fdd5933e4c0f5fe2ea5cd59994f8ac5fbe90ef https://git.kernel.org/stable/c/3fb61718bcbe309279205d1cc275a6435611dc77 https://git.kernel.org/stable/c/3bacf814b6a61cc683c68465f175ebd938f09c52 https://git.kernel.org/stable/c/aedf02e46eb549dac8db4821a6b9f0c6bf6e3990 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-45012 – nouveau/firmware: use dma non-coherent allocator
https://notcve.org/view.php?id=CVE-2024-45012
In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: use dma non-coherent allocator Currently, enabling SG_DEBUG in the kernel will cause nouveau to hit a BUG() on startup, when the iommu is enabled: kernel BUG at include/linux/scatterlist.h:187! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 7 PID: 930 Comm: (udev-worker) Not tainted 6.9.0-rc3Lyude-Test+ #30 Hardware name: MSI MS-7A39/A320M GAMING PRO (MS-7A39), BIOS 1.I0 01/22/2019 RIP: 0010:sg_init_one+0x85/0xa0 Code: 69 88 32 01 83 e1 03 f6 c3 03 75 20 a8 01 75 1e 48 09 cb 41 89 54 24 08 49 89 1c 24 41 89 6c 24 0c 5b 5d 41 5c e9 7b b9 88 00 <0f> 0b 0f 0b 0f 0b 48 8b 05 5e 46 9a 01 eb b2 66 66 2e 0f 1f 84 00 RSP: 0018:ffffa776017bf6a0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa77600d87000 RCX: 000000000000002b RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffffa77680d87000 RBP: 000000000000e000 R08: 0000000000000000 R09: 0000000000000000 R10: ffff98f4c46aa508 R11: 0000000000000000 R12: ffff98f4c46aa508 R13: ffff98f4c46aa008 R14: ffffa77600d4a000 R15: ffffa77600d4a018 FS: 00007feeb5aae980(0000) GS:ffff98f5c4dc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f22cb9a4520 CR3: 00000001043ba000 CR4: 00000000003506f0 Call Trace: <TASK> ? die+0x36/0x90 ? do_trap+0xdd/0x100 ? sg_init_one+0x85/0xa0 ? • https://git.kernel.org/stable/c/2541626cfb794e57ba0575a6920826f591f7ced0 https://git.kernel.org/stable/c/cc29c5546c6a373648363ac49781f1d74b530707 https://git.kernel.org/stable/c/57ca481fca97ca4553e8c85d6a94baf4cb40c40e https://git.kernel.org/stable/c/9b340aeb26d50e9a9ec99599e2a39b035fac978e •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-45011 – char: xillybus: Check USB endpoints when probing device
https://notcve.org/view.php?id=CVE-2024-45011
In the Linux kernel, the following vulnerability has been resolved: char: xillybus: Check USB endpoints when probing device Ensure, as the driver probes the device, that all endpoints that the driver may attempt to access exist and are of the correct type. All XillyUSB devices must have a Bulk IN and Bulk OUT endpoint at address 1. This is verified in xillyusb_setup_base_eps(). On top of that, a XillyUSB device may have additional Bulk OUT endpoints. The information about these endpoints' addresses is deduced from a data structure (the IDT) that the driver fetches from the device while probing it. These endpoints are checked in setup_channels(). A XillyUSB device never has more than one IN endpoint, as all data towards the host is multiplexed in this single Bulk IN endpoint. This is why setup_channels() only checks OUT endpoints. • https://git.kernel.org/stable/c/a53d1202aef122894b6e46116a92174a9123db5d https://git.kernel.org/stable/c/25ee8b2908200fc862c0434e5ad483817d50ceda https://git.kernel.org/stable/c/4267131278f5cc98f8db31d035d64bdbbfe18658 https://git.kernel.org/stable/c/5cff754692ad45d5086b75fef8cc3a99c30a1005 https://git.kernel.org/stable/c/1371d32b95972d39c1e6e4bae8b6d0df1b573731 https://git.kernel.org/stable/c/2374bf7558de915edc6ec8cb10ec3291dfab9594 •