summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-10-14Merge tag 'qcom-clk-for-7.4-2' of ↵Jerome Brunet
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into clk-qcom Qualcomm clock updates for v7.4 (second attempt) Add new clock support for Eliza, Kuno, MSM8952, Nord, Hawi, Maili, and IPQ5210. Rework common probe and CX power-domain handling. Add generic subsystem-init helpers and clean up the initcall setup. - Add camera, camera BIST, GPU, and video clock controllers for Eliza, and complete the Milos camera and video power-domain bindings. - Add Nord camera and video clocks, video AXI and QUSB2 PHY resets, EMAC interconnect clocks, and the corrected GCC GPLL enable offset. - Add Hawi camera and GPU clock controllers, extend them for Maili, and correct the camera Rivian PLL configuration. - Add global and RPMh clock controllers for Kuno. - Add the MSM8952 global clock controller and RPM clock binding. - Extend the IPQ common PLL driver with all IPQ5210 networking clock outputs, divider flags, and safe bounds handling. - Add IPQ9650 NoC clock management through the interconnect framework, add 24 MHz USB UTMI rates for three IPQ SoCs, and correct IPQ5018 and IPQ5424 clock and reset handling. - Add QCS8300 TSCSS clocks and resets, SM7250 RPMh clocks, and Glymur LNBB clocks. - Model GCC CX power-domain dependencies and runtime PM across the affected application, compute, and modem platforms. - Move always-on clock and GCC initialization into common Qualcomm probe handling across 47 camera, display, GPU, video, audio, and global clock controller drivers. - Add generic subsys_driver and subsys_platform_driver helpers, then convert the Qualcomm and Renesas clock drivers to use them. - Fix shared RCG initialization, status error propagation, and cleanup after failed rate changes. - Correct clock and reset register offsets for SM6115, QCS615, MSM8996, SDM660, and IPQ5424. - Correct APQ8064 PLL15 setup, MSM8939 Venus GDSC flags, SM8450 display clock ops, Glymur clock IDs and UFS mux ops, X1E80100 USB4 polling, and Lucid Ole PLL status handling. - Split out the X1E80100 TCSR binding and use the clk_ref helper, merge SM7150 into the SM6375 GCC binding, sort the Nord Kconfig entries, and migrate the SM8450 display controller to common driver data. - Add Abel Vesa as a reviewer for Qualcomm clock drivers.
2026-10-14ALSA: usb-audio: Use fixed control index for us16x08 mixer elementsTakashi Iwai
The callbacks for us16x08 mixer elements assume that id.index points to the channel to be operated, and the assumption is correct for now. However, since the kctls are added via snd_usb_mixer_add_control() and it looks for the empty slot if the same control name is already present, in theory, the index can become more than the channel numbers (if a conflicting name really happens). Since the mixer code in us16x08 doesn't need the search for an empty slot but requires the fixed index, this patch changes slightly how to assign the kcontrols. Now, a new argument is added to snd_usb_mixer_add_list() in order to disable the empty slot search, and use it in us16x08's add_new_ctl() helper function, instead. Fixes: d2bb390a2081 ("ALSA: usb-audio: Tascam US-16x08 DSP mixer quirk") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20261014061406.162938-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-10-14ALSA: seq: oss: Prevent duplicate MIDI device teardownCen Zhang
Each OSS MIDI alias and its coder must have one final-release owner. find_slot() pins the alias under register_lock, but snd_seq_oss_midi_check_exit_port() clears its slot in a separate critical section without checking whether another callback already removed it. The use counter protects active users, but draining it does not elect a single remover. This requires overlapping raw kernel-client port controls for the same client. snd_seq_kernel_client_ctl() does not take ioctl_mutex, and snd_seq_delete_port() releases ports_mutex before returning to the DELETE_PORT handler's PORT_EXIT broadcast. If the old deletion is delayed before that broadcast, a new port can reuse the vacant address. Its PORT_START finds and keeps the old alias. Deleting the replacement then produces a second PORT_EXIT for the same address. Non-atomic subscriber delivery holds a read rwsem, so the two receive_announce() callbacks can run concurrently: Old-port deletion Replacement-port controls ----------------- ------------------------- Unlink and drain old port Delay before PORT_EXIT Create port at the same address PORT_START keeps existing alias Delete port; PORT_EXIT pins mdev PORT_EXIT pins the same mdev Clear slot; drop pin Clear slot; drop pin Wait for users to drain Wait for users to drain Free coder; pause before kfree(mdev) Free coder again: read freed coder->buf Both callbacks can select the same alias before either clears its slot. After both drop their pins, both waits can return. The second call to snd_midi_event_free() can then read the freed coder's buffer pointer, as in the report below, and attempt to release the same objects twice. Check that the pinned alias still occupies its slot under register_lock before clearing it. A callback that finds it already removed drops its pin and returns. Only the callback that removes the alias drains users and frees the coder and record. The pin keeps the record alive through this check, and the wait remains outside the spinlock. KASAN report as below: ================================================================== BUG: KASAN: slab-use-after-free in snd_midi_event_free+0x53/0x60 Read of size 8 at addr ffff888107074518 by task alsa-seq-fixtur/492 CPU: 3 UID: 0 PID: 492 Comm: alsa-seq-fixtur Not tainted 7.2.0-rc6-pmb-bt-functional-v1+ #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x93/0xd0 print_report+0xce/0x630 ? snd_midi_event_free+0x53/0x60 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x20d/0x410 ? snd_midi_event_free+0x53/0x60 kasan_report+0xe0/0x110 ? snd_midi_event_free+0x53/0x60 snd_midi_event_free+0x53/0x60 snd_seq_oss_midi_check_exit_port+0x1d8/0x370 receive_announce+0x1b8/0x370 ? __pfx_receive_announce+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __lock_acquire+0x466/0x2260 ? snd_seq_port_use_ptr+0x40/0x170 ? srso_alias_return_thunk+0x5/0xfbef5 ? find_held_lock+0x2b/0x80 ? snd_seq_port_use_ptr+0x10c/0x170 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_release+0xc8/0x280 ? srso_alias_return_thunk+0x5/0xfbef5 ? __pfx_receive_announce+0x10/0x10 __snd_seq_deliver_single_event+0x105/0x1a0 ? snd_seq_port_use_ptr+0x111/0x170 snd_seq_deliver_single_event+0x2fc/0x770 ? __pfx_snd_seq_deliver_single_event+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __pfx_down_read_nested+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_raw_read_unlock+0x49/0xe0 ? srso_alias_return_thunk+0x5/0xfbef5 ? _raw_read_unlock+0x23/0x40 snd_seq_deliver_event+0x351/0x760 ? __pfx_snd_seq_deliver_event+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x44/0x60 ? trace_hardirqs_on+0x18/0x160 ? srso_alias_return_thunk+0x5/0xfbef5 ? _raw_spin_unlock_irqrestore+0x44/0x60 ? srso_alias_return_thunk+0x5/0xfbef5 snd_seq_kernel_client_dispatch+0x13f/0x170 snd_seq_system_broadcast+0x100/0x150 ? __pfx_snd_seq_system_broadcast+0x10/0x10 ? mark_held_locks+0x40/0x70 ? _raw_spin_unlock_irqrestore+0x44/0x60 ? srso_alias_return_thunk+0x5/0xfbef5 ? lockdep_hardirqs_on_prepare+0xea/0x1a0 ? srso_alias_return_thunk+0x5/0xfbef5 snd_seq_ioctl_delete_port+0x179/0x4b0 call_seq_client_ctl+0x90/0x110 snd_seq_kernel_client_ctl+0x8a/0x100 pmbd_case_delete_port+0xa6/0xf0 ? __pfx_pmbd_case_delete_port+0x10/0x10 ? __might_fault+0xdd/0x190 ? srso_alias_return_thunk+0x5/0xfbef5 ? __might_fault+0x14e/0x190 ? srso_alias_return_thunk+0x5/0xfbef5 ? strim+0x19c/0x200 pmbd_case_control_write+0x2c5/0x470 ? __pfx_pmbd_case_control_write+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __debugfs_file_get+0x1bd/0x7f0 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_acquire+0x17b/0x2f0 ? ksys_write+0x111/0x200 full_proxy_write+0x11f/0x180 vfs_write+0x25a/0x1010 ? __pfx_full_proxy_write+0x10/0x10 ? __pfx___mutex_lock+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_acquire+0x17b/0x2f0 ? __pfx_vfs_write+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? __fget_files+0x1e1/0x370 ksys_write+0x111/0x200 ? __pfx_ksys_write+0x10/0x10 ? rseq_register.isra.0+0x1f3/0x2e0 ? srso_alias_return_thunk+0x5/0xfbef5 ? exit_to_user_mode_loop+0x3a5/0x570 ? srso_alias_return_thunk+0x5/0xfbef5 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f3532e4e9ee Code: 08 0f 85 f5 4b ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 80 00 00 00 00 48 83 ec 08 RSP: 002b:00007f3532dafe08 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007f3532db06c0 RCX: 00007f3532e4e9ee RDX: 000000000000000a RSI: 000055efbd747156 RDI: 0000000000000003 RBP: 000055efbd747156 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000a R13: 0000000000000000 R14: 00007ffe7894e7f0 R15: 00007f35325b0000 </TASK> Allocated by task 490: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kmalloc_cache_noprof+0x251/0x610 snd_midi_event_new+0x74/0x210 snd_seq_oss_midi_check_new_port+0x329/0x610 receive_announce+0x277/0x370 __snd_seq_deliver_single_event+0x105/0x1a0 snd_seq_deliver_single_event+0x2fc/0x770 snd_seq_deliver_event+0x351/0x760 snd_seq_kernel_client_dispatch+0x13f/0x170 snd_seq_system_broadcast+0x100/0x150 snd_seq_ioctl_create_port+0x39a/0x9d0 call_seq_client_ctl+0x90/0x110 snd_seq_kernel_client_ctl+0x8a/0x100 pmbd_case_create_port+0xcc/0x160 pmbd_case_control_write+0x21d/0x470 full_proxy_write+0x11f/0x180 vfs_write+0x25a/0x1010 ksys_write+0x111/0x200 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 493: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x307/0x580 snd_midi_event_free+0x48/0x60 snd_seq_oss_midi_check_exit_port+0x1d8/0x370 receive_announce+0x1b8/0x370 __snd_seq_deliver_single_event+0x105/0x1a0 snd_seq_deliver_single_event+0x2fc/0x770 snd_seq_deliver_event+0x351/0x760 snd_seq_kernel_client_dispatch+0x13f/0x170 snd_seq_system_broadcast+0x100/0x150 snd_seq_ioctl_delete_port+0x179/0x4b0 call_seq_client_ctl+0x90/0x110 snd_seq_kernel_client_ctl+0x8a/0x100 pmbd_case_delete_port+0xa6/0xf0 pmbd_case_control_write+0x398/0x470 full_proxy_write+0x11f/0x180 vfs_write+0x25a/0x1010 ksys_write+0x111/0x200 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The buggy address belongs to the object at ffff888107074500 which belongs to the cache kmalloc-96 of size 96 The buggy address is located 24 bytes inside of freed 96-byte region [ffff888107074500, ffff888107074560) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x107074 flags: 0x200000000000000(node=0|zone=2) page_type: f5(slab) raw: 0200000000000000 ffff888100042280 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000200020 00000000f5000000 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888107074400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff888107074480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff888107074500: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888107074580: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ffff888107074600: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ================================================================== Assisted-by: LLM Signed-off-by: Cen Zhang <zzzccc427@gmail.com> Link: https://patch.msgid.link/pm-pmb-7c5128efe2110a87b872-v2-c718183fd693e73d8e95@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-10-14wifi: nxpwifi: use str_on_off() for carrier stateAryan Sinha
Both carrier prints open code the on/off ternary. Use the helper from string_choices.h instead. No change in output. Signed-off-by: Aryan Sinha <sinha.aryan03@gmail.com> Signed-off-by: Jeff Chen <jeff.chen_1@nxp.com>
2026-10-14wifi: nxpwifi: return timeout error from nxpwifi_sdio_poll_card_status()Karl Mehltretter
nxpwifi_sdio_poll_card_status() returns the result of the last register read when polling times out. If the final register read succeeds, the timeout is incorrectly reported as success. Return -ETIMEDOUT when polling runs out of retries. Fixes: 73b01e57ed3e ("wifi: nxp: add nxpwifi driver for IW61x") Assisted-by: LLM Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Signed-off-by: Jeff Chen <jeff.chen_1@nxp.com>
2026-10-14ALSA: emux: Guard the OSS argument during port initializationCen Zhang
The OSS argument must be non-NULL before reset_port_mode() writes its event_passing field. snd_emux_open_seq_oss() assigns p->oss_arg only after snd_emux_create_port() attaches the writable sequencer port, so this field is still NULL when the callback first becomes reachable. With sequencer OSS and an EMUX provider enabled, another sequencer client can learn the new address from a PORT_START announcement and send a direct SNDRV_SEQ_EVENT_OSS channel-mode command, with marker 0xfe and command byte 0x8a. The following ordering is possible: OSS opener Sequencer writer snd_emux_create_port() snd_seq_event_port_attach() publish port, announce receive PORT_START snd_seq_write() snd_emux_event_oss_input() reset_port_mode() write via NULL oss_arg p->oss_arg = arg The callback's write precedes the opener's assignment. The core's port reference keeps the private data allocated but does not wait for its initialization. The write therefore dereferences NULL and can panic the kernel, as shown by the report below. Take a single READ_ONCE() snapshot of oss_arg and update event_passing only when that snapshot is non-NULL. Pair it with WRITE_ONCE() in the open path, so the check and write use the same pointer despite concurrent initialization. The open path still sets the initial mode after assigning the argument, and subsequent channel-mode events retain their existing handling. KASAN report as below: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] CPU: 2 UID: 0 PID: 495 Comm: fixture Tainted: G O 7.2.0-rc6-pmb-bt-functional-v1+ #1 PREEMPT(lazy) Tainted: [O]=OOT_MODULE Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:snd_emux_event_oss_input+0xa76/0xdd0 Code: fc ff df 48 c1 ea 03 80 3c 02 00 0f 85 e1 02 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 5d 78 48 8d 7b 18 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 40 03 00 00 c7 43 18 00 00 00 RSP: 0018:ffff88810a937888 EFLAGS: 00010216 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff84f391b2 RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000018 RBP: ffff8881179fc000 R08: 0000000000000001 R09: 0000000000000001 R10: ffffffff89444257 R11: ffff888107dd3a00 R12: 1ffff11021526f17 R13: 0000000000000000 R14: 0000000000000001 R15: ffff888112cda000 FS: 00007fdd13c9f780(0000) GS:ffff8881fd826000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fdd13e2f943 CR3: 00000001057ba005 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <TASK> ? __pfx_snd_emux_event_oss_input+0x10/0x10 ? snd_seq_port_use_ptr+0x40/0x170 ? srso_alias_return_thunk+0x5/0xfbef5 ? find_held_lock+0x2b/0x80 ? snd_seq_port_use_ptr+0x10c/0x170 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_release+0xc8/0x280 ? srso_alias_return_thunk+0x5/0xfbef5 ? __pfx_snd_emux_event_oss_input+0x10/0x10 __snd_seq_deliver_single_event+0x105/0x1a0 ? snd_seq_port_use_ptr+0x111/0x170 snd_seq_deliver_single_event+0x2fc/0x770 ? __pfx_snd_seq_deliver_single_event+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? add_lock_to_list+0x9d/0x1e0 ? srso_alias_return_thunk+0x5/0xfbef5 ? check_prev_add+0x34c/0xe80 snd_seq_deliver_event+0x45a/0x760 ? __pfx_snd_seq_deliver_event+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_acquire+0x17b/0x2f0 snd_seq_client_enqueue_event.constprop.0+0x278/0x430 ? __pfx_snd_seq_client_enqueue_event.constprop.0+0x10/0x10 ? __might_fault+0xdd/0x190 ? srso_alias_return_thunk+0x5/0xfbef5 ? __might_fault+0x14e/0x190 ? _raw_spin_unlock_irq+0x28/0x50 snd_seq_write+0x30a/0x5e0 ? __pfx_snd_seq_write+0x10/0x10 ? selinux_file_permission+0x122/0x570 ? srso_alias_return_thunk+0x5/0xfbef5 ? security_file_permission+0x26/0x80 vfs_write+0x25a/0x1010 ? __pfx_snd_seq_write+0x10/0x10 ? __pfx_vfs_write+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? trace_hardirqs_on+0x18/0x160 ? srso_alias_return_thunk+0x5/0xfbef5 ? __call_rcu_common.constprop.0+0x5c1/0xbd0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __fput+0x5ba/0xa60 ksys_write+0x1b7/0x200 ? __pfx_ksys_write+0x10/0x10 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fdd13d31687 Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff RSP: 002b:00007fff073e9f20 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fdd13c9f780 RCX: 00007fdd13d31687 RDX: 000000000000001c RSI: 00007fff073e9fc0 RDI: 0000000000000003 RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 0000561260c48082 R13: 0000561260c48011 R14: 0000561260c4809d R15: 0000000000000002 </TASK> Modules linked in: snd_emux_validation(O) ---[ end trace 0000000000000000 ]--- RIP: 0010:snd_emux_event_oss_input+0xa76/0xdd0 Code: fc ff df 48 c1 ea 03 80 3c 02 00 0f 85 e1 02 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 5d 78 48 8d 7b 18 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 40 03 00 00 c7 43 18 00 00 00 RSP: 0018:ffff88810a937888 EFLAGS: 00010216 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff84f391b2 RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000018 RBP: ffff8881179fc000 R08: 0000000000000001 R09: 0000000000000001 R10: ffffffff89444257 R11: ffff888107dd3a00 R12: 1ffff11021526f17 R13: 0000000000000000 R14: 0000000000000001 R15: ffff888112cda000 FS: 00007fdd13c9f780(0000) GS:ffff8881fd826000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fdd13e2f943 CR3: 00000001057ba005 CR4: 0000000000770ef0 PKRU: 55555554 Kernel panic - not syncing: Fatal exception Kernel Offset: disabled Rebooting in 1 seconds.. Assisted-by: LLM Signed-off-by: Cen Zhang <zzzccc427@gmail.com> Link: https://patch.msgid.link/pm-pmb-f8d6ccb28f196910444f-v2-c253bf022b6e954a7bdc@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-10-14ALSA: vmaster: Serialize hook registration with control callbacksCen Zhang
An HDA virtual-master hook must have its private argument initialized before a control callback can invoke it. snd_hda_add_vmaster_hook() installs the trampoline through snd_ctl_add_vmaster_hook(), which stores master->hook before master->hook_private_data without serialization. When a codec with a vmaster mute hook binds to an already registered card, snd_hda_gen_build_controls() publishes and initializes the Master Playback Switch before installing the hook. A native write that changes the switch can then run in the following order: 1. The codec bind path publishes and initializes the master control in __snd_hda_add_vmaster(), then calls snd_hda_add_vmaster_hook(). 2. The hook setter stores master->hook, but has not yet stored its private argument. 3. SNDRV_CTL_IOCTL_ELEM_WRITE takes controls_rwsem and calls master_put() while the setter remains between those stores. 4. master_put() sees the callback and invokes vmaster_hook() with a NULL argument. The trampoline dereferences it before the setter can complete publication. The write lock held by snd_ctl_elem_write() does not exclude the hook setter, so this can cause a NULL pointer dereference. Take the same controls_rwsem for writing inside snd_ctl_add_vmaster_hook() so the callback and its argument are installed together with respect to native control callbacks. Pass the card into the helper and update the HDA caller, keeping the lock in the ALSA core. Release it when registration returns, before the caller synchronizes the hook. KASAN report as below: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 UID: 0 PID: 499 Comm: alsa-vmaster-tr Not tainted 7.2.0-rc6-pmb-bt-functional-v1+ #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:vmaster_hook+0x35/0xb0 Code: f5 53 48 89 fb 48 83 ec 08 e8 57 f0 9a fc eb 50 e8 50 f0 9a fc 48 8d 7b 08 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 59 48 8d 7b 10 48 8b 43 08 48 ba 00 00 00 00 00 fc RSP: 0018:ffff888117647cd0 EFLAGS: 00010212 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff84e9ff50 RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000008 RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000001 R10: ffffffff89427457 R11: ffff888115ad1d00 R12: ffffffff84e9ff30 R13: ffff888114943ca0 R14: 0000000000000000 R15: 0000000000000001 FS: 00007fe8167b3780(0000) GS:ffff88826b7e3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000557c8c2842a8 CR3: 000000011579f005 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <TASK> master_put+0x20e/0x2b0 snd_ctl_elem_write+0x37f/0x5e0 snd_ctl_ioctl+0x997/0xdd0 ? __pfx_snd_ctl_ioctl+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? selinux_file_ioctl+0xaa/0x280 ? __pfx_snd_ctl_ioctl+0x10/0x10 __x64_sys_ioctl+0x163/0x1d0 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe8168c291b Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1c 48 8b 44 24 18 64 48 2b 04 25 28 00 00 RSP: 002b:00007fffab0cb150 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fe8168c291b RDX: 00007fffab0cb310 RSI: 00000000c4c85513 RDI: 0000000000000003 RBP: 00007fffab0cb310 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007fffab0cb1c0 R14: 0000000000000001 R15: 0000557c4f71fd10 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- Fixes: ee52e56e7b12 ("ALSA: hda - Fix mute-LED fixed mode") Signed-off-by: Cen Zhang <zzzccc427@gmail.com> Assisted-by: LLM Link: https://patch.msgid.link/pm-pmb-c2667fb9cc42fbb7943c-v4-b7bc2fe90e950accb3f7@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-10-14ALSA: hda/realtek: keep headset mic on Acer SSID 0x1640Iván Ezequiel Rodriguez
The micmute-LED quirk for the Aspire A315-44P matches PCI SSID 1025:1640 before the Acer ALC256 pin fallback. The Aspire Go 15 AG15-42P shares that SSID and leaves nid 0x19 as 0x411111f0, so selecting the LED-only fixup drops the headset-mic pin remap that the fallback would have applied. Chain ALC2XX_FIXUP_HEADSET_MIC before the GPIO3 micmute LED on that SSID. Leave the Swift SFG16 entry (0x169a) unchanged. Tested on Acer Aspire AG15-42P (Callisto_BCU): PCI pick 1025:1640, Headset Mic=0x19, GPIO3 enabled with no physical micmute LED, speaker and capture paths functional. Fixes: d830631a128b ("ALSA: hda/realtek: Add micmute LED quirk for Acer Aspire A315-44P") Cc: stable@vger.kernel.org Signed-off-by: Iván Ezequiel Rodriguez <ivanrwcm25@gmail.com> Link: https://patch.msgid.link/20261013204219.9649-1-ivanrwcm25@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-10-14ALSA: line6: Use kzalloc() for PCM buffer allocationTakashi Iwai
LINE6 driver allocates the PCM buffer via kmalloc(), and this might leave some bytes uninitialized that are out of the actual ring buffer size, while it's still exposed via mmap. For avoiding the leak of the uninitialized kernel memory, simply replace it with kzalloc(). Fixes: 705ececd1c60 ("Staging: add line6 usb driver") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20261013120528.52586-5-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-10-14ALSA: pcm: Protect delay DMA sync in forward and rewind, tooTakashi Iwai
Like the previous fix for snd_pcm_delay() (in the commit 50f413b83b31 "ALSA: pcm: Protect delay DMA sync against concurrent HW_FREE"), the snd_pcm_dma_buffer_sync() call in snd_pcm_forward() and snd_pcm_rewind() needs the similar protection against the concurrent hw_free action for avoiding potential UAFs. Fixes: a25684a95646 ("ALSA: memalloc: Support for non-contiguous page allocation") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20261013120528.52586-4-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-10-14PCI: ultrarisc: Skip MEM outbound iATU setup on DP1000Xincheng Zhang
DP1000 has 16 outbound iATU windows and each window can map up to 4GB. One window is used for CFG accesses, one for I/O space and one for the 32-bit MEM aperture, leaving only 13 windows for the 64-bit MEM aperture. This limits the 64-bit MEM aperture that can be described with outbound iATU windows. DP1000 routes MEM transactions without using outbound iATU windows, so skip generic DWC MEM outbound iATU setup to allow a larger 64-bit MEM aperture. DP1000 does not use ECAM for this controller. Config space accesses keep using the normal DWC config access path and CFG outbound iATU programming. I/O space is also unchanged and still uses an outbound iATU window. The new flag only skips generic MEM-window programming. The DP1000 integration has SoC wrapper address decode for the PCIe MEM apertures described by the "ranges" property. CPU physical accesses to those MEM apertures are routed directly as PCIe MEM transactions with the corresponding PCIe bus address, without consuming outbound iATU windows. Set 'dw_pcie_rp->bypass_ob_mem_iatu' for this controller. Signed-off-by: Xincheng Zhang <zhangxincheng@ultrarisc.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260905025635.211390-3-zhangxincheng@ultrarisc.com
2026-10-14ALSA: jack: Fix kctl free at error in snd_jack_kctl_new()Takashi Iwai
When an error happens in snd_jack_kctl_new(), it tries to free the new kcontrol element via snd_ctl_free_one(). But snd_ctl_free_one() releases only the memories, and the internal linked list and hash entries still remain, which may lead to bogus accesses to user. Replace with the correct destructor, snd_ctl_remove(), for clearing the whole resources of the given kcontrol, instead. Fixes: 9058cbe1eed2 ("ALSA: jack: implement kctl creating for jack devices") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20261013120528.52586-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-10-14PCI: dwc: Allow drivers to skip MEM outbound iATU setupXincheng Zhang
Some DWC-based controllers do not require outbound iATU windows for MEM transactions. For those platforms, programming outbound iATU windows for host bridge MEM ranges is unnecessary and may constrain the available MEM aperture. The DWC PCIe RP Controller Databook v6.00a, section 3.12.2, describes the default outbound no-match behavior as pass-through. Section 3.12.5.6, "No Address Match Result", says the address is not translated and programmable TLP header fields come from the application transmit interface. This no-match path cannot translate between different parent-bus and PCI addresses, so require skipped MEM ranges to be identity-mapped. Add dw_pcie_rp->bypass_ob_mem_iatu so drivers can skip generic MEM iATU setup while using the common DWC host init path. Existing drivers keep the current behavior because the flag defaults to false. The I/O iATU setup does not use the MEM resource iterator, and the iterator may be uninitialized when MEM setup is skipped. Avoid using it in the I/O iATU error path. Signed-off-by: Xincheng Zhang <zhangxincheng@ultrarisc.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260905025635.211390-2-zhangxincheng@ultrarisc.com
2026-10-14ALSA: pcm: Fix driver_tstamp value reportingAmadeusz Sławiński
In some cases (system32 and compat64) due to incorrect assignment wrong value is being reported. Fix it. Fixes: 3ddee7f88aaf ("ALSA: Avoid using timespec for struct snd_pcm_status") Signed-off-by: Amadeusz Sławiński <amade@asmblr.net> Link: https://patch.msgid.link/20261013164256.4949-1-amade@asmblr.net Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-10-14accel/ivpu: Extend tile fuse config to 7 bitsKarol Wachowski
The buttress code that reads the tile fuse register is shared by all generations, so the register field definition should not differ between them. Extend the TILE_CONFIG mask from [6:1] to [7:1] and use it everywhere, instead of having a different field width per generation. The tile count range check in tile_disable_check() depended on the previous field width. It only logs a warning, and it would now warn on a valid value, so drop it together with the tile count defines it used. Reviewed-by: Dawid Osuchowski <dawid.osuchowski@linux.intel.com> Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com> Link: https://patch.msgid.link/20261012083802.2778448-6-karol.wachowski@linux.intel.com
2026-10-14accel/ivpu: Merge buttress register headersKarol Wachowski
Put the MTL and LNL buttress registers in a single header, like the IP registers. No register shares its offset between MTL and LNL, so the MTL ones are simply followed by the LNL ones. Also fix the DUP_IDLE typo (should be DPU_IDLE). No functional change. Reviewed-by: Dawid Osuchowski <dawid.osuchowski@linux.intel.com> Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com> Link: https://patch.msgid.link/20261012083802.2778448-5-karol.wachowski@linux.intel.com
2026-10-14accel/ivpu: Merge identical 37xx and 40xx IP functionsKarol Wachowski
With a single register header, many 37xx and 40xx functions became identical, including the IRQ handler. Keep one copy of each and call the IRQ handler directly instead of through a function pointer. No functional change. Reviewed-by: Dawid Osuchowski <dawid.osuchowski@linux.intel.com> Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com> Link: https://patch.msgid.link/20261012083802.2778448-4-karol.wachowski@linux.intel.com
2026-10-14accel/ivpu: Merge NPU IP register headersKarol Wachowski
Most registers in the 37xx and 40xx IP headers are the same, with only the prefix differing, which forces a lot of code to be duplicated per generation. Merge them into ivpu_hw_ip_reg.h. Each register is defined once with the prefix of the first generation that has it. New or changed fields use the prefix of the generation that introduced them. The CPU_SS registers that moved in 40xx are defined right below the 37xx ones. This leaves some 37xx and 40xx code paths identical, which the next patch merges. No functional change. Reviewed-by: Dawid Osuchowski <dawid.osuchowski@linux.intel.com> Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com> Link: https://patch.msgid.link/20261012083802.2778448-3-karol.wachowski@linux.intel.com
2026-10-14accel/ivpu: Add test mode to enable the FREQ_CHANGE interruptKarol Wachowski
The buttress FREQ_CHANGE interrupt is not enabled by the driver, but there is no way to turn it on for testing and debugging. Store the buttress interrupt mask in struct ivpu_hw_info, so it is set up once during HW info initialization instead of being a compile time constant, and use it everywhere the mask is needed. Add the IVPU_TEST_MODE_FREQ_CHANGE_ENABLE test mode that adds FREQ_CHANGE to this mask. No functional change with the test mode disabled. Reviewed-by: Dawid Osuchowski <dawid.osuchowski@linux.intel.com> Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com> Link: https://patch.msgid.link/20261012083802.2778448-2-karol.wachowski@linux.intel.com
2026-10-14accel/ivpu: Cache FW API version and simplify API check macrosKarol Wachowski
Copy the API version array from the firmware image header into struct ivpu_fw_info while the header is being parsed, and use the cached copy afterwards. This way the raw firmware image header is only accessed during image parsing, which is a step towards releasing the firmware image once it has been loaded. Since the API version is now available in vdev->fw before the compatibility checks run, drop the redundant fw_hdr parameter from IVPU_FW_CHECK_API_COMPAT(), IVPU_FW_CHECK_API_VER_LT() and the helpers behind them, as well as from ivpu_fw_sched_mode_select(). Also make DRM_IVPU_PARAM_FW_API_VERSION read the cached copy instead of dereferencing the firmware image directly. No functional change. Co-developed-by: Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com> Signed-off-by: Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com> Reviewed-by: Dawid Osuchowski <dawid.osuchowski@linux.intel.com> Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com> Link: https://patch.msgid.link/20261012080933.2771862-1-karol.wachowski@linux.intel.com
2026-10-14ALSA: hda/tas2781: Skip invalid TAS2563 UEFI calibration dataGergo Koteles
Some Lenovo 14ARB7 laptops do not have proper calibration data. Skip these zero calibration values and fall back to the calibration data provided by the DSP firmware. Tested-by: Georg Wenzel <g.wenzel@gmail.com> Fixes: c3ca4458cc2f ("ALSA: hda/tas2781: add TAS2563 support for 14ARB7") Cc: stable@vger.kernel.org # 6.18 Signed-off-by: Gergo Koteles <soyer@irl.hu> Tested-by: Philipp Oster <philippdev5396@outlook.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/12a1ab265a1dc0e3a062a54287c8ef48682c4efc.1791895478.git.soyer@irl.hu
2026-10-14ALSA: hda/tas2781: Assign total_sz at the end of the functionGergo Koteles
In the tas2563_save_calibration() function, cd->total_sz is assigned in several error paths. Move the assignment to the end of the function. Fixes: b6016332b889 ("ALSA: hda/tas2781: clear cali_data.total_sz when calibration read fails") Cc: stable@vger.kernel.org # 6.18 Signed-off-by: Gergo Koteles <soyer@irl.hu> Tested-by: Philipp Oster <philippdev5396@outlook.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/4b357778dce1b70a647e7e47b5ab3f0a6b2fc0cc.1791895478.git.soyer@irl.hu
2026-10-14Revert "ALSA: hda/tas2781: Enable bass speakers support"Takashi Iwai
This reverts commit 3bc4fc135ec741c5657cba6b2300bf8bf81179d2. The problem will be addressed in a more proper way later. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-10-14PCI: imx6: Use dev_err_probe() in error path of pci_pwrctrl_power_on_devices()Alexander Stein
pci_pwrctrl_power_on_devices() might return -EPROBE_DEFER resulting in an error message. Use dev_err_probe() to silence this non-error message. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260619112535.1127850-1-alexander.stein@ew.tq-group.com
2026-10-13tmpfs: fix unicode_map leaks in casefold option handlingKazuki Hanai
shmem_parse_opt_casefold() stores the unicode_map returned by utf8_load() in ctx->encoding. A filesystem context can receive the casefold parameter more than once, and a second successful parse overwrites the stored map without releasing it. The map is also leaked when an unmounted filesystem context is freed. This includes the temporary context used for remount, because shmem_reconfigure() does not take ownership of ctx->encoding. Reject a second casefold setting, clear ctx->encoding after transferring ownership to the superblock, and release any remaining map from shmem_free_fc(). An unprivileged user can repeatedly create tmpfs filesystem contexts, set the casefold parameter, and close them from a user namespace. This causes unbounded kernel memory consumption and can result in a local denial of service. Link: https://lore.kernel.org/20261002081306.637148-1-hnkz.64@gmail.com Fixes: 58e55efd6c72 ("tmpfs: Add casefold lookup support") Signed-off-by: Kazuki Hanai <hnkz.64@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Suggested-by: Gabriel Krisman Bertazi <gabriel@krisman.be> Cc: Hugh Dickins <hughd@google.com> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: André Almeida <andrealmeid@igalia.com> Cc: Christian Brauner <brauner@kernel.org> Cc: <stable@vger.kernel.org>
2026-10-13watchdog/perf: one digit too short in the raw event config copyBradley Morgan
Commit 6164be01f179 ("watchdog/perf: optimize bytes copied and remove manual NUL-termination") swapped strscpy(buf, str, sizeof(buf)) plus a manual buf[len] = 0 for strscpy(buf, str, len), and that count is one short. strscpy() keeps the last byte of the destination for the NUL, so the config loses its final digit, nmi_watchdog=r300,panic for example ends up with buf = "30" and arms the raw event with the wrong config. The empty case falls over too, strscpy() with a zero count writes nothing at all, so nmi_watchdog=r,1 leaves buf uninitialized and kstrtoull() reads whatever stack garbage is sitting there. The old code was safe on both by accident, it filled the whole buffer first and buf[len] = 0 then stomped the comma position, so the worst you got was a truncated parse failure. Pass len + 1 so the copy includes the character the NUL replaces, and reject len >= sizeof(buf) like it was before the optimization, which also turns an empty config back into a clean parse failure. Link: https://lore.kernel.org/20261003110200.3-brads@mainlining.org Fixes: 6164be01f179 ("watchdog/perf: optimize bytes copied and remove manual NUL-termination") Signed-off-by: Bradley Morgan <brads@mainlining.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Cc: Thorsten Blum <blum@kernel.org> Cc: Thomas Gleixner <tglx@kernel.org>
2026-10-13kcov: report spurious PCs in the interrupt selftestKarl Mehltretter
The KCOV interrupt selftest enables KCOV_MODE_TRACE_PC without a coverage area so that spurious coverage causes a fault. If the fault path is instrumented, the coverage callback faults recursively. Observed failure modes include a stack overflow on x86_64 and arm32 getting stuck in abort handling, neither of which identifies the original coverage event. The recursive failure is not new, but commit 9a79524d1420 ("kcov: use WRITE_ONCE() for selftest mode stores") made the selftest effective on configurations where the compiler had previously removed the mode store, exposing it more broadly. Replace the open-coded kcov_mode stores with kcov_start() and kcov_stop(), passing a 16-word buffer that records up to 15 spurious PCs, with the first word holding the count. Keep KCOV enabled for the original 300 ms window, then disable it, print all recorded PCs and panic if any were recorded. Once the buffer fills, further PCs are discarded by the existing coverage callback. This preserves the selftest's hard failure while avoiding the recursive fault path. Add decanonicalize_ip() as the inverse of canonicalize_ip(), which subtracts kaslr_offset() from recorded PCs. Restore that offset before printing the PCs with %pB, since KCOV records return addresses. Link: https://lore.kernel.org/20261002181357.14293-1-kmehltretter@gmail.com Fixes: 6cd0dd934b03 ("kcov: Add interrupt handling self test") Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Tested-by: Alexander Potapenko <glider@google.com> Reviewed-by: Alexander Potapenko <glider@google.com> Tested-by: Bradley Morgan <brads@mainlining.org> # Power10 Reviewed-by: Bradley Morgan <brads@mainlining.org> Assisted-by: LLM Cc: Andrey Konovalov <andreyknvl@gmail.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Marco Elver <elver@google.com> Cc: Bradley Morgan <include@grrlz.net> Cc: Thomas Gleixner <tglx@kernel.org>
2026-10-13kbuild: move GCOV flags to scripts/Makefile.gcovKonstantin Khorenko
* split the CFLAGS_GCOV block out of the top-level Makefile into scripts/Makefile.gcov * include it via include-$(CONFIG_GCOV_KERNEL) like neighbour KASAN/KCOV/UBSAN makefiles do * keep the include before scripts/Makefile.gcc-plugins: the try-run must not get -fplugin= options, plugins do not exist on clean builds CFLAGS_GCOV is no longer defined when CONFIG_GCOV_KERNEL is off: * its user in scripts/Makefile.lib is guarded by the CONFIG_GCOV_KERNEL * in i915/xe header an empty value is harmless The try-run compiler invocations also stop running on builds without GCOV. Link: https://lore.kernel.org/20261001-b4-prep-gcov-v1-2-794792e06f24@virtuozzo.com Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Suggested-by: Peter Oberparleiter <oberpar@linux.ibm.com> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Nicolas Schier <nsc@kernel.org> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Mikhail Zaslonko <zaslonko@linux.ibm.com>
2026-10-13kbuild: use $(CFLAGS_GCOV) in the prefer-atomic try-run testKonstantin Khorenko
Patch series "kbuild: GCOV cleanups following the prefer-atomic fix". Two cleanups Peter Oberparleiter suggested while reviewing commit 56cb9b7d96b2 ("gcov: use atomic counter updates to fix concurrent access crashes"): https://lore.kernel.org/e1b6e768-51af-468b-a729-0ed3fceef2f1@linux.ibm.com Patch 1 makes the prefer-atomic try-run test reuse $(CFLAGS_GCOV) instead of spelling the flags out again, so the test compiles with the exact GCOV flags, -fno-tree-loop-im included. Patch 2 moves the CFLAGS_GCOV block into scripts/Makefile.gcov, included via include-$(CONFIG_GCOV_KERNEL) like the other instrumentation makefiles. The try-run also stops running on builds without GCOV. This patch (of 2): Reference $(CFLAGS_GCOV) in the try-run test introduced by commit 56cb9b7d96b2 ("gcov: use atomic counter updates to fix concurrent access crashes"), otherwise it can miss potential future changes in the list of flags used for GCOV profiling like it misses -fno-tree-loop-im at the moment. The outcome of the test is unchanged: -fno-tree-loop-im does not affect the undefined symbols the test compares. Link: https://lore.kernel.org/20261001-b4-prep-gcov-v1-0-794792e06f24@virtuozzo.com Link: https://lore.kernel.org/20261001-b4-prep-gcov-v1-1-794792e06f24@virtuozzo.com Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Suggested-by: Peter Oberparleiter <oberpar@linux.ibm.com> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Nicolas Schier <nsc@kernel.org> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Mikhail Zaslonko <zaslonko@linux.ibm.com>
2026-10-13init: simplify initramfs.o build ruleYuntao Wang
CONFIG_BLK_DEV_INITRD is known to be enabled in the else branch, so there is no need to use obj-$(CONFIG_BLK_DEV_INITRD). Use obj-y directly to make the build rule clearer. Also, reorder the condition to make the code easier to follow. No functional change. Link: https://lore.kernel.org/20260930015748.311366-1-yuntao.wang@linux.dev Signed-off-by: Yuntao Wang <yuntao.wang@linux.dev> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Nicolas Schier <nsc@kernel.org> Cc: Nathan Chancellor <nathan@kernel.org>
2026-10-13resource, kunit: stop selecting GET_FREE_REGIONKarl Mehltretter
RESOURCE_KUNIT_TEST selects GET_FREE_REGION even when no other option needs it. Remove the selection to follow the dependency rule in Documentation/dev-tools/kunit/style.rst. Skip resource_test_region_intersects() when GET_FREE_REGION is disabled. GET_FREE_REGION has no prompt, so configurations without a production consumer cannot enable it. Most configurations will therefore skip this case; this is intentional. The union and intersection tests remain available. Since kunit_skip() does not return, the compiler drops the reference to the unavailable alloc_free_mem_region(), as in the CONFIG_OF_ADDRESS check in drivers/of/of_test.c. Link: https://lore.kernel.org/20260926002651.87267-1-kmehltretter@gmail.com Fixes: 99185c10d5d9 ("resource, kunit: add test case for region_intersects()") Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Bradley Morgan <brads@mainlining.org> Tested-by: Bradley Morgan <brads@mainlining.org> # Power10 Assisted-by: LLM Cc: Ying Huang <huang.ying.caritas@gmail.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Brendan Higgins <brendan.higgins@linux.dev> Cc: David Gow <david@davidgow.net> Cc: Rae Moar <raemoar63@gmail.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2026-10-13kdev_t: shift in dev_t in MKDEV()Matthias Goergens
MKDEV(ma, mi) evaluates ((ma) << MINORBITS) in whatever type the caller passes, usually int. For majors >= 2048 (legal: majors go up to 4095) the result exceeds INT_MAX, which C11 leaves undefined for a signed left shift; shifting a negative ma is undefined regardless of the major's value. In practice, on the compilers and two's complement targets the kernel supports, both cases wrap to the intended bit pattern; this patch makes the macro well defined regardless by casting the major to dev_t before shifting. For major and minor numbers in range, the device number it produces is unchanged. isofs feeds the Rock Ridge 'PN' entry's dev_high and dev_low into MKDEV() while holding them in int variables (fs/isofs/rock.c), so a crafted image can drive this exact shift. Fixing the macro covers every caller instead of just that one. Link: https://lore.kernel.org/20260927224958.508964-1-matthias.goergens@gmail.com Signed-off-by: Matthias Goergens <matthias.goergens@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Jan Kara <jack@suse.cz> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-10-13kselftest/filelock: plan for the five ofdlocks testsDanish Khateeb
ofdlocks reports five results but plans for four, so even when they all pass it ends with # Planned tests != run tests (4 != 5) and exits with KSFT_FAIL, which run_kselftest.sh reports as a failure. Link: https://lore.kernel.org/20260925205502.115327-1-danishkhateeb03@gmail.com Fixes: 33d5b13098fb ("kselftest/filelock: report each test in oftlocks separately") Signed-off-by: Danish Khateeb <danishkhateeb03@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Assisted-by: LLM Cc: Shuah Khan <shuah@kernel.org> Cc: Mark Brown <broonie@kernel.org> Cc: Jeff Layton <jlayton@kernel.org>
2026-10-13checkpatch: don't flag ACQUIRE_ERR() assignments in if conditionsGuixin Liu
ACQUIRE_ERR() and its wrappers, PM_RUNTIME_ACQUIRE_ERR() and IIO_DEV_ACQUIRE_FAILED(), report whether a conditional cleanup.h guard was acquired, and drivers consume the result directly in an if condition: if ((rc = ACQUIRE_ERR(mutex_intr, &lock))) return rc; That combined form is the established style at the 49 in-tree call sites under drivers/cxl and drivers/pci/tsm.c, so ASSIGN_IN_IF fires there only as a false positive, and every patch touching those lines carries noise that reviewers have to wave off manually. Skip the check only when every assignment in the condition assigns the result of such a call, matched by the *_ACQUIRE_ERR() / *_ACQUIRE_FAILED() naming convention of its wrappers. Plain assignments, mixed conditions and near-miss identifiers still get flagged. Link: https://lore.kernel.org/20260924033923.4140210-1-kanie@linux.alibaba.com Signed-off-by: Guixin Liu <kanie@linux.alibaba.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Suggested-by: Alison Schofield <alison.schofield@intel.com> Acked-by: Joe Perches <joe@perches.com> Assisted-by: LLM Cc: Andy Whitcroft <apw@canonical.com> Cc: Jonathan Cameron <jic23@kernel.org>
2026-10-13ocfs2/cluster: hold a reference on the heartbeat threadKarl Mehltretter
Since commit 688bc88e2046 ("ocfs2/cluster: keep heartbeat local node stable"), o2hb_thread() leaves its loop and returns when the local node changes, for example after "echo 0 > node/<name>/local". The thread was started with kthread_run() and nothing holds a reference to its task_struct, so the task is freed once it exits, while reg->hr_task still points to it. Reading the region's pid attribute then reads the freed task, and removing the region calls kthread_stop() on it: BUG: KASAN: slab-use-after-free in o2hb_region_pid_show+0xb3/0xc0 refcount_t: addition on 0; use-after-free. Oops: Oops: 0000 [#1] SMP KASAN NOPTI RIP: 0010:kthread_stop+0xb1/0x390 The thread could already return by itself before, when heartbeat start was aborted or on an unclean stop, but the local node change makes it reachable from userspace at any time. Create the thread, take a reference on it and only then wake it, so the reference cannot race with the thread exiting. Drop it with kthread_stop_put(). Link: https://lore.kernel.org/20260923010149.14391-1-kmehltretter@gmail.com Fixes: 688bc88e2046 ("ocfs2/cluster: keep heartbeat local node stable") Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/patchset/20260616074931.3774929-1-zzzccc427%40gmail.com Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com> Assisted-by: LLM Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Cen Zhang <zzzccc427@gmail.com> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Heming Zhao <heming.zhao@suse.com>
2026-10-13ocfs2: fix array out of bound access in __ocfs2_find_path()Giorgi Kobakhia
__ocfs2_find_path() walks down the extent tree and records path by calling find_path_ins(), which appends entry to path->p_node[]. It only has 5 spots. A corrupted ocfs2 image whose extent block is pointing to itself causes __ocfs2_find_path() descent endlessly, writing past the end of path->p_node[] array. UBSAN: array-index-out-of-bounds in fs/ocfs2/alloc.c:677:14 index 5 is out of range for type 'ocfs2_path_item [5]' Call Trace: <TASK> find_path_ins (fs/ocfs2/alloc.c:677 fs/ocfs2/alloc.c:1914) __ocfs2_find_path.constprop.0 (fs/ocfs2/alloc.c:1882) ocfs2_commit_truncate (fs/ocfs2/alloc.c:1924 fs/ocfs2/alloc.c:7286) ocfs2_truncate_file (fs/ocfs2/file.c:515) ocfs2_setattr (fs/ocfs2/file.c:1224) notify_change (fs/attr.c:556) do_truncate (fs/open.c:68) do_ftruncate (fs/open.c:194 (discriminator 1)) ksys_ftruncate (fs/open.c:206) __x64_sys_ftruncate (fs/open.c:211 fs/open.c:209 fs/open.c:209) Commit a406aff8c051 ("ocfs2: validate l_tree_depth to avoid out-of-bounds access") already restricts el->l_tree_depth to be less than OCFS2_MAX_PATH_DEPTH, which is equal to 5. However, does not handle the infinite descent case. Check if the el->l_tree_depth decreases on each descent. Maximum descents are restricted to 4 and the path->p_node[] array does not overflow. Link: https://lore.kernel.org/20260922202159.2421642-1-gkobakhi@asu.edu Fixes: dcd0538ff4e8 ("ocfs2: sparse b-tree support") Signed-off-by: Giorgi Kobakhia <gkobakhi@asu.edu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Tested-by: Xiang Mei <xmei5@asu.edu> Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com> Assisted-by: LLM Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: <stable@vger.kernel.org>
2026-10-13ocfs2: validate chunk and block counts of the local quota fileNguyen Ngoc Thang
ocfs2_local_read_info() trusts dqi_chunks and dqi_blocks from the local quota file header. If dqi_blocks is too small, ocfs2_extend_local_quota_file() computes a bogus chunk length, extends the file, and maps logical block dqi_blocks, which is already in the inode's metadata cache (the header or a chunk header read at mount). sb_getblk() returns that cached buffer and ocfs2_set_new_buffer_uptodate() hits BUG_ON(ocfs2_buffer_cached()): kernel BUG at fs/ocfs2/uptodate.c:509! ocfs2_extend_local_quota_file+0x45c/0x1100 ocfs2_create_local_dquot+0x8ac/0xb50 ocfs2_acquire_dquot+0x614/0xae0 ocfs2_get_init_inode+0xe9/0x1b0 ocfs2_mkdir+0x174/0x430 ocfs2_local_quota_add_chunk() has the same exposure. Reject a header whose counts don't fit the chunk layout or exceed i_size. Reproduced with a crafted image (dqi_blocks = 1, chunk 0 dqc_free = 0); syzbot has no reproducer for this report. Link: https://lore.kernel.org/20260920140710.43938-1-ngocthang2710.1999@gmail.com Fixes: 9e33d69f553a ("ocfs2: Implementation of local and global quota file handling") Signed-off-by: Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reported-by: syzbot+03aaa576f1daa1c1f2f0@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=03aaa576f1daa1c1f2f0 Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com> Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Heming Zhao <heming.zhao@suse.com>
2026-10-13ocfs2: fix possible deadlock between nfs_sync_rwlock and fs_reclaimJoseph Qi
syzbot detected a circular locking dependency on &osb->nfs_sync_rwlock: CPU0 CPU1 ---- ---- lock(fs_reclaim); lock(&ocfs2_sysfile_lock_key[INODE_ALLOC_SYSTEM_INODE]); lock(fs_reclaim); rlock(&osb->nfs_sync_rwlock); *** DEADLOCK *** Chain exists of: &osb->nfs_sync_rwlock --> &ocfs2_sysfile_lock_key[INODE_ALLOC_SYSTEM_INODE] --> fs_reclaim CPU0 is kswapd. The dentry shrinker runs under fs_reclaim and reaches ocfs2_delete_inode() through ->evict_inode(): kswapd balance_pgdat shrink_node shrink_slab super_cache_scan prune_dcache_sb shrink_dentry_list dentry_kill ocfs2_dentry_iput evict ocfs2_evict_inode ocfs2_delete_inode ocfs2_nfs_sync_lock down_read(&osb->nfs_sync_rwlock) //C0: grabbing CPU1 is a task deleting an inode. It takes nfs_sync_rwlock first, then the orphan dir and inode alloc system inode i_rwsems, and allocates the metadata reservation with GFP_KERNEL while holding them: evict ocfs2_evict_inode ocfs2_delete_inode + ocfs2_nfs_sync_lock | down_read(&osb->nfs_sync_rwlock) //C1: hold + ocfs2_wipe_inode + inode_lock(orphan_dir_inode) //C1: hold + ocfs2_truncate_for_delete | ocfs2_commit_truncate | ocfs2_remove_btree_range | ocfs2_reserve_blocks_for_rec_trunc | ocfs2_reserve_new_metadata_blocks | kzalloc_obj() //C1: grabbing | // GFP_KERNEL -> might_alloc -> fs_reclaim_acquire + ocfs2_remove_inode inode_lock(inode_alloc_inode) jbd2 pins allocations to GFP_NOFS for the lifetime of a transaction handle, but these reservations are made before ocfs2_start_trans(), so fs_reclaim is acquired with ocfs2 locks still held and the cycle closes. The same cycle is reachable from ocfs2_get_dentry() and ocfs2_get_parent(), which hold nfs_sync_rwlock for write across ocfs2_test_inode_bit() and ocfs2_iget(). This is more than a lockdep artifact. A GFP_KERNEL allocation under the orphan dir i_rwsem enters direct reclaim, which runs the shrinkers, which can evict another ocfs2 inode and re-enter ocfs2_wipe_inode() on the same task; the second inode_lock() on the singleton orphan dir inode then self-deadlocks, since i_rwsem is not recursive. Establish a GFP_NOFS allocation context for the whole nfs_sync_rwlock critical section so that nothing holding it can recurse into filesystem reclaim. Do it in ocfs2_nfs_sync_lock()/ocfs2_nfs_sync_unlock() rather than at the call sites, so that future callers cannot forget it. Link: https://lore.kernel.org/20260922093437.954127-1-joseph.qi@linux.alibaba.com Fixes: 6ca497a83e59 ("ocfs2: fix rare stale inode errors when exporting via nfs") Signed-off-by: Joseph Qi <joseph.qi@linux.alibaba.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reported-by: syzbot+a68ce48df87b8e36e915@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=a68ce48df87b8e36e915 Cc: Heming Zhao <heming.zhao@suse.com> Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com>
2026-10-13ocfs2: restore -ERANGE check in ocfs2_xattr_tree_list_index_block()Joseph Qi
ocfs2_xattr_list_entry() returns -ERANGE when the buffer handed in by the caller is too small to hold the whole xattr name list. That is the normal listxattr(2) protocol, userspace simply retries with a larger buffer, so it is not an ocfs2 error and must not be logged as one. Commit a46fa684fcb700 ("ocfs2: Don't printk the error when listing too many xattrs.") already knew this and silenced two sites, quoting (27738,0):ocfs2_iterate_xattr_buckets:3158 ERROR: status = -34 (27738,0):ocfs2_xattr_tree_list_index_block:3264 ERROR: status = -34 The refactoring in commit 47bca4950bc40f ("ocfs2: Abstract ocfs2 xattr tree extend rec iteration process.") then rewrote ocfs2_xattr_tree_list_index_block() around the new ocfs2_iterate_xattr_index_block() helper and dropped that guard, so the second message has been emitted ever since: ocfs2_xattr_tree_list_index_block:4513 ERROR: status = -34 The exemption in ocfs2_iterate_xattr_buckets() survived because that function was left alone, and the new helper does check for -ERANGE itself, which is why only the outermost caller still logs it. Restore the missing check. Only the log line changes: -ERANGE is still returned to the VFS untouched, so listxattr(2) behaves exactly as before. Link: https://lore.kernel.org/20260922094252.971631-1-joseph.qi@linux.alibaba.com Signed-off-by: Joseph Qi <joseph.qi@linux.alibaba.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Cc: Heming Zhao <heming.zhao@suse.com> Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com>
2026-10-13init/main.c: remove unreachable check in obsolete_checksetup()Sang-Heon Jeon
Since commit 1ecfea06386c ("init.h: remove long-dead __setup_null_param() macro"), .init.setup entries cannot have a NULL setup_func. So remove the NULL check. No functional change. Link: https://lore.kernel.org/20260922132630.177941-1-ekffu200098@gmail.com Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-10-13percpu_counter: annotate lockless read in _limited_add()Jose A. Perez de Azpillaga
syzbot reports a data race on fbc->count between the lockless read in the fast path of __percpu_counter_limited_add() and the locked update in percpu_counter_add_batch(), reached via shmem's used_blocks counter: the alloc path reads it through percpu_counter_limited_add() while the free path updates it through percpu_counter_sub(). Annotate the read rather than change the logic: the lockless read is deliberate, only the annotation is missing. It is an approximation, not a conservative bound. A concurrent flush moves value between fbc->count and a per-cpu counter, and other CPUs' locked slow paths add to fbc->count too, so a stale low value can let the fast path proceed where the slow path would refuse. The error is bounded by the per-cpu slack (unknown = batch * num_online_cpus()). This is existing behavior, no functional change intended. Read it with data_race(READ_ONCE(fbc->count)): data_race() tells KCSAN the race is intended (READ_ONCE() alone still triggers the report, because KCSAN reports against watchpoints set up by plain accesses), while READ_ONCE() stops the compiler from refetching the value, as in percpu_counter_read_positive(). The lock-protected accesses stay plain, so future buggy lockless writes are still caught. Link: https://lore.kernel.org/20260921215508.141641-1-azpijr@gmail.com Signed-off-by: Jose A. Perez de Azpillaga <azpijr@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reported-by: syzbot+a3c71b9db9c11c270f59@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=a3c71b9db9c11c270f59 Reviewed-by: Andrew Morton <akpm@linux-foundation.org> Cc: Dennis Zhou <dennis@kernel.org> Cc: Tejun Heo <tj@kernel.org> Cc: Christoph Lameter <cl@gentwo.org> Cc: Hugh Dickins <hughd@google.com> Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
2026-10-13rapidio: use dmaengine_get_dma_device() instead of chan->device->devFrank Li
Replace direct dma_chan::device::dev access with the proper dmaengine_get_dma_device() for consumer API. chan->device->dev is not always the device used for DMA mapping. Some DMA engines support per-channel IOMMU mappings, so different channels may use different DMA devices. dmaengine_get_dma_device() returns the correct device for each channel. This also prepares for making the DMA engine provider data structures private. DMA consumers should not access DMA engine internals directly. Link: https://lore.kernel.org/20260917205016.1293317-1-Frank.Li@oss.nxp.com Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Assisted-by: LLM Cc: Alexandre Bounine <alex.bou9@gmail.com> Cc: Dan Carpenter <error27@gmail.com> Cc: Kees Cook <kees@kernel.org> Cc: Matt Porter <mporter@kernel.crashing.org> Cc: Vinod Koul <vkoul@kernel.org>
2026-10-13kcov: ignore an out-of-range comparison count in write_comp_data()Fang Xieyan
write_comp_data() reads the comparison record count from area[0] and uses it to index the coverage buffer: area = (u64 *)t->kcov_area; max_pos = t->kcov_size * sizeof(unsigned long); count = READ_ONCE(area[0]); /* Every record is KCOV_WORDS_PER_CMP 64-bit words. */ start_index = 1 + count * KCOV_WORDS_PER_CMP; end_pos = (start_index + KCOV_WORDS_PER_CMP) * sizeof(u64); if (likely(end_pos <= max_pos)) { The buffer is mmap'd writable into the collecting process, so count is under its control and end_pos <= max_pos is its only bound. A count that wraps the u64 multiply leaves end_pos below max_pos, so the check passes while the record store lands 24 bytes before the buffer, in the unmapped vmalloc guard page, and faults: BUG: unable to handle page fault for address: ffa0000000b60fe8 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page Oops: 0002 [#1] SMP KASAN NOPTI RIP: 0010:write_comp_data+0x7e/0xa0 ... Kernel panic - not syncing: Fatal exception Bound count first: only max_pos / (sizeof(u64) * KCOV_WORDS_PER_CMP) records fit, so a larger count is not a valid index and is dropped. kcov_move_area() bounds the same untrusted count this way, and no count the end_pos <= max_pos check accepts reaches that limit, so no valid record is lost. kcov is a root-only debugfs file (debugfs_create_file_unsafe("kcov", 0600, ...)) and write_comp_data() exists only under CONFIG_KCOV_ENABLE_COMPARISONS, so this is a local, debug-kernel robustness fix: the process corrupts its own buffer and the kernel oopses. It crosses no privilege boundary. Additional details at [1] Link: https://lore.kernel.org/20260917104306.22145-1-fangxy@xiaopeng.com [1] Fixes: ded97d2c2b2c ("kcov: support comparison operands collection") Signed-off-by: Fang Xieyan <fangxy@xiaopeng.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Alexander Potapenko <glider@google.com> Assisted-by: Hawkeye:GLM-5.3-flash Assisted-by: Qoder:Qwen3.8-Max Cc: Andrey Konovalov <andreyknvl@gmail.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Marco Elver <elver@google.com> Cc: Victor Chibotaru <tchibo@google.com> Cc: <stable@vger.kernel.org>
2026-10-13ocfs2: retain all security xattrs during inode creationJoseph Qi
When creating a new inode, ocfs2_init_security_get() stores the security xattr returned by the LSM framework in ocfs2_security_xattr_info so that it can be written later within the same transaction. But ocfs2_initxattrs() only ever looks at the first element of the xattr array, and it keeps the name as a bare pointer into memory owned by the security layer instead of copying it. The value, by contrast, is already duplicated with kmemdup(). With stacked LSMs, security_inode_init_security() provides one xattr per LSM, so all labels but the first are silently dropped and never written to disk, leaving newly created files without the security xattrs the other LSMs rely on. The borrowed name is not an outright bug with the LSMs in tree today: security_inode_init_security() frees only ->value once the callback returns, and documents ->name as the attribute name suffix, so the pointer stays valid for as long as ocfs2 uses it. It is fragile though, as an LSM that allocates the name together with the value would turn it into a use-after-free, so the rework below copies the names as well. Fix this by storing copies of all the security xattrs: allocate an array in ocfs2_initxattrs(), copy the names and values, account for all of them in the credit calculations, and write each one in ocfs2_init_security_set(). While at it, switch the allocations from GFP_KERNEL to GFP_NOFS. The callback runs in the inode creation path with the parent directory locked, and the security layer allocates the very same xattr array with GFP_NOFS, so direct reclaim must not be allowed to recurse into the filesystem from here. Link: https://lore.kernel.org/20260917014825.678947-1-joseph.qi@linux.alibaba.com Fixes: de3004c874e7 ("ocfs2: Switch to security_inode_init_security()") Signed-off-by: Joseph Qi <joseph.qi@linux.alibaba.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Changwei Ge <gechangwei@live.cn> Cc: Jun Piao <piaojun@huawei.com> Cc: Heming Zhao <heming.zhao@suse.com>
2026-10-13ocfs2: update xattr count before moving bucket entriesSu Yue
Since commit 2f26f58df041 ("ocfs2: annotate flexible array members with __counted_by_le()"), the xh_entries array is annotated with __counted_by_le(xh_count), so FORTIFY uses xh_count to determine its bounds. When inserting an entry into a bucket, ocfs2_xa_bucket_add_entry() shifts existing entries before incrementing xh_count. The destination therefore extends one entry past the bounds described by the old count. With CONFIG_CC_HAS_COUNTED_BY and CONFIG_FORTIFY_SOURCE enabled, ocfs2-test: single_run-WIP.sh -t reflink triggers the following failure while adding an extended attribute: [ 150.156484] memmove: detected buffer overflow: 352 byte write of buffer size 336 [ 150.156487] WARNING: lib/string_helpers.c:1036 at __fortify_report+0x3d/0x50, CPU#15: reflink_test/2336 [ 150.160496] RIP: 0010:__fortify_report+0x40/0x50 [ 150.164031] Call Trace: [ 150.164141] <TASK> [ 150.164232] __fortify_panic+0x9/0xb [ 150.164383] ocfs2_xa_bucket_add_entry.cold+0x17/0x28 [ocfs2] [ 150.164661] ocfs2_xa_set+0x8fb/0xf40 [ocfs2] Increment xh_count before memmove() so the destination bounds include the new entry. Keep the local count unchanged to calculate the insertion position and move length from the original number of entries. The caller has already checked that there is enough space for the new entry. Link: https://lore.kernel.org/20260916024750.9450-1-glass.su@suse.com Fixes: 2f26f58df041 ("ocfs2: annotate flexible array members with __counted_by_le()") Signed-off-by: Su Yue <glass.su@suse.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Heming Zhao <heming.zhao@suse.com> Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com> Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Changwei Ge <gechangwei@live.cn> Cc: Jun Piao <piaojun@huawei.com> Cc: <stable@vger.kernel.org>
2026-10-13lib: decompress_bunzip2: fix integer overflow in run-length decodingAamir Ahmed
The RUNA/RUNB decoder in get_next_block() accumulates a run length into the signed int t with no bound. runPos doubles per symbol, so t grows as at least 2^n-1 and reaches INT_MAX after 31 RUNA symbols. The guard that follows, dbufCount+t >= dbufSize, is itself a signed addition, and as the kernel builds with -fno-strict-overflow it wraps negative once dbufCount is nonzero, so the guard is skipped. while (t--) dbuf[dbufCount++] = uc then writes INT_MAX entries into a buffer holding at most 900000. One literal symbol ahead of the run is enough to make dbufCount nonzero. Bound t to the block size as it is accumulated. t only grows within a run, so the value tested never exceeds the final run length; any stream that decodes today satisfies dbufCount+t < dbufSize at the flush, hence t < dbufSize throughout, and no such stream is rejected. Because t grows as at least 2^n-1 the bound trips by the 20th symbol, leaving runPos at most 2^19, so the following runPos <<= 1 cannot overflow either. Link: https://lore.kernel.org/AS8P251MB00010FE5E38D253CF98A652AC8B92@AS8P251MB0001.EURP251.PROD.OUTLOOK.COM Fixes: bc22c17e12c1 ("bzip2/lzma: library support for gzip, bzip2 and lzma decompression") Signed-off-by: Aamir Ahmed <elb12345@hotmail.co.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Assisted-by: LLM Cc: Alain Knaff <alain@knaff.lu> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: <stable@vger.kernel.org>
2026-10-13panic: kill the "buffer unavailable" redirect fallbackBradley Morgan
The redirect buffer is a disgusting terrible hack. panic_force_buf is kmalloc'ed in a late_initcall, and until then the redirect delivers this as the panic message: Redirected panic (buffer unavailable) The whole point of the redirect is to hand the panic message to the target CPU, so the crash kernel boots knowing it panicked and not why. And that window is the entire boot, from the early_param to the late_initcall, which is exactly when you most want the message. Make it a static 1KB buffer and kill the initcall. The cost is 1KB of .bss in SMP crash dump builds, and it is only ever touched when panic_force_cpu= is set anyway. The local msg variable is gone too, the buffer goes directly to panic_smp_redirect_cpu(). Link: https://lore.kernel.org/20260916182957.7788-7-brads@mainlining.org Signed-off-by: Bradley Morgan <brads@mainlining.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Suggested-by: Petr Mladek <pmladek@suse.com> Reviewed-by: Petr Mladek <pmladek@suse.com> Cc: Guenetr Roeck <linux@roeck-us.net> Cc: Sashiko <sashiko-bot@kernel.org> Cc: Wang Jinchao <wangjinchao600@gmail.com> Cc: Wim Van Sebroeck <wim@linux-watchdog.org> Cc: <stable@vger.kernel.org>
2026-10-13panic: allow force_cpu redirect from an NMIBradley Morgan
nmi_panic() claims panic_cpu via panic_try_start() before calling panic(). When the panic later reaches panic_try_force_cpu(), the panic_in_progress() check sees panic_cpu set and refuses to redirect. The crash kernel runs on the CPU that took the NMI instead of the CPU requested with panic_force_cpu=: nmi_panic() panic_try_start() wins, panic_cpu = X panic("%s", msg) vpanic() panic_try_force_cpu() panic_in_progress() true, panic_cpu is X return false redirect bypassed panic_try_start() already won __crash_kexec() on X, not the requested CPU Try the redirect before claiming panic_cpu instead, as suggested by Petr Mladek. nmi_panic() now calls panic_try_force_cpu() first and claims panic_cpu only when no redirect happened. The requested CPU claims panic_cpu itself when it runs panic(), so panic_cpu does not need to be handed off. panic_try_force_cpu() copies the arguments before formatting (patch 3), so nmi_panic() can pass them to vpanic() again when no redirect happens. The redirect IPI is sent with smp_call_function_single_async(), which is not guaranteed to work from NMI context. Treat it as best effort. It is worth the risk because the redirection is only used when the crash kernel would not work on the panicking CPU anyway. Keep returning when the panic is already running on this CPU. A nested NMI, for example with unknown_nmi_panic while this CPU is inside panic(), must return and let the interrupted panic() continue instead of parking the CPU in nmi_panic_self_stop(). Mark the redirecting CPU offline before stopping it, like vpanic() does, so that panic_other_cpus_shutdown() on the target CPU does not wait for it. Link: https://lore.kernel.org/20260916182957.7788-6-brads@mainlining.org Fixes: 2e171ab29f91 ("panic: add panic_force_cpu= parameter to redirect panic to a specific CPU") Signed-off-by: Bradley Morgan <brads@mainlining.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/patchset/20260708164312.19044-1-include@grrlz.net Reviewed-by: Petr Mladek <pmladek@suse.com> Cc: Guenetr Roeck <linux@roeck-us.net> Cc: Wang Jinchao <wangjinchao600@gmail.com> Cc: Wim Van Sebroeck <wim@linux-watchdog.org> Cc: <stable@vger.kernel.org>
2026-10-13panic: restore variable arguments to nmi_panic()Bradley Morgan
nmi_panic() used to accept variable arguments until commit ebc41f20d77f ("panic: change nmi_panic from macro to function") flattened it to a final message string. vpanic() did not exist back then, so the function had to format through panic("%s", msg). Bring the variable arguments back and format with vpanic() directly. The next patch makes nmi_panic() try the panic_force_cpu= redirect before claiming panic_cpu. panic_try_force_cpu() needs to print the message but it is used also by panic() which accepts variable argument list. The string could be formatted only when a CPU gets assigned to process the redirection. Otherwise, there might be a race when writing to the `panic_force_buf`. No current caller passes a string with format specifiers. The closest one is hpwdt_pretimeout(), which builds panic_msg with hex_byte_pack() and has only two variants, both plain strings. But the new __printf() annotation on nmi_panic() would warn with -Wformat-security there because the buffer is passed directly as the format argument, so switch it to nmi_panic(regs, "%s", panic_msg). [pmladek@suse.com: changelog fix] Link: https://lore.kernel.org/arJxFybmtD7OBIcL@pathway.suse.cz Link: https://lore.kernel.org/20260916182957.7788-5-brads@mainlining.org Signed-off-by: Bradley Morgan <brads@mainlining.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Suggested-by: Petr Mladek <pmladek@suse.com> Reviewed-by: Petr Mladek <pmladek@suse.com> Cc: Guenetr Roeck <linux@roeck-us.net> Cc: Sashiko <sashiko-bot@kernel.org> Cc: Wang Jinchao <wangjinchao600@gmail.com> Cc: Wim Van Sebroeck <wim@linux-watchdog.org> Cc: <stable@vger.kernel.org>
2026-10-13panic: fix va_list reuse in panic_try_force_cpu()Bradley Morgan
vsnprintf() consumes the caller's va_list. When the redirect fails, vpanic() reuses it for the panic message, which is undefined behavior. Use va_copy(). Link: https://lore.kernel.org/20260916182957.7788-4-brads@mainlining.org Fixes: 2e171ab29f91 ("panic: add panic_force_cpu= parameter to redirect panic to a specific CPU") Signed-off-by: Bradley Morgan <brads@mainlining.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Petr Mladek <pmladek@suse.com> Cc: Guenetr Roeck <linux@roeck-us.net> Cc: Sashiko <sashiko-bot@kernel.org> Cc: Wang Jinchao <wangjinchao600@gmail.com> Cc: Wim Van Sebroeck <wim@linux-watchdog.org> Cc: <stable@vger.kernel.org>