CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-53090 – afs: Fix lock recursion
https://notcve.org/view.php?id=CVE-2024-53090
In the Linux kernel, the following vulnerability has been resolved: afs: Fix lock recursion afs_wake_up_async_call() can incur lock recursion. The problem is that it is called from AF_RXRPC whilst holding the ->notify_lock, but it tries to take a ref on the afs_call struct in order to pass it to a work queue - but if the afs_call is already queued, we then have an extraneous ref that must be put... calling afs_put_call() may call back down into AF_RXRPC through rxrpc_kernel_shutdown_call(), however, which might try taking the ->notify_lock again. This case isn't very common, however, so defer it to a workqueue. The oops looks something like: BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646 lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0 CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: <TASK> dump_stack_lvl+0x47/0x70 do_raw_spin_lock+0x3c/0x90 rxrpc_kernel_shutdown_call+0x83/0xb0 afs_put_call+0xd7/0x180 rxrpc_notify_socket+0xa0/0x190 rxrpc_input_split_jumbo+0x198/0x1d0 rxrpc_input_data+0x14b/0x1e0 ? rxrpc_input_call_packet+0xc2/0x1f0 rxrpc_input_call_event+0xad/0x6b0 rxrpc_input_packet_on_conn+0x1e1/0x210 rxrpc_input_packet+0x3f2/0x4d0 rxrpc_io_thread+0x243/0x410 ? __pfx_rxrpc_io_thread+0x10/0x10 kthread+0xcf/0xe0 ? • https://git.kernel.org/stable/c/d7cbf81df996b1eae2dee8deb6df08e2eba78661 https://git.kernel.org/stable/c/610a79ffea02102899a1373fe226d949944a7ed6 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-53063 – media: dvbdev: prevent the risk of out of memory access
https://notcve.org/view.php?id=CVE-2024-53063
In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: prevent the risk of out of memory access The dvbdev contains a static variable used to store dvb minors. The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is set or not. When not set, dvb_register_device() won't check for boundaries, as it will rely that a previous call to dvb_register_adapter() would already be enforcing it. On a similar way, dvb_device_open() uses the assumption that the register functions already did the needed checks. This can be fragile if some device ends using different calls. This also generate warnings on static check analysers like Coverity. So, add explicit guards to prevent potential risk of OOM issues. • https://git.kernel.org/stable/c/5dd3f3071070f5a306bdf8d474c80062f5691cba https://git.kernel.org/stable/c/fedfde9deb83ac8d2f3d5f36f111023df34b1684 https://git.kernel.org/stable/c/3b88675e18b6517043a6f734eaa8ea6eb3bfa140 https://git.kernel.org/stable/c/a4a17210c03ade1c8d9a9f193a105654b7a05c11 https://git.kernel.org/stable/c/5f76f7df14861e3a560898fa41979ec92424b58f https://git.kernel.org/stable/c/b751a96025275c17f04083cbfe856822f1658946 https://git.kernel.org/stable/c/1e461672616b726f29261ee81bb991528818537c https://git.kernel.org/stable/c/9c17085fabbde2041c893d29599800f2d •
CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0CVE-2024-53057 – net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT
https://notcve.org/view.php?id=CVE-2024-53057
In the Linux kernel, the following vulnerability has been resolved: net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT In qdisc_tree_reduce_backlog, Qdiscs with major handle ffff: are assumed to be either root or ingress. This assumption is bogus since it's valid to create egress qdiscs with major handle ffff: Budimir Markovic found that for qdiscs like DRR that maintain an active class list, it will cause a UAF with a dangling class pointer. In 066a3b5b2346, the concern was to avoid iterating over the ingress qdisc since its parent is itself. The proper fix is to stop when parent TC_H_ROOT is reached because the only way to retrieve ingress is when a hierarchy which does not contain a ffff: major handle call into qdisc_lookup with TC_H_MAJ(TC_H_ROOT). In the scenario where major ffff: is an egress qdisc in any of the tree levels, the updates will also propagate to TC_H_ROOT, which then the iteration must stop. net/sched/sch_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) • https://git.kernel.org/stable/c/066a3b5b2346febf9a655b444567b7138e3bb939 https://git.kernel.org/stable/c/e7f9a6f97eb067599a74f3bcb6761976b0ed303e https://git.kernel.org/stable/c/dbe778b08b5101df9e89bc06e0a3a7ecd2f4ef20 https://git.kernel.org/stable/c/ce691c814bc7a3c30c220ffb5b7422715458fd9b https://git.kernel.org/stable/c/05df1b1dff8f197f1c275b57ccb2ca33021df552 https://git.kernel.org/stable/c/580b3189c1972aff0f993837567d36392e9d981b https://git.kernel.org/stable/c/597cf9748c3477bf61bc35f0634129f56764ad24 https://git.kernel.org/stable/c/9995909615c3431a5304c1210face5f26 • CWE-416: Use After Free •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-53052 – io_uring/rw: fix missing NOWAIT check for O_DIRECT start write
https://notcve.org/view.php?id=CVE-2024-53052
In the Linux kernel, the following vulnerability has been resolved: io_uring/rw: fix missing NOWAIT check for O_DIRECT start write When io_uring starts a write, it'll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn't set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress. Since freezing requires CAP_SYS_ADMIN in the first place, this isn't something that can be triggered by a regular user. • https://git.kernel.org/stable/c/485d9232112b17f389b29497ff41b97b3189546b https://git.kernel.org/stable/c/4e24041ba86d50aaa4c792ae2c88ed01b3d96243 https://git.kernel.org/stable/c/9e8debb8e51354b201db494689198078ec2c1e75 https://git.kernel.org/stable/c/003d2996964c03dfd34860500428f4cdf1f5879e https://git.kernel.org/stable/c/26b8c48f369b7591f5679e0b90612f4862a32929 https://git.kernel.org/stable/c/1d60d74e852647255bd8e76f5a22dc42531e4389 •
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 •