CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-41095 – drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes
https://notcve.org/view.php?id=CVE-2024-41095
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes In nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. • https://git.kernel.org/stable/c/9289cd3450d1da3e271ef4b054d4d2932c41243e https://git.kernel.org/stable/c/dbd75f32252508ed6c46c3288a282c301a57ceeb https://git.kernel.org/stable/c/259549b2ccf795b7f91f7b5aba47286addcfa389 https://git.kernel.org/stable/c/0d17604f2e44b3df21e218fe8fb3b836d41bac49 https://git.kernel.org/stable/c/f95ed0f54b3d3faecae1140ddab854f904a6e7c8 https://git.kernel.org/stable/c/cb751e48bbcffd292090f7882b23b215111b3d72 https://git.kernel.org/stable/c/bdda5072494f2a7215d94fc4124ad1949a218714 https://git.kernel.org/stable/c/66edf3fb331b6c55439b10f9862987b09 •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-41093 – drm/amdgpu: avoid using null object of framebuffer
https://notcve.org/view.php?id=CVE-2024-41093
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: avoid using null object of framebuffer Instead of using state->fb->obj[0] directly, get object from framebuffer by calling drm_gem_fb_get_obj() and return error code when object is null to avoid using null object of framebuffer. • https://git.kernel.org/stable/c/7f35e01cb0ea4d295f5c067bb5c67dfcddaf05bc https://git.kernel.org/stable/c/6ce0544cabaa608018d5922ab404dc656a9d8447 https://git.kernel.org/stable/c/330c8c1453848c04d335bad81371a66710210800 https://git.kernel.org/stable/c/dd9ec0ea4cdde0fc48116e63969fc83e81d7ef46 https://git.kernel.org/stable/c/bcfa48ff785bd121316592b131ff6531e3e696bb https://access.redhat.com/security/cve/CVE-2024-41093 https://bugzilla.redhat.com/show_bug.cgi?id=2300488 • CWE-476: NULL Pointer Dereference •
CVSS: 6.7EPSS: 0%CPEs: 6EXPL: 0CVE-2024-41092 – drm/i915/gt: Fix potential UAF by revoke of fence registers
https://notcve.org/view.php?id=CVE-2024-41092
In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Fix potential UAF by revoke of fence registers CI has been sporadically reporting the following issue triggered by igt@i915_selftest@live@hangcheck on ADL-P and similar machines: <6> [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence ... <6> [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled <6> [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled <3> [414.070354] Unable to pin Y-tiled fence; err:-4 <3> [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(&fence->active)) ... <4>[ 609.603992] ------------[ cut here ]------------ <2>[ 609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301! <4>[ 609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI <4>[ 609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G U W 6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1 <4>[ 609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 <4>[ 609.604010] Workqueue: i915 __i915_gem_free_work [i915] <4>[ 609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915] ... <4>[ 609.604271] Call Trace: <4>[ 609.604273] <TASK> ... <4>[ 609.604716] __i915_vma_evict+0x2e9/0x550 [i915] <4>[ 609.604852] __i915_vma_unbind+0x7c/0x160 [i915] <4>[ 609.604977] force_unbind+0x24/0xa0 [i915] <4>[ 609.605098] i915_vma_destroy+0x2f/0xa0 [i915] <4>[ 609.605210] __i915_gem_object_pages_fini+0x51/0x2f0 [i915] <4>[ 609.605330] __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915] <4>[ 609.605440] process_scheduled_works+0x351/0x690 ... In the past, there were similar failures reported by CI from other IGT tests, observed on other platforms. Before commit 63baf4f3d587 ("drm/i915/gt: Only wait for GPU activity before unbinding a GGTT fence"), i915_vma_revoke_fence() was waiting for idleness of vma->active via fence_update(). That commit introduced vma->fence->active in order for the fence_update() to be able to wait selectively on that one instead of vma->active since only idleness of fence registers was needed. But then, another commit 0d86ee35097a ("drm/i915/gt: Make fence revocation unequivocal") replaced the call to fence_update() in i915_vma_revoke_fence() with only fence_write(), and also added that GEM_BUG_ON(! • https://git.kernel.org/stable/c/0d86ee35097ae0f1c2c50f2b8035ef480e25e4f1 https://git.kernel.org/stable/c/f771b91f21c46ad1217328d05e72a2c7e3add535 https://git.kernel.org/stable/c/29c0fdf49078ab161570d3d1c6e13d66f182717d https://git.kernel.org/stable/c/ca0fabd365a27a94a36e68a7a02df8ff3c13dac6 https://git.kernel.org/stable/c/06dec31a0a5112a91f49085e8a8fa1a82296d5c7 https://git.kernel.org/stable/c/414f4a31f7a811008fd9a33b06216b060bad18fc https://git.kernel.org/stable/c/996c3412a06578e9d779a16b9e79ace18125ab50 https://access.redhat.com/security/cve/CVE-2024-41092 • CWE-416: Use After Free •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-41089 – drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes
https://notcve.org/view.php?id=CVE-2024-41089
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). The same applies to drm_cvt_mode(). Add a check to avoid null pointer dereference. • https://git.kernel.org/stable/c/ffabad4aa91e33ced3c6ae793fb37771b3e9cb51 https://git.kernel.org/stable/c/1c9f2e60150b4f13789064370e37f39e6e060f50 https://git.kernel.org/stable/c/56fc4d3b0bdef691831cd95715a7ca3ebea98b2d https://git.kernel.org/stable/c/5eecb49a6c268dc229005bf6e8167d4001dc09a0 https://git.kernel.org/stable/c/30cbf6ffafbbdd8a6e4e5f0a2e9a9827ee83f3ad https://git.kernel.org/stable/c/7ece609b0ce7a7ea8acdf512a77d1fee26621637 https://git.kernel.org/stable/c/6e49a157d541e7e97b815a56f4bdfcbc89844a59 https://git.kernel.org/stable/c/6d411c8ccc0137a612e0044489030a194 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-41088 – can: mcp251xfd: fix infinite loop when xmit fails
https://notcve.org/view.php?id=CVE-2024-41088
In the Linux kernel, the following vulnerability has been resolved: can: mcp251xfd: fix infinite loop when xmit fails When the mcp251xfd_start_xmit() function fails, the driver stops processing messages, and the interrupt routine does not return, running indefinitely even after killing the running application. Error messages: [ 441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16 [ 441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3). ... and repeat forever. The issue can be triggered when multiple devices share the same SPI interface. And there is concurrent access to the bus. The problem occurs because tx_ring->head increments even if mcp251xfd_start_xmit() fails. Consequently, the driver skips one TX package while still expecting a response in mcp251xfd_handle_tefif_one(). Resolve the issue by starting a workqueue to write the tx obj synchronously if err = -EBUSY. In case of another error, decrement tx_ring->head, remove skb from the echo stack, and drop the message. [mkl: use more imperative wording in patch description] • https://git.kernel.org/stable/c/55e5b97f003e85e66babb55f357627d52081a264 https://git.kernel.org/stable/c/f926c022ebaabf7963bebf89a97201d66978a025 https://git.kernel.org/stable/c/3e72558c1711d524e3150103739ddd06650e291b https://git.kernel.org/stable/c/6c6b4afa59c2fb4d1759235f866d8caed2aa4729 https://git.kernel.org/stable/c/d8fb63e46c884c898a38f061c2330f7729e75510 •