CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-46840 – btrfs: clean up our handling of refs == 0 in snapshot delete
https://notcve.org/view.php?id=CVE-2024-46840
In the Linux kernel, the following vulnerability has been resolved: btrfs: clean up our handling of refs == 0 in snapshot delete In reada we BUG_ON(refs == 0), which could be unkind since we aren't holding a lock on the extent leaf and thus could get a transient incorrect answer. In walk_down_proc we also BUG_ON(refs == 0), which could happen if we have extent tree corruption. Change that to return -EUCLEAN. In do_walk_down() we catch this case and handle it correctly, however we return -EIO, which -EUCLEAN is a more appropriate error code. Finally in walk_up_proc we have the same BUG_ON(refs == 0), so convert that to proper error handling. Also adjust the error message so we can actually do something with the information. • https://git.kernel.org/stable/c/c847b28a799733b04574060ab9d00f215970627d https://git.kernel.org/stable/c/71291aa7246645ef622621934d2067400380645e https://git.kernel.org/stable/c/c60676b81fab456b672796830f6d8057058f029c https://git.kernel.org/stable/c/728d4d045b628e006b48a448f3326a7194c88d32 https://git.kernel.org/stable/c/9cc887ac24b7a0598f4042ae9af6b9a33072f75b https://git.kernel.org/stable/c/7d1df13bf078ffebfedd361d714ff6cee1ff01b9 https://git.kernel.org/stable/c/03804641ec2d0da4fa088ad21c88e703d151ce16 https://git.kernel.org/stable/c/b8ccef048354074a548f108e51d0557d6 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-46836 – usb: gadget: aspeed_udc: validate endpoint index for ast udc
https://notcve.org/view.php?id=CVE-2024-46836
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: aspeed_udc: validate endpoint index for ast udc We should verify the bound of the array to assure that host may not manipulate the index to point past endpoint array. Found by static analysis. • https://git.kernel.org/stable/c/31bd4fab49c0adc6228848357c1b1df9395858af https://git.kernel.org/stable/c/b2a50ffdd1a079869a62198a8d1441355c513c7c https://git.kernel.org/stable/c/6fe9ca2ca389114c8da66e534c18273497843e8a https://git.kernel.org/stable/c/ee0d382feb44ec0f445e2ad63786cd7f3f6a8199 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-46835 – drm/amdgpu: Fix smatch static checker warning
https://notcve.org/view.php?id=CVE-2024-46835
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix smatch static checker warning adev->gfx.imu.funcs could be NULL • https://git.kernel.org/stable/c/d40c2c3dd0395fe7fdc19bd96551e87251426d66 https://git.kernel.org/stable/c/8bc7b3ce33e64c74211ed17aec823fc4e523426a https://git.kernel.org/stable/c/c2056c7a840f0dbf293bc3b0d91826d001668fb0 https://git.kernel.org/stable/c/bdbdc7cecd00305dc844a361f9883d3a21022027 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-46834 – ethtool: fail closed if we can't get max channel used in indirection tables
https://notcve.org/view.php?id=CVE-2024-46834
In the Linux kernel, the following vulnerability has been resolved: ethtool: fail closed if we can't get max channel used in indirection tables Commit 0d1b7d6c9274 ("bnxt: fix crashes when reducing ring count with active RSS contexts") proves that allowing indirection table to contain channels with out of bounds IDs may lead to crashes. Currently the max channel check in the core gets skipped if driver can't fetch the indirection table or when we can't allocate memory. Both of those conditions should be extremely rare but if they do happen we should try to be safe and fail the channel change. • https://git.kernel.org/stable/c/101737d8b88dbd4be6010bac398fe810f1950036 https://git.kernel.org/stable/c/2899d58462ba868287d6ff3acad3675e7adf934f •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-46833 – net: hns3: void array out of bound when loop tnl_num
https://notcve.org/view.php?id=CVE-2024-46833
In the Linux kernel, the following vulnerability has been resolved: net: hns3: void array out of bound when loop tnl_num When query reg inf of SSU, it loops tnl_num times. However, tnl_num comes from hardware and the length of array is a fixed value. To void array out of bound, make sure the loop time is not greater than the length of array • https://git.kernel.org/stable/c/c33a9806dc806bcb4a31dc71fb06979219181ad4 https://git.kernel.org/stable/c/86db7bfb06704ef17340eeae71c832f21cfce35c •