Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SEV: Compute the correct max length of the in-GHCB scratch area<br /> <br /> When setting the length of the GHCB scratch area, and the area is in the<br /> GHCB shared buffer, set the effective length of the scratch area to the max<br /> possible size given the start of the guest-provided pointer, and the end of<br /> the shared buffer.<br /> <br /> The code was "fine" when first introduced, as KVM doesn&amp;#39;t consult the<br /> length of the buffer when emulating MMIO, because the passed in @len always<br /> specifies the *max* size required. But for PSC requests, the incoming @len<br /> is just the minimum length (to process the header), and KVM needs to know<br /> the full size of the scratch area to avoid buffer overflows (spoiler alert).<br /> <br /> Opportunistically rename @len =&gt; @min_len to better reflect its role.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SEV: Ignore Port I/O requests of length &amp;#39;0&amp;#39;<br /> <br /> Explicitly ignore Port I/O requests of length &amp;#39;0&amp;#39; (or count &amp;#39;0&amp;#39;), so that<br /> setting up the software scratch area (and other code) doesn&amp;#39;t have to<br /> worry about underflowing the length, and to allow for WARNing on trying<br /> to configure the scratch area with len==0.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Correctly cap ZCR_EL2 provided by a guest hypervisor<br /> <br /> ZCR_EL2 can be updated by a VHE guest hypervisor either using ZCR_EL2<br /> (which traps) or ZCR_EL1 (which does not trap). KVM handles both in<br /> different way:<br /> <br /> - on ZCR_EL2 trap, ZCR_EL2.LEN is immediately capped at the VM&amp;#39;s own<br /> VL limit. This has the potential to break existing SW that relies<br /> on the full LEN field to be stateful.<br /> <br /> - on ZCR_EL1 access, we do absolutely nothing.<br /> <br /> On restoring the SVE context for an L2 guest, we directly restore the<br /> guest hypervisor&amp;#39;s view of ZCR_EL2 into the physical ZCR_EL2. If the<br /> guest&amp;#39;s view of the register was updated using the ZCR_EL2 accessor,<br /> the value has already been sanitised (with the caveat mentioned above).<br /> <br /> But if the guest used ZCR_EL1, the raw value is written into the HW,<br /> and the L2 guest can now access VLs that it shouldn&amp;#39;t.<br /> <br /> Fix all the above by moving the VL capping to the restore points,<br /> ensuring that:<br /> <br /> - the HW is always programmed with a capped value, irrespective of<br /> the accessor being used,<br /> <br /> - the ZCR_EL2.LEN field is always completely stateful, irrespective<br /> of the accessor being used.<br /> <br /> Additionally, move ZCR_EL2 to be a sanitised register, ensuring that<br /> only the LEN field is actually stateful. This requires some creative<br /> construction of the RES0 mask, as the sysreg generation script does<br /> not yet generate RAZ/WI fields.<br /> <br /> [maz: rewrote commit message, tidy up access_zcr_el2()]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> parport: Fix race between port and client registration<br /> <br /> The parport subsystem registers port devices before they are fully<br /> initialised, resulting in a race condition where client drivers such<br /> as lp can attach to ports that are not completely initialised or even<br /> being torn down.<br /> <br /> When the port and client drivers are built as modules and loaded<br /> around the same time during boot, this occasionally results in a<br /> crash. I was able to make this happen reliably in a VM with a<br /> PC-style parallel port by patching parport_pc to fail probing:<br /> <br /> &gt; --- a/drivers/parport/parport_pc.c<br /> &gt; +++ b/drivers/parport/parport_pc.c<br /> &gt; @@ -2069,7 +2069,7 @@ static struct parport *__parport_pc_probe_port(unsigned long int base,<br /> &gt; if (!p)<br /> &gt; goto out3;<br /> &gt;<br /> &gt; - base_res = request_region(base, 3, p-&gt;name);<br /> &gt; + base_res = NULL;<br /> &gt; if (!base_res)<br /> &gt; goto out4;<br /> &gt;<br /> <br /> and then running:<br /> <br /> while true; do<br /> modprobe lp &amp; modprobe parport_pc<br /> wait<br /> rmmod lp parport_pc<br /> done<br /> <br /> for a few seconds.<br /> <br /> In the long term I think port registration should be changed to put<br /> the call to device_add() inside parport_announce_port(), but since the<br /> latter currently cannot fail this will require changing all port<br /> drivers.<br /> <br /> For now, add a flag to indicate whether a port has been "announced"<br /> and only try to attach client drivers to ports when the flag is set.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_sync: fix UAF in hci_le_create_cis_sync<br /> <br /> hci_le_create_cis_sync() dereferences conn-&gt;conn_timeout after releasing<br /> both rcu_read_lock() and hci_dev_lock(hdev). The conn pointer was<br /> obtained from an RCU-protected iteration over hdev-&gt;conn_hash.list and<br /> is not valid once these locks are dropped. A concurrent disconnect can<br /> free the hci_conn between the unlock and the dereference, causing a<br /> use-after-free read.<br /> <br /> The cancellation mechanism in hci_conn_del() cannot prevent this because<br /> hci_le_create_cis_pending() queues hci_create_cis_sync with data=NULL:<br /> <br /> hci_cmd_sync_queue(hdev, hci_create_cis_sync, NULL, NULL);<br /> <br /> While hci_conn_del() dequeues with data=conn:<br /> <br /> hci_cmd_sync_dequeue(hdev, NULL, conn, NULL);<br /> <br /> Since NULL != conn, the lookup in _hci_cmd_sync_lookup_entry() never<br /> matches, and the pending work item is not cancelled.<br /> <br /> Fix this by saving conn-&gt;conn_timeout into a local variable while the<br /> locks are still held, so the stale conn pointer is never dereferenced<br /> after unlock.<br /> <br /> This is the same class of bug as the one fixed by commit 035c25007c9e<br /> ("Bluetooth: hci_sync: Fix UAF on le_read_features_complete") which<br /> addressed the identical pattern in a different function.<br /> <br /> This vulnerability was identified using 0sec.ai, an open-source<br /> automated security auditing platform (https://github.com/0sec-labs).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: mt6359: fix unchecked return value in mt6358_read_imp<br /> <br /> In mt6358_read_imp(), the variable val_v is passed to regmap_read()<br /> but the return value is not checked. If the read fails, val_v remains<br /> uninitialized and its random stack content is subsequently reported<br /> as a measurement result.<br /> <br /> Initialize val_v to zero to ensure a predictable value is reported<br /> in case of bus failure and to prevent potential stack data leakage.<br /> This also satisfies static analyzers that might otherwise flag the<br /> variable as used uninitialized.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: xpad - fix out-of-bounds access for Share button<br /> <br /> xpadone_process_packet() receives len directly from urb-&gt;actual_length<br /> and uses it to index the share-button byte at data[len - 18] or<br /> data[len - 26]. Since both len and data[0] are under the device&amp;#39;s<br /> control, a broken controller can send a GIP_CMD_INPUT packet with<br /> actual_length

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc2: Fix use after free in debug code<br /> <br /> We&amp;#39;re not allowed to dereference "urb" after calling<br /> usb_hcd_giveback_urb() so save the urb-&gt;status ahead of time.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: buffer: hw-consumer: fix use-after-free in error path<br /> <br /> In the err_put_buffers cleanup path of iio_hw_consumer_alloc(), the code<br /> was using list_for_each_entry() to iterate through buffers while calling<br /> iio_buffer_put() which can free the current buffer if refcount drops to 0.<br /> The list_for_each_entry() loop macro then evaluates buf-&gt;head.next to<br /> continue iteration, accessing the freed buffer.<br /> <br /> Fix this by using list_for_each_entry_safe().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: serial: omninet: fix memory corruption with small endpoint<br /> <br /> Make sure that the bulk-out buffers are at least as large as the<br /> hardcoded transfer size to avoid user-controlled slab corruption should<br /> a malicious device report a smaller endpoint max packet size than<br /> expected.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: buffer: Fix DMA fence leak in iio_buffer_enqueue_dmabuf()<br /> <br /> iio_buffer_enqueue_dmabuf() allocates a struct iio_dma_fence (104 bytes,<br /> kmalloc-128) via kmalloc_obj()+dma_fence_init(), which sets the initial<br /> kref to 1. It then calls dma_resv_add_fence() which takes a second<br /> reference (kref=2), and stores a raw pointer in block-&gt;fence.<br /> <br /> On the success path the function returns without calling dma_fence_put()<br /> to release the initial reference, so every buffer enqueue permanently<br /> leaks one kmalloc-128 allocation.<br /> <br /> The iio_buffer_cleanup() work item only releases the temporary reference<br /> taken during completion signalling by iio_buffer_signal_dmabuf_done();<br /> the initial reference from dma_fence_init() is never released.<br /> <br /> With four iio_rwdev instances at 240kHz and 512 samples per buffer,<br /> this produces ~1875 kmalloc-128 allocations per second matching the<br /> observed slab growth exactly. A test with ftrace confirmed that the<br /> dma_fence_destroy event was never triggered.<br /> <br /> Fix by calling dma_fence_put() after dma_resv_add_fence(), transferring<br /> ownership of the fence to the DMA reservation object. The DMA fence then<br /> gets properly discarded after being signalled.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: chemical: scd30: fix division by zero in write_raw<br /> <br /> Add a zero check for val2 before using it as a divisor when setting the<br /> sampling frequency. A user writing a zero fractional part to the<br /> sampling_frequency sysfs attribute triggers a division by zero in the<br /> kernel.