Vulnerabilities

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.

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

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).

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.

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.

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.

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().

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: chemical: mhz19b: reject oversized serial replies<br /> <br /> mhz19b_receive_buf() appends each serdev chunk into the fixed<br /> MHZ19B_CMD_SIZE receive buffer and advances buf_idx by len without<br /> checking that the chunk fits in the remaining space. A large callback<br /> can therefore overflow st-&gt;buf before the command path validates the<br /> reply.<br /> <br /> Reset the reply state before each command and reject oversized serial<br /> replies before copying them into the fixed buffer. When an oversized<br /> reply is detected, wake the waiter and report -EMSGSIZE instead of<br /> overwriting st-&gt;buf.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: gyro: adis16260: fix division by zero in write_raw<br /> <br /> Add a validation check for the sampling frequency value before using it<br /> as a divisor. A user writing zero to the sampling_frequency sysfs<br /> attribute triggers a division by zero in the kernel.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: gyro: itg3200: fix i2c read into the wrong stack location<br /> <br /> itg3200_read_all_channels() takes `__be16 *buf&amp;#39; as a parameter and<br /> fills the i2c_msg destination as `(char *)&amp;buf&amp;#39;. Since `buf&amp;#39; is the<br /> parameter (a pointer), `&amp;buf&amp;#39; is the address of the local pointer<br /> slot on the stack of itg3200_read_all_channels(), not the address<br /> of the caller&amp;#39;s scan buffer. The (char *) cast hides the type<br /> mismatch.<br /> <br /> i2c_transfer() therefore writes ITG3200_SCAN_ELEMENTS * sizeof(s16)<br /> = 8 bytes into the parameter&amp;#39;s stack slot, which is discarded when<br /> the function returns. The caller&amp;#39;s scan buffer in<br /> itg3200_trigger_handler() is never written to, so<br /> iio_push_to_buffers_with_timestamp() pushes uninitialised stack<br /> contents to userspace via /dev/iio:deviceX every scan -- both a<br /> functional bug (no actual gyroscope or temperature data is<br /> delivered through the triggered buffer) and an information leak.<br /> <br /> The non-buffered read_raw() path is unaffected: it goes through<br /> itg3200_read_reg_s16() which uses `&amp;out&amp;#39; on a local s16 value,<br /> where that is correct.<br /> <br /> Drop the spurious `&amp;&amp;#39; so the i2c read writes into the caller&amp;#39;s<br /> buffer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: nxp-sar-adc: fix division by zero in write_raw<br /> <br /> Add a validation check for the sampling frequency value before using it<br /> as a divisor. A user writing zero or a negative value to the<br /> sampling_frequency sysfs attribute triggers a division by zero in the<br /> kernel.<br /> <br /> Also prevent unsigned integer underflow when the computed cycle count is<br /> smaller than NXP_SAR_ADC_CONV_TIME, which would wrap the u32 inpsamp to<br /> a huge value.