Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix ACKALL packet handling<br /> <br /> rxrpc_input_ackall() accepts ACKALL packets without checking whether the<br /> call is in a state that can legitimately have outstanding transmit buffers.<br /> A forged ACKALL can therefore reach a new service call in<br /> RXRPC_CALL_SERVER_RECV_REQUEST before any reply packets have been queued.<br /> <br /> In that state call-&gt;tx_top is zero and call-&gt;tx_queue is NULL, so<br /> rxrpc_rotate_tx_window() dereferences a NULL txqueue and triggers a<br /> null-pointer dereference.<br /> <br /> Fix the handling of ACKALL packets by the following means:<br /> <br /> (1) Add two new call states: RXRPC_CALL_CLIENT_PRE_SEND which indicates<br /> that the client call is connected, but nothing has been transmitted as<br /> yet; and RXRPC_CALL_CLIENT_AWAIT_ACK, which indicates that everything<br /> has been transmitted at least once, but we&amp;#39;re now waiting for the<br /> stuff remaining in the Tx buffer to be ACK&amp;#39;d (retransmissions may<br /> still happen).<br /> <br /> The RXRPC_CALL_CLIENT_PRE_SEND state is set when the call is assigned<br /> a channel and transitions to RXRPC_CALL_CLIENT_SEND_REQUEST when the<br /> first packet is transmitted.<br /> <br /> RXRPC_CALL_CLIENT_AWAIT_REPLY is then narrowed in scope to indicate<br /> that all Tx packets have been ACK&amp;#39;d and we&amp;#39;re now waiting for the<br /> reply to be received.<br /> <br /> (2) As per Wyatt Feng&amp;#39;s original patch[1], the ACKALL handler then checks<br /> that the call state is one in which there might be stuff in the Tx<br /> buffer to ACK, but now this includes AWAIT_ACK rather than<br /> AWAIT_REPLY. ACKALL packets are ignored if received in the wrong<br /> state.<br /> <br /> Note that unlike Wyatt Feng&amp;#39;s patch, it&amp;#39;s no longer necessary to check<br /> to see if the Tx buffer exists as this the state set now covers this.<br /> <br /> (3) Make the ACKALL handler use call-&gt;tx_transmitted rather than<br /> call-&gt;tx_top as the former is explicitly the highest packet seq number<br /> transmitted, whereas the latter has a looser definition.<br /> <br /> Thanks to Jeffrey Altman for a description of the history of the ACKALL<br /> packet[1].

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix potential infinite loop in rxrpc_recvmsg()<br /> <br /> Fix the wait in rxrpc_recvmsg() also take check the oob queue.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix leak of released call in recvmsg(MSG_PEEK)<br /> <br /> Fix rxrpc_recvmsg() to also drop the ref it holds on an already-released<br /> call if MSG_PEEK is in force (the function holds a ref on the call<br /> irrespective of whether MSG_PEEK is specified or not).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix UAF in rxgk_issue_challenge()<br /> <br /> Fix rxgk_issue_challenge() to free the page containing the challenge<br /> content after invoking the tracepoint as the whdr passed to the tracepoint<br /> points into the page just freed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Don&amp;#39;t move a peeked OOB message onto the pending queue<br /> <br /> rxrpc_recvmsg_oob() takes a received oob message off recvmsg_oobq and,<br /> if a response is needed, moves it onto the pending_oobq tree. However,<br /> only the unlink from recvmsg_oobq is guarded by MSG_PEEK; the move onto<br /> pending_oobq always runs.<br /> <br /> As a result, reading a challenge with MSG_PEEK leaves the skb on<br /> recvmsg_oobq while also adding it to pending_oobq. Since struct<br /> sk_buff&amp;#39;s rbnode shares storage with its next and prev pointers,<br /> rb_insert_color() overwrites the list linkage, and the skb, which holds<br /> a single reference, becomes reachable from both queues at once.<br /> <br /> When the socket is closed both queues are drained in turn. While<br /> draining recvmsg_oobq, __skb_unlink() follows the next and prev<br /> pointers that rbnode has overwritten and writes to a bad address. Also,<br /> as the skb holds a single reference but is freed from each queue, both<br /> the skb and the connection reference it holds are released twice. This<br /> leads to memory corruption and to a use-after-free caused by the<br /> connection refcount underflow.<br /> <br /> MSG_PEEK does not consume the message from the queue, so only unlink it<br /> from recvmsg_oobq and then move it onto pending_oobq or free it when<br /> the message is actually consumed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: rxrpc_verify_data ensure rx_dec_buffer alloc<br /> <br /> rxrpc_recvmsg_data() calls rxrpc_verify_data() whenever the<br /> rxrpc_call.rx_dec_buffer is unallocated and assumes that upon<br /> successful return that rx_dec_buffer must be allocated.<br /> However, rxrpc_verify_data() does not request an allocation if<br /> the rxrpc_skb_priv.len is zero.<br /> <br /> In addition, failure to allocate rx_dec_buffer will result in a<br /> call to skb_copy_bits() with a NULL destination which can<br /> trigger a NULL pointer dereference.<br /> <br /> To prevent these issues rxrpc_verify_data() is modified to<br /> always attempt to allocate the rxrpc_call.rx_dec_buffer if it<br /> is NULL.<br /> <br /> This issue was identified with assistance of a private<br /> sashiko instance.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: serialize kernel accept preallocation with socket teardown<br /> <br /> rxrpc_kernel_charge_accept() reads rx-&gt;backlog without any<br /> socket/backlog synchronization and passes that raw pointer into<br /> rxrpc_service_prealloc_one(). A concurrent rxrpc_discard_prealloc()<br /> sets rx-&gt;backlog = NULL and frees the backlog rings, so a kernel<br /> preallocation worker can keep using a freed struct rxrpc_backlog<br /> while updating *_backlog_head/tail and array slots.<br /> <br /> Serialize the state check and backlog lookup with the socket lock,<br /> and reject kernel preallocation once teardown has disabled<br /> listening or discarded the service backlog.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: uvcvideo: Fix deadlock if uvc_status_stop is called from async_ctrl.work<br /> <br /> If a UVC camera has an asynchronous control, uvc_status_stop may be<br /> called from async_ctrl.work:<br /> <br /> uvc_ctrl_status_event_work()<br /> uvc_ctrl_status_event()<br /> uvc_ctrl_clear_handle()<br /> uvc_pm_put()<br /> uvc_status_put()<br /> uvc_status_stop()<br /> cancel_work_sync()<br /> <br /> This will cause a deadlock, since cancel_work_sync will wait for<br /> uvc_ctrl_status_event_work to complete before returning.<br /> <br /> Fix this by returning early from uvc_status_stop if we are currently in<br /> the work function. flush_status now remains false until uvc_status_start<br /> is called again, ensuring that uvc_ctrl_status_event_work won&amp;#39;t resubmit<br /> the URB.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: sun4i-ss - Remove insecure and unused rng_alg<br /> <br /> Remove sun4i_ss_rng, as it is insecure and unused:<br /> <br /> - It has multiple vulnerabilities. sun4i_ss_prng_seed() is missing<br /> locking and has a buffer overflow. sun4i_ss_prng_generate() fails to<br /> fill the entire buffer with cryptographic random bytes, because it<br /> rounds the destination length down and also doesn&amp;#39;t actually wait for<br /> the hardware to be ready before pulling bytes from it.<br /> <br /> - No user of this code is known. It&amp;#39;s usable only theoretically via the<br /> "rng" algorithm type of AF_ALG. But userspace actually just uses the<br /> actual Linux RNG (/dev/random etc) instead. And rng_algs don&amp;#39;t<br /> contribute entropy to the actual Linux RNG either. (This may have<br /> been confused with hwrng, which does contribute entropy.)<br /> <br /> The sun4i_ss_prng_seed() buffer overflow was reported by Tianchu Chen<br /> and discovered by Atuin - Automated Vulnerability Discovery Engine<br /> <br /> There&amp;#39;s no point in fixing all these vulnerabilities individually when<br /> this is unused code, so let&amp;#39;s just remove it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/gpusvm: Reject VMAs with VM_IO or VM_PFNMAP when creating SVM ranges<br /> <br /> VMAs marked with VM_IO or VM_PFNMAP are not backed by struct page<br /> objects, which GPUSVM requires in order to operate correctly. In<br /> particular, get_pages() relies on hmm_range_fault() to resolve struct<br /> pages for the target range.<br /> <br /> Attempting to create an SVM range on such VMAs results in repeated<br /> get_pages() failures and can lead to an infinite loop inside a driver’s<br /> page‑fault handler. Prevent this by rejecting ranges on VM_IO or<br /> VM_PFNMAP VMAs and returning -EIO.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/rockchip: dw_dp: Switch to drmm_kzalloc()<br /> <br /> Driver makes use of drmm_encoder_init() to initialize the encoder and<br /> automatically handle the cleanup by registering drm_encoder_cleanup()<br /> with drmm_add_action().<br /> <br /> However, the internal structure containing the encoder part gets<br /> allocated with devm_kzalloc(), which happens while component_bind_all()<br /> is being called from Rockchip DRM driver. The component framework<br /> further ensures it is deallocated as part of releasing all the resources<br /> claimed during bind, which is triggered from component_unbind_all().<br /> <br /> When the reference to the DRM device gets eventually dropped via<br /> drm_dev_put() in rockchip_drm_unbind(), drmm_encoder_alloc_release()<br /> attempts to access the now released encoder structure, leading to<br /> use-after-free.<br /> <br /> Ensure driver&amp;#39;s internal structure is still reachable on encoder cleanup<br /> by switching from a device-managed allocation to a drm-managed one.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/rockchip: inno-hdmi: Switch to drmm_kzalloc()<br /> <br /> Driver makes use of drmm_encoder_init() to initialize the encoder and<br /> automatically handle the cleanup by registering drm_encoder_cleanup()<br /> with drmm_add_action().<br /> <br /> However, the internal structure containing the encoder part gets<br /> allocated with devm_kzalloc(), which happens while component_bind_all()<br /> is being called from Rockchip DRM driver. The component framework<br /> further ensures it is deallocated as part of releasing all the resources<br /> claimed during bind, which is triggered from component_unbind_all().<br /> <br /> When the reference to the DRM device gets eventually dropped via<br /> drm_dev_put() in rockchip_drm_unbind(), drmm_encoder_alloc_release()<br /> attempts to access the now released encoder structure, leading to<br /> use-after-free.<br /> <br /> Ensure driver&amp;#39;s internal structure is still reachable on encoder cleanup<br /> by switching from a device-managed allocation to a drm-managed one.