CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-53051 – drm/i915/hdcp: Add encoder check in intel_hdcp_get_capability
https://notcve.org/view.php?id=CVE-2024-53051
In the Linux kernel, the following vulnerability has been resolved: drm/i915/hdcp: Add encoder check in intel_hdcp_get_capability Sometimes during hotplug scenario or suspend/resume scenario encoder is not always initialized when intel_hdcp_get_capability add a check to avoid kernel null pointer dereference. • https://git.kernel.org/stable/c/4912e8fb3c37fb2dedf48d9c18bbbecd70e720f8 https://git.kernel.org/stable/c/31b42af516afa1e184d1a9f9dd4096c54044269a •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-53050 – drm/i915/hdcp: Add encoder check in hdcp2_get_capability
https://notcve.org/view.php?id=CVE-2024-53050
In the Linux kernel, the following vulnerability has been resolved: drm/i915/hdcp: Add encoder check in hdcp2_get_capability Add encoder check in intel_hdcp2_get_capability to avoid null pointer error. • https://git.kernel.org/stable/c/5b89dcf23575eb5bb95ce8d672cbc2232c2eb096 https://git.kernel.org/stable/c/d34f4f058edf1235c103ca9c921dc54820d14d40 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-53049 – slub/kunit: fix a WARNING due to unwrapped __kmalloc_cache_noprof
https://notcve.org/view.php?id=CVE-2024-53049
In the Linux kernel, the following vulnerability has been resolved: slub/kunit: fix a WARNING due to unwrapped __kmalloc_cache_noprof 'modprobe slub_kunit' will have a warning as shown below. The root cause is that __kmalloc_cache_noprof was directly used, which resulted in no alloc_tag being allocated. This caused current->alloc_tag to be null, leading to a warning in alloc_tag_add_check. Let's add an alloc_hook layer to __kmalloc_cache_noprof specifically within lib/slub_kunit.c, which is the only user of this internal slub function outside kmalloc implementation itself. [58162.947016] WARNING: CPU: 2 PID: 6210 at ./include/linux/alloc_tag.h:125 alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.957721] Call trace: [58162.957919] alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.958286] __kmalloc_cache_noprof+0x14c/0x344 [58162.958615] test_kmalloc_redzone_access+0x50/0x10c [slub_kunit] [58162.959045] kunit_try_run_case+0x74/0x184 [kunit] [58162.959401] kunit_generic_run_threadfn_adapter+0x2c/0x4c [kunit] [58162.959841] kthread+0x10c/0x118 [58162.960093] ret_from_fork+0x10/0x20 [58162.960363] ---[ end trace 0000000000000000 ]--- • https://git.kernel.org/stable/c/a0a44d9175b349df2462089140fb7f292100bd7c https://git.kernel.org/stable/c/79aea7dfd98fbbf282d1408fc21849fc9a677768 https://git.kernel.org/stable/c/2b059d0d1e624adc6e69a754bc48057f8bf459dc •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-53048 – ice: fix crash on probe for DPLL enabled E810 LOM
https://notcve.org/view.php?id=CVE-2024-53048
In the Linux kernel, the following vulnerability has been resolved: ice: fix crash on probe for DPLL enabled E810 LOM The E810 Lan On Motherboard (LOM) design is vendor specific. Intel provides the reference design, but it is up to vendor on the final product design. For some cases, like Linux DPLL support, the static values defined in the driver does not reflect the actual LOM design. Current implementation of dpll pins is causing the crash on probe of the ice driver for such DPLL enabled E810 LOM designs: WARNING: (...) at drivers/dpll/dpll_core.c:495 dpll_pin_get+0x2c4/0x330 ... Call Trace: <TASK> ? __warn+0x83/0x130 ? dpll_pin_get+0x2c4/0x330 ? • https://git.kernel.org/stable/c/d7999f5ea64bb10d2857b8cbfe973be373bac7c9 https://git.kernel.org/stable/c/82b107a27bab29146e159b6b9f21146c97c45a53 https://git.kernel.org/stable/c/6e58c33106220c6c0c8fbee9ab63eae76ad8f260 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-53047 – mptcp: init: protect sched with rcu_read_lock
https://notcve.org/view.php?id=CVE-2024-53047
In the Linux kernel, the following vulnerability has been resolved: mptcp: init: protect sched with rcu_read_lock Enabling CONFIG_PROVE_RCU_LIST with its dependence CONFIG_RCU_EXPERT creates this splat when an MPTCP socket is created: ============================= WARNING: suspicious RCU usage 6.12.0-rc2+ #11 Not tainted ----------------------------- net/mptcp/sched.c:44 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 no locks held by mptcp_connect/176. stack backtrace: CPU: 0 UID: 0 PID: 176 Comm: mptcp_connect Not tainted 6.12.0-rc2+ #11 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) mptcp_sched_find (net/mptcp/sched.c:44 (discriminator 7)) mptcp_init_sock (net/mptcp/protocol.c:2867 (discriminator 1)) ? sock_init_data_uid (arch/x86/include/asm/atomic.h:28) inet_create.part.0.constprop.0 (net/ipv4/af_inet.c:386) ? __sock_create (include/linux/rcupdate.h:347 (discriminator 1)) __sock_create (net/socket.c:1576) __sys_socket (net/socket.c:1671) ? __pfx___sys_socket (net/socket.c:1712) ? • https://git.kernel.org/stable/c/1730b2b2c5a5a886007b247366aebe0976dc8881 https://git.kernel.org/stable/c/cb8b81ad3e893a6d18dcdd3754cc2ea2a42c0136 https://git.kernel.org/stable/c/494eb22f9a7bd03783e60595a57611c209175f1a https://git.kernel.org/stable/c/3deb12c788c385e17142ce6ec50f769852fcec65 •