Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bfs: handle set_blocksize failures<br /> <br /> bfs uses buffer_heads, which don&amp;#39;t handle block size &gt; PAGE_SIZE well.<br /> Without this, mounting will hit the<br /> <br /> BUG_ON(offset &gt;= folio_size(folio));<br /> <br /> in folio_set_bh on the first __bread_gfp call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> affs: handle set_blocksize failures<br /> <br /> affs uses buffer_heads, which don&amp;#39;t handle block size &gt; PAGE_SIZE well.<br /> Without this, mounting we will hit the<br /> <br /> BUG_ON(offset &gt;= folio_size(folio));<br /> <br /> in folio_set_bh on the first __bread_gfp call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/rds: Don&amp;#39;t sleep inside rds_ib_conn_path_shutdown<br /> <br /> New rds rdma self tests exposed a hang when tearing down<br /> the ib network configs. This is caused by the shutdown worker<br /> thread sleeping on the wait_event call, which blocks other work<br /> items in the queue. Fix this by changing wait_event to<br /> wait_event timeout, and looping until the wait check succeeds.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: don&amp;#39;t call ieee80211_handle_reconfig_failure when not needed<br /> <br /> In case reconfiguration of NAN fails, we call<br /> ieee80211_handle_reconfig_failure, that marks all interfaces as not in<br /> the driver.<br /> Then, at the error path of the reconfig, cfg80211_shutdown_all_interfaces<br /> is called to destroy all the interfaces.<br /> <br /> If we have any other interface but the NAN one, for example a BSS<br /> station, then when its state (links, stations) will be removed, we<br /> won&amp;#39;t tell the driver about this, because we will think that the<br /> interfaces are not in the driver, and then drivers might remain with<br /> dangling pointers to objects like stations and links (at least for<br /> iwlwifi this is the case).<br /> <br /> ieee80211_handle_reconfig_failure is meant to be called after we cleaned<br /> up the state in the driver, there is no reason to call it for NAN<br /> reconfiguration failure.<br /> <br /> Fix the code to just warn in such a case, as we do in other error paths<br /> in reconfig where it is too complicated to rewind.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Bound GPIO I2C table entry count from VBIOS<br /> <br /> Reject undersized tables and cap the derived entry count<br /> to AMDGPU_MAX_I2C_BUS so we do not overrun adev-&gt;i2c_bus[]<br /> or walk an absurd number of entries on corrupt size fields.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/counter: Fix num_counters leak on bind_qp failure in alloc_and_bind()<br /> <br /> When __rdma_counter_bind_qp() fails in alloc_and_bind(), the error path<br /> jumps to err_mode which frees the counter without decrementing<br /> port_counter-&gt;num_counters. The only place that decrements is<br /> rdma_counter_free(), which is unreachable since the counter was never<br /> successfully bound.<br /> <br /> This leak accumulates across repeated failures, permanently preventing<br /> the port from switching to AUTO mode (-EBUSY in __counter_set_mode())<br /> and blocking the MANUAL→NONE auto-revert in rdma_counter_free(). When<br /> the mode was NONE before the call, the MANUAL mode set by<br /> __counter_set_mode() also leaks since the revert logic is never<br /> reached.<br /> <br /> Add an err_bind label between the num_counters increment and the<br /> existing err_mode label. It decrements num_counters and mirrors the<br /> MANUAL→NONE revert from rdma_counter_free(), ensuring the port state<br /> is fully restored on bind failure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> driver core: Avoid warning when removing a device while its supplier is unbinding<br /> <br /> During driver removal, the following warning can appear:<br /> WARNING: CPU: 1 PID: 139 at drivers/base/core.c:1497 __device_links_no_driver+0xcc/0xfc<br /> ...<br /> Call trace:<br /> __device_links_no_driver+0xcc/0xfc (P)<br /> device_links_driver_cleanup+0xa8/0xf0<br /> device_release_driver_internal+0x208/0x23c<br /> device_links_unbind_consumers+0xe0/0x108<br /> device_release_driver_internal+0xec/0x23c<br /> device_links_unbind_consumers+0xe0/0x108<br /> device_release_driver_internal+0xec/0x23c<br /> device_links_unbind_consumers+0xe0/0x108<br /> device_release_driver_internal+0xec/0x23c<br /> driver_detach+0xa0/0x12c<br /> bus_remove_driver+0x6c/0xbc<br /> driver_unregister+0x30/0x60<br /> pci_unregister_driver+0x20/0x9c<br /> lan966x_pci_driver_exit+0x18/0xa90 [lan966x_pci]<br /> <br /> This warning is triggered when a consumer is removed because the links<br /> status of its supplier is not DL_DEV_DRIVER_BOUND and the link flag<br /> DL_FLAG_SYNC_STATE_ONLY is not set.<br /> <br /> The topology in terms of consumers/suppliers used was the following<br /> (consumer ---&gt; supplier):<br /> <br /> i2c -----------&gt; OIC ----&gt; PCI device<br /> | ^<br /> | |<br /> +---&gt; pinctrl ---+<br /> <br /> When the PCI device is removed, the OIC (interrupt controller) has to be<br /> removed. In order to remove the OIC, pinctrl and i2c need to be removed<br /> and to remove pinctrl, i2c need to be removed. The removal order is:<br /> 1) i2c<br /> 2) pinctrl<br /> 3) OIC<br /> 4) PCI device<br /> <br /> In details, the removal sequence is the following (with 0000:01:00.0 the<br /> PCI device):<br /> driver_detach: call device_release_driver_internal(0000:01:00.0)...<br /> device_links_busy(0000:01:00.0):<br /> links-&gt;status = DL_DEV_UNBINDING<br /> device_links_unbind_consumers(0000:01:00.0):<br /> 0000:01:00.0--oic link-&gt;status = DL_STATE_SUPPLIER_UNBIND<br /> call device_release_driver_internal(oic)...<br /> device_links_busy(oic):<br /> links-&gt;status = DL_DEV_UNBINDING<br /> device_links_unbind_consumers(oic):<br /> oic--pinctrl link-&gt;status = DL_STATE_SUPPLIER_UNBIND<br /> call device_release_driver_internal(pinctrl)...<br /> device_links_busy(pinctrl):<br /> links-&gt;status = DL_DEV_UNBINDING<br /> device_links_unbind_consumers(pinctrl):<br /> pinctrl--i2c link-&gt;status = DL_STATE_SUPPLIER_UNBIND<br /> call device_release_driver_internal(i2c)...<br /> device_links_busy(i2c): links-&gt;status = DL_DEV_UNBINDING<br /> __device_links_no_driver(i2c)...<br /> pinctrl--i2c link-&gt;status is DL_STATE_SUPPLIER_UNBIND<br /> oic--i2c link-&gt;status is DL_STATE_ACTIVE<br /> oic--i2c link-&gt;supplier-&gt;links.status is DL_DEV_UNBINDING<br /> <br /> The warning is triggered by the i2c removal because the OIC (supplier)<br /> links status is not DL_DEV_DRIVER_BOUND. Its links status is indeed set<br /> to DL_DEV_UNBINDING.<br /> <br /> It is perfectly legit to have the links status set to DL_DEV_UNBINDING<br /> in that case. Indeed we had started to unbind the OIC which triggered<br /> the consumer unbinding and didn&amp;#39;t finish yet when the i2c is unbound.<br /> <br /> Avoid the warning when the supplier links status is set to<br /> DL_DEV_UNBINDING and thus support this removal sequence without any<br /> warnings.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: serial: 8250: protect against NULL uart-&gt;port.dev in register<br /> <br /> serial8250_register_8250_port() conditionally copies uart-&gt;port.dev<br /> from up-&gt;port.dev only when up-&gt;port.dev is non-NULL:<br /> <br /> if (up-&gt;port.dev) {<br /> uart-&gt;port.dev = up-&gt;port.dev;<br /> ...<br /> }<br /> <br /> So if both the existing uart slot and up have a NULL -&gt;dev,<br /> uart-&gt;port.dev remains NULL. The very next ACPI companion check<br /> then dereferences it unconditionally:<br /> <br /> if (!has_acpi_companion(uart-&gt;port.dev)) {<br /> <br /> has_acpi_companion() reads dev-&gt;fwnode without a NULL guard<br /> (include/linux/acpi.h), so this NULL-derefs the kernel for the<br /> remaining no-dev case rather than just skipping the<br /> mctrl_gpio_init() initialisation as intended.<br /> <br /> smatch flags the inconsistency:<br /> <br /> drivers/tty/serial/8250/8250_core.c:767<br /> serial8250_register_8250_port() error: &amp;#39;uart-&gt;port.dev&amp;#39; could be<br /> null (see line 719)<br /> <br /> Guard the call with a NULL check so register continues to work<br /> for callers that legitimately have no parent device (legacy<br /> non-OF/non-ACPI registrations).<br /> <br /> No functional change for callers that pass a non-NULL -&gt;dev.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: 8250: fix possible ISR soft lockup<br /> <br /> There are rare cases in which the host gets stuck in the ISR because it<br /> is flooded with messages during the startup phase.<br /> <br /> The reason for the soft lockup in the ISR is the missing FIFO error IRQ<br /> (FIFOE) handling. Not handling it and reporting IRQ_HANDLED triggers<br /> the IRQ immediately again.<br /> <br /> Fix this by adding a check for the FIFOE status and clearing the FIFO<br /> if no data is ready (DR).<br /> <br /> This behavior was observed on an AM62L device which uses the OMAP 8250<br /> driver. Fix it for all 8250 drivers, since the OMAP driver&amp;#39;s special<br /> IRQ setup handling may trigger this behavior more frequently, but it<br /> is not ensured that other 8250 drivers aren&amp;#39;t affected.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: goku_udc: avoid NULL deref of dev-&gt;driver in INT_USBRESET log<br /> <br /> goku_irq() handles a number of bus events under a single ep0 path.<br /> It already guards the gadget driver suspend/resume callbacks against a<br /> NULL -&gt;driver:<br /> <br /> if (dev-&gt;gadget.speed != USB_SPEED_UNKNOWN<br /> &amp;&amp; dev-&gt;driver<br /> &amp;&amp; dev-&gt;driver-&gt;resume) {<br /> spin_unlock(&amp;dev-&gt;lock);<br /> dev-&gt;driver-&gt;resume(&amp;dev-&gt;gadget);<br /> ...<br /> }<br /> <br /> but the very next branch unconditionally dereferences dev-&gt;driver<br /> when an INT_USBRESET arrives:<br /> <br /> if (stat &amp; INT_USBRESET) {<br /> ACK(INT_USBRESET);<br /> INFO(dev, "USB reset done, gadget %s\n",<br /> dev-&gt;driver-&gt;driver.name);<br /> }<br /> <br /> If the controller raises INT_USBRESET before any gadget driver has<br /> been bound (or after one has been unbound), dev-&gt;driver is NULL and<br /> the printk dereferences NULL.<br /> <br /> smatch flags the inconsistency:<br /> <br /> drivers/usb/gadget/udc/goku_udc.c:1618 goku_irq() error:<br /> we previously assumed &amp;#39;dev-&gt;driver&amp;#39; could be null (see line 1607)<br /> <br /> Fall back to a placeholder when the gadget driver is not bound.<br /> <br /> No functional change while a gadget driver is bound.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: core: hcd: fix possible deadlock in rh control transfers<br /> <br /> &gt;From within the SCSI error handler memory allocations must not<br /> trigger IO. Handling errors in UAS and the storage driver may<br /> involve resetting a device. The thread doing the reset itself<br /> relies on VM magic. However, that is insufficient, as resetting<br /> a device involves resuming it. Resumption as well as resetting<br /> involves conrol transfers to the parent of the device to be reset.<br /> That may be a root hub. Hence usbcore must heed the flags passed<br /> to usb_submit_urb() processing control transfers to root hubs.<br /> <br /> The problem exist since the storage driver has been merged.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usbip: vhci_hcd: fix NULL deref in status_show_vhci<br /> <br /> platform_get_drvdata() can return NULL if a VHCI host controller&amp;#39;s<br /> probe failed (e.g. due to USB bus number exhaustion). status_show_vhci()<br /> checked for a NULL pdev but not for a NULL hcd returned by<br /> platform_get_drvdata(). Passing NULL to hcd_to_vhci_hcd() does not<br /> return NULL - it returns a pointer offset of 0x260, causing a NULL<br /> pointer dereference when that value is subsequently dereferenced.<br /> <br /> Add a NULL check on hcd before calling hcd_to_vhci_hcd(). Move<br /> status_show_not_ready() above status_show_vhci() to make it callable<br /> from the new error path without a forward declaration.