Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix oops in write-retry from mis-resetting the subreq iterator<br /> <br /> Fix the resetting of the subrequest iterator in netfs_retry_write_stream()<br /> to use the iterator-reset function as the iterator may have been shortened<br /> by a previous retry. In such a case, the amount of data to be written by<br /> the subrequest is not "subreq-&gt;len" but "subreq-&gt;len -<br /> subreq-&gt;transferred".<br /> <br /> Without this, KASAN may see an error in iov_iter_revert():<br /> <br /> BUG: KASAN: slab-out-of-bounds in iov_iter_revert lib/iov_iter.c:633 [inline]<br /> BUG: KASAN: slab-out-of-bounds in iov_iter_revert+0x443/0x5a0 lib/iov_iter.c:611<br /> Read of size 4 at addr ffff88802912a0b8 by task kworker/u32:7/1147<br /> <br /> CPU: 1 UID: 0 PID: 1147 Comm: kworker/u32:7 Not tainted 6.15.0-rc6-syzkaller-00052-g9f35e33144ae #0 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> Workqueue: events_unbound netfs_write_collection_worker<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:408 [inline]<br /> print_report+0xc3/0x670 mm/kasan/report.c:521<br /> kasan_report+0xe0/0x110 mm/kasan/report.c:634<br /> iov_iter_revert lib/iov_iter.c:633 [inline]<br /> iov_iter_revert+0x443/0x5a0 lib/iov_iter.c:611<br /> netfs_retry_write_stream fs/netfs/write_retry.c:44 [inline]<br /> netfs_retry_writes+0x166d/0x1a50 fs/netfs/write_retry.c:231<br /> netfs_collect_write_results fs/netfs/write_collect.c:352 [inline]<br /> netfs_write_collection_worker+0x23fd/0x3830 fs/netfs/write_collect.c:374<br /> process_one_work+0x9cf/0x1b70 kernel/workqueue.c:3238<br /> process_scheduled_works kernel/workqueue.c:3319 [inline]<br /> worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400<br /> kthread+0x3c2/0x780 kernel/kthread.c:464<br /> ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI/pwrctrl: Cancel outstanding rescan work when unregistering<br /> <br /> It&amp;#39;s possible to trigger use-after-free here by:<br /> <br /> (a) forcing rescan_work_func() to take a long time and<br /> (b) utilizing a pwrctrl driver that may be unloaded for some reason<br /> <br /> Cancel outstanding work to ensure it is finished before we allow our data<br /> structures to be cleaned up.<br /> <br /> [bhelgaas: tidy commit log]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: renesas_usbhs: Reorder clock handling and power management in probe<br /> <br /> Reorder the initialization sequence in `usbhs_probe()` to enable runtime<br /> PM before accessing registers, preventing potential crashes due to<br /> uninitialized clocks.<br /> <br /> Currently, in the probe path, registers are accessed before enabling the<br /> clocks, leading to a synchronous external abort on the RZ/V2H SoC.<br /> The problematic call flow is as follows:<br /> <br /> usbhs_probe()<br /> usbhs_sys_clock_ctrl()<br /> usbhs_bset()<br /> usbhs_write()<br /> iowrite16()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: ti: Add NULL check in udma_probe()<br /> <br /> devm_kasprintf() returns NULL when memory allocation fails. Currently,<br /> udma_probe() does not check for this case, which results in a NULL<br /> pointer dereference.<br /> <br /> Add NULL check after devm_kasprintf() to prevent this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (asus-ec-sensors) check sensor index in read_string()<br /> <br /> Prevent a potential invalid memory access when the requested sensor<br /> is not found.<br /> <br /> find_ec_sensor_index() may return a negative value (e.g. -ENOENT),<br /> but its result was used without checking, which could lead to<br /> undefined behavior when passed to get_sensor_info().<br /> <br /> Add a proper check to return -EINVAL if sensor_index is negative.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.<br /> <br /> [groeck: Return error code returned from find_ec_sensor_index]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: acpi: Prevent null pointer dereference in usb_acpi_add_usb4_devlink()<br /> <br /> As demonstrated by the fix for update_port_device_state,<br /> commit 12783c0b9e2c ("usb: core: Prevent null pointer dereference in update_port_device_state"),<br /> usb_hub_to_struct_hub() can return NULL in certain scenarios,<br /> such as during hub driver unbind or teardown race conditions,<br /> even if the underlying usb_device structure exists.<br /> <br /> Plus, all other places that call usb_hub_to_struct_hub() in the same file<br /> do check for NULL return values.<br /> <br /> If usb_hub_to_struct_hub() returns NULL, the subsequent access to<br /> hub-&gt;ports[udev-&gt;portnum - 1] will cause a null pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: ad4851: fix ad4858 chan pointer handling<br /> <br /> The pointer returned from ad4851_parse_channels_common() is incremented<br /> internally as each channel is populated. In ad4858_parse_channels(),<br /> the same pointer was further incremented while setting ext_scan_type<br /> fields for each channel. This resulted in indio_dev-&gt;channels being set<br /> to a pointer past the end of the allocated array, potentially causing<br /> memory corruption or undefined behavior.<br /> <br /> Fix this by iterating over the channels using an explicit index instead<br /> of incrementing the pointer. This preserves the original base pointer<br /> and ensures all channel metadata is set correctly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> coresight: holding cscfg_csdev_lock while removing cscfg from csdev<br /> <br /> There&amp;#39;ll be possible race scenario for coresight config:<br /> <br /> CPU0 CPU1<br /> (perf enable) load module<br /> cscfg_load_config_sets()<br /> activate config. // sysfs<br /> (sys_active_cnt == 1)<br /> ...<br /> cscfg_csdev_enable_active_config()<br /> lock(csdev-&gt;cscfg_csdev_lock)<br /> deactivate config // sysfs<br /> (sys_activec_cnt == 0)<br /> cscfg_unload_config_sets()<br /> cscfg_remove_owned_csdev_configs()<br /> // here load config activate by CPU1<br /> unlock(csdev-&gt;cscfg_csdev_lock)<br /> <br /> iterating config_csdev_list could be raced with config_csdev_list&amp;#39;s<br /> entry delete.<br /> <br /> To resolve this race , hold csdev-&gt;cscfg_csdev_lock() while<br /> cscfg_remove_owned_csdev_configs()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/connector: only call HDMI audio helper plugged cb if non-null<br /> <br /> On driver remove, sound/soc/codecs/hdmi-codec.c calls the plugged_cb<br /> with NULL as the callback function and codec_dev, as seen in its<br /> hdmi_remove function.<br /> <br /> The HDMI audio helper then happily tries calling said null function<br /> pointer, and produces an Oops as a result.<br /> <br /> Fix this by only executing the callback if fn is non-null. This means<br /> the .plugged_cb and .plugged_cb_dev members still get appropriately<br /> cleared.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: MGMT: reject malformed HCI_CMD_SYNC commands<br /> <br /> In &amp;#39;mgmt_hci_cmd_sync()&amp;#39;, check whether the size of parameters passed<br /> in &amp;#39;struct mgmt_cp_hci_cmd_sync&amp;#39; matches the total size of the data<br /> (i.e. &amp;#39;sizeof(struct mgmt_cp_hci_cmd_sync)&amp;#39; plus trailing bytes).<br /> Otherwise, large invalid &amp;#39;params_len&amp;#39; will cause &amp;#39;hci_cmd_sync_alloc()&amp;#39;<br /> to do &amp;#39;skb_put_data()&amp;#39; from an area beyond the one actually passed to<br /> &amp;#39;mgmt_hci_cmd_sync()&amp;#39;.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> coresight: prevent deactivate active config while enabling the config<br /> <br /> While enable active config via cscfg_csdev_enable_active_config(),<br /> active config could be deactivated via configfs&amp;#39; sysfs interface.<br /> This could make UAF issue in below scenario:<br /> <br /> CPU0 CPU1<br /> (sysfs enable) load module<br /> cscfg_load_config_sets()<br /> activate config. // sysfs<br /> (sys_active_cnt == 1)<br /> ...<br /> cscfg_csdev_enable_active_config()<br /> lock(csdev-&gt;cscfg_csdev_lock)<br /> // here load config activate by CPU1<br /> unlock(csdev-&gt;cscfg_csdev_lock)<br /> <br /> deactivate config // sysfs<br /> (sys_activec_cnt == 0)<br /> cscfg_unload_config_sets()<br /> unload module<br /> <br /> // access to config_desc which freed<br /> // while unloading module.<br /> cscfg_csdev_enable_config<br /> <br /> To address this, use cscfg_config_desc&amp;#39;s active_cnt as a reference count<br /> which will be holded when<br /> - activate the config.<br /> - enable the activated config.<br /> and put the module reference when config_active_cnt == 0.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: Fix potential null-ptr-deref in mlb_usio_probe()<br /> <br /> devm_ioremap() can return NULL on error. Currently, mlb_usio_probe()<br /> does not check for this case, which could result in a NULL pointer<br /> dereference.<br /> <br /> Add NULL check after devm_ioremap() to prevent this issue.