Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix out-of-bounds access in &amp;#39;dcn21_link_encoder_create&amp;#39;<br /> <br /> An issue was identified in the dcn21_link_encoder_create function where<br /> an out-of-bounds access could occur when the hpd_source index was used<br /> to reference the link_enc_hpd_regs array. This array has a fixed size<br /> and the index was not being checked against the array&amp;#39;s bounds before<br /> accessing it.<br /> <br /> This fix adds a conditional check to ensure that the hpd_source index is<br /> within the valid range of the link_enc_hpd_regs array. If the index is<br /> out of bounds, the function now returns NULL to prevent undefined<br /> behavior.<br /> <br /> References:<br /> <br /> [ 65.920507] ------------[ cut here ]------------<br /> [ 65.920510] UBSAN: array-index-out-of-bounds in drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn21/dcn21_resource.c:1312:29<br /> [ 65.920519] index 7 is out of range for type &amp;#39;dcn10_link_enc_hpd_registers [5]&amp;#39;<br /> [ 65.920523] CPU: 3 PID: 1178 Comm: modprobe Tainted: G OE 6.8.0-cleanershaderfeatureresetasdntipmi200nv2132 #13<br /> [ 65.920525] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS WMJ0429N_Weekly_20_04_2 04/29/2020<br /> [ 65.920527] Call Trace:<br /> [ 65.920529] <br /> [ 65.920532] dump_stack_lvl+0x48/0x70<br /> [ 65.920541] dump_stack+0x10/0x20<br /> [ 65.920543] __ubsan_handle_out_of_bounds+0xa2/0xe0<br /> [ 65.920549] dcn21_link_encoder_create+0xd9/0x140 [amdgpu]<br /> [ 65.921009] link_create+0x6d3/0xed0 [amdgpu]<br /> [ 65.921355] create_links+0x18a/0x4e0 [amdgpu]<br /> [ 65.921679] dc_create+0x360/0x720 [amdgpu]<br /> [ 65.921999] ? dmi_matches+0xa0/0x220<br /> [ 65.922004] amdgpu_dm_init+0x2b6/0x2c90 [amdgpu]<br /> [ 65.922342] ? console_unlock+0x77/0x120<br /> [ 65.922348] ? dev_printk_emit+0x86/0xb0<br /> [ 65.922354] dm_hw_init+0x15/0x40 [amdgpu]<br /> [ 65.922686] amdgpu_device_init+0x26a8/0x33a0 [amdgpu]<br /> [ 65.922921] amdgpu_driver_load_kms+0x1b/0xa0 [amdgpu]<br /> [ 65.923087] amdgpu_pci_probe+0x1b7/0x630 [amdgpu]<br /> [ 65.923087] local_pci_probe+0x4b/0xb0<br /> [ 65.923087] pci_device_probe+0xc8/0x280<br /> [ 65.923087] really_probe+0x187/0x300<br /> [ 65.923087] __driver_probe_device+0x85/0x130<br /> [ 65.923087] driver_probe_device+0x24/0x110<br /> [ 65.923087] __driver_attach+0xac/0x1d0<br /> [ 65.923087] ? __pfx___driver_attach+0x10/0x10<br /> [ 65.923087] bus_for_each_dev+0x7d/0xd0<br /> [ 65.923087] driver_attach+0x1e/0x30<br /> [ 65.923087] bus_add_driver+0xf2/0x200<br /> [ 65.923087] driver_register+0x64/0x130<br /> [ 65.923087] ? __pfx_amdgpu_init+0x10/0x10 [amdgpu]<br /> [ 65.923087] __pci_register_driver+0x61/0x70<br /> [ 65.923087] amdgpu_init+0x7d/0xff0 [amdgpu]<br /> [ 65.923087] do_one_initcall+0x49/0x310<br /> [ 65.923087] ? kmalloc_trace+0x136/0x360<br /> [ 65.923087] do_init_module+0x6a/0x270<br /> [ 65.923087] load_module+0x1fce/0x23a0<br /> [ 65.923087] init_module_from_file+0x9c/0xe0<br /> [ 65.923087] ? init_module_from_file+0x9c/0xe0<br /> [ 65.923087] idempotent_init_module+0x179/0x230<br /> [ 65.923087] __x64_sys_finit_module+0x5d/0xa0<br /> [ 65.923087] do_syscall_64+0x76/0x120<br /> [ 65.923087] entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> [ 65.923087] RIP: 0033:0x7f2d80f1e88d<br /> [ 65.923087] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48<br /> [ 65.923087] RSP: 002b:00007ffc7bc1aa78 EFLAGS: 00000246 ORIG_RAX: 0000000000000139<br /> [ 65.923087] RAX: ffffffffffffffda RBX: 0000564c9c1db130 RCX: 00007f2d80f1e88d<br /> [ 65.923087] RDX: 0000000000000000 RSI: 0000564c9c1e5480 RDI: 000000000000000f<br /> [ 65.923087] RBP: 0000000000040000 R08: 0000000000000000 R09: 0000000000000002<br /> [ 65.923087] R10: 000000000000000f R11: 0000000000000246 R12: 0000564c9c1e5480<br /> [ 65.923087] R13: 0000564c9c1db260 R14: 0000000000000000 R15: 0000564c9c1e54b0<br /> [ 65.923087] <br /> [ 65.923927] ---[ end trace ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kcsan: Turn report_filterlist_lock into a raw_spinlock<br /> <br /> Ran Xiaokai reports that with a KCSAN-enabled PREEMPT_RT kernel, we can see<br /> splats like:<br /> <br /> | BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48<br /> | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1<br /> | preempt_count: 10002, expected: 0<br /> | RCU nest depth: 0, expected: 0<br /> | no locks held by swapper/1/0.<br /> | irq event stamp: 156674<br /> | hardirqs last enabled at (156673): [] do_idle+0x1f9/0x240<br /> | hardirqs last disabled at (156674): [] sysvec_apic_timer_interrupt+0x14/0xc0<br /> | softirqs last enabled at (0): [] copy_process+0xfc7/0x4b60<br /> | softirqs last disabled at (0): [] 0x0<br /> | Preemption disabled at:<br /> | [] paint_ptr+0x2a/0x90<br /> | CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.11.0+ #3<br /> | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014<br /> | Call Trace:<br /> | <br /> | dump_stack_lvl+0x7e/0xc0<br /> | dump_stack+0x1d/0x30<br /> | __might_resched+0x1a2/0x270<br /> | rt_spin_lock+0x68/0x170<br /> | kcsan_skip_report_debugfs+0x43/0xe0<br /> | print_report+0xb5/0x590<br /> | kcsan_report_known_origin+0x1b1/0x1d0<br /> | kcsan_setup_watchpoint+0x348/0x650<br /> | __tsan_unaligned_write1+0x16d/0x1d0<br /> | hrtimer_interrupt+0x3d6/0x430<br /> | __sysvec_apic_timer_interrupt+0xe8/0x3a0<br /> | sysvec_apic_timer_interrupt+0x97/0xc0<br /> | <br /> <br /> On a detected data race, KCSAN&amp;#39;s reporting logic checks if it should<br /> filter the report. That list is protected by the report_filterlist_lock<br /> *non-raw* spinlock which may sleep on RT kernels.<br /> <br /> Since KCSAN may report data races in any context, convert it to a<br /> raw_spinlock.<br /> <br /> This requires being careful about when to allocate memory for the filter<br /> list itself which can be done via KCSAN&amp;#39;s debugfs interface. Concurrent<br /> modification of the filter list via debugfs should be rare: the chosen<br /> strategy is to optimistically pre-allocate memory before the critical<br /> section and discard if unused.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: fix OOB map writes when deleting elements<br /> <br /> Jordy says:<br /> <br /> "<br /> In the xsk_map_delete_elem function an unsigned integer<br /> (map-&gt;max_entries) is compared with a user-controlled signed integer<br /> (k). Due to implicit type conversion, a large unsigned value for<br /> map-&gt;max_entries can bypass the intended bounds check:<br /> <br /> if (k &gt;= map-&gt;max_entries)<br /> return -EINVAL;<br /> <br /> This allows k to hold a negative value (between -2147483648 and -2),<br /> which is then used as an array index in m-&gt;xsk_map[k], which results<br /> in an out-of-bounds access.<br /> <br /> spin_lock_bh(&amp;m-&gt;lock);<br /> map_entry = &amp;m-&gt;xsk_map[k]; // Out-of-bounds map_entry<br /> old_xs = unrcu_pointer(xchg(map_entry, NULL)); // Oob write<br /> if (old_xs)<br /> xsk_map_sock_delete(old_xs, map_entry);<br /> spin_unlock_bh(&amp;m-&gt;lock);<br /> <br /> The xchg operation can then be used to cause an out-of-bounds write.<br /> Moreover, the invalid map_entry passed to xsk_map_sock_delete can lead<br /> to further memory corruption.<br /> "<br /> <br /> It indeed results in following splat:<br /> <br /> [76612.897343] BUG: unable to handle page fault for address: ffffc8fc2e461108<br /> [76612.904330] #PF: supervisor write access in kernel mode<br /> [76612.909639] #PF: error_code(0x0002) - not-present page<br /> [76612.914855] PGD 0 P4D 0<br /> [76612.917431] Oops: Oops: 0002 [#1] PREEMPT SMP<br /> [76612.921859] CPU: 11 UID: 0 PID: 10318 Comm: a.out Not tainted 6.12.0-rc1+ #470<br /> [76612.929189] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019<br /> [76612.939781] RIP: 0010:xsk_map_delete_elem+0x2d/0x60<br /> [76612.944738] Code: 00 00 41 54 55 53 48 63 2e 3b 6f 24 73 38 4c 8d a7 f8 00 00 00 48 89 fb 4c 89 e7 e8 2d bf 05 00 48 8d b4 eb 00 01 00 00 31 ff 87 3e 48 85 ff 74 05 e8 16 ff ff ff 4c 89 e7 e8 3e bc 05 00 31<br /> [76612.963774] RSP: 0018:ffffc9002e407df8 EFLAGS: 00010246<br /> [76612.969079] RAX: 0000000000000000 RBX: ffffc9002e461000 RCX: 0000000000000000<br /> [76612.976323] RDX: 0000000000000001 RSI: ffffc8fc2e461108 RDI: 0000000000000000<br /> [76612.983569] RBP: ffffffff80000001 R08: 0000000000000000 R09: 0000000000000007<br /> [76612.990812] R10: ffffc9002e407e18 R11: ffff888108a38858 R12: ffffc9002e4610f8<br /> [76612.998060] R13: ffff888108a38858 R14: 00007ffd1ae0ac78 R15: ffffc9002e4610c0<br /> [76613.005303] FS: 00007f80b6f59740(0000) GS:ffff8897e0ec0000(0000) knlGS:0000000000000000<br /> [76613.013517] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [76613.019349] CR2: ffffc8fc2e461108 CR3: 000000011e3ef001 CR4: 00000000007726f0<br /> [76613.026595] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [76613.033841] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [76613.041086] PKRU: 55555554<br /> [76613.043842] Call Trace:<br /> [76613.046331] <br /> [76613.048468] ? __die+0x20/0x60<br /> [76613.051581] ? page_fault_oops+0x15a/0x450<br /> [76613.055747] ? search_extable+0x22/0x30<br /> [76613.059649] ? search_bpf_extables+0x5f/0x80<br /> [76613.063988] ? exc_page_fault+0xa9/0x140<br /> [76613.067975] ? asm_exc_page_fault+0x22/0x30<br /> [76613.072229] ? xsk_map_delete_elem+0x2d/0x60<br /> [76613.076573] ? xsk_map_delete_elem+0x23/0x60<br /> [76613.080914] __sys_bpf+0x19b7/0x23c0<br /> [76613.084555] __x64_sys_bpf+0x1a/0x20<br /> [76613.088194] do_syscall_64+0x37/0xb0<br /> [76613.091832] entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> [76613.096962] RIP: 0033:0x7f80b6d1e88d<br /> [76613.100592] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48<br /> [76613.119631] RSP: 002b:00007ffd1ae0ac68 EFLAGS: 00000206 ORIG_RAX: 0000000000000141<br /> [76613.131330] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f80b6d1e88d<br /> [76613.142632] RDX: 0000000000000098 RSI: 00007ffd1ae0ad20 RDI: 0000000000000003<br /> [76613.153967] RBP: 00007ffd1ae0adc0 R08: 0000000000000000 R09: 0000000000000000<br /> [76613.166030] R10: 00007f80b6f77040 R11: 0000000000000206 R12: 00007ffd1ae0aed8<br /> [76613.177130] R13: 000055ddf42ce1e9 R14: 000055ddf42d0d98 R15: 00<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw88: use ieee80211_purge_tx_queue() to purge TX skb<br /> <br /> When removing kernel modules by:<br /> rmmod rtw88_8723cs rtw88_8703b rtw88_8723x rtw88_sdio rtw88_core<br /> <br /> Driver uses skb_queue_purge() to purge TX skb, but not report tx status<br /> causing "Have pending ack frames!" warning. Use ieee80211_purge_tx_queue()<br /> to correct this.<br /> <br /> Since ieee80211_purge_tx_queue() doesn&amp;#39;t take locks, to prevent racing<br /> between TX work and purge TX queue, flush and destroy TX work in advance.<br /> <br /> wlan0: deauthenticating from aa:f5:fd:60:4c:a8 by local<br /> choice (Reason: 3=DEAUTH_LEAVING)<br /> ------------[ cut here ]------------<br /> Have pending ack frames!<br /> WARNING: CPU: 3 PID: 9232 at net/mac80211/main.c:1691<br /> ieee80211_free_ack_frame+0x5c/0x90 [mac80211]<br /> CPU: 3 PID: 9232 Comm: rmmod Tainted: G C<br /> 6.10.1-200.fc40.aarch64 #1<br /> Hardware name: pine64 Pine64 PinePhone Braveheart<br /> (1.1)/Pine64 PinePhone Braveheart (1.1), BIOS 2024.01 01/01/2024<br /> pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : ieee80211_free_ack_frame+0x5c/0x90 [mac80211]<br /> lr : ieee80211_free_ack_frame+0x5c/0x90 [mac80211]<br /> sp : ffff80008c1b37b0<br /> x29: ffff80008c1b37b0 x28: ffff000003be8000 x27: 0000000000000000<br /> x26: 0000000000000000 x25: ffff000003dc14b8 x24: ffff80008c1b37d0<br /> x23: ffff000000ff9f80 x22: 0000000000000000 x21: 000000007fffffff<br /> x20: ffff80007c7e93d8 x19: ffff00006e66f400 x18: 0000000000000000<br /> x17: ffff7ffffd2b3000 x16: ffff800083fc0000 x15: 0000000000000000<br /> x14: 0000000000000000 x13: 2173656d61726620 x12: 6b636120676e6964<br /> x11: 0000000000000000 x10: 000000000000005d x9 : ffff8000802af2b0<br /> x8 : ffff80008c1b3430 x7 : 0000000000000001 x6 : 0000000000000001<br /> x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000<br /> x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000003be8000<br /> Call trace:<br /> ieee80211_free_ack_frame+0x5c/0x90 [mac80211]<br /> idr_for_each+0x74/0x110<br /> ieee80211_free_hw+0x44/0xe8 [mac80211]<br /> rtw_sdio_remove+0x9c/0xc0 [rtw88_sdio]<br /> sdio_bus_remove+0x44/0x180<br /> device_remove+0x54/0x90<br /> device_release_driver_internal+0x1d4/0x238<br /> driver_detach+0x54/0xc0<br /> bus_remove_driver+0x78/0x108<br /> driver_unregister+0x38/0x78<br /> sdio_unregister_driver+0x2c/0x40<br /> rtw_8723cs_driver_exit+0x18/0x1000 [rtw88_8723cs]<br /> __do_sys_delete_module.isra.0+0x190/0x338<br /> __arm64_sys_delete_module+0x1c/0x30<br /> invoke_syscall+0x74/0x100<br /> el0_svc_common.constprop.0+0x48/0xf0<br /> do_el0_svc+0x24/0x38<br /> el0_svc+0x3c/0x158<br /> el0t_64_sync_handler+0x120/0x138<br /> el0t_64_sync+0x194/0x198<br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: fix shift-out-of-bounds in dbSplit<br /> <br /> When dmt_budmin is less than zero, it causes errors<br /> in the later stages. Added a check to return an error beforehand<br /> in dbAllocCtl itself.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: array-index-out-of-bounds fix in dtReadFirst<br /> <br /> The value of stbl can be sometimes out of bounds due<br /> to a bad filesystem. Added a check with appopriate return<br /> of error code in that case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath10k: avoid NULL pointer error during sdio remove<br /> <br /> When running &amp;#39;rmmod ath10k&amp;#39;, ath10k_sdio_remove() will free sdio<br /> workqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON<br /> is set to yes, kernel panic will happen:<br /> Call trace:<br /> destroy_workqueue+0x1c/0x258<br /> ath10k_sdio_remove+0x84/0x94<br /> sdio_bus_remove+0x50/0x16c<br /> device_release_driver_internal+0x188/0x25c<br /> device_driver_detach+0x20/0x2c<br /> <br /> This is because during &amp;#39;rmmod ath10k&amp;#39;, ath10k_sdio_remove() will call<br /> ath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release()<br /> will finally be called in ath10k_core_destroy(). This function will free<br /> struct cfg80211_registered_device *rdev and all its members, including<br /> wiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio<br /> workqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.<br /> <br /> After device release, destroy_workqueue() will use NULL pointer then the<br /> kernel panic happen.<br /> <br /> Call trace:<br /> ath10k_sdio_remove<br /> -&gt;ath10k_core_unregister<br /> ……<br /> -&gt;ath10k_core_stop<br /> -&gt;ath10k_hif_stop<br /> -&gt;ath10k_sdio_irq_disable<br /> -&gt;ath10k_hif_power_down<br /> -&gt;del_timer_sync(&amp;ar_sdio-&gt;sleep_timer)<br /> -&gt;ath10k_core_destroy<br /> -&gt;ath10k_mac_destroy<br /> -&gt;ieee80211_free_hw<br /> -&gt;wiphy_free<br /> ……<br /> -&gt;wiphy_dev_release<br /> -&gt;destroy_workqueue<br /> <br /> Need to call destroy_workqueue() before ath10k_core_destroy(), free<br /> the work queue buffer first and then free pointer of work queue by<br /> ath10k_core_destroy(). This order matches the error path order in<br /> ath10k_sdio_probe().<br /> <br /> No work will be queued on sdio workqueue between it is destroyed and<br /> ath10k_core_destroy() is called. Based on the call_stack above, the<br /> reason is:<br /> Only ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and<br /> ath10k_sdio_irq_disable() will queue work on sdio workqueue.<br /> Sleep timer will be deleted before ath10k_core_destroy() in<br /> ath10k_hif_power_down().<br /> ath10k_sdio_irq_disable() only be called in ath10k_hif_stop().<br /> ath10k_core_unregister() will call ath10k_hif_power_down() to stop hif<br /> bus, so ath10k_sdio_hif_tx_sg() won&amp;#39;t be called anymore.<br /> <br /> Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: inet6: do not leave a dangling sk pointer in inet6_create()<br /> <br /> sock_init_data() attaches the allocated sk pointer to the provided sock<br /> object. If inet6_create() fails later, the sk object is released, but the<br /> sock object retains the dangling sk pointer, which may cause use-after-free<br /> later.<br /> <br /> Clear the sock sk pointer on error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: inet: do not leave a dangling sk pointer in inet_create()<br /> <br /> sock_init_data() attaches the allocated sk object to the provided sock<br /> object. If inet_create() fails later, the sk object is freed, but the<br /> sock object retains the dangling pointer, which may create use-after-free<br /> later.<br /> <br /> Clear the sk pointer in the sock object on error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ieee802154: do not leave a dangling sk pointer in ieee802154_create()<br /> <br /> sock_init_data() attaches the allocated sk object to the provided sock<br /> object. If ieee802154_create() fails later, the allocated sk object is<br /> freed, but the dangling pointer remains in the provided sock object, which<br /> may allow use-after-free.<br /> <br /> Clear the sk pointer in the sock object on error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: af_can: do not leave a dangling sk pointer in can_create()<br /> <br /> On error can_create() frees the allocated sk object, but sock_init_data()<br /> has already attached it to the provided sock object. This will leave a<br /> dangling sk pointer in the sock object and may cause use-after-free later.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: RFCOMM: avoid leaving dangling sk pointer in rfcomm_sock_alloc()<br /> <br /> bt_sock_alloc() attaches allocated sk object to the provided sock object.<br /> If rfcomm_dlc_alloc() fails, we release the sk object, but leave the<br /> dangling pointer in the sock object, which may cause use-after-free.<br /> <br /> Fix this by swapping calls to bt_sock_alloc() and rfcomm_dlc_alloc().