Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: bla: put backbone reference on failed claim hash insert<br /> <br /> When batadv_bla_add_claim() fails to insert a new claim into the hash, it<br /> leaked a reference to the backbone_gw for which the claim was intended.<br /> Call batadv_backbone_gw_put() on the error path to release the reference<br /> and avoid leaking the backbone_gw object.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: bla: only purge non-released claims<br /> <br /> When batadv_bla_purge_claims() goes through the list of claims, it is only<br /> traversing the hash list with an rcu_read_lock(). Due to a potential<br /> parallel batadv_claim_put(), it can happen that it encounters a claim which<br /> was actually in the process of being released+freed by<br /> batadv_claim_release(). In this case, backbone_gw is set to NULL before the<br /> delayed RCU kfree is started. Calling batadv_bla_claim_get_backbone_gw() is<br /> then no longer allowed because it would cause a NULL-ptr derefence.<br /> <br /> To avoid this, only claims with a valid reference counter must be purged.<br /> All others are already taken care of.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL<br /> <br /> The SCTP_SENDALL path in sctp_sendmsg() iterates ep-&gt;asocs with<br /> list_for_each_entry_safe(), which caches the next entry in @tmp before<br /> the loop body runs. The body calls sctp_sendmsg_to_asoc(), which may<br /> drop the socket lock inside sctp_wait_for_sndbuf().<br /> <br /> While the lock is dropped, another thread can SCTP_SOCKOPT_PEELOFF the<br /> association cached in @tmp, migrating it to a new endpoint via<br /> sctp_sock_migrate() (list_del_init() + list_add_tail() to<br /> newep-&gt;asocs), and optionally close the new socket which frees the<br /> association via kfree_rcu(). The cached @tmp can also be freed by a<br /> network ABORT for that association, processed in softirq while the<br /> lock is dropped.<br /> <br /> sctp_wait_for_sndbuf() revalidates @asoc (the current entry) on re-lock<br /> via the "sk != asoc-&gt;base.sk" and "asoc-&gt;base.dead" checks, but nothing<br /> revalidates @tmp. After a successful return, the iterator advances to<br /> the stale @tmp, yielding either a use-after-free (if the peeled socket<br /> was closed) or a list-walk onto the new endpoint&amp;#39;s list head (type<br /> confusion of &amp;newep-&gt;asocs as a struct sctp_association *).<br /> <br /> Both are reachable from CapEff=0; the type-confusion path gives<br /> controlled indirect call via the outqueue.sched-&gt;init_sid pointer.<br /> <br /> Fix by re-deriving @tmp from @asoc after sctp_sendmsg_to_asoc()<br /> returns. @asoc is known to still be on ep-&gt;asocs at that point: the<br /> only callers that list_del an association from ep-&gt;asocs are<br /> sctp_association_free() (which sets asoc-&gt;base.dead) and<br /> sctp_assoc_migrate() (which changes asoc-&gt;base.sk), and<br /> sctp_wait_for_sndbuf() checks both under the lock before any<br /> successful return; a tripped check propagates as err

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/vcn3: Prevent OOB reads when parsing dec msg<br /> <br /> Check bounds against the end of the BO whenever we access the msg.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: playstation: Clamp num_touch_reports<br /> <br /> A device would never lie about the number of touch reports would it?<br /> <br /> If it does the loop in dualshock4_parse_report will read off the end of<br /> the touch_reports array, up to about 2 KiB for the maximum number of 256<br /> loop iteraions. The data that is read is emitted via evdev if the<br /> DS4_TOUCH_POINT_INACTIVE bit happens to be set. Protect against this by<br /> clamping the num_touch_reports value provided by the device to the<br /> maximum size of the touch_reports array.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock/virtio: fix accept queue count leak on transport mismatch<br /> <br /> virtio_transport_recv_listen() calls sk_acceptq_added() before<br /> vsock_assign_transport(). If vsock_assign_transport() fails or<br /> selects a different transport, the error path returns without<br /> calling sk_acceptq_removed(), permanently incrementing<br /> sk_ack_backlog.<br /> <br /> After approximately backlog+1 such failures, sk_acceptq_is_full()<br /> returns true, causing the listener to reject all new connections.<br /> <br /> Fix by moving sk_acceptq_added() to after the transport validation,<br /> matching the pattern used by vmci_transport and hyperv_transport.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/hdcp: Add NULL check for media_gt in intel_hdcp_gsc_check_status()<br /> <br /> When media GT is disabled via configfs, there is no allocation for<br /> media_gt, which is kept as NULL. In such scenario,<br /> intel_hdcp_gsc_check_status() results in a kernel pagefault error due to<br /> &amp;gt-&gt;uc.gsc being evaluated as an invalid memory address.<br /> <br /> Fix that by introducing a NULL check on media_gt and bailing out early<br /> if so.<br /> <br /> While at it, also drop the NULL check for gsc, since it can&amp;#39;t be NULL if<br /> media_gt is not NULL.<br /> <br /> v2:<br /> - Get address for gsc only after checking that gt is not NULL.<br /> (Shuicheng)<br /> - Drop the NULL check for gsc. (Shuicheng)<br /> v3:<br /> - Add "Fixes" and "Cc: " tags. (Matt)<br /> <br /> (cherry picked from commit bfaf87e84ca3ca3f6e275f9ae56da47a8b55ffd1)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/vcn4: Avoid overflow on msg bound check<br /> <br /> As pointed out by SDL, the previous condition may be vulnerable to<br /> overflow.<br /> <br /> (cherry picked from commit 3c5367d950140d4ec7af830b2268a5a6fdaa3885)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: mpc52xx: fix use-after-free on unbind<br /> <br /> The state machine work is scheduled by the interrupt handler and<br /> therefore needs to be cancelled after disabling interrupts to avoid a<br /> potential use-after-free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/sdma4: replace BUG_ON with WARN_ON in fence emission<br /> <br /> sdma_v4_0_ring_emit_fence() contains two BUG_ON(addr &amp; 0x3) assertions<br /> that verify fence writeback addresses are dword-aligned. These<br /> assertions can be reached from unprivileged userspace via crafted<br /> DRM_IOCTL_AMDGPU_CS submissions, causing a fatal kernel panic in a<br /> scheduler worker thread.<br /> <br /> Replace both BUG_ON() calls with WARN_ON() to log the condition without<br /> crashing the kernel. A misaligned fence address at this point indicates<br /> a driver bug, but crashing the kernel is never the correct response when<br /> the assertion is reachable from userspace.<br /> <br /> The CS IOCTL path is the correct place to filter invalid submissions;<br /> the ring emission callback is too late to do anything about it.<br /> <br /> (cherry picked from commit b90250bd933afd1ba94d86d6b13821997b22b18e)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> EDAC/versalnet: Fix device name memory leak<br /> <br /> The device name allocated via kzalloc() in init_one_mc() is assigned to<br /> dev-&gt;init_name but never freed on the normal removal path. device_register()<br /> copies init_name and then sets dev-&gt;init_name to NULL, so the name pointer<br /> becomes unreachable from the device. Thus leaking memory.<br /> <br /> Use a stack-local char array instead of using kzalloc() for name.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: rockchip: rkcif: Add missing MUST_CONNECT flag to pads<br /> <br /> The pads missed checks for connected devices which may a null dereference<br /> when the stream is enabled.<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address<br /> 0000000000000020<br /> pc : rkcif_interface_enable_streams+0x48/0xf0<br /> lr : rkcif_interface_enable_streams+0x44/0xf0<br /> Call trace:<br /> rkcif_interface_enable_streams+0x48/0xf0<br /> v4l2_subdev_enable_streams+0x26c/0x3f0<br /> rkcif_stream_start_streaming+0x140/0x278<br /> vb2_start_streaming+0x74/0x188<br /> vb2_core_streamon+0xe0/0x1d8<br /> vb2_ioctl_streamon+0x60/0xa8<br /> v4l_streamon+0x2c/0x40<br /> __video_do_ioctl+0x34c/0x400<br /> video_usercopy+0x2d0/0x800<br /> video_ioctl2+0x20/0x60<br /> v4l2_ioctl+0x48/0x78