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 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-45010 – mptcp: pm: only mark 'subflow' endp as available
https://notcve.org/view.php?id=CVE-2024-45010
In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: only mark 'subflow' endp as available Adding the following warning ... WARN_ON_ONCE(msk->pm.local_addr_used == 0) ... before decrementing the local_addr_used counter helped to find a bug when running the "remove single address" subtest from the mptcp_join.sh selftests. Removing a 'signal' endpoint will trigger the removal of all subflows linked to this endpoint via mptcp_pm_nl_rm_addr_or_subflow() with rm_type == MPTCP_MIB_RMSUBFLOW. This will decrement the local_addr_used counter, which is wrong in this case because this counter is linked to 'subflow' endpoints, and here it is a 'signal' endpoint that is being removed. Now, the counter is decremented, only if the ID is being used outside of mptcp_pm_nl_rm_addr_or_subflow(), only for 'subflow' endpoints, and if the ID is not 0 -- local_addr_used is not taking into account these ones. This marking of the ID as being available, and the decrement is done no matter if a subflow using this ID is currently available, because the subflow could have been closed before. • https://git.kernel.org/stable/c/06faa22710342bca5e9c249634199c650799fce6 https://git.kernel.org/stable/c/7fdc870d08960961408a44c569f20f50940e7d4f https://git.kernel.org/stable/c/43cf912b0b0fc7b4fd12cbc735d1f5afb8e1322d https://git.kernel.org/stable/c/9849cfc67383ceb167155186f8f8fe8a896b60b3 https://git.kernel.org/stable/c/322ea3778965da72862cca2a0c50253aacf65fe6 •
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 •
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 •