[Deepin-Kernel-SIG] [linux 6.6-y] [Upstream] Update kernel base to 6.6.140-p1#1763
[Deepin-Kernel-SIG] [linux 6.6-y] [Upstream] Update kernel base to 6.6.140-p1#1763opsiff wants to merge 100 commits into
Conversation
commit 3c318f97dcc50b2e0556a1813bd6958678e881fd upstream. parse_uac2_sample_rate_range() caps the number of enumerated rates at MAX_NR_RATES, but it only breaks out of the current rate loop. A malformed UAC2 RANGE response with additional triplets continues parsing the remaining triplets and repeatedly prints "invalid uac2 rates" while probe still holds register_mutex. Stop the whole parse once the cap is reached and return the number of rates collected so far. Fixes: 4fa0e81 ("ALSA: usb-audio: fix possible hang and overflow in parse_uac2_sample_rate_range()") Cc: stable@vger.kernel.org Reported-by: syzbot+d56178c27a4710960820@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d56178c27a4710960820 Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Link: https://patch.msgid.link/20260415-usb-audio-uac2-rate-cap-v1-1-5ecbafc120d8@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit ab5ba9fd138758ddc50222264ff246b31e397abf) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit fca9c850042a7ab4828ce3a9caa8bc40ea09856a upstream. snd_emuusb_set_samplerate() unconditionally notifies the E-MU SampleRate Extension Unit control after issuing SET_CUR. If snd_usb_mixer_set_ctl_value() fails, the control value has not changed, yet snd_usb_mixer_notify_id() still invalidates the cache and emits a value-change event to userspace. Notify the control only after a successful write. Fixes: 7d2b451 ("ALSA: usb-audio - Added functionality for E-mu 0404USB/0202USB/TrackerPre") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Link: https://patch.msgid.link/20260421-alsa-emuusb-samplerate-notify-v1-1-8b63bbc1d7f1@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 610ba605a4f7dec8aeae47a3ab1922ac148494f5) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit a9224f26b754b5034719248891ff3c2ea0d11144 upstream. snd_microii_spdif_switch_put() returns 0 when the requested vendor register value differs from the cached one. This comparison was inverted by the resume-support conversion, so real SPDIF switch toggles are ignored while no-op writes still issue SET_CUR and report success. Return early only when the requested value matches the cached one. Fixes: 288673b ("ALSA: usb-audio: Add resume support for MicroII SPDIF ctls") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Link: https://patch.msgid.link/20260421-microii-spdif-switch-fix-v1-1-5c50dc28b88f@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit d1905dbbb7c0debdfc062a218a786bf430626abe) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit 25e531b422dc2ac90cdae3b6e74b5cdeb081440d upstream. xHCI hardware maintains its endpoint state between add_endpoint() and drop_endpoint() calls followed by successful check_bandwidth(). So does the driver. Core may call endpoint_disable() during xHCI endpoint life, so don't clear host_ep->hcpriv then, because this breaks endpoint_reset(). If a driver calls usb_set_interface(), submits URBs which make host sequence state non-zero and calls usb_clear_halt(), the device clears its sequence state but xhci_endpoint_reset() bails out. The next URB malfunctions: USB2 loses one packet, USB3 gets Transaction Error or may not complete at all on some (buggy?) HCs from ASMedia and AMD. This is triggered by uvcvideo on bulk video devices. The code was copied from ehci_endpoint_disable() but it isn't needed here - hcpriv should only be NULL on emulated root hub endpoints. It might prevent resetting and inadvertently enabling a disabled and dropped endpoint, but core shouldn't try to reset dropped endpoints. Document xhci requirements regarding hcpriv. They are currently met. Fixes: 18b7406 ("xhci: Fix use-after-free regression in xhci clear hub TT implementation") Cc: stable@vger.kernel.org Signed-off-by: Michal Pecio <michal.pecio@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260402131342.2628648-26-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 8429841d12ca137971087441038cff3828fd187c) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit a4e99587102a83ee911c670752fbca694c7e557f upstream. The usb role switch will update ID and VBUS states at the same time, and vbus will not drop when execute data role swap in Type-C usecase. So lets not wait vbus drop in usb role switch case too. Fixes: e1b5d2b ("usb: chipidea: core: handle usb role switch in a common way") Cc: stable@vger.kernel.org Acked-by: Peter Chen <peter.chen@kernel.org> Reviewed-by: Jun Li <jun.li@nxp.com> Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Link: https://patch.msgid.link/20260402071457.2516021-3-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 82d050713073b6647cdb5212cdf502a0fb3f8e70) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
…hange commit b94b631d9f78e653855f7fb58dbcb86c2a856f6f upstream. For USB role switch-triggered IRQ, ID and VBUS change come together, for example when switching from host to device mode. ID indicate a role switch and VBUS is required to determine whether the device controller can start operating. Currently, ci_irq_handler() handles only a single event per invocation. This can cause an issue where switching to device mode results in the device controller not working at all. Allowing ci_irq_handler() to handle both ID and VBUS change in one call resolves this issue. Meanwhile, this change also affects the VBUS event handling logic. Previously, if an ID event indicated host mode the VBUS IRQ will be ignored as the device disable BSE when stop() is called. With the new behavior, if ID and VBUS IRQ occur together and the target mode is host, the VBUS event is queued and ci_handle_vbus_change() will call usb_gadget_vbus_connect(), after which USBMODE is switched to device mode, causing host mode to stop working. To prevent this, an additional check is added to skip handling VBUS event when current role is not device mode. Suggested-by: Peter Chen <peter.chen@kernel.org> Fixes: e1b5d2b ("usb: chipidea: core: handle usb role switch in a common way") Cc: stable@vger.kernel.org Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Link: https://patch.msgid.link/20260402071457.2516021-2-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit e3a0ebd80ae685d8003eedb61506dff186a27423) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit 52521e8398839105ef8eb22b3f0993f9b0d11a57 upstream. We introduced the upper bound checks of the packet sizes by the ep->maxframesize for avoiding the URB submission errors. However, the check was applied at an incorrect place in the function snd_usb_endpoint_set_params() where ep->maxframesize isn't defined yet; the value is defined at a bit later position. So this ended up with a failure at the first run while the second run works. For fixing it, move the check at the correct place, right after the calculation of ep->maxframesize in the same function. Fixes: 7fe8dec ("ALSA: usb-audio: Cap the packet size pre-calculations") Link: https://bugzilla.kernel.org/show_bug.cgi?id=221292 Cc: <stable@vger.kernel.org> Link: https://patch.msgid.link/20260410143220.1676344-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 8775fa6e2914dad4168d971351585e787deea249) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit 2fc87d37be1b730a149b035f9375fdb8cc5333a5 upstream.
nouveau_gem_pushbuf_reloc_apply() validates each relocation with
if (r->reloc_bo_offset + 4 > nvbo->bo.base.size)
but reloc_bo_offset is __u32 (uapi/drm/nouveau_drm.h) and the integer
literal 4 promotes to unsigned int, so the addition is performed in 32
bits and wraps before the comparison against the size_t bo size.
Cast to u64 so the addition happens in 64-bit arithmetic.
Cc: Lyude Paul <lyude@redhat.com>
Cc: Danilo Krummrich <dakr@kernel.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@gmail.com>
Cc: Simona Vetter <simona@ffwll.ch>
Reported-by: Anthropic
Cc: stable <stable@kernel.org>
Assisted-by: gkh_clanker_t1000
Fixes: a1606a9 ("drm/nouveau: new gem pushbuf interface, bump to 0.0.16")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Add Fixes: tag. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit fa297e919d1680c38ab268ff952b1698dac987f6)
Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
…lution commit d45963a93c1495e9f1338fde91d0ebba8fd22474 upstream. When selecting the high resolution values from the array, FIELD_GET() is used to pull from a 3 bit register, yet the array being indexed has only 5 values in it. Odds are the hardware is sane, but just to be safe, properly check before just overflowing and reading random data and then setting up chip values based on that. Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/2026021934-nearby-playroom-036b@gregkh Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 28a2e047d03721e0517c67ee726eaa6621c30e5f) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit 4b6e6ead556734bdc14024c5f837132b1e7a4b84 upstream. ibmasm_handle_mouse_interrupt() performs an out-of-bounds MMIO read when the queue reader or writer index from hardware exceeds REMOTE_QUEUE_SIZE (60). A compromised service processor can trigger this by writing an out-of-range value to the reader or writer MMIO register before asserting an interrupt. Since writer is re-read from hardware on every loop iteration, it can also be set to an out-of-range value after the loop has already started. The root cause is that get_queue_reader() and get_queue_writer() return raw readl() values that are passed directly into get_queue_entry(), which computes: queue_begin + reader * sizeof(struct remote_input) with no bounds check. This unchecked MMIO address is then passed to memcpy_fromio(), reading 8 bytes from unintended device registers. For sufficiently large values the address falls outside the PCI BAR mapping entirely, triggering a machine check exception. Fix by checking both indices against REMOTE_QUEUE_SIZE at the top of the loop body, before any call to get_queue_entry(). On an out-of-range value, reset the reader register to 0 via set_queue_reader() before breaking, so that normal queue operation can resume if the corrupted hardware state is transient. Reported-by: Yuhao Jiang <danisjiang@gmail.com> Fixes: 278d72a ("[PATCH] ibmasm driver: redesign handling of remote control events") Cc: stable@vger.kernel.org Cc: ychen@northwestern.edu Signed-off-by: Tyllis Xu <LivelyCarpet87@gmail.com> Link: https://patch.msgid.link/20260308062108.258940-1-LivelyCarpet87@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit fc7e9a74e32299d7e93e178ca482a0b59ef1595b) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit 0eb09f737428e482a32a2e31e5e223f2b35a71d3 upstream. The command_file_write() handler allocates a kernel buffer of exactly count bytes and copies user data into it, but does not validate the buffer against the dot command protocol before passing it to get_dot_command_size() and get_dot_command_timeout(). Since both the allocation size (count) and the header fields (command_size, data_size) are independently user-controlled, an attacker can cause get_dot_command_size() to return a value exceeding the allocation, triggering OOB reads in get_dot_command_timeout() and an out-of-bounds memcpy_toio() that leaks kernel heap memory to the service processor. Fix with two guards: reject writes smaller than sizeof(struct dot_command_header) before allocation, then after copying user data reject commands where the buffer is smaller than the total size declared by the header (sizeof(header) + command_size + data_size). This ensures all subsequent header and payload field accesses stay within the buffer. Fixes: 1da177e ("Linux-2.6.12-rc2") Reported-by: Yuhao Jiang <danisjiang@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Tyllis Xu <LivelyCarpet87@gmail.com> Link: https://patch.msgid.link/20260314165355.548119-1-LivelyCarpet87@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit a672682d39dd34e2b5ba4feb436723bed65125ff) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit 9aad71144fa3682cca3837a06c8623016790e7ec upstream. The ibmasm_send_i2o_message() function uses get_dot_command_size() to compute the byte count for memcpy_toio(), but this value is derived from user-controlled fields in the dot_command_header (command_size: u8, data_size: u16) and is never validated against the actual allocation size. A root user can write a small buffer with inflated header fields, causing memcpy_toio() to read up to ~65 KB past the end of the allocation into adjacent kernel heap, which is then forwarded to the service processor over MMIO. Silently clamping the copy size is not sufficient: if the header fields claim a larger size than the buffer, the SP receives a dot command whose own header is inconsistent with the I2O message length, which can cause the SP to desynchronize. Reject such commands outright by returning failure. Validate command_size before calling get_mfa_inbound() to avoid leaking an I2O message frame: reading INBOUND_QUEUE_PORT dequeues a hardware frame from the controller's free pool, and returning without a corresponding set_mfa_inbound() call would permanently exhaust it. Additionally, clamp command_size to I2O_COMMAND_SIZE before the memcpy_toio() so the MMIO write stays within the I2O message frame, consistent with the clamping already performed by outgoing_message_size() for the header field. Fixes: 1da177e ("Linux-2.6.12-rc2") Reported-by: Yuhao Jiang <danisjiang@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Tyllis Xu <LivelyCarpet87@gmail.com> Link: https://patch.msgid.link/20260314165805.548293-1-LivelyCarpet87@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit fd19eb1c75047a4ed4e855f56cafd704dc3914e0) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit f3850d399de3b6142b02315227ef9e772ed0c302 upstream. Remove the flag IORESOURCE_BUSY flag from coreboot's framebuffer resource. It prevents simpledrm from successfully requesting the range for its own use; resulting in errors such as [ 2.775430] simple-framebuffer simple-framebuffer.0: [drm] could not acquire memory region [mem 0x80000000-0x80407fff flags 0x80000200] As with other uses of simple-framebuffer, the simple-framebuffer device should only declare it's I/O resources, but not actively use them. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 851b4c1 ("firmware: coreboot: Add coreboot framebuffer driver") Acked-by: Tzung-Bi Shih <tzungbi@kernel.org> Acked-by: Julius Werner <jwerner@chromium.org> Cc: Samuel Holland <samuel@sholland.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Tzung-Bi Shih <tzungbi@kernel.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Julius Werner <jwerner@chromium.org> Cc: chrome-platform@lists.linux.dev Cc: <stable@vger.kernel.org> # v4.18+ Link: https://patch.msgid.link/20260217155836.96267-3-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit d0b27c41aa09406d0c8f315af332b003559dffd6) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 302a1f6 ] This attemps to fix possible UAFs caused by struct mgmt_pending being freed while still being processed like in the following trace, in order to fix mgmt_pending_valid is introduce and use to check if the mgmt_pending hasn't been removed from the pending list, on the complete callbacks it is used to check and in addtion remove the cmd from the list while holding mgmt_pending_lock to avoid TOCTOU problems since if the cmd is left on the list it can still be accessed and freed. BUG: KASAN: slab-use-after-free in mgmt_add_adv_patterns_monitor_sync+0x35/0x50 net/bluetooth/mgmt.c:5223 Read of size 8 at addr ffff8880709d4dc0 by task kworker/u11:0/55 CPU: 0 UID: 0 PID: 55 Comm: kworker/u11:0 Not tainted 6.16.4 #2 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace: <TASK> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 mgmt_add_adv_patterns_monitor_sync+0x35/0x50 net/bluetooth/mgmt.c:5223 hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x711/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16.4/arch/x86/entry/entry_64.S:245 </TASK> Allocated by task 12210: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4364 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] mgmt_pending_new+0x65/0x1e0 net/bluetooth/mgmt_util.c:269 mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 __add_adv_patterns_monitor+0x130/0x200 net/bluetooth/mgmt.c:5247 add_adv_patterns_monitor+0x214/0x360 net/bluetooth/mgmt.c:5364 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:729 sock_write_iter+0x258/0x330 net/socket.c:1133 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x5c9/0xb30 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 12221: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2381 [inline] slab_free mm/slub.c:4648 [inline] kfree+0x18e/0x440 mm/slub.c:4847 mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 __mgmt_power_off+0x169/0x350 net/bluetooth/mgmt.c:9444 hci_dev_close_sync+0x754/0x1330 net/bluetooth/hci_sync.c:5290 hci_dev_do_close net/bluetooth/hci_core.c:501 [inline] hci_dev_close+0x108/0x200 net/bluetooth/hci_core.c:526 sock_do_ioctl+0xd9/0x300 net/socket.c:1192 sock_ioctl+0x576/0x790 net/socket.c:1313 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: cf75ad8 ("Bluetooth: hci_sync: Convert MGMT_SET_POWERED") Fixes: 2bd1b23 ("Bluetooth: hci_sync: Convert MGMT_OP_SET_DISCOVERABLE to use cmd_sync") Fixes: f056a65 ("Bluetooth: hci_sync: Convert MGMT_OP_SET_CONNECTABLE to use cmd_sync") Fixes: 3244845 ("Bluetooth: hci_sync: Convert MGMT_OP_SSP") Fixes: d81a494 ("Bluetooth: hci_sync: Convert MGMT_OP_SET_LE") Fixes: b338d91 ("Bluetooth: Implement support for Mesh") Fixes: 6f6ff38 ("Bluetooth: hci_sync: Convert MGMT_OP_SET_LOCAL_NAME") Fixes: 71efbb0 ("Bluetooth: hci_sync: Convert MGMT_OP_SET_PHY_CONFIGURATION") Fixes: b747a83 ("Bluetooth: hci_sync: Refactor add Adv Monitor") Fixes: abfeea4 ("Bluetooth: hci_sync: Convert MGMT_OP_START_DISCOVERY") Fixes: 26ac4c5 ("Bluetooth: hci_sync: Convert MGMT_OP_SET_ADVERTISING") Reported-by: cen zhang <zzzccc427@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Charles Xu <charles_xu@189.cn> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 0b60eb04b8524e1b4b3f07fea0d16fda9a677d9a) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 71203f6 ] There is a race condition/UAF in padata_reorder that goes back to the initial commit. A reference count is taken at the start of the process in padata_do_parallel, and released at the end in padata_serial_worker. This reference count is (and only is) required for padata_replace to function correctly. If padata_replace is never called then there is no issue. In the function padata_reorder which serves as the core of padata, as soon as padata is added to queue->serial.list, and the associated spin lock released, that padata may be processed and the reference count on pd would go away. Fix this by getting the next padata before the squeue->serial lock is released. In order to make this possible, simplify padata_reorder by only calling it once the next padata arrives. Fixes: 16295be ("padata: Generic parallelization/serialization interface") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> [ Adjust context of padata_find_next(). Replace cpumask_next_wrap(cpu, pd->cpumask.pcpu) with cpumask_next_wrap(cpu, pd->cpumask.pcpu, -1, false) in padata_reorder() in v6.6 according to dc5bb9b ("cpumask: deprecate cpumask_next_wrap()") and f954a2d ("padata: switch padata_find_next() to using cpumask_next_wrap()") . ] Signed-off-by: Bin Lan <lanbincn@139.com> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit a11a12a9880ab37342b73c93cfe1a3ada02ff0db) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 82a0302 ] Remove comment for reorder_work which no longer exists. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Fixes: 71203f6 ("padata: Fix pd UAF once and for all") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Bin Lan <lanbincn@139.com> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit c7f4dad628137e272b297d46b595ed8d572c7d82) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit c4ac100 ] Replace kvmalloc_array() + copy_from_user() with vmemdup_array_user() on the fast path. This shrinks the source code and improves separation between the kernel and userspace slabs. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Fang Wang <32840572@qq.com> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit be7c5dcfd3c7de7e093599224aba2675774c26d1) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 6270b1a5dab94665d7adce3dc78bc9066ed28bdd ] Userspace can pass an arbitrary number of BO list entries via the bo_number field. Although the previous multiplication overflow check prevents out-of-bounds allocation, a large number of entries could still cause excessive memory allocation (up to potentially gigabytes) and unnecessarily long list processing times. Introduce a hard limit of 128k entries per BO list, which is more than sufficient for any realistic use case (e.g., a single list containing all buffers in a large scene). This prevents memory exhaustion attacks and ensures predictable performance. Return -EINVAL if the requested entry count exceeds the limit Reviewed-by: Christian König <christian.koenig@amd.com> Suggested-by: Christian König <christian.koenig@amd.com> Signed-off-by: Jesse Zhang <jesse.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 688b87d39e0aa8135105b40dc167d74b5ada5332) Cc: stable@vger.kernel.org Signed-off-by: Fang Wang <32840572@qq.com> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit e620378aab78d415bd8a15a2f91c145906520288) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit 6b839b3 upstream. While browsing through ChromeOS crash reports, I found one with an allocation failure that looked like this: chrome: page allocation failure: order:7, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null),cpuset=urgent,mems_allowed=0 CPU: 7 PID: 3295 Comm: chrome Not tainted 5.15.133-20574-g8044615ac35c #1 (HASH:1162 1) Hardware name: Google Lazor (rev3 - 8) with KB Backlight (DT) Call trace: ... warn_alloc+0x104/0x174 __alloc_pages+0x5f0/0x6e4 kmalloc_order+0x44/0x98 kmalloc_order_trace+0x34/0x124 __kmalloc+0x228/0x36c __regset_get+0x68/0xcc regset_get_alloc+0x1c/0x28 elf_core_dump+0x3d8/0xd8c do_coredump+0xeb8/0x1378 get_signal+0x14c/0x804 ... An order 7 allocation is (1 << 7) contiguous pages, or 512K. It's not a surprise that this allocation failed on a system that's been running for a while. More digging showed that it was fairly easy to see the order 7 allocation by just sending a SIGQUIT to chrome (or other processes) to generate a core dump. The actual amount being allocated was 279,584 bytes and it was for "core_note_type" NT_ARM_SVE. There was quite a bit of discussion [1] on the mailing lists in response to my v1 patch attempting to switch to vmalloc. The overall conclusion was that we could likely reduce the 279,584 byte allocation by quite a bit and Mark Brown has sent a patch to that effect [2]. However even with the 279,584 byte allocation gone there are still 65,552 byte allocations. These are just barely more than the 65,536 bytes and thus would require an order 5 allocation. An order 5 allocation is still something to avoid unless necessary and nothing needs the memory here to be contiguous. Change the allocation to kvzalloc() which should still be efficient for small allocations but doesn't force the memory subsystem to work hard (and maybe fail) at getting a large contiguous chunk. [1] https://lore.kernel.org/r/20240201171159.1.Id9ad163b60d21c9e56c2d686b0cc9083a8ba7924@changeid [2] https://lore.kernel.org/r/20240203-arm64-sve-ptrace-regset-size-v1-1-2c3ba1386b9e@kernel.org Link: https://lkml.kernel.org/r/20240205092626.v2.1.Id9ad163b60d21c9e56c2d686b0cc9083a8ba7924@changeid Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Cc: Al Viro <viro@ZenIV.linux.org.uk> Cc: Christian Brauner <brauner@kernel.org> Cc: Dave Martin <Dave.Martin@arm.com> Cc: Eric Biederman <ebiederm@xmission.com> Cc: Jan Kara <jack@suse.cz> Cc: Kees Cook <keescook@chromium.org> Cc: Mark Brown <broonie@kernel.org> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Wen Yang <wen.yang@linux.dev> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit abc6bdcbc0456014a74a49a8319e1450d45dda5c) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit f72e77c33e4b5657af35125e75bab249256030f3 upstream. In various places in the kernel, we modify the fwnode "flags" member by doing either: fwnode->flags |= SOME_FLAG; fwnode->flags &= ~SOME_FLAG; This type of modification is not thread-safe. If two threads are both mucking with the flags at the same time then one can clobber the other. While flags are often modified while under the "fwnode_link_lock", this is not universally true. Create some accessor functions for setting, clearing, and testing the FWNODE flags and move all users to these accessor functions. New accessor functions use set_bit() and clear_bit(), which are thread-safe. Cc: stable@vger.kernel.org Fixes: c2c724c ("driver core: Add fw_devlink_parse_fwtree()") Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mark Brown <broonie@kernel.org> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org> Reviewed-by: Saravana Kannan <saravanak@kernel.org> Link: https://patch.msgid.link/20260317090112.v2.1.I0a4d03104ecd5103df3d76f66c8d21b1d15a2e38@changeid [ Fix fwnode_clear_flag() argument alignment, restore dropped blank line in fwnode_dev_initialized(), and remove unnecessary parentheses around fwnode_test_flag() calls. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Conflicts: include/linux/fwnode.h (cherry picked from commit 17b399cbb9fa1b00e51a5f2ca24c3d1d9e0d9811) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit d647c5b2fbf81560818dacade360abc8c00a9665 upstream.
During ocfs2 dio operations, JBD2 may report warnings via following
call trace:
ocfs2_dio_end_io_write
ocfs2_mark_extent_written
ocfs2_change_extent_flag
ocfs2_split_extent
ocfs2_try_to_merge_extent
ocfs2_extend_rotate_transaction
ocfs2_extend_trans
jbd2__journal_restart
start_this_handle
output: JBD2: kworker/6:2 wants too many credits credits:5450 rsv_credits:0 max:5449
To prevent exceeding the credits limit, modify ocfs2_dio_end_io_write() to
handle extents in a batch of transaction.
Additionally, relocate ocfs2_del_inode_from_orphan(). The orphan inode
should only be removed from the orphan list after the extent tree update
is complete. This ensures that if a crash occurs in the middle of extent
tree updates, we won't leave stale blocks beyond EOF.
This patch also changes the logic for updating the inode size and removing
orphan, making it similar to ext4_dio_write_end_io(). Both operations are
performed only when everything looks good.
Finally, thanks to Jans and Joseph for providing the bug fix prototype and
suggestions.
Link: https://lkml.kernel.org/r/20260402134328.27334-2-heming.zhao@suse.com
Signed-off-by: Heming Zhao <heming.zhao@suse.com>
Suggested-by: Jan Kara <jack@suse.cz>
Suggested-by: Joseph Qi <joseph.qi@linux.alibaba.com>
Reviewed-by: Jan Kara <jack@suse.cz>
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>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 886f97fa59d0bbfa9859fb1a66dd9e014b522d89)
Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit a2225b6e834a838ae3c93709760edc0a169eb2f2 ] The moment we link a "struct device" into the list of devices for the bus, it's possible probe can happen. This is because another thread can load the driver at any time and that can cause the device to probe. This has been seen in practice with a stack crawl that looks like this [1]: really_probe() __driver_probe_device() driver_probe_device() __driver_attach() bus_for_each_dev() driver_attach() bus_add_driver() driver_register() __platform_driver_register() init_module() [some module] do_one_initcall() do_init_module() load_module() __arm64_sys_finit_module() invoke_syscall() As a result of the above, it was seen that device_links_driver_bound() could be called for the device before "dev->fwnode->dev" was assigned. This prevented __fw_devlink_pickup_dangling_consumers() from being called which meant that other devices waiting on our driver's sub-nodes were stuck deferring forever. It's believed that this problem is showing up suddenly for two reasons: 1. Android has recently (last ~1 year) implemented an optimization to the order it loads modules [2]. When devices opt-in to this faster loading, modules are loaded one-after-the-other very quickly. This is unlike how other distributions do it. The reproduction of this problem has only been seen on devices that opt-in to Android's "parallel module loading". 2. Android devices typically opt-in to fw_devlink, and the most noticeable issue is the NULL "dev->fwnode->dev" in device_links_driver_bound(). fw_devlink is somewhat new code and also not in use by all Linux devices. Even though the specific symptom where "dev->fwnode->dev" wasn't assigned could be fixed by moving that assignment higher in device_add(), other parts of device_add() (like the call to device_pm_add()) are also important to run before probe. Only moving the "dev->fwnode->dev" assignment would likely fix the current symptoms but lead to difficult-to-debug problems in the future. Fix the problem by preventing probe until device_add() has run far enough that the device is ready to probe. If somehow we end up trying to probe before we're allowed, __driver_probe_device() will return -EPROBE_DEFER which will make certain the device is noticed. In the race condition that was seen with Android's faster module loading, we will temporarily add the device to the deferred list and then take it off immediately when device_add() probes the device. Instead of adding another flag to the bitfields already in "struct device", instead add a new "flags" field and use that. This allows us to freely change the bit from different thread without worrying about corrupting nearby bits (and means threads changing other bit won't corrupt us). [1] Captured on a machine running a downstream 6.6 kernel [2] https://cs.android.com/android/platform/superproject/main/+/main:system/core/libmodprobe/libmodprobe.cpp?q=LoadModulesParallel Cc: stable@vger.kernel.org Fixes: 2023c61 ("Driver core: add new device to bus's list before probing") Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/20260406162231.v5.1.Id750b0fbcc94f23ed04b7aecabcead688d0d8c17@changeid Signed-off-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Conflicts: include/linux/device.h (cherry picked from commit 29166a0e732fdd6b2bed72420f26bc2bea77f86f) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 0c965d2784fbbd7f8e3b96d875c9cfdf7c00da3d ] The LoongArch syscall number is directly controlled by userspace, but does not have a array_index_nospec() boundry to prevent access past the syscall function pointer tables. Cc: stable@vger.kernel.org Assisted-by: gkh_clanker_2000 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 108f2cd13577a410c0ad6ea00708596d9d0dfc90) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit e3668b371329ea036ff022ce8ecc82f8befcf003 upstream. As reported by Qu Wenruo and Avinesh Kumar, the following getconf PAGESIZE 65536 blkdiscard -p 4k /dev/zram0 takes literally forever to complete. zram doesn't support partial discards and just returns immediately w/o doing any discard work in such cases. The problem is that we forget to endio on our way out, so blkdiscard sleeps forever in submit_bio_wait(). Fix this by jumping to end_bio label, which does bio_endio(). Link: https://lore.kernel.org/20260331074255.777019-1-senozhatsky@chromium.org Fixes: 0120dd6 ("zram: make zram_bio_discard more self-contained") Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org> Reported-by: Qu Wenruo <wqu@suse.com> Closes: https://lore.kernel.org/linux-block/92361cd3-fb8b-482e-bc89-15ff1acb9a59@suse.com Tested-by: Qu Wenruo <wqu@suse.com> Reported-by: Avinesh Kumar <avinesh.kumar@suse.com> Closes: https://bugzilla.suse.com/show_bug.cgi?id=1256530 Reviewed-by: Christoph Hellwig <hch@lst.de> Cc: Brian Geffon <bgeffon@google.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: Minchan Kim <minchan@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 2d1f18efccdb8b29552399d024c36b705447e975) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit eb101d2abdcccb514ca4fccd3b278dd8267374f6 upstream. pci_upstream_bridge() returns NULL if the device is on a root bus. If 8821CE is installed in the system with such a PCI topology, the probing routine will crash. This has probably been unnoticed as 8821CE is mostly supplied in laptops where there is a PCI-to-PCI bridge located upstream from the device. However the card might be installed on a system with different configuration. Check if the bridge does exist for the specific workaround to be applied. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool. Fixes: 24f5e38 ("rtw88: Disable PCIe ASPM while doing NAPI poll on 8821CE") Cc: stable@vger.kernel.org Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260220094730.49791-1-pchelkin@ispras.ru Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit cc9b6303e7ea91bc360b42c7edc1fe9ceb2f47fe) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit 91e901c65b4da02a6fd543e3f0049829ae9645b7 upstream. Building ARCH=um on glibc >= 2.43 fails: arch/um/drivers/cow_user.c: error: implicit declaration of function 'strrchr' [-Wimplicit-function-declaration] glibc 2.43's C23 const-preserving strrchr() macro does not survive UML's global -Dstrrchr=kernel_strrchr remap from arch/um/Makefile. Call kernel_strrchr() directly in cow_user.c so the source no longer depends on the -D rewrite. Fixes: 2c51a4b ("um: fix strrchr() problems") Suggested-by: Johannes Berg <johannes@sipsolutions.net> Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Assisted-by: Codex:gpt-5-4 Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Link: https://patch.msgid.link/20260408070102.2325572-1-michael.bommarito@gmail.com [remove unnecessary 'extern'] Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 8c43ed08643a991de370887370bc7364a0a0cefa) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit 1c78c2002380a1fe31bfb01a3d5f29809e55a096 upstream. The SPI subsystem frees the controller and any subsystem allocated driver data as part of deregistration (unless the allocation is device managed). Take another reference before deregistering the controller so that the driver data is not freed until the driver is done with it. Fixes: 307c897 ("spi: spi-imx: replace struct spi_imx_data::bitbang by pointer to struct spi_controller") Cc: stable@vger.kernel.org # 5.19 Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20260324082326.901043-2-johan@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit f99165ef067723221472ce1aff632bc74f562643) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 8fc6056 ] As reported, on-disk footer.ino and footer.nid is the same and out-of-range, let's add sanity check on f2fs_alloc_nid() to detect any potential corruption in free_nid_list. Signed-off-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Robert Garcia <rob_garcia@163.com> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 9337ed5e777e1c19854928cba7a8131dd00e611b) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit 915b692e6cb723aac658c25eb82c58fd81235110 upstream. MAY_BACKLOG requests can return EBUSY. Handle them by checking for that value and filtering out EINPROGRESS notifications. Reported-by: Yiming Qian <yimingqian591@gmail.com> Fixes: 5a1436b ("crypto: pcrypt - call the complete function on error") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Cc: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 9f1cbca178c03188e201ed175251372149bb25f2) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit 07fd339b2c253205794bea5d9b4b7548a4546c56 upstream. The function testdrv_probe() retrieves the device_node from the PCI device, applies an overlay, and then immediately calls of_node_put(dn). This releases the reference held by the PCI core, potentially freeing the node if the reference count drops to zero. Later, the same freed pointer 'dn' is passed to of_platform_default_populate(), leading to a use-after-free. The reference to pdev->dev.of_node is owned by the device model and should not be released by the driver. Remove the erroneous of_node_put() to prevent premature freeing. Fixes: 26409dd ("of: unittest: Add pci_dt_testdrv pci driver") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang <vulab@iscas.ac.cn> Link: https://patch.msgid.link/20260409034859.429071-1-vulab@iscas.ac.cn Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 0ba03e06f037df704d9b032e36d417633e2326bc) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit 655ef638a2bc3cd0a9eff99a02f83cab94a3a917 upstream. Since commit c662b04 ("crypto: af_alg/hash: Support MSG_SPLICE_PAGES"), the crypto core may pass large scatterlists spanning multiple pages to drivers supporting ahash operations. As a result, a driver can now receive large ahash requests. The SEC1 engine has a limitation where a single descriptor cannot process more than 32k of data. The current implementation attempts to handle the entire request within a single descriptor, which leads to failures raised by the driver: "length exceeds h/w max limit" Address this limitation by splitting large ahash requests into multiple descriptors, each respecting the 32k hardware limit. This allows processing arbitrarily large requests. Cc: stable@vger.kernel.org Fixes: c662b04 ("crypto: af_alg/hash: Support MSG_SPLICE_PAGES") Signed-off-by: Paul Louvel <paul.louvel@bootlin.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 00463d5f864ae28b7938d5acd0ddd800d5457e8b) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit a1b80018b8cec27fc06a8b04a7f8b5f6cfe86eae upstream. Previous commit introduces a new last_request variable in the context structure. Renaming the first/last existing member variable in the context structure to improve readability. Cc: stable@vger.kernel.org Signed-off-by: Paul Louvel <paul.louvel@bootlin.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit a866e2b1c65edaee2e1bb1024ee2c761ced335f8) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit 0471921e2d1043dcc6de5cffb49dd37709521abe upstream. Add logging to more easily determine reason for transmit failure Cc: stable@vger.kernel.org # v6.6+ Fixes: 280db21 ("tpm_tis: Resend command to recover from data transfer errors") Signed-off-by: Jacqueline Wong <jacqwong@google.com> Signed-off-by: Jordan Hand <jhand@google.com> Link: https://lore.kernel.org/r/20260415160006.2275325-2-jacqwong@google.com Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 2e0fd1cb4de48d4e0e0b5ed9c9aca3256f83b817) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit 949692da7211572fac419b2986b6abc0cd1aeb76 upstream. tpm_tis_send_main() will attempt to retry sending data TPM_RETRY times. Currently, if those retries are exhausted, the driver will attempt to call execute. The TPM will be in the wrong state, leading to the operation simply timing out. Instead, if there is still an error after retries are exhausted, return that error immediately. Cc: stable@vger.kernel.org # v6.6+ Fixes: 280db21 ("tpm_tis: Resend command to recover from data transfer errors") Signed-off-by: Jacqueline Wong <jacqwong@google.com> Signed-off-by: Jordan Hand <jhand@google.com> Link: https://lore.kernel.org/r/20260415160006.2275325-3-jacqwong@google.com Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit f92cc1d2c0b4225e5497c1b63a56db56abbe2209) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit 30c4d2f26bb3538c328035cea2e6265c8320539e upstream. The driver reuses the OF node of the parent multi-function device but fails to take another reference to balance the one dropped by the platform bus code when unbinding the MFD and deregistering the child devices. Fix this by using the intended helper for reusing OF nodes. Fixes: 435af89 ("rtc: New driver for RTC in Netronix embedded controller") Cc: stable@vger.kernel.org # 5.13 Cc: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20260407122717.2676774-1-johan@kernel.org Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit d975c077fbdc9dfa0336937364d095b88cec739b) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit 049a57421dd67a28c45ae7e92c36df758033e5fa upstream. damos_adjust_quota() uses time_after_eq() to show if it is time to start a new quota charge window, comparing the current jiffies and the scheduled next charge window start time. If it is, the next charge window start time is updated and the new charge window starts. The time check and next window start time update is skipped while the scheme is deactivated by the watermarks. Let's suppose the deactivation is kept more than LONG_MAX jiffies (assuming CONFIG_HZ of 250, more than 99 days in 32 bit systems and more than one billion years in 64 bit systems), resulting in having the jiffies larger than the next charge window start time + LONG_MAX. Then, the time_after_eq() call can return false until another LONG_MAX jiffies are passed. This means the scheme can continue working after being reactivated by the watermarks. But, soon, the quota will be exceeded and the scheme will again effectively stop working until the next charge window starts. Because the current charge window is extended to up to LONG_MAX jiffies, however, it will look like it stopped unexpectedly and indefinitely, from the user's perspective. Fix this by using !time_in_range_open() instead. The issue was discovered [1] by sashiko. Link: https://lore.kernel.org/20260329152306.45796-1-sj@kernel.org Link: https://lore.kernel.org/20260324040722.57944-1-sj@kernel.org [1] Fixes: ee801b7 ("mm/damon/schemes: activate schemes based on a watermarks mechanism") Signed-off-by: SeongJae Park <sj@kernel.org> Cc: <stable@vger.kernel.org> # 5.16.x Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 14c643ecdc42c40ceda4299d17e1ebd7b279cedf) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit 161ce69c2c89781784b945d8e281ff2da9dede9c upstream. The current implementation of validate_range() in fs/userfaultfd.c performs a hard check against mmap_min_addr. This is redundant because UFFDIO_REGISTER operates on memory ranges that must already be backed by a VMA. Enforcing mmap_min_addr or capability checks again in userfaultfd is unnecessary and prevents applications like binary compilers from using UFFD for valid memory regions mapped by application. Remove the redundant check for mmap_min_addr. We started using UFFD instead of the classic mprotect approach in the binary translator to track application writes. During development, we encountered this bug. The translator cannot control where the translated application chooses to map its memory and if the app requires a low-address area, UFFD fails, whereas mprotect would work just fine. I believe this is a genuine logic bug rather than an improvement, and I would appreciate including the fix in stable. Link: https://lore.kernel.org/20260409103345.15044-1-komlomal@gmail.com Fixes: 86039bd ("userfaultfd: add new syscall to provide memory externalization") Signed-off-by: Denis M. Karpov <komlomal@gmail.com> Reviewed-by: Lorenzo Stoakes <ljs@kernel.org> Acked-by: Harry Yoo (Oracle) <harry@kernel.org> Reviewed-by: Pedro Falcato <pfalcato@suse.de> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com> Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christian Brauner <brauner@kernel.org> Cc: Jan Kara <jack@suse.cz> Cc: Jann Horn <jannh@google.com> Cc: Peter Xu <peterx@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit f3deabe0f5ac920412500e71452fd9d0a68379ba) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
…rspace read commit d0ad1b05bbe6f8da159a4dfb6692b3b7ce30ccc8 upstream. When attempting to play nice with userspace that hasn't enabled KVM_CAP_EXCEPTION_PAYLOAD, defer KVM's non-architectural delivery of the payload until userspace actually reads relevant vCPU state, and more importantly, force delivery of the payload in *all* paths where userspace saves relevant vCPU state, not just KVM_GET_VCPU_EVENTS. Ignoring userspace save/restore for the moment, delivering the payload before the exception is injected is wrong regardless of whether L1 or L2 is running. To make matters even more confusing, the flaw *currently* being papered over by the !is_guest_mode() check isn't even the same bug that commit da998b4 ("kvm: x86: Defer setting of CR2 until #PF delivery") was trying to avoid. At the time of commit da998b4, KVM didn't correctly handle exception intercepts, as KVM would wait until VM-Entry into L2 was imminent to check if the queued exception should morph to a nested VM-Exit. I.e. KVM would deliver the payload to L2 and then synthesize a VM-Exit into L1. But the payload was only the most blatant issue, e.g. waiting to check exception intercepts would also lead to KVM incorrectly escalating a should-be-intercepted #PF into a #DF. That underlying bug was eventually fixed by commit 7709aba ("KVM: x86: Morph pending exceptions to pending VM-Exits at queue time"), but in the interim, commit a06230b ("KVM: x86: Deliver exception payload on KVM_GET_VCPU_EVENTS") came along and subtly added another dependency on the !is_guest_mode() check. While not recorded in the changelog, the motivation for deferring the !exception_payload_enabled delivery was to fix a flaw where a synthesized MTF (Monitor Trap Flag) VM-Exit would drop a pending #DB and clobber DR6. On a VM-Exit, VMX CPUs save pending #DB information into the VMCS, which is emulated by KVM in nested_vmx_update_pending_dbg() by grabbing the payload from the queue/pending exception. I.e. prematurely delivering the payload would cause the pending #DB to not be recorded in the VMCS, and of course, clobber L2's DR6 as seen by L1. Jumping back to save+restore, the quirked behavior of forcing delivery of the payload only works if userspace does KVM_GET_VCPU_EVENTS *before* CR2 or DR6 is saved, i.e. before KVM_GET_SREGS{,2} and KVM_GET_DEBUGREGS. E.g. if userspace does KVM_GET_SREGS before KVM_GET_VCPU_EVENTS, then the CR2 saved by userspace won't contain the payload for the exception save by KVM_GET_VCPU_EVENTS. Deliberately deliver the payload in the store_regs() path, as it's the least awful option even though userspace may not be doing save+restore. Because if userspace _is_ doing save restore, it could elide KVM_GET_SREGS knowing that SREGS were already saved when the vCPU exited. Link: https://lore.kernel.org/all/20200207103608.110305-1-oupton@google.com Cc: Yosry Ahmed <yosry.ahmed@linux.dev> Cc: stable@vger.kernel.org Reviewed-by: Yosry Ahmed <yosry.ahmed@linux.dev> Tested-by: Yosry Ahmed <yosry.ahmed@linux.dev> Link: https://patch.msgid.link/20260218005438.2619063-1-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 35053cdec1191af1b6cea87cf3b2cf679704c21b) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit e63fb1379f4b9300a44739964e69549bebbcdca4 upstream. When restoring a vCPU in guest mode, any state restored before KVM_SET_NESTED_STATE (e.g. KVM_SET_SREGS) will mark the corresponding dirty bits in vmcb01, as it is the active VMCB before switching to vmcb02 in svm_set_nested_state(). Hence, mark all fields in vmcb02 dirty in svm_set_nested_state() to capture any previously restored fields. Fixes: cc440cd ("KVM: nSVM: implement KVM_GET_NESTED_STATE and KVM_SET_NESTED_STATE") CC: stable@vger.kernel.org Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev> Link: https://patch.msgid.link/20260210010806.3204289-1-yosry.ahmed@linux.dev Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 15003179c74d7c84d9be0091f88af51d51571670) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit 778d8c1b2a6ffe622ddcd3bb35b620e6e41f4da0 upstream. After VMRUN in guest mode, nested_sync_control_from_vmcb02() syncs fields written by the CPU from vmcb02 to the cached vmcb12. This is because the cached vmcb12 is used as the authoritative copy of some of the controls, and is the payload when saving/restoring nested state. NextRIP is also written by the CPU (in some cases) after VMRUN, but is not sync'd to the cached vmcb12. As a result, it is corrupted after save/restore (replaced by the original value written by L1 on nested VMRUN). This could cause problems for both KVM (e.g. when injecting a soft IRQ) or L1 (e.g. when using NextRIP to advance RIP after emulating an instruction). Fix this by sync'ing NextRIP to the cache after VMRUN of L2, but only after completing interrupts (not in nested_sync_control_from_vmcb02()), as KVM may update NextRIP (e.g. when re-injecting a soft IRQ). Fixes: cc440cd ("KVM: nSVM: implement KVM_GET_NESTED_STATE and KVM_SET_NESTED_STATE") CC: stable@vger.kernel.org Co-developed-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260225005950.3739782-2-yosry@kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 702ce67817decf5e351a751107ff52cc5306d5da) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit 03bee264f8ebfd39e0254c98e112d033a7aa9055 upstream. After VMRUN in guest mode, nested_sync_control_from_vmcb02() syncs fields written by the CPU from vmcb02 to the cached vmcb12. This is because the cached vmcb12 is used as the authoritative copy of some of the controls, and is the payload when saving/restoring nested state. int_state is also written by the CPU, specifically bit 0 (i.e. SVM_INTERRUPT_SHADOW_MASK) for nested VMs, but it is not sync'd to cached vmcb12. This does not cause a problem if KVM_SET_NESTED_STATE preceeds KVM_SET_VCPU_EVENTS in the restore path, as an interrupt shadow would be correctly restored to vmcb02 (KVM_SET_VCPU_EVENTS overwrites what KVM_SET_NESTED_STATE restored in int_state). However, if KVM_SET_VCPU_EVENTS preceeds KVM_SET_NESTED_STATE, an interrupt shadow would be restored into vmcb01 instead of vmcb02. This would mostly be benign for L1 (delays an interrupt), but not for L2. For L2, the vCPU could hang (e.g. if a wakeup interrupt is delivered before a HLT that should have been in an interrupt shadow). Sync int_state to the cached vmcb12 in nested_sync_control_from_vmcb02() to avoid this problem. With that, KVM_SET_NESTED_STATE restores the correct interrupt shadow state, and if KVM_SET_VCPU_EVENTS follows it would overwrite it with the same value. Fixes: cc440cd ("KVM: nSVM: implement KVM_GET_NESTED_STATE and KVM_SET_NESTED_STATE") CC: stable@vger.kernel.org Signed-off-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260225005950.3739782-3-yosry@kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 1709418535a8df95532999d61b03d59975280258) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit d99df02ff427f461102230f9c5b90a6c64ee8e23 upstream. INVLPGA should cause a #UD when EFER.SVME is not set. Add a check to properly inject #UD when EFER.SVME=0. Fixes: ff09238 ("KVM: SVM: Implement INVLPGA") Cc: stable@vger.kernel.org Signed-off-by: Kevin Cheng <chengkev@google.com> Reviewed-by: Yosry Ahmed <yosry.ahmed@linux.dev> Link: https://patch.msgid.link/20260228033328.2285047-3-chengkev@google.com [sean: tag for stable@] Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 3ac9d4241d205f5d0df06358349ca718ebb0fa12) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit d5bde6113aed8315a2bfe708730b721be9c2f48b upstream. When reacting to an intercept update, explicitly mark vmcb01's intercepts dirty, as KVM always initially operates on vmcb01, and nested_svm_vmexit() isn't guaranteed to mark VMCB_INTERCEPTS as dirty. I.e. if L2 is active, KVM will modify the intercepts for L1, but might not mark them as dirty before the next VMRUN of L1. Fixes: 116a0a2 ("KVM: SVM: Add clean-bit for intercetps, tsc-offset and pause filter count") Cc: stable@vger.kernel.org Reviewed-by: Yosry Ahmed <yosry.ahmed@linux.dev> Link: https://patch.msgid.link/20260218230958.2877682-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 36f36a6e4e74c5d478bedf9496d45269fadfece8) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit 24f7d36b824b65cf1a2db3db478059187b2a37b0 upstream. On nested VMRUN, KVM ensures AVIC is inhibited by requesting KVM_REQ_APICV_UPDATE, triggering a check of inhibit reasons, finding APICV_INHIBIT_REASON_NESTED, and disabling AVIC. However, when KVM_SET_NESTED_STATE is performed on a vCPU not in guest mode with AVIC enabled, KVM_REQ_APICV_UPDATE is not requested, and AVIC is not inhibited. Request KVM_REQ_APICV_UPDATE in the KVM_SET_NESTED_STATE path if AVIC is active, similar to the nested VMRUN path. Fixes: f44509f ("KVM: x86: SVM: allow AVIC to co-exist with a nested guest running") Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260224225017.3303870-1-yosry@kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 263640149d81c1414c41d86f69f9e63389add74e) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit 5c247d08bc81bbad4c662dcf5654137a2f8483ec upstream. KVM currently uses the value of CR2 from vmcb02 to update vmcb12 on nested #VMEXIT. This value is incorrect in some cases, causing L1 to run L2 with a corrupted CR2. This could lead to segfaults or data corruption if L2 is in the middle of handling a #PF and reads a corrupted CR2. Use the correct value in vcpu->arch.cr2 instead. The value in vcpu->arch.cr2 is sync'd to vmcb02 shortly before a VMRUN of L2, and sync'd back to vcpu->arch.cr2 shortly after. The value are only out-of-sync in two cases: after save+restore, and after a #PF is injected into L2. In either case, if a #VMEXIT to L1 is synthesized before L2 runs, using the value in vmcb02 would be incorrect. After save+restore, the value of CR2 is restored by KVM_SET_SREGS into vcpu->arch.cr2. It is not reflect in vmcb02 until a VMRUN of L2. Before that, it holds whatever was in vmcb02 before restore, which would be zero on a new vCPU that never ran nested. If a #VMEXIT to L1 is synthesized before L2 ever runs, using vcpu->arch.cr2 to update vmcb12 is the right thing to do. The #PF injection case is more nuanced. Although the APM is a bit unclear about when CR2 is written during a #PF, the SDM is more clear: Processors update CR2 whenever a page fault is detected. If a second page fault occurs while an earlier page fault is being delivered, the faulting linear address of the second fault will overwrite the contents of CR2 (replacing the previous address). These updates to CR2 occur even if the page fault results in a double fault or occurs during the delivery of a double fault. KVM injecting the exception surely counts as the #PF being "detected". More importantly, when an exception is injected into L2 at the time of a synthesized #VMEXIT, KVM updates exit_int_info in vmcb12 accordingly, such that an L1 hypervisor can re-inject the exception. If CR2 is not written at that point, the L1 hypervisor have no way of correctly re-injecting the #PF. Hence, if a #VMEXIT to L1 is synthesized after the #PF is injected into L2 but before it actually runs, using vcpu->arch.cr2 to update vmcb12 is also the right thing to do. Note that KVM does _not_ update vcpu->arch.cr2 when a #PF is pending for L2, only when it is injected. The distinction is important, because only injected (but not intercepted) exceptions are propagated to L1 through exit_int_info. It would be incorrect to update CR2 in vmcb12 for a pending #PF, as L1 would perceive an updated CR2 value with no #PF. Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev> Link: https://patch.msgid.link/20260203201010.1871056-1-yosry.ahmed@linux.dev Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit d218a0e8a63ce1e1458a8672dcb9237f89afb745) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit 01ddcdc55e097ca38c28ae656711b8e6d1df71f8 upstream. nested_svm_vmrun() currently only injects a #GP if kvm_vcpu_map() fails with -EINVAL. But it could also fail with -EFAULT if creating a host mapping failed. Inject a #GP in all cases, no reason to treat failure modes differently. Fixes: 8c5fbf1 ("KVM/nSVM: Use the new mapping API for mapping guest memory") CC: stable@vger.kernel.org Co-developed-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260303003421.2185681-6-yosry@kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit ddc242a7bb449a935afdfa877f291e8d958170df) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit f85a6ce06e4a0d49652f57967a649ab09e06287c upstream. According to the APM, GIF is set to 0 on any #VMEXIT, including an #VMEXIT(INVALID) due to failed consistency checks. Clear GIF on consistency check failures. Fixes: 3d6368e ("KVM: SVM: Add VMRUN handler") Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260303003421.2185681-11-yosry@kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 83754e459c4bee8cb42d5dbc7641eb5140686d97) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit 69b721a86d0dcb026f6db7d111dcde7550442d2e upstream.
According to the APM, from the reference of the VMRUN instruction:
Upon #VMEXIT, the processor performs the following actions in order to
return to the host execution context:
...
clear EVENTINJ field in VMCB
KVM already syncs EVENTINJ fields from vmcb02 to cached vmcb12 on every
L2->L0 #VMEXIT. Since these fields are zeroed by the CPU on #VMEXIT, they
will mostly be zeroed in vmcb12 on nested #VMEXIT by nested_svm_vmexit().
However, this is not the case when:
1. Consistency checks fail, as nested_svm_vmexit() is not called.
2. Entering guest mode fails before L2 runs (e.g. due to failed load of
CR3).
(2) was broken by commit 2d8a42b ("KVM: nSVM: synchronize VMCB
controls updated by the processor on every vmexit"), as prior to that
nested_svm_vmexit() always zeroed EVENTINJ fields.
Explicitly clear the fields in all nested #VMEXIT code paths.
Fixes: 3d6368e ("KVM: SVM: Add VMRUN handler")
Fixes: 2d8a42b ("KVM: nSVM: synchronize VMCB controls updated by the processor on every vmexit")
Cc: stable@vger.kernel.org
Signed-off-by: Yosry Ahmed <yosry@kernel.org>
Link: https://patch.msgid.link/20260303003421.2185681-12-yosry@kernel.org
[sean: massage changelog formatting]
Signed-off-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit c0095cef73030026d35271d43628401e77fde4de)
Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Reviewer's GuideUpdates Deepin 6.6.y kernel base to v6.6.140 and pulls in upstream fixes across Bluetooth mgmt, crypto, padata, filesystems, networking drivers, KVM, device core/fwnode flags, random kernel stack offset handling, and assorted subsystem bugfixes and hardening changes. Sequence diagram for updated device_add and driver probe readinesssequenceDiagram
participant UserSpace as UserSpace
participant Bus as bus_add_device
participant Core as device_add
participant Dev as struct_device
participant Driver as __driver_probe_device
UserSpace->>Core: device_add(Dev)
Core->>Bus: bus_add_device(Dev)
Bus-->>Core: device linked into klist_devices
Note over UserSpace,Driver: A driver may try to bind via another path
UserSpace->>Driver: __driver_probe_device(Dev)
Driver->>Dev: dev_ready_to_probe()
alt not ready
Driver-->>UserSpace: -EPROBE_DEFER ("Device not ready to probe")
end
Core->>Dev: dev_set_ready_to_probe()
Core->>Bus: bus_probe_device(Dev)
Bus->>Driver: __driver_probe_device(Dev)
Driver->>Dev: dev_ready_to_probe()
alt ready
Driver->>Dev: dev->can_match = true
Driver-->>Bus: probe succeeds / fails normally
end
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
There was a problem hiding this comment.
Pull request overview
Updates the Deepin kernel base to upstream Linux 6.6.140 (stable backports), pulling in a broad set of correctness, robustness, and security fixes across core kernel subsystems, drivers, networking, filesystems, virtualization, and tooling.
Changes:
- Bumps multiple userland tools/selftests and improves robustness of taskstats netlink handling.
- Lands core-kernel fixes and hardening in areas like device core probing readiness, fwnode flag thread-safety, padata ordering, and stack randomization plumbing.
- Incorporates many targeted subsystem/driver fixes (Bluetooth mgmt pending handling, USB audio, MMC, NVMe quirks, filesystems, KVM nested virtualization, etc.).
Reviewed changes
Copilot reviewed 105 out of 106 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| tools/testing/selftests/mqueue/settings | Extends mqueue selftest timeout. |
| tools/accounting/procacct.c | Increases taskstats buffer and adds truncation detection via recvmsg(). |
| tools/accounting/getdelays.c | Same taskstats recvmsg() truncation handling as procacct. |
| sound/usb/mixer.c | Adjusts volume range warning threshold and commentary. |
| sound/usb/mixer_quirks.c | Error-handling fixups and SPDIF switch logic correction. |
| sound/usb/format.c | Tightens UAC2 sample-rate parsing behavior on overflow. |
| sound/usb/endpoint.c | Moves packsize clamping to after maxframesize is computed. |
| sound/usb/caiaq/device.c | Propagates setup errors from device init path. |
| sound/usb/caiaq/control.c | Avoids redundant writes and rolls back state on USB command failure. |
| sound/usb/6fire/control.c | Fixes input volume update logic by comparing adjusted values. |
| sound/pci/ctxfi/ctatc.c | Improves SPDIF resource selection fallback for PLL rate. |
| sound/drivers/pcmtest.c | Fixes init error unwinding and resource cleanup ordering. |
| sound/core/seq/oss/seq_oss_rw.c | Returns correct byte count on successful patch load. |
| sound/core/misc.c | Hardens fasync work/free behavior and locking. |
| sound/core/control.c | Prevents enum name parsing from reading past buffer end. |
| sound/aoa/soundbus/i2sbus/core.c | Fixes device node refcounting (of_node_get/put). |
| net/strparser/strparser.c | Clears queued skb state on abort to avoid leaks/dangling pointers. |
| net/smc/smc_clc.c | Avoids NULL deref when declining first contact without lgr. |
| net/rds/rdma.c | Simplifies error path around cookie put_user handling. |
| net/qrtr/ns.c | Fixes callback restore on init failure/remove and synchronizes teardown. |
| net/ipv4/icmp.c | Adds nospec hardening around ICMP type table indexing. |
| net/ceph/auth.c | Fixes auth protocol init condition after protocol reset. |
| net/caif/cfsrvl.c | Improves teardown safety by unlinking layers before release. |
| net/bluetooth/mgmt.c | Refactors pending command validation/removal under lock; fixes lifetime handling. |
| net/bluetooth/mgmt_util.h | Adds helpers to validate/list pending mgmt commands safely. |
| net/bluetooth/mgmt_util.c | Implements mgmt_pending_listed()/valid() helpers with locking semantics. |
| mm/damon/core.c | Uses time_in_range_open() to handle quota window wrap/edge cases. |
| lib/ts_kmp.c | Adds overflow/zero-length validation to KMP init sizing. |
| kernel/regset.c | Switches to kvzalloc/kvfree for large regset buffers. |
| kernel/padata.c | Reworks reorder logic to address races/UAF in serialization ordering. |
| kernel/fork.c | Initializes per-task kstack offset on fork. |
| io_uring/timeout.c | Rejects unexpected SQE padding/addr3 fields for timeouts. |
| io_uring/poll.c | Fixes poll_refs comparisons and propagates EPOLLONESHOT to apoll events. |
| init/main.c | Removes per-CPU kstack_offset storage (now per-task). |
| include/linux/usb.h | Clarifies hcpriv lifetime requirements while bandwidth is allocated. |
| include/linux/tpm_eventlog.h | Converts TPM_MEMREMAP/UNMAP fallback macros to inline stubs. |
| include/linux/sched.h | Adds per-task kstack_offset storage. |
| include/linux/randomize_kstack.h | Switches stack randomization tracking to per-task and adds init helper. |
| include/linux/padata.h | Updates parallel_data by removing reorder work/lock fields. |
| include/linux/fwnode.h | Converts fwnode flags to atomic bit operations and adds helpers. |
| include/linux/f2fs_fs.h | Adds STOP_CP_REASON_CORRUPTED_NID stop reason. |
| include/linux/device.h | Introduces device flags bitmap and ready_to_probe accessors. |
| fs/userfaultfd.c | Removes mmap_min_addr check for unaligned range validation. |
| fs/ocfs2/aops.c | Batches DIO extent marking and defers orphan cleanup until success. |
| fs/f2fs/node.c | Adds invalid nid helper and stops checkpoint on corrupted free nid list. |
| fs/ext2/inode.c | Detects inconsistent zero-link inodes and reports EFSCORRUPTED. |
| fs/erofs/dir.c | Hardens dirent parsing and validates name offsets/lengths. |
| fs/binfmt_elf.c | Uses kvfree for note data allocations. |
| drivers/usb/host/xhci.c | Adjusts endpoint disable behavior (hcpriv preservation). |
| drivers/usb/chipidea/otg.c | Restricts vbus handling to gadget role and refines ID switch logic. |
| drivers/usb/chipidea/core.c | Coalesces OTG ID/BSV IRQ handling and queues work once. |
| drivers/spi/spi.c | Uses fwnode flag helper when clearing NOT_DEVICE. |
| drivers/spi/spi-imx.c | Balances controller refcount across remove path. |
| drivers/rtc/rtc-ntxec.c | Uses device_set_of_node_from_dev() instead of manual of_node assignment. |
| drivers/remoteproc/xlnx_r5_remoteproc.c | Avoids NULL deref when mailbox RX msg is absent. |
| drivers/power/supply/axp288_charger.c | Uses devm_work_autocancel helpers for work cleanup. |
| drivers/pci/endpoint/functions/pci-epf-ntb.c | Simplifies EPC interface teardown and adjusts bind error paths. |
| drivers/of/unittest.c | Fixes of_node refcounting in unittest PCI overlay path. |
| drivers/of/platform.c | Uses fwnode flag helper when clearing NOT_DEVICE. |
| drivers/of/dynamic.c | Uses fwnode_set_flag() for NOT_DEVICE on attach. |
| drivers/of/base.c | Uses fwnode_set_flag() for BEST_EFFORT on stdout node. |
| drivers/nvme/host/pci.c | Adds quirk entry for a new Kingston device ID. |
| drivers/nvme/host/core.c | Disables write-zeroes limits when quirked. |
| drivers/net/wireless/realtek/rtw88/pci.c | Adds NULL check for bridge before vendor access. |
| drivers/net/phy/mdio_bus.c | Uses fwnode_set_flag() for NEEDS_CHILD_BOUND_ON_ADD. |
| drivers/net/ethernet/micrel/ks8851.h | Changes lock/unlock callback signatures to drop irqsave flags. |
| drivers/net/ethernet/micrel/ks8851_spi.c | Updates locking helpers and call sites for new signature. |
| drivers/net/ethernet/micrel/ks8851_par.c | Switches to BH-safe locking (spin_lock_bh) and updates call sites. |
| drivers/net/ethernet/micrel/ks8851_common.c | Updates locking wrapper API and ensures RX runs with BHs disabled. |
| drivers/mmc/host/sdhci-of-dwcmshc.c | Disables clock while configuring DLL; re-enables via sdhci_enable_clk(). |
| drivers/mmc/core/queue.h | Adds per-request flags and single-block retry indicator. |
| drivers/mmc/core/block.c | Forces single-block recovery mode on write retries. |
| drivers/misc/ibmasm/remote.c | Validates queue indices to avoid out-of-bounds access. |
| drivers/misc/ibmasm/lowlevel.c | Adds size validation and uses size_t for command sizing. |
| drivers/misc/ibmasm/ibmasmfs.c | Validates command header length and command size vs write count. |
| drivers/mfd/stpmic1.c | Adds retry on power-off regmap update and logs failures. |
| drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c | Cancels pending work on release to avoid UAF. |
| drivers/media/platform/amphion/vpu_v4l2.c | Changes mem2mem ops callback from job_abort to job_ready. |
| drivers/media/i2c/imx219.c | Properly handles optional reset GPIO acquisition errors. |
| drivers/md/raid10.c | Fixes error path to free r10bio when request wait fails. |
| drivers/leds/rgb/leds-qcom-lpg.c | Validates clock index to avoid out-of-bounds. |
| drivers/infiniband/sw/rxe/rxe_recv.c | Tightens header-length validation including pad and ICRC. |
| drivers/iio/adc/ti-ads7950.c | Uses unaligned timestamp buffer push helper. |
| drivers/iio/adc/ad7768-1.c | Sends SYNC pulse in one-shot mode before waiting for completion. |
| drivers/i2c/i2c-core-of.c | Uses fwnode flag helper when clearing NOT_DEVICE. |
| drivers/gpu/drm/tiny/arcpgu.c | Uses __free(device_node) for node lifetime management. |
| drivers/gpu/drm/nouveau/nouveau_gem.c | Fixes relocation bounds check by widening to u64. |
| drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | Adds entry limit and uses vmemdup_array_user() fast path. |
| drivers/firmware/google/framebuffer-coreboot.c | Adjusts framebuffer resource flags. |
| drivers/crypto/talitos.c | Refactors ahash handling for SEC1 large requests and completion sequencing. |
| drivers/char/tpm/tpm_tis_core.c | Improves diagnostics and error handling for DATA_EXPECT and retry exhaustion. |
| drivers/bus/imx-weim.c | Uses fwnode flag helper when clearing NOT_DEVICE. |
| drivers/block/zram/zram_drv.c | Ensures discard path always ends bio. |
| drivers/block/rbd.c | Fixes error path by deleting device on disk add failure. |
| drivers/base/dd.c | Defers probing until device_add marks device ready_to_probe. |
| drivers/base/core.c | Makes fwnode flags thread-safe and marks devices ready_to_probe in device_add(). |
| crypto/pcrypt.c | Handles -EINPROGRESS in completion and treats -EBUSY as async. |
| certs/extract-cert.c | Guards key_pass usage behind USE_PKCS11_ENGINE. |
| arch/x86/kvm/x86.c | Fixes exception payload delivery semantics across save/restore paths. |
| arch/x86/kvm/svm/svm.c | Adds nested permission check for invlpga and updates NextRIP cache. |
| arch/x86/kvm/svm/nested.c | Fixes dirty tracking/exit state sync and nested state restore edge cases. |
| arch/um/drivers/cow_user.c | Avoids glibc C23 strrchr macro clash by calling kernel_strrchr(). |
| arch/parisc/kernel/syscalls/syscall.tbl | Corrects _llseek syscall table entry ABI qualifier. |
| arch/loongarch/kernel/syscall.c | Adds nospec hardening for sys_call_table indexing. |
| arch/loongarch/kernel/cpu-probe.c | Adds cpu_show_spectre_v1 sysfs output implementation. |
| arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi | Updates eMMC pinctrl pulls for MMC0_DAT[1-7]. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| if (err) { | ||
| u8 mgmt_err = mgmt_status(err); | ||
|
|
||
| if (enable && hci_dev_test_and_clear_flag(hdev, | ||
| HCI_SSP_ENABLED)) { | ||
| new_settings(hdev, NULL); | ||
| } | ||
|
|
||
| mgmt_pending_foreach(MGMT_OP_SET_SSP, hdev, true, | ||
| cmd_status_rsp, &mgmt_err); | ||
| mgmt_cmd_status(cmd->sk, cmd->hdev->id, cmd->opcode, mgmt_err); |
| card->private_free = card_free; | ||
| err = setup_card(cdev); | ||
| if (err < 0) | ||
| return err; |
| struct v4l2_m2m_ctx *m2m_ctx = inst->fh.m2m_ctx; | ||
|
|
||
| v4l2_m2m_job_finish(m2m_ctx->m2m_dev, m2m_ctx); | ||
| return 0; |
Update kernel base to 6.6.140.
git log --oneline v6.6.139..c0095cef73030 |wc
104 942 7544
Merged(3):
rxrpc: Fix re-decryption of RESPONSE packets
rxrpc: Fix rxkad crypto unalignment handling
rxrpc: Fix memory leaks in rxkad_verify_response()
Handle(2):
driver core: Don't let a device probe until it's ready
device property: Make modifications of fwnode "flags" thread safe
Skip(1):
net: txgbe: fix firmware version check
Summary by Sourcery
Update the 6.6-based kernel with upstream fixes across Bluetooth, crypto, storage, networking, KVM, device core, and assorted drivers to improve correctness, robustness, and security.
Bug Fixes:
Enhancements: