CVSS: -EPSS: %CPEs: 5EXPL: 0CVE-2024-46839 – workqueue: Improve scalability of workqueue watchdog touch
https://notcve.org/view.php?id=CVE-2024-46839
In the Linux kernel, the following vulnerability has been resolved: workqueue: Improve scalability of workqueue watchdog touch On a ~2000 CPU powerpc system, hard lockups have been observed in the workqueue code when stop_machine runs (in this case due to CPU hotplug). This is due to lots of CPUs spinning in multi_cpu_stop, calling touch_nmi_watchdog() which ends up calling wq_watchdog_touch(). wq_watchdog_touch() writes to the global variable wq_watchdog_touched, and that can find itself in the same cacheline as other important workqueue data, which slows down operations to the point of lockups. In the case of the following abridged trace, worker_pool_idr was in the hot line, causing the lockups to always appear at idr_find. watchdog: CPU 1125 self-detected hard LOCKUP @ idr_find Call Trace: get_work_pool __queue_work call_timer_fn run_timer_softirq __do_softirq do_softirq_own_stack irq_exit timer_interrupt decrementer_common_virt * interrupt: 900 (timer) at multi_cpu_stop multi_cpu_stop cpu_stopper_thread smpboot_thread_fn kthread Fix this by having wq_watchdog_touch() only write to the line if the last time a touch was recorded exceeds 1/4 of the watchdog threshold. • https://git.kernel.org/stable/c/9d08fce64dd77f42e2361a4818dbc4b50f3c7dad https://git.kernel.org/stable/c/a2abd35e7dc55bf9ed01e2b3481fa78e086d3bf4 https://git.kernel.org/stable/c/241bce1c757d0587721512296952e6bba69631ed https://git.kernel.org/stable/c/da5f374103a1e0881bbd35847dc57b04ac155eb0 https://git.kernel.org/stable/c/98f887f820c993e05a12e8aa816c80b8661d4c87 •
CVSS: -EPSS: %CPEs: 3EXPL: 0CVE-2024-46838 – userfaultfd: don't BUG_ON() if khugepaged yanks our page table
https://notcve.org/view.php?id=CVE-2024-46838
In the Linux kernel, the following vulnerability has been resolved: userfaultfd: don't BUG_ON() if khugepaged yanks our page table Since khugepaged was changed to allow retracting page tables in file mappings without holding the mmap lock, these BUG_ON()s are wrong - get rid of them. We could also remove the preceding "if (unlikely(...))" block, but then we could reach pte_offset_map_lock() with transhuge pages not just for file mappings but also for anonymous mappings - which would probably be fine but I think is not necessarily expected. • https://git.kernel.org/stable/c/1d65b771bc08cd054cf6d3766a72e113dc46d62f https://git.kernel.org/stable/c/4a594acc12d5954cdc71d4450a386748bf3d136a https://git.kernel.org/stable/c/db978287e908d48b209e374b00d847b2d785e0a9 https://git.kernel.org/stable/c/4828d207dc5161dc7ddf9a4f6dcfd80c7dd7d20a •
CVSS: -EPSS: %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: %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: %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 •