CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-45021 – memcg_write_event_control(): fix a user-triggerable oops
https://notcve.org/view.php?id=CVE-2024-45021
In the Linux kernel, the following vulnerability has been resolved: memcg_write_event_control(): fix a user-triggerable oops we are *not* guaranteed that anything past the terminating NUL is mapped (let alone initialized with anything sane). • https://git.kernel.org/stable/c/0dea116876eefc9c7ca9c5d74fe665481e499fa3 https://git.kernel.org/stable/c/fa5bfdf6cb5846a00e712d630a43e3cf55ccb411 https://git.kernel.org/stable/c/1b37ec85ad95b612307627758c6018cd9d92cca8 https://git.kernel.org/stable/c/ad149f5585345e383baa65f1539d816cd715fd3b https://git.kernel.org/stable/c/0fbe2a72e853a1052abe9bc2b7df8ddb102da227 https://git.kernel.org/stable/c/43768fa80fd192558737e24ed6548f74554611d7 https://git.kernel.org/stable/c/f1aa7c509aa766080db7ab3aec2e31b1df09e57c https://git.kernel.org/stable/c/21b578f1d599edb87462f11113c5b0fc7 •
CVSS: -EPSS: 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 •
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: 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 •