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: 3EXPL: 0CVE-2024-50304 – ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find()
https://notcve.org/view.php?id=CVE-2024-50304
In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find() The per-netns IP tunnel hash table is protected by the RTNL mutex and ip_tunnel_find() is only called from the control path where the mutex is taken. Add a lockdep expression to hlist_for_each_entry_rcu() in ip_tunnel_find() in order to validate that the mutex is held and to silence the suspicious RCU usage warning [1]. [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted ----------------------------- net/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/362: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: <TASK> dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 ip_tunnel_find+0x435/0x4d0 ip_tunnel_newlink+0x517/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f • https://git.kernel.org/stable/c/c54419321455631079c7d6e60bc732dd0c5914c5 https://git.kernel.org/stable/c/27c1c98bd3b44b7c5f5c0ecfe1a1ec1240b73829 https://git.kernel.org/stable/c/f20fe2cfe06ca1b008b09da4f2b4e0c5547ccef6 https://git.kernel.org/stable/c/90e0569dd3d32f4f4d2ca691d3fa5a8a14a13c12 •
CVSS: -EPSS: 0%CPEs: 10EXPL: 0CVE-2024-50302 – HID: core: zero-initialize the report buffer
https://notcve.org/view.php?id=CVE-2024-50302
In the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report. • https://git.kernel.org/stable/c/27ce405039bfe6d3f4143415c638f56a3df77dca https://git.kernel.org/stable/c/b2b6cadad699d44a8a5b2a60f3d960e00d6fb3b7 https://git.kernel.org/stable/c/fe6c9b48ebc920ff21c10c50ab2729440c734254 https://git.kernel.org/stable/c/e7ea60184e1e88a3c9e437b3265cbb6439aa7e26 https://git.kernel.org/stable/c/3f9e88f2672c4635960570ee9741778d4135ecf5 https://git.kernel.org/stable/c/d7dc68d82ab3fcfc3f65322465da3d7031d4ab46 https://git.kernel.org/stable/c/05ade5d4337867929e7ef664e7ac8e0c734f1aaf https://git.kernel.org/stable/c/1884ab3d22536a5c14b17c78c2ce76d17 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50299 – sctp: properly validate chunk size in sctp_sf_ootb()
https://notcve.org/view.php?id=CVE-2024-50299
In the Linux kernel, the following vulnerability has been resolved: sctp: properly validate chunk size in sctp_sf_ootb() A size validation fix similar to that in Commit 50619dbf8db7 ("sctp: add size validation when walking chunks") is also required in sctp_sf_ootb() to address a crash reported by syzbot: BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166 sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159 ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233 • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/67b9a278b80f71ec62091ded97c6bcbea33b5ec3 https://git.kernel.org/stable/c/9b5d42aeaf1a52f73b003a33da6deef7df34685f https://git.kernel.org/stable/c/40b283ba76665437bc2ac72079c51b57b25bff9e https://git.kernel.org/stable/c/a758aa6a773bb872196bcc3173171ef8996bddf0 https://git.kernel.org/stable/c/bf9bff13225baf5f658577f7d985fc4933d79527 https://git.kernel.org/stable/c/d3fb3cc83cf313e4f87063ce0f3fea76b071567b https://git.kernel.org/stable/c/8820d2d6589f62ee5514793fff9b50c9f •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50290 – media: cx24116: prevent overflows on SNR calculus
https://notcve.org/view.php?id=CVE-2024-50290
In the Linux kernel, the following vulnerability has been resolved: media: cx24116: prevent overflows on SNR calculus as reported by Coverity, if reading SNR registers fail, a negative number will be returned, causing an underflow when reading SNR registers. Prevent that. • https://git.kernel.org/stable/c/8953db793d5bdeea5ac92c9e97f57d3ff8a7dccf https://git.kernel.org/stable/c/127b9076baeadd734b18ddc8f2cd93b47d5a3ea3 https://git.kernel.org/stable/c/cad97ca8cfd43a78a19b59949f33e3563d369247 https://git.kernel.org/stable/c/828047c70f4716fde4b1316f7b610e97a4e83824 https://git.kernel.org/stable/c/f2b4f277c41db8d548f38f1dd091bbdf6a5acb07 https://git.kernel.org/stable/c/fbefe31e4598cdb0889eee2e74c995b2212efb08 https://git.kernel.org/stable/c/83c152b55d88cbf6fc4685941fcb31333986774d https://git.kernel.org/stable/c/3a1ed994d9454132354b860321414955d •