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: 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 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52915 – media: dvb-usb-v2: af9035: Fix null-ptr-deref in af9035_i2c_master_xfer
https://notcve.org/view.php?id=CVE-2023-52915
In the Linux kernel, the following vulnerability has been resolved: media: dvb-usb-v2: af9035: Fix null-ptr-deref in af9035_i2c_master_xfer In af9035_i2c_master_xfer, msg is controlled by user. When msg[i].buf is null and msg[i].len is zero, former checks on msg[i].buf would be passed. Malicious data finally reach af9035_i2c_master_xfer. If accessing msg[i].buf[0] without sanity check, null ptr deref would happen. We add check on msg[i].len to prevent crash. Similar commit: commit 0ed554fd769a ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()") • https://git.kernel.org/stable/c/b2f54ed7739dfdf42c4df0a11131aad7c8635464 https://git.kernel.org/stable/c/fa58d9db5cad4bb7bb694b6837e3b96d87554f2b https://git.kernel.org/stable/c/b49c6e5dd236787f13a062ec528d724169f11152 https://git.kernel.org/stable/c/6c01ef65de0b321b2db1ef9abf8f1d15862b937e https://git.kernel.org/stable/c/d9ef84a7c222497ecb5fdf93361c76931804825e https://git.kernel.org/stable/c/0143f282b15f7cedc0392ea10050fb6000fd16e6 https://git.kernel.org/stable/c/41b7181a40af84448a2b144fb02d8bf32b7e9a23 https://git.kernel.org/stable/c/7bf744f2de0a848fb1d717f5831b03db9 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-45008 – Input: MT - limit max slots
https://notcve.org/view.php?id=CVE-2024-45008
In the Linux kernel, the following vulnerability has been resolved: Input: MT - limit max slots syzbot is reporting too large allocation at input_mt_init_slots(), for num_slots is supplied from userspace using ioctl(UI_DEV_CREATE). Since nobody knows possible max slots, this patch chose 1024. • https://git.kernel.org/stable/c/2829c80614890624456337e47320289112785f3e https://git.kernel.org/stable/c/87f610a1a7fbdb1f2e3d90b54c955bd3b8a0c322 https://git.kernel.org/stable/c/05dd9aabd04f9b5eb04dab9bb83d8c3e982d7549 https://git.kernel.org/stable/c/95f73d01f547dfc67fda3022c51e377a0454b505 https://git.kernel.org/stable/c/94736334b8a25e4fae8daa6934e54a31f099be43 https://git.kernel.org/stable/c/8f04edd554d191834e9e1349ef030318ea6b11ba https://git.kernel.org/stable/c/cd19f1799c32ba7b874474b1b968815ce5364f73 https://git.kernel.org/stable/c/99d3bf5f7377d42f8be60a6b9cb60fb0b •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-45007 – char: xillybus: Don't destroy workqueue from work item running on it
https://notcve.org/view.php?id=CVE-2024-45007
In the Linux kernel, the following vulnerability has been resolved: char: xillybus: Don't destroy workqueue from work item running on it Triggered by a kref decrement, destroy_workqueue() may be called from within a work item for destroying its own workqueue. This illegal situation is averted by adding a module-global workqueue for exclusive use of the offending work item. Other work items continue to be queued on per-device workqueues to ensure performance. • https://git.kernel.org/stable/c/409b495f8e3300d5fba08bc817fa8825dae48cc9 https://git.kernel.org/stable/c/5d3567caff2a1d678aa40cc74a54e1318941fad3 https://git.kernel.org/stable/c/a7ad105b12256ec7fb6d6d1a0e2e60f00b7da157 https://git.kernel.org/stable/c/aa1a19724fa2c31e97a9be48baedd4692b265157 https://git.kernel.org/stable/c/ccbde4b128ef9c73d14d0d7817d68ef795f6d131 •