Vulnerabilities

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 /> 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 /> dm: limit swapping tables for devices with zone write plugs<br /> <br /> dm_revalidate_zones() only allowed new or previously unzoned devices to<br /> call blk_revalidate_disk_zones(). If the device was already zoned,<br /> disk-&gt;nr_zones would always equal md-&gt;nr_zones, so dm_revalidate_zones()<br /> returned without doing any work. This would make the zoned settings for<br /> the device not match the new table. If the device had zone write plug<br /> resources, it could run into errors like bdev_zone_is_seq() reading<br /> invalid memory because disk-&gt;conv_zones_bitmap was the wrong size.<br /> <br /> If the device doesn&amp;#39;t have any zone write plug resources, calling<br /> blk_revalidate_disk_zones() will always correctly update device. If<br /> blk_revalidate_disk_zones() fails, it can still overwrite or clear the<br /> current disk-&gt;nr_zones value. In this case, DM must restore the previous<br /> value of disk-&gt;nr_zones, so that the zoned settings will continue to<br /> match the previous value that it fell back to.<br /> <br /> If the device already has zone write plug resources,<br /> blk_revalidate_disk_zones() will not correctly update them, if it is<br /> called for arbitrary zoned device changes. Since there is not much need<br /> for this ability, the easiest solution is to disallow any table reloads<br /> that change the zoned settings, for devices that already have zone plug<br /> resources. Specifically, if a device already has zone plug resources<br /> allocated, it can only switch to another zoned table that also emulates<br /> zone append. Also, it cannot change the device size or the zone size. A<br /> device can switch to an error target.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm: fix dm_blk_report_zones<br /> <br /> If dm_get_live_table() returned NULL, dm_put_live_table() was never<br /> called. Also, it is possible that md-&gt;zone_revalidate_map will change<br /> while calling this function. Only read it once, so that we are always<br /> using the same value. Otherwise we might miss a call to<br /> dm_put_live_table().<br /> <br /> Finally, while md-&gt;zone_revalidate_map is set and a process is calling<br /> blk_revalidate_disk_zones() to set up the zone append emulation<br /> resources, it is possible that another process, perhaps triggered by<br /> blkdev_report_zones_ioctl(), will call dm_blk_report_zones(). If<br /> blk_revalidate_disk_zones() fails, these resources can be freed while<br /> the other process is still using them, causing a use-after-free error.<br /> <br /> blk_revalidate_disk_zones() will only ever be called when initially<br /> setting up the zone append emulation resources, such as when setting up<br /> a zoned dm-crypt table for the first time. Further table swaps will not<br /> set md-&gt;zone_revalidate_map or call blk_revalidate_disk_zones().<br /> However it must be called using the new table (referenced by<br /> md-&gt;zone_revalidate_map) and the new queue limits while the DM device is<br /> suspended. dm_blk_report_zones() needs some way to distinguish between a<br /> call from blk_revalidate_disk_zones(), which must be allowed to use<br /> md-&gt;zone_revalidate_map to access this not yet activated table, and all<br /> other calls to dm_blk_report_zones(), which should not be allowed while<br /> the device is suspended and cannot use md-&gt;zone_revalidate_map, since<br /> the zone resources might be freed by the process currently calling<br /> blk_revalidate_disk_zones().<br /> <br /> Solve this by tracking the process that sets md-&gt;zone_revalidate_map in<br /> dm_revalidate_zones() and only allowing that process to make use of it<br /> in dm_blk_report_zones().

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 /> 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 /> page_pool: Fix use-after-free in page_pool_recycle_in_ring<br /> <br /> syzbot reported a uaf in page_pool_recycle_in_ring:<br /> <br /> BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862<br /> Read of size 8 at addr ffff8880286045a0 by task syz.0.284/6943<br /> <br /> CPU: 0 UID: 0 PID: 6943 Comm: syz.0.284 Not tainted 6.13.0-rc3-syzkaller-gdfa94ce54f41 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0x169/0x550 mm/kasan/report.c:489<br /> kasan_report+0x143/0x180 mm/kasan/report.c:602<br /> lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862<br /> __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:165 [inline]<br /> _raw_spin_unlock_bh+0x1b/0x40 kernel/locking/spinlock.c:210<br /> spin_unlock_bh include/linux/spinlock.h:396 [inline]<br /> ptr_ring_produce_bh include/linux/ptr_ring.h:164 [inline]<br /> page_pool_recycle_in_ring net/core/page_pool.c:707 [inline]<br /> page_pool_put_unrefed_netmem+0x748/0xb00 net/core/page_pool.c:826<br /> page_pool_put_netmem include/net/page_pool/helpers.h:323 [inline]<br /> page_pool_put_full_netmem include/net/page_pool/helpers.h:353 [inline]<br /> napi_pp_put_page+0x149/0x2b0 net/core/skbuff.c:1036<br /> skb_pp_recycle net/core/skbuff.c:1047 [inline]<br /> skb_free_head net/core/skbuff.c:1094 [inline]<br /> skb_release_data+0x6c4/0x8a0 net/core/skbuff.c:1125<br /> skb_release_all net/core/skbuff.c:1190 [inline]<br /> __kfree_skb net/core/skbuff.c:1204 [inline]<br /> sk_skb_reason_drop+0x1c9/0x380 net/core/skbuff.c:1242<br /> kfree_skb_reason include/linux/skbuff.h:1263 [inline]<br /> __skb_queue_purge_reason include/linux/skbuff.h:3343 [inline]<br /> <br /> root cause is:<br /> <br /> page_pool_recycle_in_ring<br /> ptr_ring_produce<br /> spin_lock(&amp;r-&gt;producer_lock);<br /> WRITE_ONCE(r-&gt;queue[r-&gt;producer++], ptr)<br /> //recycle last page to pool<br /> page_pool_release<br /> page_pool_scrub<br /> page_pool_empty_ring<br /> ptr_ring_consume<br /> page_pool_return_page //release all page<br /> __page_pool_destroy<br /> free_percpu(pool-&gt;recycle_stats);<br /> free(pool) //free<br /> <br /> spin_unlock(&amp;r-&gt;producer_lock); //pool-&gt;ring uaf read<br /> recycle_stat_inc(pool, ring);<br /> <br /> page_pool can be free while page pool recycle the last page in ring.<br /> Add producer-lock barrier to page_pool_release to prevent the page<br /> pool from being free before all pages have been recycled.<br /> <br /> recycle_stat_inc() is empty when CONFIG_PAGE_POOL_STATS is not<br /> enabled, which will trigger Wempty-body build warning. Add definition<br /> for pool stat macro to fix warning.

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