Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: nl80211: reject cooked mode if it is set along with other flags<br /> <br /> It is possible to set both MONITOR_FLAG_COOK_FRAMES and MONITOR_FLAG_ACTIVE<br /> flags simultaneously on the same monitor interface from the userspace. This<br /> causes a sub-interface to be created with no IEEE80211_SDATA_IN_DRIVER bit<br /> set because the monitor interface is in the cooked state and it takes<br /> precedence over all other states. When the interface is then being deleted<br /> the kernel calls WARN_ONCE() from check_sdata_in_driver() because of missing<br /> that bit.<br /> <br /> Fix this by rejecting MONITOR_FLAG_COOK_FRAMES if it is set along with<br /> other flags.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: regulatory: improve invalid hints checking<br /> <br /> Syzbot keeps reporting an issue [1] that occurs when erroneous symbols<br /> sent from userspace get through into user_alpha2[] via<br /> regulatory_hint_user() call. Such invalid regulatory hints should be<br /> rejected.<br /> <br /> While a sanity check from commit 47caf685a685 ("cfg80211: regulatory:<br /> reject invalid hints") looks to be enough to deter these very cases,<br /> there is a way to get around it due to 2 reasons.<br /> <br /> 1) The way isalpha() works, symbols other than latin lower and<br /> upper letters may be used to determine a country/domain.<br /> For instance, greek letters will also be considered upper/lower<br /> letters and for such characters isalpha() will return true as well.<br /> However, ISO-3166-1 alpha2 codes should only hold latin<br /> characters.<br /> <br /> 2) While processing a user regulatory request, between<br /> reg_process_hint_user() and regulatory_hint_user() there happens to<br /> be a call to queue_regulatory_request() which modifies letters in<br /> request-&gt;alpha2[] with toupper(). This works fine for latin symbols,<br /> less so for weird letter characters from the second part of _ctype[].<br /> <br /> Syzbot triggers a warning in is_user_regdom_saved() by first sending<br /> over an unexpected non-latin letter that gets malformed by toupper()<br /> into a character that ends up failing isalpha() check.<br /> <br /> Prevent this by enhancing is_an_alpha2() to ensure that incoming<br /> symbols are latin letters and nothing else.<br /> <br /> [1] Syzbot report:<br /> ------------[ cut here ]------------<br /> Unexpected user alpha2: A�<br /> WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 is_user_regdom_saved net/wireless/reg.c:440 [inline]<br /> WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 restore_alpha2 net/wireless/reg.c:3424 [inline]<br /> WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 restore_regulatory_settings+0x3c0/0x1e50 net/wireless/reg.c:3516<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 964 Comm: kworker/1:2 Not tainted 6.12.0-rc5-syzkaller-00044-gc1e939a21eb1 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024<br /> Workqueue: events_power_efficient crda_timeout_work<br /> RIP: 0010:is_user_regdom_saved net/wireless/reg.c:440 [inline]<br /> RIP: 0010:restore_alpha2 net/wireless/reg.c:3424 [inline]<br /> RIP: 0010:restore_regulatory_settings+0x3c0/0x1e50 net/wireless/reg.c:3516<br /> ...<br /> Call Trace:<br /> <br /> crda_timeout_work+0x27/0x50 net/wireless/reg.c:542<br /> process_one_work kernel/workqueue.c:3229 [inline]<br /> process_scheduled_works+0xa65/0x1850 kernel/workqueue.c:3310<br /> worker_thread+0x870/0xd30 kernel/workqueue.c:3391<br /> kthread+0x2f2/0x390 kernel/kthread.c:389<br /> ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/amd_nb: Use rdmsr_safe() in amd_get_mmconfig_range()<br /> <br /> Xen doesn&amp;#39;t offer MSR_FAM10H_MMIO_CONF_BASE to all guests. This results<br /> in the following warning:<br /> <br /> unchecked MSR access error: RDMSR from 0xc0010058 at rIP: 0xffffffff8101d19f (xen_do_read_msr+0x7f/0xa0)<br /> Call Trace:<br /> xen_read_msr+0x1e/0x30<br /> amd_get_mmconfig_range+0x2b/0x80<br /> quirk_amd_mmconfig_area+0x28/0x100<br /> pnp_fixup_device+0x39/0x50<br /> __pnp_add_device+0xf/0x150<br /> pnp_add_device+0x3d/0x100<br /> pnpacpi_add_device_handler+0x1f9/0x280<br /> acpi_ns_get_device_callback+0x104/0x1c0<br /> acpi_ns_walk_namespace+0x1d0/0x260<br /> acpi_get_devices+0x8a/0xb0<br /> pnpacpi_init+0x50/0x80<br /> do_one_initcall+0x46/0x2e0<br /> kernel_init_freeable+0x1da/0x2f0<br /> kernel_init+0x16/0x1b0<br /> ret_from_fork+0x30/0x50<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> based on quirks for a "PNP0c01" device. Treating MMCFG as disabled is the<br /> right course of action, so no change is needed there.<br /> <br /> This was most likely exposed by fixing the Xen MSR accessors to not be<br /> silently-safe.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> slimbus: messaging: Free transaction ID in delayed interrupt scenario<br /> <br /> In case of interrupt delay for any reason, slim_do_transfer()<br /> returns timeout error but the transaction ID (TID) is not freed.<br /> This results into invalid memory access inside<br /> qcom_slim_ngd_rx_msgq_cb() due to invalid TID.<br /> <br /> Fix the issue by freeing the TID in slim_do_transfer() before<br /> returning timeout error to avoid invalid memory access.<br /> <br /> Call trace:<br /> __memcpy_fromio+0x20/0x190<br /> qcom_slim_ngd_rx_msgq_cb+0x130/0x290 [slim_qcom_ngd_ctrl]<br /> vchan_complete+0x2a0/0x4a0<br /> tasklet_action_common+0x274/0x700<br /> tasklet_action+0x28/0x3c<br /> _stext+0x188/0x620<br /> run_ksoftirqd+0x34/0x74<br /> smpboot_thread_fn+0x1d8/0x464<br /> kthread+0x178/0x238<br /> ret_from_fork+0x10/0x20<br /> Code: aa0003e8 91000429 f100044a 3940002b (3800150b)<br /> ---[ end trace 0fe00bec2b975c99 ]---<br /> Kernel panic - not syncing: Oops: Fatal exception in interrupt.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFS: fix nfs_release_folio() to not deadlock via kcompactd writeback<br /> <br /> Add PF_KCOMPACTD flag and current_is_kcompactd() helper to check for it so<br /> nfs_release_folio() can skip calling nfs_wb_folio() from kcompactd.<br /> <br /> Otherwise NFS can deadlock waiting for kcompactd enduced writeback which<br /> recurses back to NFS (which triggers writeback to NFSD via NFS loopback<br /> mount on the same host, NFSD blocks waiting for XFS&amp;#39;s call to<br /> __filemap_get_folio):<br /> <br /> 6070.550357] INFO: task kcompactd0:58 blocked for more than 4435 seconds.<br /> <br /> {---<br /> [58] "kcompactd0"<br /> [] folio_wait_bit+0xe8/0x200<br /> [] folio_wait_writeback+0x2b/0x80<br /> [] nfs_wb_folio+0x80/0x1b0 [nfs]<br /> [] nfs_release_folio+0x68/0x130 [nfs]<br /> [] split_huge_page_to_list_to_order+0x362/0x840<br /> [] migrate_pages_batch+0x43d/0xb90<br /> [] migrate_pages_sync+0x9a/0x240<br /> [] migrate_pages+0x93c/0x9f0<br /> [] compact_zone+0x8e2/0x1030<br /> [] compact_node+0xdb/0x120<br /> [] kcompactd+0x121/0x2e0<br /> [] kthread+0xcf/0x100<br /> [] ret_from_fork+0x31/0x40<br /> [] ret_from_fork_asm+0x1a/0x30<br /> ---}<br /> <br /> [akpm@linux-foundation.org: fix build]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/imagination: avoid deadlock on fence release<br /> <br /> Do scheduler queue fence release processing on a workqueue, rather<br /> than in the release function itself.<br /> <br /> Fixes deadlock issues such as the following:<br /> <br /> [ 607.400437] ============================================<br /> [ 607.405755] WARNING: possible recursive locking detected<br /> [ 607.415500] --------------------------------------------<br /> [ 607.420817] weston:zfq0/24149 is trying to acquire lock:<br /> [ 607.426131] ffff000017d041a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: pvr_gem_object_vunmap+0x40/0xc0 [powervr]<br /> [ 607.436728]<br /> but task is already holding lock:<br /> [ 607.442554] ffff000017d105a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: dma_buf_ioctl+0x250/0x554<br /> [ 607.451727]<br /> other info that might help us debug this:<br /> [ 607.458245] Possible unsafe locking scenario:<br /> <br /> [ 607.464155] CPU0<br /> [ 607.466601] ----<br /> [ 607.469044] lock(reservation_ww_class_mutex);<br /> [ 607.473584] lock(reservation_ww_class_mutex);<br /> [ 607.478114]<br /> *** DEADLOCK ***

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: rcar: Use raw_spinlock to protect register access<br /> <br /> Use raw_spinlock in order to fix spurious messages about invalid context<br /> when spinlock debugging is enabled. The lock is only used to serialize<br /> register access.<br /> <br /> [ 4.239592] =============================<br /> [ 4.239595] [ BUG: Invalid wait context ]<br /> [ 4.239599] 6.13.0-rc7-arm64-renesas-05496-gd088502a519f #35 Not tainted<br /> [ 4.239603] -----------------------------<br /> [ 4.239606] kworker/u8:5/76 is trying to lock:<br /> [ 4.239609] ffff0000091898a0 (&amp;p-&gt;lock){....}-{3:3}, at: gpio_rcar_config_interrupt_input_mode+0x34/0x164<br /> [ 4.239641] other info that might help us debug this:<br /> [ 4.239643] context-{5:5}<br /> [ 4.239646] 5 locks held by kworker/u8:5/76:<br /> [ 4.239651] #0: ffff0000080fb148 ((wq_completion)async){+.+.}-{0:0}, at: process_one_work+0x190/0x62c<br /> [ 4.250180] OF: /soc/sound@ec500000/ports/port@0/endpoint: Read of boolean property &amp;#39;frame-master&amp;#39; with a value.<br /> [ 4.254094] #1: ffff80008299bd80 ((work_completion)(&amp;entry-&gt;work)){+.+.}-{0:0}, at: process_one_work+0x1b8/0x62c<br /> [ 4.254109] #2: ffff00000920c8f8<br /> [ 4.258345] OF: /soc/sound@ec500000/ports/port@1/endpoint: Read of boolean property &amp;#39;bitclock-master&amp;#39; with a value.<br /> [ 4.264803] (&amp;dev-&gt;mutex){....}-{4:4}, at: __device_attach_async_helper+0x3c/0xdc<br /> [ 4.264820] #3: ffff00000a50ca40 (request_class#2){+.+.}-{4:4}, at: __setup_irq+0xa0/0x690<br /> [ 4.264840] #4:<br /> [ 4.268872] OF: /soc/sound@ec500000/ports/port@1/endpoint: Read of boolean property &amp;#39;frame-master&amp;#39; with a value.<br /> [ 4.273275] ffff00000a50c8c8 (lock_class){....}-{2:2}, at: __setup_irq+0xc4/0x690<br /> [ 4.296130] renesas_sdhi_internal_dmac ee100000.mmc: mmc1 base at 0x00000000ee100000, max clock rate 200 MHz<br /> [ 4.304082] stack backtrace:<br /> [ 4.304086] CPU: 1 UID: 0 PID: 76 Comm: kworker/u8:5 Not tainted 6.13.0-rc7-arm64-renesas-05496-gd088502a519f #35<br /> [ 4.304092] Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT)<br /> [ 4.304097] Workqueue: async async_run_entry_fn<br /> [ 4.304106] Call trace:<br /> [ 4.304110] show_stack+0x14/0x20 (C)<br /> [ 4.304122] dump_stack_lvl+0x6c/0x90<br /> [ 4.304131] dump_stack+0x14/0x1c<br /> [ 4.304138] __lock_acquire+0xdfc/0x1584<br /> [ 4.426274] lock_acquire+0x1c4/0x33c<br /> [ 4.429942] _raw_spin_lock_irqsave+0x5c/0x80<br /> [ 4.434307] gpio_rcar_config_interrupt_input_mode+0x34/0x164<br /> [ 4.440061] gpio_rcar_irq_set_type+0xd4/0xd8<br /> [ 4.444422] __irq_set_trigger+0x5c/0x178<br /> [ 4.448435] __setup_irq+0x2e4/0x690<br /> [ 4.452012] request_threaded_irq+0xc4/0x190<br /> [ 4.456285] devm_request_threaded_irq+0x7c/0xf4<br /> [ 4.459398] ata1: link resume succeeded after 1 retries<br /> [ 4.460902] mmc_gpiod_request_cd_irq+0x68/0xe0<br /> [ 4.470660] mmc_start_host+0x50/0xac<br /> [ 4.474327] mmc_add_host+0x80/0xe4<br /> [ 4.477817] tmio_mmc_host_probe+0x2b0/0x440<br /> [ 4.482094] renesas_sdhi_probe+0x488/0x6f4<br /> [ 4.486281] renesas_sdhi_internal_dmac_probe+0x60/0x78<br /> [ 4.491509] platform_probe+0x64/0xd8<br /> [ 4.495178] really_probe+0xb8/0x2a8<br /> [ 4.498756] __driver_probe_device+0x74/0x118<br /> [ 4.503116] driver_probe_device+0x3c/0x154<br /> [ 4.507303] __device_attach_driver+0xd4/0x160<br /> [ 4.511750] bus_for_each_drv+0x84/0xe0<br /> [ 4.515588] __device_attach_async_helper+0xb0/0xdc<br /> [ 4.520470] async_run_entry_fn+0x30/0xd8<br /> [ 4.524481] process_one_work+0x210/0x62c<br /> [ 4.528494] worker_thread+0x1ac/0x340<br /> [ 4.532245] kthread+0x10c/0x110<br /> [ 4.535476] ret_from_fork+0x10/0x20

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: memory-failure: update ttu flag inside unmap_poisoned_folio<br /> <br /> Patch series "mm: memory_failure: unmap poisoned folio during migrate<br /> properly", v3.<br /> <br /> Fix two bugs during folio migration if the folio is poisoned.<br /> <br /> <br /> This patch (of 3):<br /> <br /> Commit 6da6b1d4a7df ("mm/hwpoison: convert TTU_IGNORE_HWPOISON to<br /> TTU_HWPOISON") introduce TTU_HWPOISON to replace TTU_IGNORE_HWPOISON in<br /> order to stop send SIGBUS signal when accessing an error page after a<br /> memory error on a clean folio. However during page migration, anon folio<br /> must be set with TTU_HWPOISON during unmap_*(). For pagecache we need<br /> some policy just like the one in hwpoison_user_mappings to set this flag. <br /> So move this policy from hwpoison_user_mappings to unmap_poisoned_folio to<br /> handle this warning properly.<br /> <br /> Warning will be produced during unamp poison folio with the following log:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 1 PID: 365 at mm/rmap.c:1847 try_to_unmap_one+0x8fc/0xd3c<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 365 Comm: bash Tainted: G W 6.13.0-rc1-00018-gacdb4bbda7ab #42<br /> Tainted: [W]=WARN<br /> Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015<br /> pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : try_to_unmap_one+0x8fc/0xd3c<br /> lr : try_to_unmap_one+0x3dc/0xd3c<br /> Call trace:<br /> try_to_unmap_one+0x8fc/0xd3c (P)<br /> try_to_unmap_one+0x3dc/0xd3c (L)<br /> rmap_walk_anon+0xdc/0x1f8<br /> rmap_walk+0x3c/0x58<br /> try_to_unmap+0x88/0x90<br /> unmap_poisoned_folio+0x30/0xa8<br /> do_migrate_range+0x4a0/0x568<br /> offline_pages+0x5a4/0x670<br /> memory_block_action+0x17c/0x374<br /> memory_subsys_offline+0x3c/0x78<br /> device_offline+0xa4/0xd0<br /> state_store+0x8c/0xf0<br /> dev_attr_store+0x18/0x2c<br /> sysfs_kf_write+0x44/0x54<br /> kernfs_fop_write_iter+0x118/0x1a8<br /> vfs_write+0x3a8/0x4bc<br /> ksys_write+0x6c/0xf8<br /> __arm64_sys_write+0x1c/0x28<br /> invoke_syscall+0x44/0x100<br /> el0_svc_common.constprop.0+0x40/0xe0<br /> do_el0_svc+0x1c/0x28<br /> el0_svc+0x30/0xd0<br /> el0t_64_sync_handler+0xc8/0xcc<br /> el0t_64_sync+0x198/0x19c<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> [mawupeng1@huawei.com: unmap_poisoned_folio(): remove shadowed local `mapping&amp;#39;, per Miaohe]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched_ext: Fix pick_task_scx() picking non-queued tasks when it&amp;#39;s called without balance()<br /> <br /> a6250aa251ea ("sched_ext: Handle cases where pick_task_scx() is called<br /> without preceding balance_scx()") added a workaround to handle the cases<br /> where pick_task_scx() is called without prececing balance_scx() which is due<br /> to a fair class bug where pick_taks_fair() may return NULL after a true<br /> return from balance_fair().<br /> <br /> The workaround detects when pick_task_scx() is called without preceding<br /> balance_scx() and emulates SCX_RQ_BAL_KEEP and triggers kicking to avoid<br /> stalling. Unfortunately, the workaround code was testing whether @prev was<br /> on SCX to decide whether to keep the task running. This is incorrect as the<br /> task may be on SCX but no longer runnable.<br /> <br /> This could lead to a non-runnable task to be returned from pick_task_scx()<br /> which cause interesting confusions and failures. e.g. A common failure mode<br /> is the task ending up with (!on_rq &amp;&amp; on_cpu) state which can cause<br /> potential wakers to busy loop, which can easily lead to deadlocks.<br /> <br /> Fix it by testing whether @prev has SCX_TASK_QUEUED set. This makes<br /> @prev_on_scx only used in one place. Open code the usage and improve the<br /> comment while at it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix bad hist from corrupting named_triggers list<br /> <br /> The following commands causes a crash:<br /> <br /> ~# cd /sys/kernel/tracing/events/rcu/rcu_callback<br /> ~# echo &amp;#39;hist:name=bad:keys=common_pid:onmax(bogus).save(common_pid)&amp;#39; &gt; trigger<br /> bash: echo: write error: Invalid argument<br /> ~# echo &amp;#39;hist:name=bad:keys=common_pid&amp;#39; &gt; trigger<br /> <br /> Because the following occurs:<br /> <br /> event_trigger_write() {<br /> trigger_process_regex() {<br /> event_hist_trigger_parse() {<br /> <br /> data = event_trigger_alloc(..);<br /> <br /> event_trigger_register(.., data) {<br /> cmd_ops-&gt;reg(.., data, ..) [hist_register_trigger()] {<br /> data-&gt;ops-&gt;init() [event_hist_trigger_init()] {<br /> save_named_trigger(name, data) {<br /> list_add(&amp;data-&gt;named_list, &amp;named_triggers);<br /> }<br /> }<br /> }<br /> }<br /> <br /> ret = create_actions(); (return -EINVAL)<br /> if (ret)<br /> goto out_unreg;<br /> [..]<br /> ret = hist_trigger_enable(data, ...) {<br /> list_add_tail_rcu(&amp;data-&gt;list, &amp;file-&gt;triggers); free) name)<br /> del_named_trigger(data) {<br /> list_del(&amp;data-&gt;named_list);

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> acpi: typec: ucsi: Introduce a -&gt;poll_cci method<br /> <br /> For the ACPI backend of UCSI the UCSI "registers" are just a memory copy<br /> of the register values in an opregion. The ACPI implementation in the<br /> BIOS ensures that the opregion contents are synced to the embedded<br /> controller and it ensures that the registers (in particular CCI) are<br /> synced back to the opregion on notifications. While there is an ACPI call<br /> that syncs the actual registers to the opregion there is rarely a need to<br /> do this and on some ACPI implementations it actually breaks in various<br /> interesting ways.<br /> <br /> The only reason to force a sync from the embedded controller is to poll<br /> CCI while notifications are disabled. Only the ucsi core knows if this<br /> is the case and guessing based on the current command is suboptimal, i.e.<br /> leading to the following spurious assertion splat:<br /> <br /> WARNING: CPU: 3 PID: 76 at drivers/usb/typec/ucsi/ucsi.c:1388 ucsi_reset_ppm+0x1b4/0x1c0 [typec_ucsi]<br /> CPU: 3 UID: 0 PID: 76 Comm: kworker/3:0 Not tainted 6.12.11-200.fc41.x86_64 #1<br /> Hardware name: LENOVO 21D0/LNVNB161216, BIOS J6CN45WW 03/17/2023<br /> Workqueue: events_long ucsi_init_work [typec_ucsi]<br /> RIP: 0010:ucsi_reset_ppm+0x1b4/0x1c0 [typec_ucsi]<br /> Call Trace:<br /> <br /> ucsi_init_work+0x3c/0xac0 [typec_ucsi]<br /> process_one_work+0x179/0x330<br /> worker_thread+0x252/0x390<br /> kthread+0xd2/0x100<br /> ret_from_fork+0x34/0x50<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> Thus introduce a -&gt;poll_cci() method that works like -&gt;read_cci() with an<br /> additional forced sync and document that this should be used when polling<br /> with notifications disabled. For all other backends that presumably don&amp;#39;t<br /> have this issue use the same implementation for both methods.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mctp i3c: handle NULL header address<br /> <br /> daddr can be NULL if there is no neighbour table entry present,<br /> in that case the tx packet should be dropped.<br /> <br /> saddr will usually be set by MCTP core, but check for NULL in case a<br /> packet is transmitted by a different protocol.