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 •
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-45009 – mptcp: pm: only decrement add_addr_accepted for MPJ req
https://notcve.org/view.php?id=CVE-2024-45009
In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: only decrement add_addr_accepted for MPJ req Adding the following warning ... WARN_ON_ONCE(msk->pm.add_addr_accepted == 0) ... before decrementing the add_addr_accepted counter helped to find a bug when running the "remove single subflow" subtest from the mptcp_join.sh selftest. Removing a 'subflow' endpoint will first trigger a RM_ADDR, then the subflow closure. Before this patch, and upon the reception of the RM_ADDR, the other peer will then try to decrement this add_addr_accepted. That's not correct because the attached subflows have not been created upon the reception of an ADD_ADDR. A way to solve that is to decrement the counter only if the attached subflow was an MP_JOIN to a remote id that was not 0, and initiated by the host receiving the RM_ADDR. • https://git.kernel.org/stable/c/d0876b2284cf8b34dd214b2d0aa21071c345da59 https://git.kernel.org/stable/c/35b31f5549ede4070566b949781e83495906b43d https://git.kernel.org/stable/c/85b866e4c4e63a1d7afb58f1e24273caad03d0b7 https://git.kernel.org/stable/c/d20bf2c96d7ffd171299b32f562f70e5bf5dc608 https://git.kernel.org/stable/c/2060f1efab370b496c4903b840844ecaff324c3c https://git.kernel.org/stable/c/1c1f721375989579e46741f59523e39ec9b2a9bd •
CVSS: -EPSS: 0%CPEs: 1EXPL: 0CVE-2023-52916 – media: aspeed: Fix memory overwrite if timing is 1600x900
https://notcve.org/view.php?id=CVE-2023-52916
In the Linux kernel, the following vulnerability has been resolved: media: aspeed: Fix memory overwrite if timing is 1600x900 When capturing 1600x900, system could crash when system memory usage is tight. The way to reproduce this issue: 1. Use 1600x900 to display on host 2. Mount ISO through 'Virtual media' on OpenBMC's web 3. Run script as below on host to do sha continuously #!/bin/bash while [ [1] ]; do find /media -type f -printf '"%h/%f"\n' | xargs sha256sum done 4. • https://git.kernel.org/stable/c/c281355068bc258fd619c5aefd978595bede7bfe •