Vulnerabilities

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.

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_set_pipapo_avx2: fix initial map fill<br /> <br /> If the first field doesn&amp;#39;t cover the entire start map, then we must zero<br /> out the remainder, else we leak those bits into the next match round map.<br /> <br /> The early fix was incomplete and did only fix up the generic C<br /> implementation.<br /> <br /> A followup patch adds a test case to nft_concat_range.sh.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mld: avoid panic on init failure<br /> <br /> In case of an error during init, in_hw_restart will be set, but it will<br /> never get cleared.<br /> Instead, we will retry to init again, and then we will act like we are in a<br /> restart when we are actually not.<br /> <br /> This causes (among others) to a NULL pointer dereference when canceling<br /> rx_omi::finished_work, that was not even initialized, because we thought<br /> that we are in hw_restart.<br /> <br /> Set in_hw_restart to true only if the fw is running, then we know that<br /> FW was loaded successfully and we are not going to the retry loop.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gve: add missing NULL check for gve_alloc_pending_packet() in TX DQO<br /> <br /> gve_alloc_pending_packet() can return NULL, but gve_tx_add_skb_dqo()<br /> did not check for this case before dereferencing the returned pointer.<br /> <br /> Add a missing NULL check to prevent a potential NULL pointer<br /> dereference when allocation fails.<br /> <br /> This improves robustness in low-memory scenarios.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: wwan: t7xx: Fix napi rx poll issue<br /> <br /> When driver handles the napi rx polling requests, the netdev might<br /> have been released by the dellink logic triggered by the disconnect<br /> operation on user plane. However, in the logic of processing skb in<br /> polling, an invalid netdev is still being used, which causes a panic.<br /> <br /> BUG: kernel NULL pointer dereference, address: 00000000000000f1<br /> Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> RIP: 0010:dev_gro_receive+0x3a/0x620<br /> [...]<br /> Call Trace:<br /> <br /> ? __die_body+0x68/0xb0<br /> ? page_fault_oops+0x379/0x3e0<br /> ? exc_page_fault+0x4f/0xa0<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? __pfx_t7xx_ccmni_recv_skb+0x10/0x10 [mtk_t7xx (HASH:1400 7)]<br /> ? dev_gro_receive+0x3a/0x620<br /> napi_gro_receive+0xad/0x170<br /> t7xx_ccmni_recv_skb+0x48/0x70 [mtk_t7xx (HASH:1400 7)]<br /> t7xx_dpmaif_napi_rx_poll+0x590/0x800 [mtk_t7xx (HASH:1400 7)]<br /> net_rx_action+0x103/0x470<br /> irq_exit_rcu+0x13a/0x310<br /> sysvec_apic_timer_interrupt+0x56/0x90<br />