Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: battery: Fix possible crash when unregistering a battery hook<br /> <br /> When a battery hook returns an error when adding a new battery, then<br /> the battery hook is automatically unregistered.<br /> However the battery hook provider cannot know that, so it will later<br /> call battery_hook_unregister() on the already unregistered battery<br /> hook, resulting in a crash.<br /> <br /> Fix this by using the list head to mark already unregistered battery<br /> hooks as already being unregistered so that they can be ignored by<br /> battery_hook_unregister().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: fix null-ptr-deref when journal load failed.<br /> <br /> During the mounting process, if journal_reset() fails because of too short<br /> journal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer. <br /> Subsequently, ocfs2_journal_shutdown() calls<br /> jbd2_journal_flush()-&gt;jbd2_cleanup_journal_tail()-&gt;<br /> __jbd2_update_log_tail()-&gt;jbd2_journal_update_sb_log_tail()<br /> -&gt;lock_buffer(journal-&gt;j_sb_buffer), resulting in a null-pointer<br /> dereference error.<br /> <br /> To resolve this issue, we should check the JBD2_LOADED flag to ensure the<br /> journal was properly loaded. Additionally, use journal instead of<br /> osb-&gt;journal directly to simplify the code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: fix array out-of-bound access in SoC stats<br /> <br /> Currently, the ath12k_soc_dp_stats::hal_reo_error array is defined with a<br /> maximum size of DP_REO_DST_RING_MAX. However, the ath12k_dp_rx_process()<br /> function access ath12k_soc_dp_stats::hal_reo_error using the REO<br /> destination SRNG ring ID, which is incorrect. SRNG ring ID differ from<br /> normal ring ID, and this usage leads to out-of-bounds array access. To<br /> fix this issue, modify ath12k_dp_rx_process() to use the normal ring ID<br /> directly instead of the SRNG ring ID to avoid out-of-bounds array access.<br /> <br /> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: don&amp;#39;t readahead the relocation inode on RST<br /> <br /> On relocation we&amp;#39;re doing readahead on the relocation inode, but if the<br /> filesystem is backed by a RAID stripe tree we can get ENOENT (e.g. due to<br /> preallocated extents not being mapped in the RST) from the lookup.<br /> <br /> But readahead doesn&amp;#39;t handle the error and submits invalid reads to the<br /> device, causing an assertion in the scatter-gather list code:<br /> <br /> BTRFS info (device nvme1n1): balance: start -d -m -s<br /> BTRFS info (device nvme1n1): relocating block group 6480920576 flags data|raid0<br /> BTRFS error (device nvme1n1): cannot find raid-stripe for logical [6481928192, 6481969152] devid 2, profile raid0<br /> ------------[ cut here ]------------<br /> kernel BUG at include/linux/scatterlist.h:115!<br /> Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 0 PID: 1012 Comm: btrfs Not tainted 6.10.0-rc7+ #567<br /> RIP: 0010:__blk_rq_map_sg+0x339/0x4a0<br /> RSP: 0018:ffffc90001a43820 EFLAGS: 00010202<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802<br /> RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000<br /> RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8<br /> R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000<br /> FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000002cd11000 CR3: 00000001109ea001 CR4: 0000000000370eb0<br /> Call Trace:<br /> <br /> ? __die_body.cold+0x14/0x25<br /> ? die+0x2e/0x50<br /> ? do_trap+0xca/0x110<br /> ? do_error_trap+0x65/0x80<br /> ? __blk_rq_map_sg+0x339/0x4a0<br /> ? exc_invalid_op+0x50/0x70<br /> ? __blk_rq_map_sg+0x339/0x4a0<br /> ? asm_exc_invalid_op+0x1a/0x20<br /> ? __blk_rq_map_sg+0x339/0x4a0<br /> nvme_prep_rq.part.0+0x9d/0x770<br /> nvme_queue_rq+0x7d/0x1e0<br /> __blk_mq_issue_directly+0x2a/0x90<br /> ? blk_mq_get_budget_and_tag+0x61/0x90<br /> blk_mq_try_issue_list_directly+0x56/0xf0<br /> blk_mq_flush_plug_list.part.0+0x52b/0x5d0<br /> __blk_flush_plug+0xc6/0x110<br /> blk_finish_plug+0x28/0x40<br /> read_pages+0x160/0x1c0<br /> page_cache_ra_unbounded+0x109/0x180<br /> relocate_file_extent_cluster+0x611/0x6a0<br /> ? btrfs_search_slot+0xba4/0xd20<br /> ? balance_dirty_pages_ratelimited_flags+0x26/0xb00<br /> relocate_data_extent.constprop.0+0x134/0x160<br /> relocate_block_group+0x3f2/0x500<br /> btrfs_relocate_block_group+0x250/0x430<br /> btrfs_relocate_chunk+0x3f/0x130<br /> btrfs_balance+0x71b/0xef0<br /> ? kmalloc_trace_noprof+0x13b/0x280<br /> btrfs_ioctl+0x2c2e/0x3030<br /> ? kvfree_call_rcu+0x1e6/0x340<br /> ? list_lru_add_obj+0x66/0x80<br /> ? mntput_no_expire+0x3a/0x220<br /> __x64_sys_ioctl+0x96/0xc0<br /> do_syscall_64+0x54/0x110<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7fcc04514f9b<br /> Code: Unable to access opcode bytes at 0x7fcc04514f71.<br /> RSP: 002b:00007ffeba923370 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fcc04514f9b<br /> RDX: 00007ffeba923460 RSI: 00000000c4009420 RDI: 0000000000000003<br /> RBP: 0000000000000000 R08: 0000000000000013 R09: 0000000000000001<br /> R10: 00007fcc043fbba8 R11: 0000000000000246 R12: 00007ffeba924fc5<br /> R13: 00007ffeba923460 R14: 0000000000000002 R15: 00000000004d4bb0<br /> <br /> Modules linked in:<br /> ---[ end trace 0000000000000000 ]---<br /> RIP: 0010:__blk_rq_map_sg+0x339/0x4a0<br /> RSP: 0018:ffffc90001a43820 EFLAGS: 00010202<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802<br /> RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000<br /> RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8<br /> R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000<br /> FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fcc04514f71 CR3: 00000001109ea001 CR4: 0000000000370eb0<br /> Kernel p<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> l2tp: prevent possible tunnel refcount underflow<br /> <br /> When a session is created, it sets a backpointer to its tunnel. When<br /> the session refcount drops to 0, l2tp_session_free drops the tunnel<br /> refcount if session-&gt;tunnel is non-NULL. However, session-&gt;tunnel is<br /> set in l2tp_session_create, before the tunnel refcount is incremented<br /> by l2tp_session_register, which leaves a small window where<br /> session-&gt;tunnel is non-NULL when the tunnel refcount hasn&amp;#39;t been<br /> bumped.<br /> <br /> Moving the assignment to l2tp_session_register is trivial but<br /> l2tp_session_create calls l2tp_session_set_header_len which uses<br /> session-&gt;tunnel to get the tunnel&amp;#39;s encap. Add an encap arg to<br /> l2tp_session_set_header_len to avoid using session-&gt;tunnel.<br /> <br /> If l2tpv3 sessions have colliding IDs, it is possible for<br /> l2tp_v3_session_get to race with l2tp_session_register and fetch a<br /> session which doesn&amp;#39;t yet have session-&gt;tunnel set. Add a check for<br /> this case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpiolib: Fix potential NULL pointer dereference in gpiod_get_label()<br /> <br /> In `gpiod_get_label()`, it is possible that `srcu_dereference_check()` may<br /> return a NULL pointer, leading to a scenario where `label-&gt;str` is accessed<br /> without verifying if `label` itself is NULL.<br /> <br /> This patch adds a proper NULL check for `label` before accessing<br /> `label-&gt;str`. The check for `label-&gt;str != NULL` is removed because<br /> `label-&gt;str` can never be NULL if `label` is not NULL.<br /> <br /> This fixes the issue where the label name was being printed as `(efault)`<br /> when dumping the sysfs GPIO file when `label == NULL`.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Prevent null pointer access in xe_migrate_copy<br /> <br /> xe_migrate_copy designed to copy content of TTM resources. When source<br /> resource is null, it will trigger a NULL pointer dereference in<br /> xe_migrate_copy. To avoid this situation, update lacks source flag to<br /> true for this case, the flag will trigger xe_migrate_clear rather than<br /> xe_migrate_copy.<br /> <br /> Issue trace:<br /> [317.089847] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 14,<br /> sizes: 4194304 &amp; 4194304<br /> [317.089945] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 15,<br /> sizes: 4194304 &amp; 4194304<br /> [317.128055] BUG: kernel NULL pointer dereference, address:<br /> 0000000000000010<br /> [317.128064] #PF: supervisor read access in kernel mode<br /> [317.128066] #PF: error_code(0x0000) - not-present page<br /> [317.128069] PGD 0 P4D 0<br /> [317.128071] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [317.128074] CPU: 1 UID: 0 PID: 1440 Comm: kunit_try_catch Tainted:<br /> G U N 6.11.0-rc7-xe #1<br /> [317.128078] Tainted: [U]=USER, [N]=TEST<br /> [317.128080] Hardware name: Intel Corporation Lunar Lake Client<br /> Platform/LNL-M LP5 RVP1, BIOS LNLMFWI1.R00.3221.D80.2407291239 07/29/2024<br /> [317.128082] RIP: 0010:xe_migrate_copy+0x66/0x13e0 [xe]<br /> [317.128158] Code: 00 00 48 89 8d e0 fe ff ff 48 8b 40 10 4c 89 85 c8<br /> fe ff ff 44 88 8d bd fe ff ff 65 48 8b 3c 25 28 00 00 00 48 89 7d d0 31<br /> ff 79 10 48 89 85 a0 fe ff ff 48 8b 00 48 89 b5 d8 fe ff ff 83 ff<br /> [317.128162] RSP: 0018:ffffc9000167f9f0 EFLAGS: 00010246<br /> [317.128164] RAX: ffff8881120d8028 RBX: ffff88814d070428 RCX:<br /> 0000000000000000<br /> [317.128166] RDX: ffff88813cb99c00 RSI: 0000000004000000 RDI:<br /> 0000000000000000<br /> [317.128168] RBP: ffffc9000167fbb8 R08: ffff88814e7b1f08 R09:<br /> 0000000000000001<br /> [317.128170] R10: 0000000000000001 R11: 0000000000000001 R12:<br /> ffff88814e7b1f08<br /> [317.128172] R13: ffff88814e7b1f08 R14: ffff88813cb99c00 R15:<br /> 0000000000000001<br /> [317.128174] FS: 0000000000000000(0000) GS:ffff88846f280000(0000)<br /> knlGS:0000000000000000<br /> [317.128176] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [317.128178] CR2: 0000000000000010 CR3: 000000011f676004 CR4:<br /> 0000000000770ef0<br /> [317.128180] DR0: 0000000000000000 DR1: 0000000000000000 DR2:<br /> 0000000000000000<br /> [317.128182] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7:<br /> 0000000000000400<br /> [317.128184] PKRU: 55555554<br /> [317.128185] Call Trace:<br /> [317.128187] <br /> [317.128189] ? show_regs+0x67/0x70<br /> [317.128194] ? __die_body+0x20/0x70<br /> [317.128196] ? __die+0x2b/0x40<br /> [317.128198] ? page_fault_oops+0x15f/0x4e0<br /> [317.128203] ? do_user_addr_fault+0x3fb/0x970<br /> [317.128205] ? lock_acquire+0xc7/0x2e0<br /> [317.128209] ? exc_page_fault+0x87/0x2b0<br /> [317.128212] ? asm_exc_page_fault+0x27/0x30<br /> [317.128216] ? xe_migrate_copy+0x66/0x13e0 [xe]<br /> [317.128263] ? __lock_acquire+0xb9d/0x26f0<br /> [317.128265] ? __lock_acquire+0xb9d/0x26f0<br /> [317.128267] ? sg_free_append_table+0x20/0x80<br /> [317.128271] ? lock_acquire+0xc7/0x2e0<br /> [317.128273] ? mark_held_locks+0x4d/0x80<br /> [317.128275] ? trace_hardirqs_on+0x1e/0xd0<br /> [317.128278] ? _raw_spin_unlock_irqrestore+0x31/0x60<br /> [317.128281] ? __pm_runtime_resume+0x60/0xa0<br /> [317.128284] xe_bo_move+0x682/0xc50 [xe]<br /> [317.128315] ? lock_is_held_type+0xaa/0x120<br /> [317.128318] ttm_bo_handle_move_mem+0xe5/0x1a0 [ttm]<br /> [317.128324] ttm_bo_validate+0xd1/0x1a0 [ttm]<br /> [317.128328] shrink_test_run_device+0x721/0xc10 [xe]<br /> [317.128360] ? find_held_lock+0x31/0x90<br /> [317.128363] ? lock_release+0xd1/0x2a0<br /> [317.128365] ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10<br /> [kunit]<br /> [317.128370] xe_bo_shrink_kunit+0x11/0x20 [xe]<br /> [317.128397] kunit_try_run_case+0x6e/0x150 [kunit]<br /> [317.128400] ? trace_hardirqs_on+0x1e/0xd0<br /> [317.128402] ? _raw_spin_unlock_irqrestore+0x31/0x60<br /> [317.128404] kunit_generic_run_threadfn_adapter+0x1e/0x40 [ku<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/guc_submit: add missing locking in wedged_fini<br /> <br /> Any non-wedged queue can have a zero refcount here and can be running<br /> concurrently with an async queue destroy, therefore dereferencing the<br /> queue ptr to check wedge status after the lookup can trigger UAF if<br /> queue is not wedged. Fix this by keeping the submission_state lock held<br /> around the check to postpone the free and make the check safe, before<br /> dropping again around the put() to avoid the deadlock.<br /> <br /> (cherry picked from commit d28af0b6b9580b9f90c265a7da0315b0ad20bbfd)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name<br /> <br /> It&amp;#39;s observed that a crash occurs during hot-remove a memory device,<br /> in which user is accessing the hugetlb. See calltrace as following:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 1 PID: 14045 at arch/x86/mm/fault.c:1278 do_user_addr_fault+0x2a0/0x790<br /> Modules linked in: kmem device_dax cxl_mem cxl_pmem cxl_port cxl_pci dax_hmem dax_pmem nd_pmem cxl_acpi nd_btt cxl_core crc32c_intel nvme virtiofs fuse nvme_core nfit libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc s<br /> mirror dm_region_hash dm_log dm_mod<br /> CPU: 1 PID: 14045 Comm: daxctl Not tainted 6.10.0-rc2-lizhijian+ #492<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:do_user_addr_fault+0x2a0/0x790<br /> Code: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41<br /> RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046<br /> RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 0000000000000000<br /> RDX: 0000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36<br /> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a57658<br /> R13: 0000000000001000 R14: ffff88800bc2e040 R15: 0000000000000000<br /> FS: 00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? __warn+0x8d/0x190<br /> ? do_user_addr_fault+0x2a0/0x790<br /> ? report_bug+0x1c3/0x1d0<br /> ? handle_bug+0x3c/0x70<br /> ? exc_invalid_op+0x14/0x70<br /> ? asm_exc_invalid_op+0x16/0x20<br /> ? do_user_addr_fault+0x2a0/0x790<br /> ? exc_page_fault+0x31/0x200<br /> exc_page_fault+0x68/0x200<br /> <br /> BUG: unable to handle page fault for address: 0000000000001000<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0<br /> Oops: Oops: 0000 [#1] PREEMPT SMP PTI<br /> ---[ end trace 0000000000000000 ]---<br /> BUG: unable to handle page fault for address: 0000000000001000<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0<br /> Oops: Oops: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 1 PID: 14045 Comm: daxctl Kdump: loaded Tainted: G W 6.10.0-rc2-lizhijian+ #492<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:dentry_name+0x1f4/0x440<br /> <br /> ? dentry_name+0x2fa/0x440<br /> vsnprintf+0x1f3/0x4f0<br /> vprintk_store+0x23a/0x540<br /> vprintk_emit+0x6d/0x330<br /> _printk+0x58/0x80<br /> dump_mapping+0x10b/0x1a0<br /> ? __pfx_free_object_rcu+0x10/0x10<br /> __dump_page+0x26b/0x3e0<br /> ? vprintk_emit+0xe0/0x330<br /> ? _printk+0x58/0x80<br /> ? dump_page+0x17/0x50<br /> dump_page+0x17/0x50<br /> do_migrate_range+0x2f7/0x7f0<br /> ? do_migrate_range+0x42/0x7f0<br /> ? offline_pages+0x2f4/0x8c0<br /> offline_pages+0x60a/0x8c0<br /> memory_subsys_offline+0x9f/0x1c0<br /> ? lockdep_hardirqs_on+0x77/0x100<br /> ? _raw_spin_unlock_irqrestore+0x38/0x60<br /> device_offline+0xe3/0x110<br /> state_store+0x6e/0xc0<br /> kernfs_fop_write_iter+0x143/0x200<br /> vfs_write+0x39f/0x560<br /> ksys_write+0x65/0xf0<br /> do_syscall_64+0x62/0x130<br /> <br /> Previously, some sanity check have been done in dump_mapping() before<br /> the print facility parsing &amp;#39;%pd&amp;#39; though, it&amp;#39;s still possible to run into<br /> an invalid dentry.d_name.name.<br /> <br /> Since dump_mapping() only needs to dump the filename only, retrieve it<br /> by itself in a safer way to prevent an unnecessary crash.<br /> <br /> Note that either retrieving the filename with &amp;#39;%pd&amp;#39; or<br /> strncpy_from_kernel_nofault(), the filename could be unreliable.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: avoid to add interface to list twice when SER<br /> <br /> If SER L2 occurs during the WoWLAN resume flow, the add interface flow<br /> is triggered by ieee80211_reconfig(). However, due to<br /> rtw89_wow_resume() return failure, it will cause the add interface flow<br /> to be executed again, resulting in a double add list and causing a kernel<br /> panic. Therefore, we have added a check to prevent double adding of the<br /> list.<br /> <br /> list_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628.<br /> ------------[ cut here ]------------<br /> kernel BUG at lib/list_debug.c:37!<br /> invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W O 6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7<br /> Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 06/24/2021<br /> Workqueue: events_freezable ieee80211_restart_work [mac80211]<br /> RIP: 0010:__list_add_valid_or_report+0x5e/0xb0<br /> Code: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 00 00 0f 0b 48 c7 c7 c8 bc 12<br /> RSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246<br /> RAX: 0000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900<br /> RDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001<br /> RBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0<br /> R10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060<br /> R13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010<br /> FS: 0000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0<br /> Call Trace:<br /> <br /> ? __die_body+0x1f/0x70<br /> ? die+0x3d/0x60<br /> ? do_trap+0xa4/0x110<br /> ? __list_add_valid_or_report+0x5e/0xb0<br /> ? do_error_trap+0x6d/0x90<br /> ? __list_add_valid_or_report+0x5e/0xb0<br /> ? handle_invalid_op+0x30/0x40<br /> ? __list_add_valid_or_report+0x5e/0xb0<br /> ? exc_invalid_op+0x3c/0x50<br /> ? asm_exc_invalid_op+0x16/0x20<br /> ? __list_add_valid_or_report+0x5e/0xb0<br /> rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f]<br /> drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc]<br /> ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc]<br /> ? finish_wait+0x3e/0x90<br /> ? synchronize_rcu_expedited+0x174/0x260<br /> ? sync_rcu_exp_done_unlocked+0x50/0x50<br /> ? wake_bit_function+0x40/0x40<br /> ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc]<br /> process_scheduled_works+0x1e5/0x480<br /> worker_thread+0xea/0x1e0<br /> kthread+0xdb/0x110<br /> ? move_linked_works+0x90/0x90<br /> ? kthread_associate_blkcg+0xa0/0xa0<br /> ret_from_fork+0x3b/0x50<br /> ? kthread_associate_blkcg+0xa0/0xa0<br /> ret_from_fork_asm+0x11/0x20<br /> <br /> Modules linked in: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydev<br /> gsmi: Log Shutdown Reason 0x03<br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk_iocost: fix more out of bound shifts<br /> <br /> Recently running UBSAN caught few out of bound shifts in the<br /> ioc_forgive_debts() function:<br /> <br /> UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38<br /> shift exponent 80 is too large for 64-bit type &amp;#39;u64&amp;#39; (aka &amp;#39;unsigned long<br /> long&amp;#39;)<br /> ...<br /> UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30<br /> shift exponent 80 is too large for 64-bit type &amp;#39;u64&amp;#39; (aka &amp;#39;unsigned long<br /> long&amp;#39;)<br /> ...<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xca/0x130<br /> __ubsan_handle_shift_out_of_bounds+0x22c/0x280<br /> ? __lock_acquire+0x6441/0x7c10<br /> ioc_timer_fn+0x6cec/0x7750<br /> ? blk_iocost_init+0x720/0x720<br /> ? call_timer_fn+0x5d/0x470<br /> call_timer_fn+0xfa/0x470<br /> ? blk_iocost_init+0x720/0x720<br /> __run_timer_base+0x519/0x700<br /> ...<br /> <br /> Actual impact of this issue was not identified but I propose to fix the<br /> undefined behaviour.<br /> The proposed fix to prevent those out of bound shifts consist of<br /> precalculating exponent before using it the shift operations by taking<br /> min value from the actual exponent and maximum possible number of bits.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: PAD: fix crash in exit_round_robin()<br /> <br /> The kernel occasionally crashes in cpumask_clear_cpu(), which is called<br /> within exit_round_robin(), because when executing clear_bit(nr, addr) with<br /> nr set to 0xffffffff, the address calculation may cause misalignment within<br /> the memory, leading to access to an invalid memory address.<br /> <br /> ----------<br /> BUG: unable to handle kernel paging request at ffffffffe0740618<br /> ...<br /> CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G OE X --------- - - 4.18.0-425.19.2.el8_7.x86_64 #1<br /> ...<br /> RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad]<br /> Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31<br /> RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202<br /> RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246<br /> RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8<br /> R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000e<br /> R13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000e<br /> FS: 0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> ? acpi_pad_add+0x120/0x120 [acpi_pad]<br /> kthread+0x10b/0x130<br /> ? set_kthread_struct+0x50/0x50<br /> ret_from_fork+0x1f/0x40<br /> ...<br /> CR2: ffffffffe0740618<br /> <br /> crash&gt; dis -lr ffffffffc0726923<br /> ...<br /> /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 114<br /> 0xffffffffc0726918 : mov %r12d,%r12d<br /> /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 325<br /> 0xffffffffc072691b : mov -0x3f8d7de0(,%r12,4),%eax<br /> /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 80<br /> 0xffffffffc0726923 : lock btr %rax,0x19cf4(%rip) # 0xffffffffc0740620 <br /> <br /> crash&gt; px tsk_in_cpu[14]<br /> $66 = 0xffffffff<br /> <br /> crash&gt; px 0xffffffffc072692c+0x19cf4<br /> $99 = 0xffffffffc0740620<br /> <br /> crash&gt; sym 0xffffffffc0740620<br /> ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad]<br /> <br /> crash&gt; px pad_busy_cpus_bits[0]<br /> $42 = 0xfffc0<br /> ----------<br /> <br /> To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before calling<br /> cpumask_clear_cpu() in exit_round_robin(), just as it is done in<br /> round_robin_cpu().<br /> <br /> [ rjw: Subject edit, avoid updates to the same value ]