CVSS: -EPSS: 0%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: 0%CPEs: 2EXPL: 0CVE-2024-46837 – drm/panthor: Restrict high priorities on group_create
https://notcve.org/view.php?id=CVE-2024-46837
In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Restrict high priorities on group_create We were allowing any users to create a high priority group without any permission checks. As a result, this was allowing possible denial of service. We now only allow the DRM master or users with the CAP_SYS_NICE capability to set higher priorities than PANTHOR_GROUP_PRIORITY_MEDIUM. As the sole user of that uAPI lives in Mesa and hardcode a value of MEDIUM [1], this should be safe to do. Additionally, as those checks are performed at the ioctl level, panthor_group_create now only check for priority level validity. [1]https://gitlab.freedesktop.org/mesa/mesa/-/blob/f390835074bdf162a63deb0311d1a6de527f9f89/src/gallium/drivers/panfrost/pan_csf.c#L1038 • https://git.kernel.org/stable/c/de85488138247d034eb3241840424a54d660926b https://git.kernel.org/stable/c/33eb0344e186a2bcc257c6c5a6e65c1cb42adb4a https://git.kernel.org/stable/c/5f7762042f8a5377bd8a32844db353c0311a7369 •
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 •