Author: Pierre Barre <[email protected]> Date: Thu Apr 2 12:03:12 2026 +0200 9p: fix access mode flags being ORed instead of replaced commit da2346a48a5a1fed86c3fe3d73c0b60e7b3027c9 upstream. Since commit 1f3e4142c0eb ("9p: convert to the new mount API"), v9fs_apply_options() applies parsed mount flags with |= onto flags already set by v9fs_session_init(). For 9P2000.L, session_init sets V9FS_ACCESS_CLIENT as the default, so when the user mounts with "access=user", both bits end up set. Access mode checks compare against exact values, so having both bits set matches neither mode. This causes v9fs_fid_lookup() to fall through to the default switch case, using INVALID_UID (nobody/65534) instead of current_fsuid() for all fid lookups. Root is then unable to chown or perform other privileged operations. Fix by clearing the access mask before applying the user's choice. Fixes: 1f3e4142c0eb ("9p: convert to the new mount API") Signed-off-by: Pierre Barre <[email protected]> Reviewed-by: Christian Schoenebeck <[email protected]> Message-ID: <[email protected]> Cc: [email protected] Signed-off-by: Dominique Martinet <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cássio Gabriel <[email protected]> Date: Thu Apr 16 10:24:40 2026 -0300 ALSA: 6fire: Fix input volume change detection commit dc88eef8f55e85e92d016cdf7e291f5560efd79b upstream. usb6fire_control_input_vol_put() stores the analog capture volume as a signed offset in rt->input_vol[] (-15..+15), but it compares the cached value against the user-visible mixer value (0..30) before subtracting 15. This mixes two domains in the change detection path. Since the runtime is zero-initialized, the visible default is 15; writing 0 right after probe is ignored, while writing 15 is reported as a change even though the cached value remains 0. Normalize the user value before comparing it with the cached offset. Fixes: 06bb4e743501 ("ALSA: snd-usb-6fire: add analog input volume control") Cc: [email protected] Signed-off-by: Cássio Gabriel <[email protected]> Link: https://patch.msgid.link/20260416-alsa-6fire-input-volume-change-detection-v1-1-ec78299168df@gmail.com Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cássio Gabriel <[email protected]> Date: Fri Apr 24 09:48:41 2026 -0300 ALSA: aloop: Fix peer runtime UAF during format-change stop commit e5c33cdc6f402eab8abd36ecf436b22c9d3a8aff upstream. loopback_check_format() may stop the capture side when playback starts with parameters that no longer match a running capture stream. Commit 826af7fa62e3 ("ALSA: aloop: Fix racy access at PCM trigger") moved the peer lookup under cable->lock, but the actual snd_pcm_stop() still runs after dropping that lock. A concurrent close can clear the capture entry from cable->streams[] and detach or free its runtime while the playback trigger path still holds a stale peer substream pointer. Keep a per-cable count of in-flight peer stops before dropping cable->lock, and make free_cable() wait for those stops before detaching the runtime. This preserves the existing behavior while making the peer runtime lifetime explicit. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=8fa95c41eafbc9d2ff6f Fixes: 597603d615d2 ("ALSA: introduce the snd-aloop module for the PCM loopback") Cc: [email protected] Suggested-by: Takashi Iwai <[email protected]> Signed-off-by: Cássio Gabriel <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cássio Gabriel <[email protected]> Date: Tue Mar 31 18:14:04 2026 -0300 ALSA: aoa: i2sbus: clear stale prepared state commit 5ed060d5491597490fb53ec69da3edc4b1e8c165 upstream. The i2sbus PCM code uses pi->active to constrain the sibling stream to an already prepared duplex format and rate in i2sbus_pcm_open(). That state is set from i2sbus_pcm_prepare(), but the current code only clears it on close. As a result, the sibling stream can inherit stale constraints after the prepared state has been torn down. Clear pi->active when hw_params() or hw_free() tears down the prepared state, and set it again only after prepare succeeds. Replace the stale FIXME in the duplex constraint comment with a description of the current driver behavior: i2sbus still programs a single shared transport configuration for both directions, so mixed formats are not supported in duplex mode. Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Fixes: f3d9478b2ce4 ("[ALSA] snd-aoa: add snd-aoa") Cc: [email protected] Signed-off-by: Cássio Gabriel <[email protected]> Link: https://patch.msgid.link/20260331-aoa-i2sbus-clear-stale-active-v2-1-3764ae2889a1@gmail.com Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cássio Gabriel <[email protected]> Date: Mon Mar 30 01:00:34 2026 -0300 ALSA: aoa: i2sbus: fix OF node lifetime handling commit 4ec93f070eda6b765b62efcaed9241c3b3b0b6ad upstream. i2sbus_add_dev() keeps the matched "sound" child pointer after for_each_child_of_node() has dropped the iterator reference. Take an extra reference before saving that node and drop it after the layout-id/device-id lookup is complete. The function also stores np in dev->sound.ofdev.dev.of_node without taking a reference for the embedded soundbus device. Since i2sbus overrides the embedded platform device release callback, balance that reference explicitly in the local error path and in i2sbus_release_dev(). Fixes: f3d9478b2ce4 ("[ALSA] snd-aoa: add snd-aoa") Cc: [email protected] Signed-off-by: Cássio Gabriel <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thorsten Blum <[email protected]> Date: Tue Mar 10 11:29:20 2026 +0100 ALSA: aoa: Skip devices with no codecs in i2sbus_resume() commit fd7df93013c5118812e63a52635dc6c3a805a1de upstream. In i2sbus_resume(), skip devices with an empty codec list, which avoids using an uninitialized 'sysclock_factor' in the 32-bit format path in i2sbus_pcm_prepare(). In i2sbus_pcm_prepare(), replace two list_for_each_entry() loops with a single list_first_entry() now that the codec list is guaranteed to be non-empty by all callers. Fixes: f3d9478b2ce4 ("[ALSA] snd-aoa: add snd-aoa") Cc: [email protected] Signed-off-by: Thorsten Blum <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Takashi Iwai <[email protected]> Date: Mon Apr 27 16:56:15 2026 +0200 ALSA: caiaq: Don't abort when no input device is available commit b32ae47a2b0a1fb4bd4942242847966d9b178222 upstream. The previous fix to handle the error from setup_card() caused a regression for the models that have no dedicated input device; snd_usb_caiaq_input_init() just returns -EINVAL, and we treat it as a fatal error although it should be ignored. As a regression fix, change the error code to -ENODEV, and ignore this error in the callee, to continue probing. Fixes: 28abd224db4a ("ALSA: caiaq: Handle probe errors properly") Cc: <[email protected]> Link: https://bugzilla.kernel.org/show_bug.cgi?id=221423 Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cássio Gabriel <[email protected]> Date: Fri Apr 17 10:41:33 2026 -0300 ALSA: caiaq: Fix control_put() result and cache rollback commit a3542d1b30f92307f545f2def14e8d988dffdff0 upstream. control_put() always returns 1 and updates cdev->control_state[] before sending the USB command. It also ignores transport errors from usb_bulk_msg(), snd_usb_caiaq_send_command(), and snd_usb_caiaq_send_command_bank(). That breaks the ALSA .put() contract and can leave control_get() reporting a cached value the device never accepted. Return 0 for unchanged values, propagate transport failures, and restore the cached byte when the write fails. Fixes: 8e3cd08ed8e59 ("[ALSA] caiaq - add control API and more input features") Cc: [email protected] Signed-off-by: Cássio Gabriel <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Takashi Iwai <[email protected]> Date: Mon Apr 27 14:37:53 2026 +0200 ALSA: caiaq: Fix potentially leftover ep1_in_urb at error path commit 0a7b5221b5b51cc798fcfc3be00d02eade149d69 upstream. The previous fix for handling the error from setup_card() missed that an internal URB cdev->ep1_in_urb might have been already submitted beforehand. In the normal case, this URB gets killed at the disconnection, but in the error path, we didn't do it, hence there can be a potential leak. Fix it in the error path for setup_card(), too. Fixes: 28abd224db4a ("ALSA: caiaq: Handle probe errors properly") Cc: <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Deepanshu Kartikey <[email protected]> Date: Sun Apr 26 05:49:34 2026 +0530 ALSA: caiaq: fix usb_dev refcount leak on probe failure commit 7a5f1cd22d47f8ca4b760b6334378ae42c1bd24b upstream. create_card() takes a reference on the USB device with usb_get_dev() and stores the matching usb_put_dev() in card_free(), which is installed as the snd_card's ->private_free destructor. However, ->private_free is only assigned near the end of init_card(), after several failure points (usb_set_interface(), EP type checks, usb_submit_urb(), the EP1_CMD_GET_DEVICE_INFO exchange, and its timeout). When any of those fail, init_card() returns an error to snd_probe(), which calls snd_card_free(card). Because ->private_free is still NULL, card_free() never runs, the usb_get_dev() reference is not dropped, and the struct usb_device leaks along with its descriptor allocations and device_private. syzbot reproduces this with a malformed UAC3 device whose only valid altsetting is 0; init_card()'s usb_set_interface(usb_dev, 0, 1) call fails with -EIO and triggers the leak. Move the ->private_free assignment into create_card(), immediately after usb_get_dev(), so that every error path reaching snd_card_free() balances the reference. card_free()'s callees (snd_usb_caiaq_input_free, free_urbs, kfree) already tolerate the partially-initialized state because the chip private area is zero-initialized by snd_card_new(). Fixes: 80bb50e2d459 ("ALSA: caiaq: take a reference on the USB device in create_card()") Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=2afd7e71155c7e241560 Tested-by: [email protected] Cc: [email protected] Signed-off-by: Deepanshu Kartikey <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Takashi Iwai <[email protected]> Date: Tue Apr 14 12:59:00 2026 +0200 ALSA: caiaq: Handle probe errors properly commit 28abd224db4a49560b452115bca3672a20e45b2f upstream. The probe procedure of setup_card() in caiaq driver doesn't treat the error cases gracefully, e.g. the error from snd_card_register() calls snd_card_free() but continues. This would lead to a UAF for the further calls like snd_usb_caiaq_control_init(), as Berk suggested in another patch in the link below. However, the problem is not only that; in general, this function drops the all error handlings (as it's a void function) although its caller can propagate an error to snd_probe(), which eventually calls snd_card_free() as a proper error path. That said, we should treat each error case in setup_card(), and just return the error code promptly, which is then handled later as a fatal error in snd_probe(). This patch achieves it by changing the setup_card() to return an error code. Also, the superfluous snd_card_free() call is removed, too. Note that card->private_free can be set still safely at returning an error. All called functions in card_free() have checks of the unassigned resources or NULL checks. Fixes: 8e3cd08ed8e5 ("[ALSA] caiaq - add control API and more input features") Cc: [email protected] Link: https://lore.kernel.org/[email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ziqing Chen <[email protected]> Date: Tue Apr 14 21:24:37 2026 +0800 ALSA: control: Validate buf_len before strnlen() in snd_ctl_elem_init_enum_names() commit e0da8a8cac74f4b9f577979d131f0d2b88a84487 upstream. snd_ctl_elem_init_enum_names() advances pointer p through the names buffer while decrementing buf_len. If buf_len reaches zero but items remain, the next iteration calls strnlen(p, 0). While strnlen(p, 0) returns 0 and would hit the existing name_len == 0 error path, CONFIG_FORTIFY_SOURCE's fortified strnlen() first checks maxlen against __builtin_dynamic_object_size(). When Clang loses track of p's object size inside the loop, this triggers a BRK exception panic before the return value is examined. Add a buf_len == 0 guard at the loop entry to prevent calling fortified strnlen() on an exhausted buffer. Found by kernel fuzz testing through Xiaomi Smartphone. Fixes: 8d448162bda5 ("ALSA: control: add support for ENUMERATED user space controls") Cc: [email protected] Signed-off-by: Ziqing Chen <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Takashi Iwai <[email protected]> Date: Mon Apr 20 08:17:20 2026 +0200 ALSA: core: Fix potential data race at fasync handling commit 8146cd333d235ed32d48bb803fdf743472d7c783 upstream. In snd_fasync_work_fn(), which is the offload work for traversing and processing the pending fasync list, the call of kill_fasync() is done outside the snd_fasync_lock for avoiding deadlocks. The problem is that its the references of fasync->on, fasync->signal and fasync->poll are done there also outside the lock. Since these may be modified by snd_kill_fasync() call concurrently from other process, inconsistent values might be passed to kill_fasync(). Although there shouldn't be critical UAF, it's still better to be addressed. This patch moves the kill_fasync() argument evaluations inside the snd_fasync_lock for avoiding the data races above. The handling in fasync->on flag is optimized in the loop to skip directly. Also, for more clarity, snd_fasync_free() takes the lock and unlink the pending entry more directly instead of clearing fasync->on flag. Reported-by: Jake Lamberson <[email protected]> Fixes: ef34a0ae7a26 ("ALSA: core: Add async signal helpers") Cc: <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Harin Lee <[email protected]> Date: Mon Apr 6 16:49:13 2026 +0900 ALSA: ctxfi: Add fallback to default RSR for S/PDIF commit 7d61662197ecdc458e33e475b6ada7f6da61d364 upstream. spdif_passthru_playback_get_resources() uses atc->pll_rate as the RSR for the MSR calculation loop. However, pll_rate is only updated in atc_pll_init() and not in hw_pll_init(), so it remains 0 after the card init. When spdif_passthru_playback_setup() skips atc_pll_init() for 32000 Hz, (rsr * desc.msr) always becomes 0, causing the loop to spin indefinitely. Add fallback to use atc->rsr when atc->pll_rate is 0. This reflects the hardware state, since hw_card_init() already configures the PLL to the default RSR. Fixes: 8cc72361481f ("ALSA: SB X-Fi driver merge") Cc: [email protected] Signed-off-by: Harin Lee <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Spencer Payton <[email protected]> Date: Tue Apr 21 10:49:18 2026 +0200 ALSA: hda/realtek - Add mute LED support for HP Victus 15-fa2xxx commit eacda758e3c01db98b5c231f56cf9a6e05ced75c upstream. The mute LED on this laptop uses ALC245 but requires a quirk to work. This patch enables the existing ALC245_FIXUP_HP_MUTE_LED_COEFBIT quirk for the device. Tested my Victus 15-fa2xxx (PCI SSID 103c:8dcd). The LED behaviour works as intended. Cc: [email protected] Signed-off-by: Spencer Payton <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Guangshuo Li <[email protected]> Date: Thu Apr 16 03:31:38 2026 +0800 ALSA: pcmtest: fix reference leak on failed device registration commit 4ff036f95238f02c87e5d7c0a9d93748582a8950 upstream. When platform_device_register() fails in mod_init(), the embedded struct device in pcmtst_pdev has already been initialized by device_initialize(), but the failure path returns the error without dropping the device reference for the current platform device: mod_init() -> platform_device_register(&pcmtst_pdev) -> device_initialize(&pcmtst_pdev.dev) -> setup_pdev_dma_masks(&pcmtst_pdev) -> platform_device_add(&pcmtst_pdev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before returning the error. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fixes: 315a3d57c64c5 ("ALSA: Implement the new Virtual PCM Test Driver") Cc: [email protected] Signed-off-by: Guangshuo Li <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cássio Gabriel <[email protected]> Date: Tue Apr 21 10:03:06 2026 -0300 ALSA: pcmtest: Fix resource leaks in module init error paths commit d5d5f80416a3a749906c04d56575e2290792654b upstream. pcmtest allocates its pattern buffers and creates its debugfs tree before registering the platform device and driver, but mod_init() does not release those resources when a later init step fails. As a result, a debugfs directory creation failure leaks the pattern buffers, while platform_device_register() and platform_driver_register() failures leave both the pattern buffers and the debugfs tree behind. The recent fix for failed device registration only dropped the embedded device reference. Add the missing cleanup for the debugfs tree and pattern buffers in the remaining module init error paths. Fixes: 315a3d57c64c ("ALSA: Implement the new Virtual PCM Test Driver") Cc: [email protected] Signed-off-by: Cássio Gabriel <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cássio Gabriel <[email protected]> Date: Tue Mar 24 16:59:41 2026 -0300 ALSA: seq_oss: return full count for successful SEQ_FULLSIZE writes commit bbc6c0dda54fc0ad8f8aed0b796c23e186e1a188 upstream. snd_seq_oss_write() currently returns the raw load_patch() callback result for SEQ_FULLSIZE events. That callback is documented as returning 0 on success and -errno on failure, but snd_seq_oss_write() is the file write path and should report the number of user bytes consumed on success. Some in-tree backends also return backend-specific positive values, which can still be shorter than the original write size. Return the full byte count for successful SEQ_FULLSIZE writes. Preserve negative errors and convert any nonnegative completion to the original count. Cc: [email protected] Signed-off-by: Cássio Gabriel <[email protected]> Link: https://patch.msgid.link/20260324-alsa-seq-oss-fullsize-write-return-v1-1-66d448510538@gmail.com Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cássio Gabriel <[email protected]> Date: Tue Apr 21 21:53:52 2026 -0300 ALSA: usb-audio: Avoid false E-MU sample-rate notifications 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: 7d2b451e65d2 ("ALSA: usb-audio - Added functionality for E-mu 0404USB/0202USB/TrackerPre") Cc: [email protected] Signed-off-by: Cássio Gabriel <[email protected]> Link: https://patch.msgid.link/20260421-alsa-emuusb-samplerate-notify-v1-1-8b63bbc1d7f1@gmail.com Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Takashi Iwai <[email protected]> Date: Fri Apr 10 16:32:19 2026 +0200 ALSA: usb-audio: Evaluate packsize caps at the right place 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: 7fe8dec3f628 ("ALSA: usb-audio: Cap the packet size pre-calculations") Link: https://bugzilla.kernel.org/show_bug.cgi?id=221292 Cc: <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cássio Gabriel <[email protected]> Date: Tue Apr 21 22:07:41 2026 -0300 ALSA: usb-audio: Fix Audio Advantage Micro II SPDIF switch 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: 288673beae6c ("ALSA: usb-audio: Add resume support for MicroII SPDIF ctls") Cc: [email protected] Signed-off-by: Cássio Gabriel <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cássio Gabriel <[email protected]> Date: Wed Apr 15 12:04:53 2026 -0300 ALSA: usb-audio: stop parsing UAC2 rates at MAX_NR_RATES 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: 4fa0e81b8350 ("ALSA: usb-audio: fix possible hang and overflow in parse_uac2_sample_rate_range()") Cc: [email protected] Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=d56178c27a4710960820 Signed-off-by: Cássio Gabriel <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David (Ming Qiang) Wu <[email protected]> Date: Mon Mar 9 18:48:37 2026 -0400 amdgpu/jpeg: fix deepsleep register for jpeg 5_0_0 and 5_0_2 commit e90dc3b2d73986610476b02c29d0074aa4d92fb0 upstream. PCTL0__MMHUB_DEEPSLEEP_IB is 0x69004 on MMHUB 4,1,0 and and 0x60804 on MMHUB 4,2,0. 0x62a04 is on MMHUB 1,8,0/1. The DS bits are adjusted to cover more JPEG engines and MMHUB version. Signed-off-by: David (Ming Qiang) Wu <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Daniel J Blueman <[email protected]> Date: Fri Mar 27 19:58:32 2026 +0800 apparmor: Fix string overrun due to missing termination commit 828bf7929bedcb79b560b5b4e44f22abee07d31b upstream. When booting Ubuntu 26.04 with Linux 7.0-rc4 on an ARM64 Qualcomm Snapdragon X1 we see a string buffer overrun: BUG: KASAN: slab-out-of-bounds in aa_dfa_match (security/apparmor/match.c:535) Read of size 1 at addr ffff0008901cc000 by task snap-update-ns/2120 CPU: 5 UID: 60578 PID: 2120 Comm: snap-update-ns Not tainted 7.0.0-rc4+ #22 PREEMPTLAZY Hardware name: LENOVO 83ED/LNVNB161216, BIOS NHCN60WW 09/11/2025 Call trace: show_stack (arch/arm64/kernel/stacktrace.c:501) (C) dump_stack_lvl (lib/dump_stack.c:122) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) __asan_report_load1_noabort (mm/kasan/report_generic.c:378) aa_dfa_match (security/apparmor/match.c:535) match_mnt_path_str (security/apparmor/mount.c:244 security/apparmor/mount.c:336) match_mnt (security/apparmor/mount.c:371) aa_bind_mount (security/apparmor/mount.c:447 (discriminator 4)) apparmor_sb_mount (security/apparmor/lsm.c:719 (discriminator 1)) security_sb_mount (security/security.c:1062 (discriminator 31)) path_mount (fs/namespace.c:4101) __arm64_sys_mount (fs/namespace.c:4172 fs/namespace.c:4361 fs/namespace.c:4338 fs/namespace.c:4338) invoke_syscall.constprop.0 (arch/arm64/kernel/syscall.c:35 arch/arm64/kernel/syscall.c:49) el0_svc_common.constprop.0 (./include/linux/thread_info.h:142 (discriminator 2) arch/arm64/kernel/syscall.c:140 (discriminator 2)) do_el0_svc (arch/arm64/kernel/syscall.c:152) el0_svc (arch/arm64/kernel/entry-common.c:80 arch/arm64/kernel/entry-common.c:725) el0t_64_sync_handler (arch/arm64/kernel/entry-common.c:744) el0t_64_sync (arch/arm64/kernel/entry.S:596) Allocated by task 2120: kasan_save_stack (mm/kasan/common.c:58) kasan_save_track (./arch/arm64/include/asm/current.h:19 mm/kasan/common.c:70 mm/kasan/common.c:79) kasan_save_alloc_info (mm/kasan/generic.c:571) __kasan_kmalloc (mm/kasan/common.c:419) __kmalloc_noprof (./include/linux/kasan.h:263 mm/slub.c:5260 mm/slub.c:5272) aa_get_buffer (security/apparmor/lsm.c:2201) aa_bind_mount (security/apparmor/mount.c:442) apparmor_sb_mount (security/apparmor/lsm.c:719 (discriminator 1)) security_sb_mount (security/security.c:1062 (discriminator 31)) path_mount (fs/namespace.c:4101) __arm64_sys_mount (fs/namespace.c:4172 fs/namespace.c:4361 fs/namespace.c:4338 fs/namespace.c:4338) invoke_syscall.constprop.0 (arch/arm64/kernel/syscall.c:35 arch/arm64/kernel/syscall.c:49) el0_svc_common.constprop.0 (./include/linux/thread_info.h:142 (discriminator 2) arch/arm64/kernel/syscall.c:140 (discriminator 2)) do_el0_svc (arch/arm64/kernel/syscall.c:152) el0_svc (arch/arm64/kernel/entry-common.c:80 arch/arm64/kernel/entry-common.c:725) el0t_64_sync_handler (arch/arm64/kernel/entry-common.c:744) el0t_64_sync (arch/arm64/kernel/entry.S:596) The buggy address belongs to the object at ffff0008901ca000 which belongs to the cache kmalloc-rnd-06-8k of size 8192 The buggy address is located 0 bytes to the right of allocated 8192-byte region [ffff0008901ca000, ffff0008901cc000) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x9101c8 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:-1 pincount:0 flags: 0x8000000000000040(head|zone=2) page_type: f5(slab) raw: 8000000000000040 ffff000800016c40 fffffdffe2d14e10 ffff000800015c70 raw: 0000000000000000 0000000800010001 00000000f5000000 0000000000000000 head: 8000000000000040 ffff000800016c40 fffffdffe2d14e10 ffff000800015c70 head: 0000000000000000 0000000800010001 00000000f5000000 0000000000000000 head: 8000000000000003 fffffdffe2407201 fffffdffffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff0008901cbf00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff0008901cbf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff0008901cc000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff0008901cc080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff0008901cc100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc This was introduced by previous incorrect conversion from strcpy(). Fix it by adding the missing terminator. Cc: [email protected] Reviewed-by: Georgia Garcia <[email protected]> Signed-off-by: Daniel J Blueman <[email protected]> Fixes: 93d4dbdc8da0 ("apparmor: Replace deprecated strcpy in d_namespace_path") Signed-off-by: John Johansen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cengiz Can <[email protected]> Date: Tue Feb 10 11:17:14 2026 +0300 apparmor: use target task's context in apparmor_getprocattr() commit 4afc61702bdcc3b9b519749ef966cf762a6e7051 upstream. apparmor_getprocattr() incorrectly calls task_ctx(current) instead of task_ctx(task) when retrieving prev and exec attributes, returning the caller's labels rather than the target's. Fix by passing task to task_ctx(). The issue can be reproduced when a process with an onexec transition (e.g., configured by a container runtime) is inspected via /proc/<pid>/attr/apparmor/exec. The reader's own value is returned instead of the target's. Reported-by: Qualys Security Advisory <[email protected]> Fixes: 3b529a7600d8 ("apparmor: move task domain change info to task security") Cc: [email protected] Co-developed-by: Cengiz Can <[email protected]> Signed-off-by: Cengiz Can <[email protected]> Co-developed-by: John Johansen <[email protected]> Signed-off-by: John Johansen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Anshuman Khandual <[email protected]> Date: Mon Mar 9 02:57:24 2026 +0000 arm64/mm: Enable batched TLB flush in unmap_hotplug_range() commit 48478b9f791376b4b89018d7afdfd06865498f65 upstream. During a memory hot remove operation, both linear and vmemmap mappings for the memory range being removed, get unmapped via unmap_hotplug_range() but mapped pages get freed only for vmemmap mapping. This is just a sequential operation where each table entry gets cleared, followed by a leaf specific TLB flush, and then followed by memory free operation when applicable. This approach was simple and uniform both for vmemmap and linear mappings. But linear mapping might contain CONT marked block memory where it becomes necessary to first clear out all entire in the range before a TLB flush. This is as per the architecture requirement. Hence batch all TLB flushes during the table tear down walk and finally do it in unmap_hotplug_range(). Prior to this fix, it was hypothetically possible for a speculative access to a higher address in the contiguous block to fill the TLB with shattered entries for the entire contiguous range after a lower address had already been cleared and invalidated. Due to the table entries being shattered, the subsequent TLB invalidation for the higher address would not then clear the TLB entries for the lower address, meaning stale TLB entries could persist. Besides it also helps in improving the performance via TLBI range operation along with reduced synchronization instructions. The time spent executing unmap_hotplug_range() improved 97% measured over a 2GB memory hot removal in KVM guest. This scheme is not applicable during vmemmap mapping tear down where memory needs to be freed and hence a TLB flush is required after clearing out page table entry. Cc: Will Deacon <[email protected]> Cc: [email protected] Cc: [email protected] Closes: https://lore.kernel.org/all/aWZYXhrT6D2M-7-N@willie-the-truck/ Fixes: bbd6ec605c0f ("arm64/mm: Enable memory hot remove") Cc: [email protected] Reviewed-by: David Hildenbrand (Arm) <[email protected]> Reviewed-by: Ryan Roberts <[email protected]> Signed-off-by: Ryan Roberts <[email protected]> Signed-off-by: Anshuman Khandual <[email protected]> Signed-off-by: Catalin Marinas <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Robert Marko <[email protected]> Date: Tue Jan 27 13:32:15 2026 +0100 arm64: dts: marvell: uDPU: add ethernet aliases commit 38f09c97340cd23f976242e6cb1e7aa4c8ed28d0 upstream. On eDPU plus, which is an updated revision of eDPU which uses an external MV88E6361 switch we are relying on U-Boot to detect the board, and then enable and disable the required nodes for that revision. However, it seems that I missed adding the required aliases for ethernet controllers, and this worked as in OpenWrt we had added those locally. Cc: [email protected] Fixes: 660b8b2f3944 ("arm64: dts: marvell: eDPU: add support for version with external switch") Signed-off-by: Robert Marko <[email protected]> Signed-off-by: Gregory CLEMENT <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Francesco Dolcini <[email protected]> Date: Fri Mar 20 08:30:30 2026 +0100 arm64: dts: ti: am62-verdin: Enable pullup for eMMC data pins commit d5325810814ee995debfa0b6c4a22e0391598bef upstream. Verdin AM62 board does not have external pullups on eMMC DAT1-DAT7 pins. Enable internal pullups on DAT1-DAT7 considering: - without a host-side pullup, these lines rely solely on the eMMC device's internal pullup (R_int, 10kohm-150kohm per JEDEC), which may exceed the recommended 50kohm max for 1.8V VCCQ - JEDEC JESD84-B51 Table 200 requires host-side pullups (R_DAT, 10kohm-100kohm) on all data lines to prevent bus floating Fixes: 316b80246b16 ("arm64: dts: ti: add verdin am62") Cc: [email protected] Signed-off-by: Francesco Dolcini <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Vignesh Raghavendra <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ryan Roberts <[email protected]> Date: Mon Mar 30 17:17:02 2026 +0100 arm64: mm: Fix rodata=full block mapping support for realm guests commit f12b435de2f2bb09ce406467020181ada528844c upstream. Commit a166563e7ec37 ("arm64: mm: support large block mapping when rodata=full") enabled the linear map to be mapped by block/cont while still allowing granular permission changes on BBML2_NOABORT systems by lazily splitting the live mappings. This mechanism was intended to be usable by realm guests since they need to dynamically share dma buffers with the host by "decrypting" them - which for Arm CCA, means marking them as shared in the page tables. However, it turns out that the mechanism was failing for realm guests because realms need to share their dma buffers (via __set_memory_enc_dec()) much earlier during boot than split_kernel_leaf_mapping() was able to handle. The report linked below showed that GIC's ITS was one such user. But during the investigation I found other callsites that could not meet the split_kernel_leaf_mapping() constraints. The problem is that we block map the linear map based on the boot CPU supporting BBML2_NOABORT, then check that all the other CPUs support it too when finalizing the caps. If they don't, then we stop_machine() and split to ptes. For safety, split_kernel_leaf_mapping() previously wouldn't permit splitting until after the caps were finalized. That ensured that if any secondary cpus were running that didn't support BBML2_NOABORT, we wouldn't risk breaking them. I've fix this problem by reducing the black-out window where we refuse to split; there are now 2 windows. The first is from T0 until the page allocator is inititialized. Splitting allocates memory for the page allocator so it must be in use. The second covers the period between starting to online the secondary cpus until the system caps are finalized (this is a very small window). All of the problematic callers are calling __set_memory_enc_dec() before the secondary cpus come online, so this solves the problem. However, one of these callers, swiotlb_update_mem_attributes(), was trying to split before the page allocator was initialized. So I have moved this call from arch_mm_preinit() to mem_init(), which solves the ordering issue. I've added warnings and return an error if any attempt is made to split in the black-out windows. Note there are other issues which prevent booting all the way to user space, which will be fixed in subsequent patches. Reported-by: Jinjiang Tu <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Fixes: a166563e7ec3 ("arm64: mm: support large block mapping when rodata=full") Cc: [email protected] Reviewed-by: Kevin Brodsky <[email protected]> Signed-off-by: Ryan Roberts <[email protected]> Reviewed-by: Suzuki K Poulose <[email protected]> Tested-by: Suzuki K Poulose <[email protected]> Signed-off-by: Catalin Marinas <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Brian Ruley <[email protected]> Date: Wed Apr 15 18:12:48 2026 +0100 ARM: 9472/1: fix race condition on PG_dcache_clean in __sync_icache_dcache() commit 75f9a484e817adea211c73f89ed938a2b2f90953 upstream. This bug was already discovered and fixed for arm64 in commit 588a513d3425 ("arm64: Fix race condition on PG_dcache_clean in __sync_icache_dcache()"). Verified with added instrumentation to track dcache flushes in a ring buffer, as shown by the (distilled) output: kernel: SIGILL at b6b80ac0 cpu 1 pid 32663 linux_pte=8eff659f hw_pte=8eff6e7e young=1 exec=1 kernel: dcache flush START cpu0 pfn=8eff6 ts=48629557020154 kernel: dcache flush SKIPPED cpu1 pfn=8eff6 ts=48629557020154 kernel: dcache flush FINISH cpu0 pfn=8eff6 ts=48629557036154 audisp-syslog: comm="journalctl" exe="/usr/bin/journalctl" sig=4 [...] Discussions in the mailing list mentioned that arch/arm is also affected but the fix was never applied to it [1][2]. Apply the change now, since the race condition can cause sporadic SIGILL's and SEGV's especially while under high memory pressure. Link: https://lore.kernel.org/all/adzMOdySgMIePcue@willie-the-truck [1] Link: https://lore.kernel.org/all/[email protected] [2] Signed-off-by: Brian Ruley <[email protected]> Reviewed-by: Will Deacon <[email protected]> Cc: <[email protected]> Fixes: 6012191aa9c6 ("ARM: 6380/1: Introduce __sync_icache_dcache() for VIPT caches") Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Russell King (Oracle) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Damien Le Moal <[email protected]> Date: Fri Feb 27 22:19:45 2026 +0900 block: fix zone write plugs refcount handling in disk_zone_wplug_schedule_bio_work() commit 0a8b8af896e0ef83e188e1fe20f98f2bbb1c2459 upstream. The function disk_zone_wplug_schedule_bio_work() always takes a reference on the zone write plug of the BIO work being scheduled. This ensures that the zone write plug cannot be freed while the BIO work is being scheduled but has not run yet. However, this unconditional reference taking is fragile since the reference taken is released by the BIO work blk_zone_wplug_bio_work() function, which implies that there always must be a 1:1 relation between the work being scheduled and the work running. Make sure to drop the reference taken when scheduling the BIO work if the work is already scheduled, that is, when queue_work() returns false. Fixes: 9e78c38ab30b ("block: Hold a reference on zone write plugs to schedule submission") Cc: [email protected] Signed-off-by: Damien Le Moal <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Bart Van Assche <[email protected]> Reviewed-by: Johannes Thumshirn <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Naman Jain <[email protected]> Date: Fri Apr 10 15:34:14 2026 +0000 block: relax pgmap check in bio_add_page for compatible zone device pages commit 41c665aae2b5dbecddddcc8ace344caf630cc7a4 upstream. bio_add_page() and bio_integrity_add_page() reject pages from different dev_pagemaps entirely, returning 0 even when those pages have compatible DMA mapping requirements. This forces callers to start a new bio when buffers span pgmap boundaries, even though the pages could safely coexist as separate bvec entries. This matters for guests where memory is registered through devm_memremap_pages() with MEMORY_DEVICE_GENERIC in multiple calls, creating separate dev_pagemaps for each chunk. When a direct I/O buffer spans two such chunks, bio_add_page() rejects the second page, forcing an unnecessary bio split or I/O failure. Introduce zone_device_pages_compatible() in blk.h to check whether two pages can coexist in the same bio as separate bvec entries. The block DMA iterator (blk_dma_map_iter_start) caches the P2PDMA mapping state from the first segment and applies it to all others, so P2PDMA pages from different pgmaps must not be mixed, and neither must P2PDMA and non-P2PDMA pages. All other combinations (MEMORY_DEVICE_GENERIC pages from different pgmaps, or MEMORY_DEVICE_GENERIC with normal RAM) use the same dma_map_phys path and are safe. Replace the blanket zone_device_pages_have_same_pgmap() rejection with zone_device_pages_compatible(), while keeping zone_device_pages_have_same_pgmap() as a merge guard. Pages from different pgmaps can be added as separate bvec entries but must not be coalesced into the same segment, as that would make it impossible to recover the correct pgmap via page_pgmap(). Fixes: 49580e690755 ("block: add check when merging zone device pages") Cc: [email protected] Signed-off-by: Naman Jain <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Shuvam Pandey <[email protected]> Date: Thu Apr 9 00:32:30 2026 +0545 Bluetooth: hci_event: fix potential UAF in SSP passkey handlers commit 85fa3512048793076eef658f66489112dcc91993 upstream. hci_conn lookup and field access must be covered by hdev lock in hci_user_passkey_notify_evt() and hci_keypress_notify_evt(), otherwise the connection can be freed concurrently. Extend the hci_dev_lock critical section to cover all conn usage in both handlers. Keep the existing keypress notification behavior unchanged by routing the early exits through a common unlock path. Fixes: 92a25256f142 ("Bluetooth: mgmt: Implement support for passkey notification") Cc: [email protected] Signed-off-by: Shuvam Pandey <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Qiang Yu <[email protected]> Date: Tue Mar 3 01:02:13 2026 -0800 bus: mhi: host: pci_generic: Switch to async power up to avoid boot delays commit cfdb41adf1c2822ad1b1791d4d11093edb5582b6 upstream. Some modem devices can take significant time (up to 20 secs for sdx75) to enter mission mode during initialization. Currently, mhi_sync_power_up() waits for this entire process to complete, blocking other driver probes and delaying system boot. Switch to mhi_async_power_up() so probe can return immediately while MHI initialization continues in the background. This eliminates lengthy boot delays and allows other drivers to probe in parallel, improving overall system boot performance. Fixes: 5571519009d0 ("bus: mhi: host: pci_generic: Add SDX75 based modem support") Signed-off-by: Qiang Yu <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Johan Hovold <[email protected]> Date: Fri Mar 27 11:45:20 2026 +0100 can: ucan: fix devres lifetime commit fed4626501c871890da287bec62a96e52da1af89 upstream. USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the control message buffer lifetime so that it is released on driver unbind. Fixes: 9f2d3eae88d2 ("can: ucan: add driver for Theobroma Systems UCAN devices") Cc: [email protected] # 4.19 Cc: Jakob Unterwurzacher <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sam Edwards <[email protected]> Date: Tue Mar 17 19:37:33 2026 -0700 ceph: fix num_ops off-by-one when crypto allocation fails commit a0d9555bf9eaeba34fe6b6bb86f442fe08ba3842 upstream. move_dirty_folio_in_page_array() may fail if the file is encrypted, the dirty folio is not the first in the batch, and it fails to allocate a bounce buffer to hold the ciphertext. When that happens, ceph_process_folio_batch() simply redirties the folio and flushes the current batch -- it can retry that folio in a future batch. However, if this failed folio is not contiguous with the last folio that did make it into the batch, then ceph_process_folio_batch() has already incremented `ceph_wbc->num_ops`; because it doesn't follow through and add the discontiguous folio to the array, ceph_submit_write() -- which expects that `ceph_wbc->num_ops` accurately reflects the number of contiguous ranges (and therefore the required number of "write extent" ops) in the writeback -- will panic the kernel: BUG_ON(ceph_wbc->op_idx + 1 != req->r_num_ops); This issue can be reproduced on affected kernels by writing to fscrypt-enabled CephFS file(s) with a 4KiB-written/4KiB-skipped/repeat pattern (total filesize should not matter) and gradually increasing the system's memory pressure until a bounce buffer allocation fails. Fix this crash by decrementing `ceph_wbc->num_ops` back to the correct value when move_dirty_folio_in_page_array() fails, but the folio already started counting a new (i.e. still-empty) extent. The defect corrected by this patch has existed since 2022 (see first `Fixes:`), but another bug blocked multi-folio encrypted writeback until recently (see second `Fixes:`). The second commit made it into 6.18.16, 6.19.6, and 7.0-rc1, unmasking the panic in those versions. This patch therefore fixes a regression (panic) introduced by cac190c7674f. Cc: [email protected] Fixes: d55207717ded ("ceph: add encryption support to writepage and writepages") Fixes: cac190c7674f ("ceph: fix write storm on fscrypted files") Signed-off-by: Sam Edwards <[email protected]> Reviewed-by: Viacheslav Dubeyko <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Max Kellermann <[email protected]> Date: Fri Mar 27 17:23:08 2026 +0100 ceph: only d_add() negative dentries when they are unhashed commit 803447f93d75ab6e40c85e6d12b5630d281d70d6 upstream. Ceph can call d_add(dentry, NULL) on a negative dentry that is already present in the primary dcache hash. In the current VFS that is not safe. d_add() goes through __d_add() to __d_rehash(), which unconditionally reinserts dentry->d_hash into the hlist_bl bucket. If the dentry is already hashed, reinserting the same node can corrupt the bucket, including creating a self-loop. Once that happens, __d_lookup() can spin forever in the hlist_bl walk, typically looping only on the d_name.hash mismatch check and eventually triggering RCU stall reports like this one: rcu: INFO: rcu_sched self-detected stall on CPU rcu: 87-....: (2100 ticks this GP) idle=3a4c/1/0x4000000000000000 softirq=25003319/25003319 fqs=829 rcu: (t=2101 jiffies g=79058445 q=698988 ncpus=192) CPU: 87 UID: 2952868916 PID: 3933303 Comm: php-cgi8.3 Not tainted 6.18.17-i1-amd #950 NONE Hardware name: Dell Inc. PowerEdge R7615/0G9DHV, BIOS 1.6.6 09/22/2023 RIP: 0010:__d_lookup+0x46/0xb0 Code: c1 e8 07 48 8d 04 c2 48 8b 00 49 89 fc 49 89 f5 48 89 c3 48 83 e3 fe 48 83 f8 01 77 0f eb 2d 0f 1f 44 00 00 48 8b 1b 48 85 db <74> 20 39 6b 18 75 f3 48 8d 7b 78 e8 ba 85 d0 00 4c 39 63 10 74 1f RSP: 0018:ff745a70c8253898 EFLAGS: 00000282 RAX: ff26e470054cb208 RBX: ff26e470054cb208 RCX: 000000006e958966 RDX: ff26e48267340000 RSI: ff745a70c82539b0 RDI: ff26e458f74655c0 RBP: 000000006e958966 R08: 0000000000000180 R09: 9cd08d909b919a89 R10: ff26e458f74655c0 R11: 0000000000000000 R12: ff26e458f74655c0 R13: ff745a70c82539b0 R14: d0d0d0d0d0d0d0d0 R15: 2f2f2f2f2f2f2f2f FS: 00007f5770896980(0000) GS:ff26e482c5d88000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5764de50c0 CR3: 000000a72abb5001 CR4: 0000000000771ef0 PKRU: 55555554 Call Trace: <TASK> lookup_fast+0x9f/0x100 walk_component+0x1f/0x150 link_path_walk+0x20e/0x3d0 path_lookupat+0x68/0x180 filename_lookup+0xdc/0x1e0 vfs_statx+0x6c/0x140 vfs_fstatat+0x67/0xa0 __do_sys_newfstatat+0x24/0x60 do_syscall_64+0x6a/0x230 entry_SYSCALL_64_after_hwframe+0x76/0x7e This is reachable with reused cached negative dentries. A Ceph lookup or atomic_open can be handed a negative dentry that is already hashed, and fs/ceph/dir.c then hits one of two paths that incorrectly assume "negative" also means "unhashed": - ceph_finish_lookup(): MDS reply is -ENOENT with no trace -> d_add(dentry, NULL) - ceph_lookup(): local ENOENT fast path for a complete directory with shared caps -> d_add(dentry, NULL) Both paths can therefore re-add an already-hashed negative dentry. Ceph already uses the correct pattern elsewhere: ceph_fill_trace() only calls d_add(dn, NULL) for a negative null-dentry reply when d_unhashed(dn) is true. Fix both fs/ceph/dir.c sites the same way: only call d_add() for a negative dentry when it is actually unhashed. If the negative dentry is already hashed, leave it in place and reuse it as-is. This preserves the existing behavior for unhashed dentries while avoiding d_hash list corruption for reused hashed negatives. Cc: [email protected] Fixes: 2817b000b02c ("ceph: directory operations") Signed-off-by: Max Kellermann <[email protected]> Reviewed-by: Viacheslav Dubeyko <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Arnd Bergmann <[email protected]> Date: Fri Mar 6 17:33:07 2026 +0100 check-uapi: link into shared objects commit a261f6dff3c1653c19c065c3b3650c625447b8a7 upstream. While testing ABI changes across all architectures, I found that abidiff sometimes produces nonsensical output. Further debugging identified missing or broken libelf support for architecture specific relocations in ET_REL binaries as the source of the problem[1]. Change the script to no longer produce a relocatable object file but instead create a shared library for each header. This makes abidiff work for all of the architectures in upstream linux kernels. Link: https://sourceware.org/bugzilla/show_bug.cgi?id=33869 Cc: [email protected] Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Thomas Weißschuh <[email protected]> Acked-by: Nathan Chancellor <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Nicolas Schier <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Giovanni Cabiddu <[email protected]> Date: Thu Apr 16 18:07:00 2026 +0100 crypto: acomp - fix wrong pointer stored by acomp_save_req() commit d7e20b9bd6c990773cf0c09e2642250b8a70263d upstream. acomp_save_req() stores &req->chain in req->base.data. When acomp_reqchain_done() is invoked on asynchronous completion, it receives &req->chain as the data argument but casts it directly to struct acomp_req. Since data points to the chain member, all subsequent field accesses are at a wrong offset, resulting in memory corruption. The issue occurs when an asynchronous hardware implementation, such as the QAT driver, completes a request that uses the DMA virtual address interface (e.g. acomp_request_set_src_dma()). This combination causes crypto_acomp_compress() to enter the acomp_do_req_chain() path, which sets acomp_reqchain_done() as the completion callback via acomp_save_req(). With KASAN enabled, this manifests as a general protection fault in acomp_reqchain_done(): general protection fault, probably for non-canonical address 0xe000040000000000 KASAN: probably user-memory-access in range [0x0000400000000000-0x0000400000000007] RIP: 0010:acomp_reqchain_done+0x15b/0x4e0 Call Trace: <IRQ> qat_comp_alg_callback+0x5d/0xa0 [intel_qat] adf_ring_response_handler+0x376/0x8b0 [intel_qat] adf_response_handler+0x60/0x170 [intel_qat] tasklet_action_common+0x223/0x820 handle_softirqs+0x1ab/0x640 </IRQ> Fix this by storing the request itself in req->base.data instead of &req->chain, so that acomp_reqchain_done() receives the correct pointer. Simplify acomp_restore_req() accordingly to access req->chain directly. Fixes: 64929fe8c0a4 ("crypto: acomp - Remove request chaining") Cc: [email protected] Signed-off-by: Giovanni Cabiddu <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Douya Le <[email protected]> Date: Sun Apr 19 16:52:59 2026 +0800 crypto: algif_aead - snapshot IV for async AEAD requests commit 5aa58c3a572b3e3b6c786953339f7978b845cc52 upstream. AF_ALG AEAD AIO requests currently use the socket-wide IV buffer during request processing. For async requests, later socket activity can update that shared state before the original request has fully completed, which can lead to inconsistent IV handling. Snapshot the IV into per-request storage when preparing the AEAD request, so in-flight operations no longer depend on mutable socket state. Fixes: d887c52d6ae4 ("crypto: algif_aead - overhaul memory management") Cc: [email protected] Reported-by: Yuan Tan <[email protected]> Reported-by: Yifan Wu <[email protected]> Reported-by: Juefei Pu <[email protected]> Reported-by: Xin Liu <[email protected]> Co-developed-by: Luxing Yin <[email protected]> Signed-off-by: Luxing Yin <[email protected]> Tested-by: Yucheng Lu <[email protected]> Signed-off-by: Douya Le <[email protected]> Signed-off-by: Ren Wei <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Cc: Eric Biggers <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Biggers <[email protected]> Date: Wed Feb 18 13:34:49 2026 -0800 crypto: arm64/aes - Fix 32-bit aes_mac_update() arg treated as 64-bit commit f8f08d7cc43237e91e3aedf7b67d015d24c38fcc upstream. Since the 'enc_after' argument to neon_aes_mac_update() and ce_aes_mac_update() has type 'int', it needs to be accessed using the corresponding 32-bit register, not the 64-bit register. The upper half of the corresponding 64-bit register may contain garbage. Fixes: 4860620da7e5 ("crypto: arm64/aes - add NEON/Crypto Extensions CBCMAC/CMAC/XCBC driver") Cc: [email protected] Reviewed-by: Ard Biesheuvel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thorsten Blum <[email protected]> Date: Wed Mar 11 03:07:35 2026 +0100 crypto: atmel-aes - Fix 3-page memory leak in atmel_aes_buff_cleanup commit 3fcfff4ed35f963380a68741bcd52742baff7f76 upstream. atmel_aes_buff_init() allocates 4 pages using __get_free_pages() with ATMEL_AES_BUFFER_ORDER, but atmel_aes_buff_cleanup() frees only the first page using free_page(), leaking the remaining 3 pages. Use free_pages() with ATMEL_AES_BUFFER_ORDER to fix the memory leak. Fixes: bbe628ed897d ("crypto: atmel-aes - improve performances of data transfer") Cc: [email protected] Signed-off-by: Thorsten Blum <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thorsten Blum <[email protected]> Date: Fri Feb 20 15:03:13 2026 +0100 crypto: atmel-ecc - Release client on allocation failure commit 095d50008d55d13f8fcf1bbeb7c6eba51779bc85 upstream. Call atmel_ecc_i2c_client_free() to release the I2C client reserved by atmel_ecc_i2c_client_alloc() when crypto_alloc_kpp() fails. Otherwise ->tfm_count will be out of sync. Fixes: 11105693fa05 ("crypto: atmel-ecc - introduce Microchip / Atmel ECC driver") Cc: [email protected] Signed-off-by: Thorsten Blum <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thorsten Blum <[email protected]> Date: Sun Feb 15 21:51:53 2026 +0100 crypto: atmel-sha204a - Fix error codes in OTP reads commit 094c276da6a0d4971c3faae09a36b51d096659b2 upstream. Return -EINVAL from atmel_i2c_init_read_otp_cmd() on invalid addresses instead of -1. Since the OTP zone is accessed in 4-byte blocks, valid addresses range from 0 to OTP_ZONE_SIZE / 4 - 1. Fix the bounds check accordingly. In atmel_sha204a_otp_read(), propagate the actual error code from atmel_i2c_init_read_otp_cmd() instead of -1. Also, return -EIO instead of -EINVAL when the device is not ready. Cc: [email protected] Fixes: e05ce444e9e5 ("crypto: atmel-sha204a - add reading from otp zone") Signed-off-by: Thorsten Blum <[email protected]> Reviewed-by: Lothar Rubusch <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thorsten Blum <[email protected]> Date: Mon Feb 16 08:45:51 2026 +0100 crypto: atmel-sha204a - Fix OTP sysfs read and error handling commit 635c3a757a567b2479639237f5f0d4d9439015f1 upstream. Fix otp_show() to read and print all 64 bytes of the OTP zone. Previously, the loop only printed half of the OTP (32 bytes), and partial output was returned on read errors. Propagate the actual error from atmel_sha204a_otp_read() instead of producing partial output. Replace sprintf() with sysfs_emit_at(), which is preferred for formatting sysfs output because it provides safer bounds checking. Cc: [email protected] Fixes: 13909a0c8897 ("crypto: atmel-sha204a - provide the otp content") Signed-off-by: Thorsten Blum <[email protected]> Reviewed-by: Lothar Rubusch <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thorsten Blum <[email protected]> Date: Sat Mar 14 20:36:29 2026 +0100 crypto: atmel-sha204a - Fix potential UAF and memory leak in remove path commit bab1adf3b87e4bfac92c4f5963c63db434d561c1 upstream. Unregister the hwrng to prevent new ->read() calls and flush the Atmel I2C workqueue before teardown to prevent a potential UAF if a queued callback runs while the device is being removed. Drop the early return to ensure sysfs entries are removed and ->hwrng.priv is freed, preventing a memory leak. Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A random number generator") Cc: [email protected] Signed-off-by: Thorsten Blum <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thorsten Blum <[email protected]> Date: Fri Feb 20 14:31:36 2026 +0100 crypto: atmel-sha204a - Fix uninitialized data access on OTP read error commit de4e66b763d1e81188cb2803ec109466582fc9d1 upstream. Return early if atmel_i2c_send_receive() fails to avoid checking potentially uninitialized data in 'cmd.data'. Cc: [email protected] Fixes: e05ce444e9e5 ("crypto: atmel-sha204a - add reading from otp zone") Signed-off-by: Thorsten Blum <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thorsten Blum <[email protected]> Date: Sat Mar 7 16:31:10 2026 +0100 crypto: atmel-tdes - fix DMA sync direction commit c8a9a647532f5c2a04180352693215e24e9dba03 upstream. Before DMA output is consumed by the CPU, ->dma_addr_out must be synced with dma_sync_single_for_cpu() instead of dma_sync_single_for_device(). Using the wrong direction can return stale cache data on non-coherent platforms. Fixes: 13802005d8f2 ("crypto: atmel - add Atmel DES/TDES driver") Fixes: 1f858040c2f7 ("crypto: atmel-tdes - add support for latest release of the IP (0x700)") Cc: [email protected] Signed-off-by: Thorsten Blum <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yucheng Lu <[email protected]> Date: Wed Apr 22 21:45:04 2026 +0800 crypto: authencesn - reject short ahash digests during instance creation commit 5db6ef9847717329f12c5ea8aba7e9f588a980c0 upstream. authencesn requires either a zero authsize or an authsize of at least 4 bytes because the ESN encrypt/decrypt paths always move 4 bytes of high-order sequence number data at the end of the authenticated data. While crypto_authenc_esn_setauthsize() already rejects explicit non-zero authsizes in the range 1..3, crypto_authenc_esn_create() still copied auth->digestsize into inst->alg.maxauthsize without validating it. The AEAD core then initialized the tfm's default authsize from that value. As a result, selecting an ahash with digest size 1..3, such as cbcmac(cipher_null), exposed authencesn instances whose default authsize was invalid even though setauthsize() would have rejected the same value. AF_ALG could then trigger the ESN tail handling with a too-short tag and hit an out-of-bounds access. Reject authencesn instances whose ahash digest size is in the invalid non-zero range 1..3 so that no tfm can inherit an unsupported default authsize. Fixes: f15f05b0a5de ("crypto: ccm - switch to separate cbcmac driver") Cc: [email protected] Reported-by: Yifan Wu <[email protected]> Reported-by: Juefei Pu <[email protected]> Co-developed-by: Yuan Tan <[email protected]> Signed-off-by: Yuan Tan <[email protected]> Suggested-by: Xin Liu <[email protected]> Tested-by: Yuhang Zheng <[email protected]> Reviewed-by: Eric Biggers <[email protected]> Signed-off-by: Yucheng Lu <[email protected]> Signed-off-by: Ren Wei <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Haoxiang Li <[email protected]> Date: Mon Mar 30 11:34:02 2026 +0800 crypto: ccree - fix a memory leak in cc_mac_digest() commit 02c64052fad03699b9c6d1df2f9b444d17e4ac50 upstream. Add cc_unmap_result() if cc_map_hash_request_final() fails to prevent potential memory leak. Fixes: 63893811b0fc ("crypto: ccree - add ahash support") Cc: [email protected] Signed-off-by: Haoxiang Li <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thomas Fourier <[email protected]> Date: Mon Mar 30 17:19:32 2026 +0200 crypto: hisilicon - Fix dma_unmap_single() direction commit 1ee57ab93b75eb59f426aef37b5498a7ffc28278 upstream. The direction used to map the buffer skreq->iv is DMA_TO_DEVICE but it is unmapped with direction DMA_BIDIRECTIONAL in the error path. Change the unmap to match the mapping. Fixes: 915e4e8413da ("crypto: hisilicon - SEC security accelerator driver") Cc: <[email protected]> Signed-off-by: Thomas Fourier <[email protected]> Reviewed-by: Thorsten Blum <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thorsten Blum <[email protected]> Date: Wed Mar 11 16:56:47 2026 +0100 crypto: nx - fix bounce buffer leaks in nx842_crypto_{alloc,free}_ctx commit adb3faf2db1a66d0f015b44ac909a32dfc7f2f9c upstream. The bounce buffers are allocated with __get_free_pages() using BOUNCE_BUFFER_ORDER (order 2 = 4 pages), but both the allocation error path and nx842_crypto_free_ctx() release the buffers with free_page(). Use free_pages() with the matching order instead. Fixes: ed70b479c2c0 ("crypto: nx - add hardware 842 crypto comp alg") Cc: [email protected] Signed-off-by: Thorsten Blum <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thorsten Blum <[email protected]> Date: Wed Mar 11 16:56:49 2026 +0100 crypto: nx - fix context leak in nx842_crypto_free_ctx commit 344e6a4f7ff4756b9b3f75e0eb7eaec297e35540 upstream. Since the scomp conversion, nx842_crypto_alloc_ctx() allocates the context separately, but nx842_crypto_free_ctx() never releases it. Add the missing kfree(ctx) to nx842_crypto_free_ctx(), and reuse nx842_crypto_free_ctx() in the allocation error path. Fixes: 980b5705f4e7 ("crypto: nx - Migrate to scomp API") Cc: [email protected] Signed-off-by: Thorsten Blum <[email protected]> Reviewed-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Gustavo A. R. Silva <[email protected]> Date: Tue Mar 17 17:40:02 2026 -0600 crypto: nx - Fix packed layout in struct nx842_crypto_header commit b0bfa49c03e3c65737eafa73d8a698eaf55379a6 upstream. struct nx842_crypto_header is declared with the __packed attribute, however the fields grouped with struct_group_tagged() were not packed. This caused the grouped header portion of the structure to lose the packed layout guarantees of the containing structure. Fix this by replacing struct_group_tagged() with __struct_group(..., ..., __packed, ...) so the grouped fields are packed, and the original layout is preserved, restoring the intended packed layout of the structure. Before changes: struct nx842_crypto_header { union { struct { __be16 magic; /* 0 2 */ __be16 ignore; /* 2 2 */ u8 groups; /* 4 1 */ }; /* 0 6 */ struct nx842_crypto_header_hdr hdr; /* 0 6 */ }; /* 0 6 */ struct nx842_crypto_header_group group[]; /* 6 0 */ /* size: 6, cachelines: 1, members: 2 */ /* last cacheline: 6 bytes */ } __attribute__((__packed__)); After changes: struct nx842_crypto_header { union { struct { __be16 magic; /* 0 2 */ __be16 ignore; /* 2 2 */ u8 groups; /* 4 1 */ } __attribute__((__packed__)); /* 0 5 */ struct nx842_crypto_header_hdr hdr; /* 0 5 */ }; /* 0 5 */ struct nx842_crypto_header_group group[]; /* 5 0 */ /* size: 5, cachelines: 1, members: 2 */ /* last cacheline: 5 bytes */ } __attribute__((__packed__)); Fixes: 1e6b251ce175 ("crypto: nx - Avoid -Wflex-array-member-not-at-end warning") Cc: [email protected] Signed-off-by: Gustavo A. R. Silva <[email protected]> Reviewed-by: Thorsten Blum <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Herbert Xu <[email protected]> Date: Thu Apr 16 17:00:50 2026 +0800 crypto: pcrypt - Fix handling of MAY_BACKLOG requests 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 <[email protected]> Fixes: 5a1436beec57 ("crypto: pcrypt - call the complete function on error") Signed-off-by: Herbert Xu <[email protected]> Cc: Eric Biggers <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Giovanni Cabiddu <[email protected]> Date: Wed Apr 1 10:31:11 2026 +0100 crypto: qat - fix IRQ cleanup on 6xxx probe failure commit 95aed2af87ec43fa7624cc81dd13d37824ad4972 upstream. When adf_dev_up() partially completes and then fails, the IRQ handlers registered during adf_isr_resource_alloc() are not detached before the MSI-X vectors are released. Since the device is enabled with pcim_enable_device(), calling pci_alloc_irq_vectors() internally registers pcim_msi_release() as a devres action. On probe failure, devres runs pcim_msi_release() which calls pci_free_irq_vectors(), tearing down the MSI-X vectors while IRQ handlers (for example 'qat0-bundle0') are still attached. This causes remove_proc_entry() warnings: [ 22.163964] remove_proc_entry: removing non-empty directory 'irq/143', leaking at least 'qat0-bundle0' Moving the devm_add_action_or_reset() before adf_dev_up() does not solve the problem since devres runs in LIFO order and pcim_msi_release(), registered later inside adf_dev_up(), would still fire before adf_device_down(). Fix by calling adf_dev_down() explicitly when adf_dev_up() fails, to properly free IRQ handlers before devres releases the MSI-X vectors. Fixes: 17fd7514ae68 ("crypto: qat - add qat_6xxx driver") Cc: [email protected] Signed-off-by: Giovanni Cabiddu <[email protected]> Reviewed-by: Ahsan Atta <[email protected]> Reviewed-by: Laurent M Coquerel <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Paul Louvel <[email protected]> Date: Mon Mar 30 12:28:18 2026 +0200 crypto: talitos - fix SEC1 32k ahash request limitation commit 655ef638a2bc3cd0a9eff99a02f83cab94a3a917 upstream. Since commit c662b043cdca ("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: [email protected] Fixes: c662b043cdca ("crypto: af_alg/hash: Support MSG_SPLICE_PAGES") Signed-off-by: Paul Louvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Paul Louvel <[email protected]> Date: Mon Mar 30 12:28:19 2026 +0200 crypto: talitos - rename first/last to first_desc/last_desc 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: [email protected] Signed-off-by: Paul Louvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Douglas Anderson <[email protected]> Date: Tue Mar 17 09:01:20 2026 -0700 device property: Make modifications of fwnode "flags" thread safe 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: [email protected] Fixes: c2c724c868c4 ("driver core: Add fw_devlink_parse_fwtree()") Reviewed-by: Andy Shevchenko <[email protected]> Acked-by: Mark Brown <[email protected]> Reviewed-by: Wolfram Sang <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Rafael J. Wysocki (Intel) <[email protected]> Reviewed-by: Saravana Kannan <[email protected]> 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 <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Junrui Luo <[email protected]> Date: Sun Mar 1 21:10:58 2026 +0800 dm mirror: fix integer overflow in create_dirty_log() commit 4c788c6f921b22f9b6c3f316c4a071c05683e7de upstream. The argument count calculation in create_dirty_log() performs `*args_used = 2 + param_count` before validating against argc. When a user provides a param_count close to UINT_MAX via the device mapper table string, this unsigned addition wraps around to a small value, causing the subsequent `argc < *args_used` check to be bypassed. The overflowed param_count is then passed as argc to dm_dirty_log_create(), where it can cause out-of-bounds reads on the argv array. Fix by comparing param_count against argc - 2 before performing the addition, following the same pattern used by parse_features() in the same file. Since argc >= 2 is already guaranteed, the subtraction is safe. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: [email protected] Reported-by: Yuhao Jiang <[email protected]> Signed-off-by: Junrui Luo <[email protected]> Reviewed-by: Benjamin Marzinski <[email protected]> Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Douglas Anderson <[email protected]> Date: Mon Apr 13 19:59:11 2026 -0700 driver core: Add kernel-doc for DEV_FLAG_COUNT enum value commit 5b484311507b5d403c1f7a45f6aa3778549e268b upstream. Even though nobody should use this value (except when declaring the "flags" bitmap), kernel-doc still gets upset that it's not documented. It reports: WARNING: ../include/linux/device.h:519 Enum value 'DEV_FLAG_COUNT' not described in enum 'struct_device_flags' Add the description of DEV_FLAG_COUNT. Fixes: a2225b6e834a ("driver core: Don't let a device probe until it's ready") Reported-by: Randy Dunlap <[email protected]> Closes: https://lore.kernel.org/[email protected] Signed-off-by: Douglas Anderson <[email protected]> Tested-by: Randy Dunlap <[email protected]> Reviewed-by: Randy Dunlap <[email protected]> Link: https://patch.msgid.link/20260413195910.1.I23aca74fe2d3636a47df196a80920fecb2643220@changeid Signed-off-by: Danilo Krummrich <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Douglas Anderson <[email protected]> Date: Mon Apr 6 16:22:54 2026 -0700 driver core: Don't let a device probe until it's ready commit a2225b6e834a838ae3c93709760edc0a169eb2f2 upstream. 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: [email protected] Fixes: 2023c610dc54 ("Driver core: add new device to bus's list before probing") Reviewed-by: Alan Stern <[email protected]> Reviewed-by: Rafael J. Wysocki (Intel) <[email protected]> Reviewed-by: Danilo Krummrich <[email protected]> Acked-by: Greg Kroah-Hartman <[email protected]> Acked-by: Marek Szyprowski <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patch.msgid.link/20260406162231.v5.1.Id750b0fbcc94f23ed04b7aecabcead688d0d8c17@changeid Signed-off-by: Danilo Krummrich <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Arjan van de Ven <[email protected]> Date: Mon Apr 20 14:57:15 2026 -0700 drm/amdgpu: fix zero-size GDS range init on RDNA4 commit 095a8b0ad3c3b5cdc3850d961adb8a8f735220bb upstream. RDNA4 (GFX 12) hardware removes the GDS, GWS, and OA on-chip memory resources. The gfx_v12_0 initialisation code correctly leaves adev->gds.gds_size, adev->gds.gws_size, and adev->gds.oa_size at zero to reflect this. amdgpu_ttm_init() unconditionally calls amdgpu_ttm_init_on_chip() for each of these resources regardless of size. When the size is zero, amdgpu_ttm_init_on_chip() forwards the call to ttm_range_man_init(), which calls drm_mm_init(mm, 0, 0). drm_mm_init() immediately fires DRM_MM_BUG_ON(start + size <= start) -- trivially true when size is zero -- crashing the kernel during modprobe of amdgpu on an RX 9070 XT. Guard against this by returning 0 early from amdgpu_ttm_init_on_chip() when size_in_page is zero. This skips TTM resource manager registration for hardware resources that are absent, without affecting any other GPU type. DRM_MM_BUG_ON() only asserts if CONFIG_DRM_DEBUG_MM is enabled in the kernel config. This is apparently rarely enabled as these chips have been in the market for over a year and this issue was only reported now. Link: https://lore.kernel.org/all/[email protected]%2F/ Link: https://bugzilla.kernel.org/show_bug.cgi?id=221376 Oops-Analysis: http://oops.fenrus.org/reports/bugzilla.korg/221376/report.html Assisted-by: GitHub Copilot:Claude Sonnet 4.6 linux-kernel-oops-x86. Signed-off-by: Arjan van de Ven <[email protected]> Cc: Alex Deucher <[email protected]> Cc: "Christian König" <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 5719ce5865279cad4fd5f01011fe037168503f2d) Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Luca Ceresoli <[email protected]> Date: Thu Apr 2 18:42:20 2026 +0200 drm/arcpgu: fix device node leak commit ad3ac32a3893a2bbcad545efc005a8e4e7ecf10c upstream. This function gets a device_node reference via of_graph_get_remote_port_parent() and stores it in encoder_node, but never puts that reference. Add it. There used to be a of_node_put(encoder_node) but it has been removed by mistake during a rework in commit 3ea66a794fdc ("drm/arc: Inline arcpgu_drm_hdmi_init"). Fixes: 3ea66a794fdc ("drm/arc: Inline arcpgu_drm_hdmi_init") Cc: [email protected] Reviewed-by: Louis Chauvet <[email protected]> Link: https://patch.msgid.link/20260402-drm-arcgpu-fix-device-node-leak-v2-1-d773cf754ae5@bootlin.com Signed-off-by: Luca Ceresoli <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Brajesh Gupta <[email protected]> Date: Mon Apr 27 11:01:37 2026 +0530 drm/imagination: Fix segfault when updating ftrace mask commit 5dfd429591f8d7185bf63a08b5c30863fb605611 upstream. Fix invalid data access by passing right data for debugfs entry. [ 171.549793] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 171.559248] Mem abort info: [ 171.562173] ESR = 0x0000000096000044 [ 171.566227] EC = 0x25: DABT (current EL), IL = 32 bits [ 171.573108] SET = 0, FnV = 0 [ 171.576448] EA = 0, S1PTW = 0 [ 171.579745] FSC = 0x04: level 0 translation fault [ 171.584760] Data abort info: [ 171.588012] ISV = 0, ISS = 0x00000044, ISS2 = 0x00000000 [ 171.593734] CM = 0, WnR = 1, TnD = 0, TagAccess = 0 [ 171.598962] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 171.604471] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000083837000 [ 171.611358] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 171.618500] Internal error: Oops: 0000000096000044 [#1] SMP [ 171.624222] Modules linked in: powervr drm_shmem_helper drm_gpuvm... [ 171.656580] CPU: 0 UID: 0 PID: 549 Comm: bash Not tainted 7.0.0-rc2-g730b257ba723-dirty #13 PREEMPT [ 171.665773] Hardware name: BeagleBoard.org BeaglePlay (DT) [ 171.671296] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 171.678306] pc : pvr_fw_trace_mask_set+0x78/0x154 [powervr] [ 171.683959] lr : pvr_fw_trace_mask_set+0x4c/0x154 [powervr] [ 171.689593] sp : ffff8000835ebb90 [ 171.692929] x29: ffff8000835ebc00 x28: ffff000005c60f80 x27: 0000000000000000 [ 171.700130] x26: 0000000000000000 x25: ffff00000504af28 x24: 0000000000000000 [ 171.707324] x23: ffff00000504af50 x22: 0000000000000203 x21: 0000000000000000 [ 171.714518] x20: ffff000005c44a80 x19: ffff000005c457b8 x18: 0000000000000000 [ 171.721715] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaae8887580 [ 171.728908] x14: 0000000000000000 x13: 0000000000000000 x12: ffff8000835ebc30 [ 171.736095] x11: ffff00000504af2a x10: ffff00008504af29 x9 : 0fffffffffffffff [ 171.743286] x8 : ffff8000835ebbf8 x7 : 0000000000000000 x6 : 000000000000002a [ 171.750479] x5 : ffff00000504af2e x4 : 0000000000000000 x3 : 0000000000000010 [ 171.757674] x2 : 0000000000000203 x1 : 0000000000000000 x0 : ffff8000835ebba0 [ 171.764871] Call trace: [ 171.767342] pvr_fw_trace_mask_set+0x78/0x154 [powervr] (P) [ 171.772984] simple_attr_write_xsigned.isra.0+0xe0/0x19c [ 171.778341] simple_attr_write+0x18/0x24 [ 171.782296] debugfs_attr_write+0x50/0x98 [ 171.786341] full_proxy_write+0x6c/0xa8 [ 171.790208] vfs_write+0xd4/0x350 [ 171.793561] ksys_write+0x70/0x108 [ 171.796995] __arm64_sys_write+0x1c/0x28 [ 171.800952] invoke_syscall+0x48/0x10c [ 171.804740] el0_svc_common.constprop.0+0x40/0xe0 [ 171.809487] do_el0_svc+0x1c/0x28 [ 171.812834] el0_svc+0x34/0x108 [ 171.816013] el0t_64_sync_handler+0xa0/0xe4 [ 171.820237] el0t_64_sync+0x198/0x19c [ 171.823939] Code: 32000262 b90ac293 1a931056 9134e293 (b9000036) [ 171.830073] ---[ end trace 0000000000000000 ]--- Fixes: a331631496a0 ("drm/imagination: Simplify module parameters") Signed-off-by: Brajesh Gupta <[email protected]> Reviewed-by: Alessio Belle <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Matt Coster <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Carlier <[email protected]> Date: Sat Apr 11 07:29:38 2026 +0100 drm/nouveau: fix nvkm_device leak on aperture removal failure commit 6597ff1d8de3f583be169587efeafd8af134e138 upstream. When aperture_remove_conflicting_pci_devices() fails during probe, the error path returns directly without unwinding the nvkm_device that was just allocated by nvkm_device_pci_new(). This leaks both the device wrapper and the pci_enable_device() reference taken inside it. Jump to the existing fail_nvkm label so nvkm_device_del() runs and balances both. The leak was introduced when the intermediate nvkm_device_del() between detection and aperture removal was dropped in favor of creating the pci device once. Fixes: c0bfe34330b5 ("drm/nouveau: create pci device once") Cc: [email protected] Signed-off-by: David Carlier <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Danilo Krummrich <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Greg Kroah-Hartman <[email protected]> Date: Mon Apr 20 21:16:09 2026 +0200 drm/nouveau: fix u32 overflow in pushbuf reloc bounds check 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 <[email protected]> Cc: Danilo Krummrich <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: David Airlie <[email protected]> Cc: Simona Vetter <[email protected]> Reported-by: Anthropic Cc: stable <[email protected]> Assisted-by: gkh_clanker_t1000 Fixes: a1606a9596e5 ("drm/nouveau: new gem pushbuf interface, bump to 0.0.16") Signed-off-by: Greg Kroah-Hartman <[email protected]> [ Add Fixes: tag. - Danilo ] Signed-off-by: Danilo Krummrich <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Swamil Jain <[email protected]> Date: Wed Apr 15 16:34:09 2026 +0530 dt-bindings: display: ti, am65x-dss: Fix AM62L DSS reg and clock constraints commit 9c469240997584449cfac51a75d1d3d71968c76f upstream. The AM62L DSS [1] support incorrectly used the same register and clock constraints as AM65x, but AM62L has a single video port Fix this by adding conditional constraints that properly define the register regions and clocks for AM62L DSS (single video port) versus other AM65x variants (dual video port). [1]: Section 12.7 (Display Subsystem and Peripherals) Link : https://www.ti.com/lit/pdf/sprujb4 Fixes: cb8d4323302c ("dt-bindings: display: ti,am65x-dss: Add support for AM62L DSS") Cc: [email protected] Signed-off-by: Swamil Jain <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Rob Herring (Arm) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Felix Gu <[email protected]> Date: Mon Mar 23 00:04:08 2026 +0800 EDAC/versalnet: Fix device_node leak in mc_probe() commit 5c709b376460ff322580c41600e31c02f7cc0307 upstream. of_parse_phandle() returns a device_node reference that must be released with of_node_put(). The original code never freed r5_core_node on any exit path, causing a memory leak. Fix this by using the automatic cleanup attribute __free(device_node) which ensures of_node_put() is called when the variable goes out of scope. Fixes: d5fe2fec6c40 ("EDAC: Add a driver for the AMD Versal NET DDR controller") Signed-off-by: Felix Gu <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Shubhrajyoti Datta <[email protected]> Cc: <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Prasanna Kumar T S M <[email protected]> Date: Sun Mar 22 06:11:39 2026 -0700 EDAC/versalnet: Fix memory leak in remove and probe error paths commit 1b6f292cb94d95c9bc22e1efe592daf62c60bc2e upstream. The mcdi object allocated using kzalloc() in the setup_mcdi() is not freed in the remove path or in probe's error handling path leading to a memory leak. Fix it by freeing the allocated memory. Fixes: d5fe2fec6c40d ("EDAC: Add a driver for the AMD Versal NET DDR controller") Signed-off-by: Prasanna Kumar T S M <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Gao Xiang <[email protected]> Date: Tue Apr 21 15:59:52 2026 +0800 erofs: fix the out-of-bounds nameoff handling for trailing dirents commit d18a3b5d337fa412a38e776e6b4b857a58836575 upstream. Currently we already have boundary-checks for nameoffs, but the trailing dirents are special since the namelens are calculated with strnlen() with unchecked nameoffs. If a crafted EROFS has a trailing dirent with nameoff >= maxsize, maxsize - nameoff can underflow, causing strnlen() to read past the directory block. nameoff0 should also be verified to be a multiple of `sizeof(struct erofs_dirent)` as well [1]. [1] https://sashiko.dev/#/patchset/20260416063511.3173774-1-hsiangkao%40linux.alibaba.com Fixes: 3aa8ec716e52 ("staging: erofs: add directory operations") Fixes: 33bac912840f ("staging: erofs: keep corrupted fs from crashing kernel in erofs_readdir()") Reported-by: Yuhao Jiang <[email protected]> Reported-by: Junrui Luo <[email protected]> Closes: https://lore.kernel.org/r/[email protected] Cc: [email protected] Signed-off-by: Gao Xiang <[email protected]> Reviewed-by: Chao Yu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Junrui Luo <[email protected]> Date: Thu Apr 9 21:59:39 2026 +0800 erofs: fix unsigned underflow in z_erofs_lz4_handle_overlap() commit 21e161de2dc660b1bb70ef5b156ab8e6e1cca3ab upstream. Some crafted images can have illegal (!partial_decoding && m_llen < m_plen) extents, and the LZ4 inplace decompression path can be wrongly hit, but it cannot handle (outpages < inpages) properly: "outpages - inpages" wraps to a large value and the subsequent rq->out[] access reads past the decompressed_pages array. However, such crafted cases can correctly result in a corruption report in the normal LZ4 non-inplace path. Let's add an additional check to fix this for backporting. Reproducible image (base64-encoded gzipped blob): H4sIAJGR12kCA+3SPUoDQRgG4MkmkkZk8QRbRFIIi9hbpEjrHQI5ghfwCN5BLCzTGtLbBI+g dilSJo1CnIm7GEXFxhT6PDDwfrs73/ywIQD/1ePD4r7Ou6ETsrq4mu7XcWfj++Pb58nJU/9i PNtbjhan04/9GtX4qVYc814WDqt6FaX5s+ZwXXeq52lndT6IuVvlblytLMvh4Gzwaf90nsvz 2DF/21+20T/ldgp5s1jXRaN4t/8izsy/OUB6e/Qa79r+JwAAAAAAAL52vQVuGQAAAP6+my1w ywAAAAAAAADwu14ATsEYtgBQAAA= $ mount -t erofs -o cache_strategy=disabled foo.erofs /mnt $ dd if=/mnt/data of=/dev/null bs=4096 count=1 Fixes: 598162d05080 ("erofs: support decompress big pcluster for lz4 backend") Reported-by: Yuhao Jiang <[email protected]> Cc: [email protected] Signed-off-by: Junrui Luo <[email protected]> Reviewed-by: Gao Xiang <[email protected]> Signed-off-by: Gao Xiang <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Vasiliy Kovalev <[email protected]> Date: Sat Apr 4 18:20:11 2026 +0300 ext2: reject inodes with zero i_nlink and valid mode in ext2_iget() commit 25947cc5b2374cd5bf627fe3141496444260d04f upstream. ext2_iget() already rejects inodes with i_nlink == 0 when i_mode is zero or i_dtime is set, treating them as deleted. However, the case of i_nlink == 0 with a non-zero mode and zero dtime slips through. Since ext2 has no orphan list, such a combination can only result from filesystem corruption - a legitimate inode deletion always sets either i_dtime or clears i_mode before freeing the inode. A crafted image can exploit this gap to present such an inode to the VFS, which then triggers WARN_ON inside drop_nlink() (fs/inode.c) via ext2_unlink(), ext2_rename() and ext2_rmdir(): WARNING: CPU: 3 PID: 609 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336 CPU: 3 UID: 0 PID: 609 Comm: syz-executor Not tainted 6.12.77+ #1 Call Trace: <TASK> inode_dec_link_count include/linux/fs.h:2518 [inline] ext2_unlink+0x26c/0x300 fs/ext2/namei.c:295 vfs_unlink+0x2fc/0x9b0 fs/namei.c:4477 do_unlinkat+0x53e/0x730 fs/namei.c:4541 __x64_sys_unlink+0xc6/0x110 fs/namei.c:4587 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> WARNING: CPU: 0 PID: 646 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336 CPU: 0 UID: 0 PID: 646 Comm: syz.0.17 Not tainted 6.12.77+ #1 Call Trace: <TASK> inode_dec_link_count include/linux/fs.h:2518 [inline] ext2_rename+0x35e/0x850 fs/ext2/namei.c:374 vfs_rename+0xf2f/0x2060 fs/namei.c:5021 do_renameat2+0xbe2/0xd50 fs/namei.c:5178 __x64_sys_rename+0x7e/0xa0 fs/namei.c:5223 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> WARNING: CPU: 0 PID: 634 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336 CPU: 0 UID: 0 PID: 634 Comm: syz-executor Not tainted 6.12.77+ #1 Call Trace: <TASK> inode_dec_link_count include/linux/fs.h:2518 [inline] ext2_rmdir+0xca/0x110 fs/ext2/namei.c:311 vfs_rmdir+0x204/0x690 fs/namei.c:4348 do_rmdir+0x372/0x3e0 fs/namei.c:4407 __x64_sys_unlinkat+0xf0/0x130 fs/namei.c:4577 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> Extend the existing i_nlink == 0 check to also catch this case, reporting the corruption via ext2_error() and returning -EFSCORRUPTED. This rejects the inode at load time and prevents it from reaching any of the namei.c paths. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: [email protected] Signed-off-by: Vasiliy Kovalev <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jan Kara <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Deepanshu Kartikey <[email protected]> Date: Sat Mar 28 20:30:38 2026 +0530 ext4: fix bounds check in check_xattrs() to prevent out-of-bounds access commit eceafc31ea7b42c984ece10d79d505c0bb6615d5 upstream. The bounds check for the next xattr entry in check_xattrs() uses (void *)next >= end, which allows next to point within sizeof(u32) bytes of end. On the next loop iteration, IS_LAST_ENTRY() reads 4 bytes via *(__u32 *)(entry), which can overrun the valid xattr region. For example, if next lands at end - 1, the check passes since next < end, but IS_LAST_ENTRY() reads 4 bytes starting at end - 1, accessing 3 bytes beyond the valid region. Fix this by changing the check to (void *)next + sizeof(u32) > end, ensuring there is always enough space for the IS_LAST_ENTRY() read on the subsequent iteration. Fixes: 3478c83cf26b ("ext4: improve xattr consistency checking and error reporting") Cc: [email protected] Link: https://lore.kernel.org/all/[email protected]/T/ [v1] Signed-off-by: Deepanshu Kartikey <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sohei Koyama <[email protected]> Date: Mon Apr 6 16:48:30 2026 +0900 ext4: fix missing brelse() in ext4_xattr_inode_dec_ref_all() commit 77d059519382bd66283e6a4e83ee186e87e7708f upstream. The commit c8e008b60492 ("ext4: ignore xattrs past end") introduced a refcount leak in when block_csum is false. ext4_xattr_inode_dec_ref_all() calls ext4_get_inode_loc() to get iloc.bh, but never releases it with brelse(). Fixes: c8e008b60492 ("ext4: ignore xattrs past end") Signed-off-by: Sohei Koyama <[email protected]> Reviewed-by: Andreas Dilger <[email protected]> Reviewed-by: Ritesh Harjani (IBM) <[email protected]> Cc: [email protected] Reviewed-by: Zhang Yi <[email protected]> Reviewed-by: Baokun Li <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Nathan Chancellor <[email protected]> Date: Wed Mar 25 18:19:15 2026 -0700 extract-cert: Wrap key_pass with '#ifdef USE_PKCS11_ENGINE' commit 4f96b7c68a9904e01049ef610d701b382dca9574 upstream. A recent strengthening of -Wunused-but-set-variable (enabled with -Wall) in clang under a new subwarning, -Wunused-but-set-global, points out an unused static global variable in certs/extract-cert.c: certs/extract-cert.c:46:20: error: variable 'key_pass' set but not used [-Werror,-Wunused-but-set-global] 46 | static const char *key_pass; | ^ After commit 558bdc45dfb2 ("sign-file,extract-cert: use pkcs11 provider for OPENSSL MAJOR >= 3"), key_pass is only used with the OpenSSL engine API, not the new provider API. Wrap key_pass's declaration and assignment with '#ifdef USE_PKCS11_ENGINE' so that it is only included with its use to clear up the warning. While this is a little uglier than just marking key_pass with the unused attribute, this will make it easier to clean up all code associated with the use of the engine API if it were ever removed in the future. While in the area, use a tab for the key_pass assignment line to match the rest of the file. Cc: [email protected] Fixes: 558bdc45dfb2 ("sign-file,extract-cert: use pkcs11 provider for OPENSSL MAJOR >= 3") Reviewed-by: Nick Desaulniers <[email protected]> Tested-by: Nick Desaulniers <[email protected]> Link: https://patch.msgid.link/20260325-certs-extract-cert-key_pass-unused-but-set-global-v1-1-ecf94326d532@kernel.org Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thomas Zimmermann <[email protected]> Date: Tue Feb 24 09:25:54 2026 +0100 fbdev: defio: Disconnect deferred I/O from the lifetime of struct fb_info commit 9ded47ad003f09a94b6a710b5c47f4aa5ceb7429 upstream. Hold state of deferred I/O in struct fb_deferred_io_state. Allocate an instance as part of initializing deferred I/O and remove it only after the final mapping has been closed. If the fb_info and the contained deferred I/O meanwhile goes away, clear struct fb_deferred_io_state.info to invalidate the mapping. Any access will then result in a SIGBUS signal. Fixes a long-standing problem, where a device hot-unplug happens while user space still has an active mapping of the graphics memory. The hot- unplug frees the instance of struct fb_info. Accessing the memory will operate on undefined state. Signed-off-by: Thomas Zimmermann <[email protected]> Fixes: 60b59beafba8 ("fbdev: mm: Deferred IO support") Cc: Helge Deller <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] # v2.6.22+ Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Tue Feb 24 11:42:04 2026 +0100 firmware: exynos-acpm: Drop fake 'const' on handle pointer commit a2be37eedb52ea26938fa4cc9de1ff84963c57ad upstream. All the functions operating on the 'handle' pointer are claiming it is a pointer to const thus they should not modify the handle. In fact that's a false statement, because first thing these functions do is drop the cast to const with container_of: struct acpm_info *acpm = handle_to_acpm_info(handle); And with such cast the handle is easily writable with simple: acpm->handle.ops.pmic_ops.read_reg = NULL; The code is not correct logically, either, because functions like acpm_get_by_node() and acpm_handle_put() are meant to modify the handle reference counting, thus they must modify the handle. Modification here happens anyway, even if the reference counting is stored in the container which the handle is part of. The code does not have actual visible bug, but incorrect 'const' annotations could lead to incorrect compiler decisions. Fixes: a88927b534ba ("firmware: add Exynos ACPM protocol driver") Cc: [email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thomas Zimmermann <[email protected]> Date: Tue Feb 17 16:56:12 2026 +0100 firmware: google: framebuffer: Do not mark framebuffer as busy 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 <[email protected]> Fixes: 851b4c14532d ("firmware: coreboot: Add coreboot framebuffer driver") Acked-by: Tzung-Bi Shih <[email protected]> Acked-by: Julius Werner <[email protected]> Cc: Samuel Holland <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Tzung-Bi Shih <[email protected]> Cc: Brian Norris <[email protected]> Cc: Julius Werner <[email protected]> Cc: [email protected] Cc: <[email protected]> # v4.18+ Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thomas Zimmermann <[email protected]> Date: Tue Feb 17 16:56:11 2026 +0100 firmware: google: framebuffer: Do not unregister platform device commit 5cd28bd28c8ce426b56ce4230dbd17537181d5ad upstream. The native driver takes over the framebuffer aperture by removing the system- framebuffer platform device. Afterwards the pointer in drvdata is dangling. Remove the entire logic around drvdata and let the kernel's aperture helpers handle this. The platform device depends on the native hardware device instead of the coreboot device anyway. When commit 851b4c14532d ("firmware: coreboot: Add coreboot framebuffer driver") added the coreboot framebuffer code, the kernel did not support device-based aperture management. Instead native driviers only removed the conflicting fbdev device. At that point, unregistering the framebuffer device most likely worked correctly. It was definitely broken after commit d9702b2a2171 ("fbdev/simplefb: Do not use struct fb_info.apertures"). So take this commit for the Fixes tag. Earlier releases might work depending on the native hardware driver. Signed-off-by: Thomas Zimmermann <[email protected]> Fixes: d9702b2a2171 ("fbdev/simplefb: Do not use struct fb_info.apertures") Acked-by: Tzung-Bi Shih <[email protected]> Acked-by: Julius Werner <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: Javier Martinez Canillas <[email protected]> Cc: Hans de Goede <[email protected]> Cc: [email protected] Cc: <[email protected]> # v6.3+ Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Lorenzo Stoakes (Oracle) <[email protected]> Date: Fri Mar 20 22:39:35 2026 +0000 fs: afs: revert mmap_prepare() change commit fbfc6578eaca12daa0c09df1e9ba7f2c657b49da upstream. Partially reverts commit 9d5403b1036c ("fs: convert most other generic_file_*mmap() users to .mmap_prepare()"). This is because the .mmap invocation establishes a refcount, but .mmap_prepare is called at a point where a merge or an allocation failure might happen after the call, which would leak the refcount increment. Functionality is being added to permit the use of .mmap_prepare in this case, but in the interim, we need to fix this. Link: https://lkml.kernel.org/r/08804c94e39d9102a3a8fbd12385e8aa079ba1d3.1774045440.git.ljs@kernel.org Fixes: 9d5403b1036c ("fs: convert most other generic_file_*mmap() users to .mmap_prepare()") Signed-off-by: Lorenzo Stoakes (Oracle) <[email protected]> Acked-by: Vlastimil Babka (SUSE) <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Alexandre Torgue <[email protected]> Cc: Al Viro <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Bodo Stroesser <[email protected]> Cc: Christian Brauner <[email protected]> Cc: Clemens Ladisch <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: David Howells <[email protected]> Cc: Dexuan Cui <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Haiyang Zhang <[email protected]> Cc: Jan Kara <[email protected]> Cc: Jann Horn <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: K. Y. Srinivasan <[email protected]> Cc: Liam Howlett <[email protected]> Cc: Long Li <[email protected]> Cc: Marc Dionne <[email protected]> Cc: "Martin K. Petersen" <[email protected]> Cc: Maxime Coquelin <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Mike Rapoport <[email protected]> Cc: Miquel Raynal <[email protected]> Cc: Pedro Falcato <[email protected]> Cc: Richard Weinberger <[email protected]> Cc: Ryan Roberts <[email protected]> Cc: Suren Baghdasaryan <[email protected]> Cc: Vignesh Raghavendra <[email protected]> Cc: Vlastimil Babka (SUSE) <[email protected]> Cc: Wei Liu <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Amir Goldstein <[email protected]> Date: Mon Mar 30 10:27:51 2026 +0200 fs: prepare for adding LSM blob to backing_file commit 880bd496ec72a6dcb00cb70c430ef752ba242ae7 upstream. In preparation to adding LSM blob to backing_file struct, factor out helpers init_backing_file() and backing_file_free(). Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Signed-off-by: Amir Goldstein <[email protected]> Reviewed-by: Serge Hallyn <[email protected]> [PM: use the term "LSM blob", fix comment style to match file] Signed-off-by: Paul Moore <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pengpeng Hou <[email protected]> Date: Thu Apr 2 13:40:16 2026 +0800 greybus: gb-beagleplay: bound bootloader receive buffering commit 1214bf28965ceaf584fb20d357731264dd2e10e1 upstream. cc1352_bootloader_rx() appends each serdev chunk into the fixed rx_buffer before parsing bootloader packets. The helper can keep leftover bytes between callbacks and may receive multiple packets in one callback, so a single count value is not constrained by one packet length. Check that the incoming chunk fits in the remaining receive buffer space before memcpy(). If it does not, drop the staged data and consume the bytes instead of overflowing rx_buffer. Fixes: 0cf7befa3ea2 ("greybus: gb-beagleplay: Add firmware upload API") Cc: stable <[email protected]> Signed-off-by: Pengpeng Hou <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Weigang He <[email protected]> Date: Mon Mar 30 12:08:00 2026 +0000 greybus: gb-beagleplay: fix sleep in atomic context in hdlc_tx_frames() commit 6b526dca0966f2370835765019a54319b78fca8d upstream. hdlc_append() calls usleep_range() to wait for circular buffer space, but it is called with tx_producer_lock (a spinlock) held via hdlc_tx_frames() -> hdlc_append_tx_frame()/hdlc_append_tx_u8()/etc. Sleeping while holding a spinlock is illegal and can trigger "BUG: scheduling while atomic". Fix this by moving the buffer-space wait out of hdlc_append() and into hdlc_tx_frames(), before the spinlock is acquired. The new flow: 1. Pre-calculate the worst-case encoded frame length. 2. Wait (with sleep) outside the lock until enough space is available, kicking the TX consumer work to drain the buffer. 3. Acquire the spinlock, re-verify space, and write the entire frame atomically. This ensures that sleeping only happens without any lock held, and that frames are either fully enqueued or not written at all. This bug is found by CodeQL static analysis tool (interprocedural sleep-in-atomic query) and my code review. Fixes: ec558bbfea67 ("greybus: Add BeaglePlay Linux Driver") Cc: stable <[email protected]> Cc: Ayush Singh <[email protected]> Cc: Johan Hovold <[email protected]> Cc: Alex Elder <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Signed-off-by: Weigang He <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Carlier <[email protected]> Date: Fri Apr 17 06:54:08 2026 +0100 gtp: disable BH before calling udp_tunnel_xmit_skb() commit 5638504a2aa9e1b9d72af9060df1a160cce2d379 upstream. gtp_genl_send_echo_req() runs as a generic netlink doit handler in process context with BH not disabled. It calls udp_tunnel_xmit_skb(), which eventually invokes iptunnel_xmit() — that uses __this_cpu_inc/dec on softnet_data.xmit.recursion to track the tunnel xmit recursion level. Without local_bh_disable(), the task may migrate between dev_xmit_recursion_inc() and dev_xmit_recursion_dec(), breaking the per-CPU counter pairing. The result is stale or negative recursion levels that can later produce false-positive SKB_DROP_REASON_RECURSION_LIMIT drops on either CPU. The other udp_tunnel_xmit_skb() call sites in gtp.c are unaffected: the data path runs under ndo_start_xmit and the echo response handlers run from the UDP encap rx softirq, both with BH already disabled. Fix it by disabling BH around the udp_tunnel_xmit_skb() call, mirroring commit 2cd7e6971fc2 ("sctp: disable BH before calling udp_tunnel_xmit_skb()"). Fixes: 6f1a9140ecda ("net: add xmit recursion limit to tunnel xmit functions") Cc: [email protected] Signed-off-by: David Carlier <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Aditya Garg <[email protected]> Date: Sat Apr 4 15:14:34 2026 +0530 HID: apple: ensure the keyboard backlight is off if suspending commit 1f95a6cd5ad78ed27a31a20cbd1facff6f10b33d upstream. Some users reported that upon suspending their keyboard backlight remained on. Fix this by adding the missing LED_CORE_SUSPENDRESUME flag. Cc: [email protected] Fixes: 394ba612f941 ("HID: apple: Add support for magic keyboard backlight on T2 Macs") Fixes: 9018eacbe623 ("HID: apple: Add support for keyboard backlight on certain T2 Macs.") Reported-by: André Eikmeyer <[email protected]> Tested-by: André Eikmeyer <[email protected]> Signed-off-by: Aditya Garg <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sanman Pradhan <[email protected]> Date: Fri Apr 10 00:26:19 2026 +0000 hwmon: (isl28022) Fix integer overflow in power calculation on 32-bit commit a7c0aaa50e40ffd8fd703d006d5a04b540b9ca92 upstream. isl28022_read_power() computes: *val = ((51200000L * ((long)data->gain)) / (long)data->shunt) * (long)regval; On 32-bit platforms, 'long' is 32 bits. With gain=8 and shunt=10000 (the default configuration): (51200000 * 8) / 10000 = 40960 40960 * 65535 = 2,684,313,600 This exceeds LONG_MAX (2,147,483,647), resulting in signed integer overflow. Additionally, dividing before multiplying by regval loses precision unnecessarily. Use u64 arithmetic with div_u64() and multiply before dividing to retain precision. The intermediate product cannot overflow u64 (worst case: 51200000 * 8 * 65535 = 26843136000000). Power is inherently non-negative, so unsigned types are the natural fit. Cap the result to LONG_MAX before returning it through the hwmon callback. Fixes: 39671a14df4f2 ("hwmon: (isl28022) new driver for ISL28022 power monitor") Cc: [email protected] Signed-off-by: Sanman Pradhan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thomas Weißschuh <[email protected]> Date: Wed Apr 8 20:45:50 2026 +0200 hwmon: (powerz) Avoid cacheline sharing for DMA buffer commit 3023c050af3600bf451153335dea5e073c9a3088 upstream. Depending on the architecture the transfer buffer may share a cacheline with the following mutex. As the buffer may be used for DMA, that is problematic. Use the high-level DMA helpers to make sure that cacheline sharing can not happen. Also drop the comment, as the helpers are documentation enough. https://sashiko.dev/#/message/20260408175814.934BFC19421%40smtp.kernel.org Fixes: 4381a36abdf1c ("hwmon: add POWER-Z driver") Cc: [email protected] # ca085faabb42: dma-mapping: add __dma_from_device_group_begin()/end() Signed-off-by: Thomas Weißschuh <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sanman Pradhan <[email protected]> Date: Fri Apr 10 00:25:41 2026 +0000 hwmon: (powerz) Fix missing usb_kill_urb() on signal interrupt commit b66437cb20a2d9ef201f40b675569f8ea7787c9f upstream. wait_for_completion_interruptible_timeout() returns -ERESTARTSYS when interrupted. This needs to abort the URB and return an error. No data has been received from the device so any reads from the transfer buffer are invalid. The original code tests !ret, which only catches the timeout case (0). On signal delivery (-ERESTARTSYS), !ret is false so the function skips usb_kill_urb() and falls through to read from the unfilled transfer buffer. Fix by capturing the return value into a long (matching the function return type) and handling signal (negative) and timeout (zero) cases with separate checks that both call usb_kill_urb() before returning. Fixes: 4381a36abdf1c ("hwmon: add POWER-Z driver") Cc: [email protected] Signed-off-by: Sanman Pradhan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sanman Pradhan <[email protected]> Date: Fri Apr 10 00:25:55 2026 +0000 hwmon: (pt5161l) Fix bugs in pt5161l_read_block_data() commit 24c73e93d6a756e1b8626bb259d2e07c5b89b370 upstream. Fix two bugs in pt5161l_read_block_data(): 1. Buffer overrun: The local buffer rbuf is declared as u8 rbuf[24], but i2c_smbus_read_block_data() can return up to I2C_SMBUS_BLOCK_MAX (32) bytes. The i2c-core copies the data into the caller's buffer before the return value can be checked, so the post-read length validation does not prevent a stack overrun if a device returns more than 24 bytes. Resize the buffer to I2C_SMBUS_BLOCK_MAX. 2. Unexpected positive return on length mismatch: When all three retries are exhausted because the device returns data with an unexpected length, i2c_smbus_read_block_data() returns a positive byte count. The function returns this directly, and callers treat any non-negative return as success, processing stale or incomplete buffer contents. Return -EIO when retries are exhausted with a positive return value, preserving the negative error code on I2C failure. Fixes: 1b2ca93cd0592 ("hwmon: Add driver for Astera Labs PT5161L retimer") Cc: [email protected] Signed-off-by: Sanman Pradhan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Chen Zhao <[email protected]> Date: Sun Apr 5 18:44:55 2026 +0300 IB/core: Fix zero dmac race in neighbor resolution commit 5e6de34d82b49cab9d8a42063e9cd0f22a4f31e5 upstream. dst_fetch_ha() checks nud_state without holding the neighbor lock, then copies ha under the seqlock. A race in __neigh_update() where nud_state is set to NUD_REACHABLE before ha is written allows dst_fetch_ha() to read a zero MAC address while the seqlock reports no concurrent writer. netevent_callback amplifies this by waking ALL pending addr_req workers when ANY neighbor becomes NUD_VALID. At scale (N peers resolving ARP concurrently), the hit probability scales as N^2, making it near-certain for large RDMA workloads. N(A): neigh_update(A) W(A): addr_resolve(A) | [sleep] | write_lock_bh(&A->lock) | | A->nud_state = NUD_REACHABLE | | // A->ha is still 0 | | [woken by netevent_cb() of | another neighbour] | | dst_fetch_ha(A) | | A->nud_state & NUD_VALID | | read_seqbegin(&A->ha_lock) | | snapshot = A->ha /* 0 */ | | read_seqretry(&A->ha_lock) | | return snapshot | seqlock(&A->ha_lock) | A->ha = mac_A /* too late */ | sequnlock(&A->ha_lock) | write_unlock_bh(&A->lock) The incorrect/zero mac is read and programmed in the device QP while it was not yet updated. This causes silent packet loss and eventual RETRY_EXC_ERR. Fix by holding the neighbor read lock across the nud_state check and ha copy in dst_fetch_ha(), ensuring it synchronizes with __neigh_update() which is updating while holding the write lock. Cc: [email protected] Fixes: 92ebb6a0a13a ("IB/cm: Remove now useless rcu_lock in dst_fetch_ha") Link: https://patch.msgid.link/r/[email protected] Signed-off-by: Chen Zhao <[email protected]> Reviewed-by: Parav Pandit <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tyllis Xu <[email protected]> Date: Sat Mar 14 11:58:05 2026 -0500 ibmasm: fix heap over-read in ibmasm_send_i2o_message() 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: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Yuhao Jiang <[email protected]> Cc: [email protected] Signed-off-by: Tyllis Xu <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tyllis Xu <[email protected]> Date: Sat Mar 14 11:53:54 2026 -0500 ibmasm: fix OOB reads in command_file_write due to missing size checks 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: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Yuhao Jiang <[email protected]> Cc: [email protected] Signed-off-by: Tyllis Xu <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jonathan Santos <[email protected]> Date: Mon Feb 23 08:59:26 2026 -0300 iio: adc: ad7768-1: fix one-shot mode data acquisition commit 8be19e233744961db6069da9c9ab63eb085a0447 upstream. According to the datasheet, one-shot mode requires a SYNC_IN pulse to trigger a new sample conversion. In the current implementation, No sync pulse was sent after switching to one-shot mode and reinit_completion() was called before mode switching, creating a race condition where spurious interrupts during mode change could trigger completion prematurely. Fix by sending a sync pulse after configuring one-shot mode and reinit_completion() to ensure it only waits for the actual conversion completion. Fixes: a5f8c7da3dbe ("iio: adc: Add AD7768-1 ADC basic support") Signed-off-by: Jonathan Santos <[email protected]> Reviewed-by: David Lechner <[email protected]> Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jonathan Santos <[email protected]> Date: Mon Feb 23 08:59:35 2026 -0300 iio: adc: ad7768-1: remove switch to one-shot mode commit 81fdc3127d013a552465c3bf9829afbed5184406 upstream. wideband low ripple FIR Filter is not available in one-shot mode. In order to make direct reads work for all filter options, remove the switch for one-shot mode and guarantee device is always in continuous conversion mode. Fixes: fb1d3b24ebf5 ("iio: adc: ad7768-1: add filter type and oversampling ratio attributes") Signed-off-by: Jonathan Santos <[email protected]> Reviewed-by: David Lechner <[email protected]> Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Lechner <[email protected]> Date: Sat Mar 14 16:12:24 2026 -0500 iio: adc: ti-ads7950: use iio_push_to_buffers_with_ts_unaligned() commit 7806c060cceb2d6895efbb6cff2f2f17cf1ec5de upstream. Use iio_push_to_buffers_with_ts_unaligned() to avoid unaligned access when writing the timestamp in the rx_buf. The previous implementation would have been fine on architectures that support 4-byte alignment of 64-bit integers but could cause issues on architectures that require 8-byte alignment. Fixes: 902c4b2446d4 ("iio: adc: New driver for TI ADS7950 chips") Signed-off-by: David Lechner <[email protected]> Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Antoniu Miclaus <[email protected]> Date: Sat May 2 20:40:01 2026 -0400 iio: frequency: admv1013: add dev variable [ Upstream commit e61b5bb0e91390adee41eaddc0a1a7d55d5652b2 ] Introduce a local struct device pointer in functions that reference &spi->dev for device-managed resource calls and device property reads, improving code readability. Signed-off-by: Antoniu Miclaus <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Stable-dep-of: aac0a51b1670 ("iio: frequency: admv1013: fix NULL pointer dereference on str") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Antoniu Miclaus <[email protected]> Date: Sat May 2 20:40:02 2026 -0400 iio: frequency: admv1013: fix NULL pointer dereference on str [ Upstream commit aac0a51b16700b403a55b67ba495de021db78763 ] When device_property_read_string() fails, str is left uninitialized but the code falls through to strcmp(str, ...), dereferencing a garbage pointer. Replace manual read/strcmp with device_property_match_property_string() and consolidate the SE mode enums into a single sequential enum, mapping to hardware register values via a switch consistent with other bitfields in the driver. Several cleanup patches have been applied to this driver recently so this will need a manual backport. Fixes: da35a7b526d9 ("iio: frequency: admv1013: add support for ADMV1013") Reviewed-by: Nuno Sá <[email protected]> Signed-off-by: Antoniu Miclaus <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Chia-Ming Chang <[email protected]> Date: Tue Feb 24 17:34:42 2026 +0800 inotify: fix watch count leak when fsnotify_add_inode_mark_locked() fails commit 6a320935fa4293e9e599ec9f85dc9eb3be7029f8 upstream. When fsnotify_add_inode_mark_locked() fails in inotify_new_watch(), the error path calls inotify_remove_from_idr() but does not call dec_inotify_watches() to undo the preceding inc_inotify_watches(). This leaks a watch count, and repeated failures can exhaust the max_user_watches limit with -ENOSPC even when no watches are active. Prior to commit 1cce1eea0aff ("inotify: Convert to using per-namespace limits"), the watch count was incremented after fsnotify_add_mark_locked() succeeded, so this path was not affected. The conversion moved inc_inotify_watches() before the mark insertion without adding the corresponding rollback. Add the missing dec_inotify_watches() call in the error path. Fixes: 1cce1eea0aff ("inotify: Convert to using per-namespace limits") Cc: [email protected] Signed-off-by: Chia-Ming Chang <[email protected]> Signed-off-by: robbieko <[email protected]> Reviewed-by: Nikolay Borisov <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jan Kara <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dmitry Torokhov <[email protected]> Date: Fri Apr 10 21:13:43 2026 -0700 Input: edt-ft5x06 - fix use-after-free in debugfs teardown commit f5f9e07060519e2287e99019a6de1eb3ebb65c37 upstream. The commit 68743c500c6e ("Input: edt-ft5x06 - use per-client debugfs directory") removed the manual debugfs teardown, relying on the I2C core to handle it. However, this creates a window where debugfs files are still accessible after edt_ft5x06_ts_teardown_debugfs() frees tsdata->raw_buffer. To prevent a use-after-free, protect the freeing of raw_buffer with the device mutex and set raw_buffer to NULL. The debugfs read function already checks if raw_buffer is NULL under the same mutex, so this safely avoids the use-after-free. Fixes: 68743c500c6e ("Input: edt-ft5x06 - use per-client debugfs directory") Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jens Axboe <[email protected]> Date: Tue Apr 21 13:24:33 2026 -0600 io_uring/poll: ensure EPOLL_ONESHOT is propagated for EPOLL_URING_WAKE commit 1967f0b1cafdde37aa9e08e6021c14bcc484b7a5 upstream. Commit: aacf2f9f382c ("io_uring: fix req->apoll_events") fixed an issue where poll->events and req->apoll_events weren't synchronized, but then when the commit referenced in Fixes got added, it didn't ensure the same thing. If we mask in EPOLLONESHOT in the regular EPOLL_URING_WAKE path, then ensure it's done for both. Including a link to the original report below, even though it's mostly nonsense. But it includes a reproducer that does show that IORING_CQE_F_MORE is set in the previous CQE, while no more CQEs will be generated for this request. Just ignore anything that pretends this is security related in any way, it's just the typical AI nonsense. Cc: [email protected] Link: https://lore.kernel.org/io-uring/CAM0zi7yQzF3eKncgHo4iVM5yFLAjsiob_ucqyWKs=hyd_GqiMg@mail.gmail.com/ Reported-by: Azizcan Daştan <[email protected]> Fixes: 4464853277d0 ("io_uring: pass in EPOLL_URING_WAKE for eventfd signaling and wakeups") Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Longxuan Yu <[email protected]> Date: Sun Apr 12 16:38:20 2026 +0800 io_uring/poll: fix signed comparison in io_poll_get_ownership() commit 326941b22806cbf2df1fbfe902b7908b368cce42 upstream. io_poll_get_ownership() uses a signed comparison to check whether poll_refs has reached the threshold for the slowpath: if (unlikely(atomic_read(&req->poll_refs) >= IO_POLL_REF_BIAS)) atomic_read() returns int (signed). When IO_POLL_CANCEL_FLAG (BIT(31)) is set in poll_refs, the value becomes negative in signed arithmetic, so the >= 128 comparison always evaluates to false and the slowpath is never taken. Fix this by casting the atomic_read() result to unsigned int before the comparison, so that the cancel flag is treated as a large positive value and correctly triggers the slowpath. Fixes: a26a35e9019f ("io_uring: make poll refs more robust") Cc: [email protected] Reported-by: Yifan Wu <[email protected]> Reported-by: Juefei Pu <[email protected]> Co-developed-by: Yuan Tan <[email protected]> Signed-off-by: Yuan Tan <[email protected]> Suggested-by: Xin Liu <[email protected]> Tested-by: Zhengchuan Liang <[email protected]> Signed-off-by: Longxuan Yu <[email protected]> Signed-off-by: Ren Wei <[email protected]> Reviewed-by: Pavel Begunkov <[email protected]> Link: https://patch.msgid.link/3a3508b08bcd7f1bc3beff848ae6e1d73d355043.1775965597.git.ylong030@ucr.edu Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jens Axboe <[email protected]> Date: Mon Apr 20 13:41:38 2026 -0600 io_uring/register: fix ring resizing with mixed/large SQEs/CQEs commit 45cd95763e198d74d369ede43aef0b1955b8dea4 upstream. The ring resizing only properly handles "normal" sized SQEs or CQEs, if there are pending entries around a resize. This normally should not be the case, but the code is supposed to handle this regardless. For the mixed SQE/CQE cases, the current copying works fine as they are indexed in the same way. Each half is just copied separately. But for fixed large SQEs and CQEs, the iteration and copy need to take that into account. Cc: [email protected] Fixes: 79cfe9e59c2a ("io_uring/register: add IORING_REGISTER_RESIZE_RINGS") Reviewed-by: Gabriel Krisman Bertazi <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pavel Begunkov <[email protected]> Date: Mon Mar 2 13:10:34 2026 +0000 io_uring/timeout: check unused sqe fields commit 484ae637a3e3d909718de7c07afd3bb34b6b8504 upstream. Zero check unused SQE fields addr3 and pad2 for timeout and timeout update requests. They're not needed now, but could be used sometime in the future. Cc: [email protected] Signed-off-by: Pavel Begunkov <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pavel Begunkov <[email protected]> Date: Tue Apr 21 09:47:04 2026 +0100 io_uring/zcrx: fix user_struct uaf commit 0fcccfd87152f957fa8312b841f6efef42a05a20 upstream. io_free_rbuf_ring() usees a struct user_struct, which io_zcrx_ifq_free() puts it down before destroying the ring. Cc: [email protected] Fixes: 5c686456a4e83 ("io_uring/zcrx: add user_struct and mm_struct to io_zcrx_ifq") Signed-off-by: Pavel Begunkov <[email protected]> Link: https://patch.msgid.link/e560ae00960d27a810522a7efc0e201c82dff351.1776760917.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pavel Begunkov <[email protected]> Date: Mon Mar 23 12:43:50 2026 +0000 io_uring/zcrx: return back two step unregistration commit e5361d25e241ac3a23177fa74ae91d049bad00d3 upstream. There are reports where io_uring instance removal takes too long and an ifq reallocation by another zcrx instance fails. Split zcrx destruction into two steps similarly how it was before, first close the queue early but maintain zcrx alive, and then when all inflight requests are completed, drop the main zcrx reference. For extra protection, mark terminated zcrx instances in xarray and warn if we double put them. Cc: [email protected] # 6.19+ Link: https://github.com/axboe/liburing/issues/1550 Reported-by: Youngmin Choi <[email protected]> Signed-off-by: Pavel Begunkov <[email protected]> Link: https://patch.msgid.link/0ce21f0565ab4358668922a28a8a36922dfebf76.1774261953.git.asml.silence@gmail.com [axboe: NULL ifq before break inside scoped guard] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Corey Minyard <[email protected]> Date: Mon Apr 13 08:00:23 2026 -0500 ipmi:ssif: Clean up kthread on errors commit 75c486cb1bcaa1a3ec3a6438498176a3a4998ae4 upstream. If an error occurs after the ssif kthread is created, but before the main IPMI code starts the ssif interface, the ssif kthread will not be stopped. So make sure the kthread is stopped on an error condition if it is running. Fixes: 259307074bfc ("ipmi: Add SMBus interface driver (SSIF)") Reported-by: Li Xiao <<[email protected]> Cc: [email protected] Reviewed-by: Li Xiao <[email protected]> Signed-off-by: Corey Minyard <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Corey Minyard <[email protected]> Date: Tue Apr 21 06:50:22 2026 -0500 ipmi:ssif: NULL thread on error commit a8aebe93a4938c0ca1941eeaae821738f869be3d upstream. Cleanup code was checking the thread for NULL, but it was possibly a PTR_ERR() in one spot. Spotted with static analysis. Link: https://sourceforge.net/p/openipmi/mailman/message/59324676/ Fixes: 75c486cb1bca ("ipmi:ssif: Clean up kthread on errors") Cc: <[email protected]> # 91eb7ec72612: ipmi:ssif: Remove unnecessary indention Cc: [email protected] Signed-off-by: Corey Minyard <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Corey Minyard <[email protected]> Date: Mon Apr 13 07:09:15 2026 -0500 ipmi:ssif: Remove unnecessary indention commit 91eb7ec7261254b6875909df767185838598e21e upstream. A section was in {} that didn't need to be, move the variable definition to the top and set th eindentino properly. Signed-off-by: Corey Minyard <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ruide Cao <[email protected]> Date: Tue Apr 21 12:16:31 2026 +0800 ipv4: icmp: validate reply type before using icmp_pointers commit 67bf002a2d7387a6312138210d0bd06e3cf4879b upstream. Extended echo replies use ICMP_EXT_ECHOREPLY as the outbound reply type. That value is outside the range covered by icmp_pointers[], which only describes the traditional ICMP types up to NR_ICMP_TYPES. Avoid consulting icmp_pointers[] for reply types outside that range, and use array_index_nospec() for the remaining in-range lookup. Normal ICMP replies keep their existing behavior unchanged. Fixes: d329ea5bd884 ("icmp: add response to RFC 8335 PROBE messages") Cc: [email protected] Reported-by: Yuan Tan <[email protected]> Reported-by: Yifan Wu <[email protected]> Reported-by: Juefei Pu <[email protected]> Reported-by: Xin Liu <[email protected]> Signed-off-by: Ruide Cao <[email protected]> Signed-off-by: Ren Wei <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/0dace90c01a5978e829ca741ef684dbd7304ce62.1776628519.git.caoruide123@gmail.com Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Greg Kroah-Hartman <[email protected]> Date: Tue Apr 21 15:16:33 2026 +0200 ipv6: rpl: reserve mac_len headroom when recompressed SRH grows commit 9e6bf146b55999a095bb14f73a843942456d1adc upstream. ipv6_rpl_srh_rcv() decompresses an RFC 6554 Source Routing Header, swaps the next segment into ipv6_hdr->daddr, recompresses, then pulls the old header and pushes the new one plus the IPv6 header back. The recompressed header can be larger than the received one when the swap reduces the common-prefix length the segments share with daddr (CmprI=0, CmprE>0, seg[0][0] != daddr[0] gives the maximum +8 bytes). pskb_expand_head() was gated on segments_left == 0, so on earlier segments the push consumed unchecked headroom. Once skb_push() leaves fewer than skb->mac_len bytes in front of data, skb_mac_header_rebuild()'s call to: skb_set_mac_header(skb, -skb->mac_len); will store (data - head) - mac_len into the u16 mac_header field, which wraps to ~65530, and the following memmove() writes mac_len bytes ~64KiB past skb->head. A single AF_INET6/SOCK_RAW/IPV6_HDRINCL packet over lo with a two segment type-3 SRH (CmprI=0, CmprE=15) reaches headroom 8 after one pass; KASAN reports a 14-byte OOB write in ipv6_rthdr_rcv. Fix this by expanding the head whenever the remaining room is less than the push size plus mac_len, and request that much extra so the rebuilt MAC header fits afterwards. Fixes: 8610c7c6e3bd ("net: ipv6: add support for rpl sr exthdr") Cc: stable <[email protected]> Reported-by: Anthropic Signed-off-by: Greg Kroah-Hartman <[email protected]> Link: https://patch.msgid.link/2026042133-gout-unvented-1bd9@gregkh Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zhang Yi <[email protected]> Date: Thu Apr 9 19:42:03 2026 +0800 jbd2: fix deadlock in jbd2_journal_cancel_revoke() commit 981fcc5674e67158d24d23e841523eccba19d0e7 upstream. Commit f76d4c28a46a ("fs/jbd2: use sleeping version of __find_get_block()") changed jbd2_journal_cancel_revoke() to use __find_get_block_nonatomic() which holds the folio lock instead of i_private_lock. This breaks the lock ordering (folio -> buffer) and causes an ABBA deadlock when the filesystem blocksize < pagesize: T1 T2 ext4_mkdir() ext4_init_new_dir() ext4_append() ext4_getblk() lock_buffer() <- A sync_blockdev() blkdev_writepages() writeback_iter() writeback_get_folio() folio_lock() <- B ext4_journal_get_create_access() jbd2_journal_cancel_revoke() __find_get_block_nonatomic() folio_lock() <- B block_write_full_folio() lock_buffer() <- A This can occasionally cause generic/013 to hang. Fix by only calling __find_get_block_nonatomic() when the passed buffer_head doesn't belong to the bdev, which is the only case that we need to look up its bdev alias. Otherwise, the lookup is redundant since the found buffer_head is equal to the one we passed in. Fixes: f76d4c28a46a ("fs/jbd2: use sleeping version of __find_get_block()") Signed-off-by: Zhang Yi <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Miguel Ojeda <[email protected]> Date: Tue Mar 31 22:58:48 2026 +0200 kbuild: rust: allow `clippy::uninlined_format_args` commit 10eea3c147141c90cf409b8df56d245c9d7f88d9 upstream. Clippy in Rust 1.88.0 (only) reports [1]: warning: variables can be used directly in the `format!` string --> rust/macros/module.rs:112:23 | 112 | let content = format!("{param}:{content}", param = param, content = content); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args = note: `-W clippy::uninlined-format-args` implied by `-W clippy::all` = help: to override `-W clippy::all` add `#[allow(clippy::uninlined_format_args)]` help: change this to | 112 - let content = format!("{param}:{content}", param = param, content = content); 112 + let content = format!("{param}:{content}"); warning: variables can be used directly in the `format!` string --> rust/macros/module.rs:198:14 | 198 | t => panic!("Unsupported parameter type {}", t), | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args = note: `-W clippy::uninlined-format-args` implied by `-W clippy::all` = help: to override `-W clippy::all` add `#[allow(clippy::uninlined_format_args)]` help: change this to | 198 - t => panic!("Unsupported parameter type {}", t), 198 + t => panic!("Unsupported parameter type {t}"), | The reason it only triggers in that version is that the lint was moved from `pedantic` to `style` in Rust 1.88.0 and then back to `pedantic` in Rust 1.89.0 [2][3]. In the first case, the suggestion is fair and a pure simplification, thus we will clean it up separately. To keep the behavior the same across all versions, and since the lint does not work for all macros (e.g. custom ones like `pr_info!`), disable it globally. Cc: [email protected] # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://lore.kernel.org/rust-for-linux/CANiq72=drAtf3y_DZ-2o4jb6Az9J3Yj4QYwWnbRui4sm4AJD3Q@mail.gmail.com/ [1] Link: https://github.com/rust-lang/rust-clippy/pull/15287 [2] Link: https://github.com/rust-lang/rust-clippy/issues/15151 [3] Link: https://patch.msgid.link/[email protected] Signed-off-by: Miguel Ojeda <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Steven Rostedt <[email protected]> Date: Mon Apr 20 14:24:26 2026 -0400 ktest: Fix the month in the name of the failure directory commit 768059ede35f197575a38b10797b52402d9d4d2f upstream. The Perl localtime() function returns the month starting at 0 not 1. This caused the date produced to create the directory for saving files of a failed run to have the month off by one. machine-test-useconfig-fail-20260314073628 The above happened in April, not March. The correct name should have been: machine-test-useconfig-fail-20260414073628 This was somewhat confusing. Cc: [email protected] Cc: John 'Warthog9' Hawley <[email protected]> Link: https://patch.msgid.link/20260420142426.33ad0293@fedora Fixes: 7faafbd69639b ("ktest: Add open and close console and start stop monitor") Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Marc Zyngier <[email protected]> Date: Wed Apr 1 11:36:00 2026 +0100 KVM: arm64: Account for RESx bits in __compute_fgt() commit d70d4323dd9636e35696639f6b4c2b2735291516 upstream. When computing Fine Grained Traps, it is preferable to account for the reserved bits. The HW will most probably ignore them, unless the bits have been repurposed to do something else. Use caution, and fold our view of the reserved bits in, Reviewed-by: Sascha Bischoff <[email protected]> Fixes: c259d763e6b09 ("KVM: arm64: Account for RES1 bits in DECLARE_FEAT_MAP() and co") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Zyngier <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yosry Ahmed <[email protected]> Date: Tue Mar 3 00:34:10 2026 +0000 KVM: nSVM: Add missing consistency check for EFER, CR0, CR4, and CS commit 96bd3e76a171a8e21a6387e54e4c420a81968492 upstream. According to the APM Volume #2, 15.5, Canonicalization and Consistency Checks (24593—Rev. 3.42—March 2024), the following condition (among others) results in a #VMEXIT with VMEXIT_INVALID (aka SVM_EXIT_ERR): EFER.LME, CR0.PG, CR4.PAE, CS.L, and CS.D are all non-zero. In the list of consistency checks done when EFER.LME and CR0.PG are set, add a check that CS.L and CS.D are not both set, after the existing check that CR4.PAE is set. This is functionally a nop because the nested VMRUN results in SVM_EXIT_ERR in HW, which is forwarded to L1, but KVM makes all consistency checks before a VMRUN is actually attempted. Fixes: 3d6368ef580a ("KVM: SVM: Add VMRUN handler") Cc: [email protected] Signed-off-by: Yosry Ahmed <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yosry Ahmed <[email protected]> Date: Tue Mar 3 00:34:09 2026 +0000 KVM: nSVM: Add missing consistency check for nCR3 validity commit b71138fcc362c67ebe66747bb22cb4e6b4d6a651 upstream. From the APM Volume #2, 15.25.4 (24593—Rev. 3.42—March 2024): When VMRUN is executed with nested paging enabled (NP_ENABLE = 1), the following conditions are considered illegal state combinations, in addition to those mentioned in “Canonicalization and Consistency Checks”: • Any MBZ bit of nCR3 is set. • Any G_PAT.PA field has an unsupported type encoding or any reserved field in G_PAT has a nonzero value. Add the consistency check for nCR3 being a legal GPA with no MBZ bits set. Note, the G_PAT.PA check is being handled separately[*]. Link: https://lore.kernel.org/kvm/[email protected] [*] Fixes: 4b16184c1cca ("KVM: SVM: Initialize Nested Nested MMU context on VMRUN") Cc: [email protected] Signed-off-by: Yosry Ahmed <[email protected]> Link: https://patch.msgid.link/[email protected] [sean: capture everything in CC(), massage changelog formatting] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yosry Ahmed <[email protected]> Date: Tue Mar 3 00:33:59 2026 +0000 KVM: nSVM: Always inject a #GP if mapping VMCB12 fails on nested VMRUN 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: 8c5fbf1a7231 ("KVM/nSVM: Use the new mapping API for mapping guest memory") CC: [email protected] Co-developed-by: Sean Christopherson <[email protected]> Signed-off-by: Yosry Ahmed <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Tue Mar 3 16:22:23 2026 -0800 KVM: nSVM: Always intercept VMMCALL when L2 is active commit 33d3617a52f9930d22b2af59f813c2fbdefa6dd5 upstream. Always intercept VMMCALL now that KVM properly synthesizes a #UD as appropriate, i.e. when L1 doesn't want to intercept VMMCALL, to avoid putting L2 into an infinite #UD loop if KVM_X86_QUIRK_FIX_HYPERCALL_INSN is enabled. By letting L2 execute VMMCALL natively and thus #UD, for all intents and purposes KVM morphs the VMMCALL intercept into a #UD intercept (KVM always intercepts #UD). When the hypercall quirk is enabled, KVM "emulates" VMMCALL in response to the #UD by trying to fixup the opcode to the "right" vendor, then restarts the guest, without skipping the VMMCALL. As a result, the guest sees an endless stream of #UDs since it's already executing the correct vendor hypercall instruction, i.e. the emulator doesn't anticipate that the #UD could be due to lack of interception, as opposed to a truly undefined opcode. Fixes: 0d945bd93511 ("KVM: SVM: Don't allow nested guest to VMMCALL into host") Cc: [email protected] Reviewed-by: Yosry Ahmed <[email protected]> Reviewed-by: Vitaly Kuznetsov <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yosry Ahmed <[email protected]> Date: Wed Feb 25 00:59:47 2026 +0000 KVM: nSVM: Always use NextRIP as vmcb02's NextRIP after first L2 VMRUN commit 8d397582f6b5e9fbcf09781c7c934b4910e94a50 upstream. For guests with NRIPS disabled, L1 does not provide NextRIP when running an L2 with an injected soft interrupt, instead it advances the current RIP before running it. KVM uses the current RIP as the NextRIP in vmcb02 to emulate a CPU without NRIPS. However, after L2 runs the first time, NextRIP will be updated by the CPU and/or KVM, and the current RIP is no longer the correct value to use in vmcb02. Hence, after save/restore, use the current RIP if and only if a nested run is pending, otherwise use NextRIP. Give soft_int_next_rip the same treatment, as it's the same logic, just for a narrower use case. Fixes: cc440cdad5b7 ("KVM: nSVM: implement KVM_GET_NESTED_STATE and KVM_SET_NESTED_STATE") CC: [email protected] Signed-off-by: Yosry Ahmed <[email protected]> Link: https://patch.msgid.link/[email protected] [sean: give soft_int_next_rip the same treatment] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yosry Ahmed <[email protected]> Date: Tue Mar 3 00:33:55 2026 +0000 KVM: nSVM: Avoid clearing VMCB_LBR in vmcb12 commit b53ab5167a81537777ac780bbd93d32613aa3bda upstream. svm_copy_lbrs() always marks VMCB_LBR dirty in the destination VMCB. However, nested_svm_vmexit() uses it to copy LBRs to vmcb12, and clearing clean bits in vmcb12 is not architecturally defined. Move vmcb_mark_dirty() to callers and drop it for vmcb12. This also facilitates incoming refactoring that does not pass the entire VMCB to svm_copy_lbrs(). Fixes: d20c796ca370 ("KVM: x86: nSVM: implement nested LBR virtualization") Cc: [email protected] Signed-off-by: Yosry Ahmed <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yosry Ahmed <[email protected]> Date: Tue Mar 3 00:34:05 2026 +0000 KVM: nSVM: Clear EVENTINJ fields in vmcb12 on nested #VMEXIT 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 2d8a42be0e2b ("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: 3d6368ef580a ("KVM: SVM: Add VMRUN handler") Fixes: 2d8a42be0e2b ("KVM: nSVM: synchronize VMCB controls updated by the processor on every vmexit") Cc: [email protected] Signed-off-by: Yosry Ahmed <[email protected]> Link: https://patch.msgid.link/[email protected] [sean: massage changelog formatting] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yosry Ahmed <[email protected]> Date: Tue Mar 3 00:34:04 2026 +0000 KVM: nSVM: Clear GIF on nested #VMEXIT(INVALID) 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: 3d6368ef580a ("KVM: SVM: Add VMRUN handler") Cc: [email protected] Signed-off-by: Yosry Ahmed <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yosry Ahmed <[email protected]> Date: Tue Mar 3 00:34:06 2026 +0000 KVM: nSVM: Clear tracking of L1->L2 NMI and soft IRQ on nested #VMEXIT commit 8998e1d012f3f45d0456f16706682cef04c3c436 upstream. KVM clears tracking of L1->L2 injected NMIs (i.e. nmi_l1_to_l2) and soft IRQs (i.e. soft_int_injected) on a synthesized #VMEXIT(INVALID) due to failed VMRUN. However, they are not explicitly cleared in other synthesized #VMEXITs. soft_int_injected is always cleared after the first VMRUN of L2 when completing interrupts, as any re-injection is then tracked by KVM (instead of purely in vmcb02). nmi_l1_to_l2 is not cleared after the first VMRUN if NMI injection failed, as KVM still needs to keep track that the NMI originated from L1 to avoid blocking NMIs for L1. It is only cleared when the NMI injection succeeds. KVM could synthesize a #VMEXIT to L1 before successfully injecting the NMI into L2 (e.g. due to a #NPF on L2's NMI handler in L1's NPTs). In this case, nmi_l1_to_l2 will remain true, and KVM may not correctly mask NMIs and intercept IRET when injecting an NMI into L1. Clear both nmi_l1_to_l2 and soft_int_injected in nested_svm_vmexit(), i.e. for all #VMEXITs except those that occur due to failed consistency checks, as those happen before nmi_l1_to_l2 or soft_int_injected are set. Fixes: 159fc6fa3b7d ("KVM: nSVM: Transparently handle L1 -> L2 NMI re-injection") Cc: [email protected] Signed-off-by: Yosry Ahmed <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Wed Mar 4 16:06:56 2026 -0800 KVM: nSVM: Delay setting soft IRQ RIP tracking fields until vCPU run commit c64bc6ed1764c1b7e3c0017019f743196074092f upstream. In the save+restore path, when restoring nested state, the values of RIP and CS base passed into nested_vmcb02_prepare_control() are mostly incorrect. They are both pulled from the vmcb02. For CS base, the value is only correct if system regs are restored before nested state. The value of RIP is whatever the vCPU had in vmcb02 before restoring nested state (zero on a freshly created vCPU). Instead, take a similar approach to NextRIP, and delay initializing the RIP tracking fields until shortly before the vCPU is run, to make sure the most up-to-date values of RIP and CS base are used regardless of KVM_SET_SREGS, KVM_SET_REGS, and KVM_SET_NESTED_STATE's relative ordering. Fixes: cc440cdad5b7 ("KVM: nSVM: implement KVM_GET_NESTED_STATE and KVM_SET_NESTED_STATE") CC: [email protected] Suggested-by: Sean Christopherson <[email protected]> Signed-off-by: Yosry Ahmed <[email protected]> Link: https://patch.msgid.link/[email protected] [sean: deal with the svm_cancel_injection() madness] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yosry Ahmed <[email protected]> Date: Wed Feb 25 00:59:48 2026 +0000 KVM: nSVM: Delay stuffing L2's current RIP into NextRIP until vCPU run commit a0592461f39c00b28f552fe842a063a00043eaa8 upstream. For guests with NRIPS disabled, L1 does not provide NextRIP when running an L2 with an injected soft interrupt, instead it advances L2's RIP before running it. KVM uses L2's current RIP as the NextRIP in vmcb02 to emulate a CPU without NRIPS. However, in svm_set_nested_state(), the value used for L2's current RIP comes from vmcb02, which is just whatever the vCPU had in vmcb02 before restoring nested state (zero on a freshly created vCPU). Passing the cached RIP value instead (i.e. kvm_rip_read()) would only fix the issue if registers are restored before nested state. Instead, split the logic of setting NextRIP in vmcb02. Handle the 'normal' case of initializing vmcb02's NextRIP using NextRIP from vmcb12 (or KVM_GET_NESTED_STATE's payload) in nested_vmcb02_prepare_control(). Delay the special case of stuffing L2's current RIP into vmcb02's NextRIP until shortly before the vCPU is run, to make sure the most up-to-date value of RIP is used regardless of KVM_SET_REGS and KVM_SET_NESTED_STATE's relative ordering. Fixes: cc440cdad5b7 ("KVM: nSVM: implement KVM_GET_NESTED_STATE and KVM_SET_NESTED_STATE") CC: [email protected] Suggested-by: Sean Christopherson <[email protected]> Signed-off-by: Yosry Ahmed <[email protected]> Link: https://patch.msgid.link/[email protected] [sean: use new helper, svm_fixup_nested_rips()] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yosry Ahmed <[email protected]> Date: Tue Mar 3 00:34:08 2026 +0000 KVM: nSVM: Drop the non-architectural consistency check for NP_ENABLE commit e0b6f031d64c086edd563e7af9c0c0a2261dd2a4 upstream. KVM currenty fails a nested VMRUN and injects VMEXIT_INVALID (aka SVM_EXIT_ERR) if L1 sets NP_ENABLE and the host does not support NPTs. On first glance, it seems like the check should actually be for guest_cpu_cap_has(X86_FEATURE_NPT) instead, as it is possible for the host to support NPTs but the guest CPUID to not advertise it. However, the consistency check is not architectural to begin with. The APM does not mention VMEXIT_INVALID if NP_ENABLE is set on a processor that does not have X86_FEATURE_NPT. Hence, NP_ENABLE should be ignored if X86_FEATURE_NPT is not available for L1, so sanitize it when copying from the VMCB12 to KVM's cache. Apart from the consistency check, NP_ENABLE in VMCB12 is currently ignored because the bit is actually copied from VMCB01 to VMCB02, not from VMCB12. Fixes: 4b16184c1cca ("KVM: SVM: Initialize Nested Nested MMU context on VMRUN") Cc: [email protected] Signed-off-by: Yosry Ahmed <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yosry Ahmed <[email protected]> Date: Tue Feb 24 22:50:17 2026 +0000 KVM: nSVM: Ensure AVIC is inhibited when restoring a vCPU to guest mode 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: f44509f849fe ("KVM: x86: SVM: allow AVIC to co-exist with a nested guest running") Cc: [email protected] Signed-off-by: Yosry Ahmed <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yosry Ahmed <[email protected]> Date: Tue Feb 10 01:08:06 2026 +0000 KVM: nSVM: Mark all of vmcb02 dirty when restoring nested state 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: cc440cdad5b7 ("KVM: nSVM: implement KVM_GET_NESTED_STATE and KVM_SET_NESTED_STATE") CC: [email protected] Signed-off-by: Yosry Ahmed <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kevin Cheng <[email protected]> Date: Tue Mar 3 16:22:22 2026 -0800 KVM: nSVM: Raise #UD if unhandled VMMCALL isn't intercepted by L1 commit c36991c6f8d2ab56ee67aff04e3c357f45cfc76c upstream. Explicitly synthesize a #UD for VMMCALL if L2 is active, L1 does NOT want to intercept VMMCALL, nested_svm_l2_tlb_flush_enabled() is true, and the hypercall is something other than one of the supported Hyper-V hypercalls. When all of the above conditions are met, KVM will intercept VMMCALL but never forward it to L1, i.e. will let L2 make hypercalls as if it were L1. The TLFS says a whole lot of nothing about this scenario, so go with the architectural behavior, which says that VMMCALL #UDs if it's not intercepted. Opportunistically do a 2-for-1 stub trade by stub-ifying the new API instead of the helpers it uses. The last remaining "single" stub will soon be dropped as well. Suggested-by: Sean Christopherson <[email protected]> Fixes: 3f4a812edf5c ("KVM: nSVM: hyper-v: Enable L2 TLB flush") Cc: Vitaly Kuznetsov <[email protected]> Cc: [email protected] Signed-off-by: Kevin Cheng <[email protected]> Link: https://patch.msgid.link/[email protected] [sean: rewrite changelog and comment, tag for stable, remove defunct stubs] Reviewed-by: Yosry Ahmed <[email protected]> Reviewed-by: Vitaly Kuznetsov <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yosry Ahmed <[email protected]> Date: Tue Mar 3 00:34:00 2026 +0000 KVM: nSVM: Refactor checking LBRV enablement in vmcb12 into a helper commit 290c8d82023ab0e1d2782d37136541e017174d7c upstream. Refactor the vCPU cap and vmcb12 flag checks into a helper. The unlikely() annotation is dropped, it's unlikely (huh) to make a difference and the CPU will probably predict it better on its own. CC: [email protected] Co-developed-by: Sean Christopherson <[email protected]> Signed-off-by: Yosry Ahmed <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yosry Ahmed <[email protected]> Date: Tue Mar 3 00:34:01 2026 +0000 KVM: nSVM: Refactor writing vmcb12 on nested #VMEXIT as a helper commit dcf3648ab71437b504abbfdc4e74622a0f1a56e3 upstream. Move mapping vmcb12 and updating it out of nested_svm_vmexit() into a helper, no functional change intended. CC: [email protected] Co-developed-by: Sean Christopherson <[email protected]> Signed-off-by: Yosry Ahmed <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yosry Ahmed <[email protected]> Date: Wed Feb 25 00:59:44 2026 +0000 KVM: nSVM: Sync interrupt shadow to cached vmcb12 after VMRUN of L2 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: cc440cdad5b7 ("KVM: nSVM: implement KVM_GET_NESTED_STATE and KVM_SET_NESTED_STATE") CC: [email protected] Signed-off-by: Yosry Ahmed <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yosry Ahmed <[email protected]> Date: Wed Feb 25 00:59:43 2026 +0000 KVM: nSVM: Sync NextRIP to cached vmcb12 after VMRUN of L2 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: cc440cdad5b7 ("KVM: nSVM: implement KVM_GET_NESTED_STATE and KVM_SET_NESTED_STATE") CC: [email protected] Co-developed-by: Sean Christopherson <[email protected]> Signed-off-by: Yosry Ahmed <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yosry Ahmed <[email protected]> Date: Tue Mar 3 00:34:02 2026 +0000 KVM: nSVM: Triple fault if mapping VMCB12 fails on nested #VMEXIT commit 1b30e7551767cb95b3e49bb169c72bbd76b56e05 upstream. KVM currently injects a #GP and hopes for the best if mapping VMCB12 fails on nested #VMEXIT, and only if the failure mode is -EINVAL. Mapping the VMCB12 could also fail if creating host mappings fails. After the #GP is injected, nested_svm_vmexit() bails early, without cleaning up (e.g. KVM_REQ_GET_NESTED_STATE_PAGES is set, is_guest_mode() is true, etc). Instead of optionally injecting a #GP, triple fault the guest if mapping VMCB12 fails since KVM cannot make a sane recovery. The APM states that a #VMEXIT will triple fault if host state is illegal or an exception occurs while loading host state, so the behavior is not entirely made up. Do not return early from nested_svm_vmexit(), continue cleaning up the vCPU state (e.g. switch back to vmcb01), to handle the failure as gracefully as possible. Fixes: cf74a78b229d ("KVM: SVM: Add VMEXIT handler and intercepts") CC: [email protected] Co-developed-by: Sean Christopherson <[email protected]> Signed-off-by: Yosry Ahmed <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yosry Ahmed <[email protected]> Date: Tue Mar 3 00:34:03 2026 +0000 KVM: nSVM: Triple fault if restore host CR3 fails on nested #VMEXIT commit 5d291ef0585ed880ed4dd71ea1a5965e0a65fb53 upstream. If loading L1's CR3 fails on a nested #VMEXIT, nested_svm_vmexit() returns an error code that is ignored by most callers, and continues to run L1 with corrupted state. A sane recovery is not possible in this case, and HW behavior is to cause a shutdown. Inject a triple fault instead, and do not return early from nested_svm_vmexit(). Continue cleaning up the vCPU state (e.g. clear pending exceptions), to handle the failure as gracefully as possible. From the APM: Upon #VMEXIT, the processor performs the following actions in order to return to the host execution context: ... if (illegal host state loaded, or exception while loading host state) shutdown else execute first host instruction following the VMRUN Remove the return value of nested_svm_vmexit(), which is mostly unchecked anyway. Fixes: d82aaef9c88a ("KVM: nSVM: use nested_svm_load_cr3() on guest->host switch") CC: [email protected] Signed-off-by: Yosry Ahmed <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yosry Ahmed <[email protected]> Date: Tue Feb 3 20:10:10 2026 +0000 KVM: nSVM: Use vcpu->arch.cr2 when updating vmcb12 on nested #VMEXIT 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: [email protected] Signed-off-by: Yosry Ahmed <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Thu Feb 12 18:38:41 2026 +0800 KVM: selftests: Fix reserved value WRMSR testcase for multi-feature MSRs commit 9396cc1e282a280bcba2e932e03994e0aada4cd8 upstream. When determining whether or not a WRMSR with reserved bits will #GP or succeed due to the WRMSR not existing per the guest virtual CPU model, expect failure if and only if _all_ features associated with the MSR are unsupported. Checking only the primary feature results in false failures when running on AMD and Hygon CPUs with only one of RDPID or RDTSCP, as AMD/Hygon CPUs ignore MSR_TSC_AUX[63:32], i.e. don't treat the bits as reserved, and so #GP only if the MSR is unsupported. Fixes: 9c38ddb3df94 ("KVM: selftests: Add an MSR test to exercise guest/host and read/write") Reported-by: Zhiquan Li <[email protected]> Closes: https://lore.kernel.org/all/[email protected] Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yosry Ahmed <[email protected]> Date: Tue Mar 3 00:33:57 2026 +0000 KVM: SVM: Add missing save/restore handling of LBR MSRs commit 3700f0788da6acf73b2df56690f4b201aa4aefd2 upstream. MSR_IA32_DEBUGCTLMSR and LBR MSRs are currently not enumerated by KVM_GET_MSR_INDEX_LIST, and LBR MSRs cannot be set with KVM_SET_MSRS. So save/restore is completely broken. Fix it by adding the MSRs to msrs_to_save_base, and allowing writes to LBR MSRs from userspace only (as they are read-only MSRs) if LBR virtualization is enabled. Additionally, to correctly restore L1's LBRs while L2 is running, make sure the LBRs are copied from the captured VMCB01 save area in svm_copy_vmrun_state(). Note, for VMX, this also fixes a flaw where MSR_IA32_DEBUGCTLMSR isn't reported as an MSR to save/restore. Note #2, over-reporting MSR_IA32_LASTxxx on Intel is ok, as KVM already handles unsupported reads and writes thanks to commit b5e2fec0ebc3 ("KVM: Ignore DEBUGCTL MSRs with no effect") (kvm_do_msr_access() will morph the unsupported userspace write into a nop). Fixes: 24e09cbf480a ("KVM: SVM: enable LBR virtualization") Cc: [email protected] Reported-by: Jim Mattson <[email protected]> Signed-off-by: Yosry Ahmed <[email protected]> Link: https://patch.msgid.link/[email protected] [sean: guard with lbrv checks, massage changelog] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Wed Feb 18 15:09:51 2026 -0800 KVM: SVM: Explicitly mark vmcb01 dirty after modifying VMCB intercepts 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: 116a0a23676e ("KVM: SVM: Add clean-bit for intercetps, tsc-offset and pause filter count") Cc: [email protected] Reviewed-by: Yosry Ahmed <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kevin Cheng <[email protected]> Date: Sat Feb 28 03:33:26 2026 +0000 KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0 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: ff092385e828 ("KVM: SVM: Implement INVLPGA") Cc: [email protected] Signed-off-by: Kevin Cheng <[email protected]> Reviewed-by: Yosry Ahmed <[email protected]> Link: https://patch.msgid.link/[email protected] [sean: tag for stable@] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yosry Ahmed <[email protected]> Date: Tue Mar 3 00:33:56 2026 +0000 KVM: SVM: Switch svm_copy_lbrs() to a macro commit 361dbe8173c460a2bf8aee23920f6c2dbdcabb94 upstream. In preparation for using svm_copy_lbrs() with 'struct vmcb_save_area' without a containing 'struct vmcb', and later even 'struct vmcb_save_area_cached', make it a macro. Macros are generally not preferred compared to functions, mainly due to type-safety. However, in this case it seems like having a simple macro copying a few fields is better than copy-pasting the same 5 lines of code in different places. Cc: [email protected] Signed-off-by: Yosry Ahmed <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Tue Feb 17 16:54:38 2026 -0800 KVM: x86: Defer non-architectural deliver of exception payload to userspace 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 da998b46d244 ("kvm: x86: Defer setting of CR2 until #PF delivery") was trying to avoid. At the time of commit da998b46d244, 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 7709aba8f716 ("KVM: x86: Morph pending exceptions to pending VM-Exits at queue time"), but in the interim, commit a06230b62b89 ("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/[email protected] Cc: Yosry Ahmed <[email protected]> Cc: [email protected] Reviewed-by: Yosry Ahmed <[email protected]> Tested-by: Yosry Ahmed <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mickaël Salaün <[email protected]> Date: Tue Apr 7 18:41:05 2026 +0200 landlock: Allow TSYNC with LOG_SUBDOMAINS_OFF and fd=-1 commit e75e38055b9df5eafd663c6db00e634f534dc426 upstream. LANDLOCK_RESTRICT_SELF_TSYNC does not allow LANDLOCK_RESTRICT_SELF_LOG_SUBDOMAINS_OFF with ruleset_fd=-1, preventing a multithreaded process from atomically propagating subdomain log muting to all threads without creating a domain layer. Relax the fd=-1 condition to accept TSYNC alongside LOG_SUBDOMAINS_OFF, and update the documentation accordingly. Add flag validation tests for all TSYNC combinations with ruleset_fd=-1, and audit tests verifying both transition directions: muting via TSYNC (logged to not logged) and override via TSYNC (not logged to logged). Cc: Günther Noack <[email protected]> Cc: [email protected] Fixes: 42fc7e6543f6 ("landlock: Multithreading support for landlock_restrict_self()") Reviewed-by: Günther Noack <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mickaël Salaün <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mickaël Salaün <[email protected]> Date: Tue Apr 7 18:41:04 2026 +0200 landlock: Fix LOG_SUBDOMAINS_OFF inheritance across fork() commit 874c8f83826c95c62c21d9edfe9ef43e5c346724 upstream. hook_cred_transfer() only copies the Landlock security blob when the source credential has a domain. This is inconsistent with landlock_restrict_self() which can set LOG_SUBDOMAINS_OFF on a credential without creating a domain (via the ruleset_fd=-1 path): the field is committed but not preserved across fork() because the child's prepare_creds() calls hook_cred_transfer() which skips the copy when domain is NULL. This breaks the documented use case where a process mutes subdomain logs before forking sandboxed children: the children lose the muting and their domains produce unexpected audit records. Fix this by unconditionally copying the Landlock credential blob. Cc: Günther Noack <[email protected]> Cc: Jann Horn <[email protected]> Cc: [email protected] Fixes: ead9079f7569 ("landlock: Add LANDLOCK_RESTRICT_SELF_LOG_SUBDOMAINS_OFF") Reviewed-by: Günther Noack <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mickaël Salaün <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Greg Kroah-Hartman <[email protected]> Date: Thu Feb 19 15:34:35 2026 +0100 leds: qcom-lpg: Check for array overflow when selecting the high resolution 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 <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Link: https://patch.msgid.link/2026021934-nearby-playroom-036b@gregkh Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Josh Law <[email protected]> Date: Sun Mar 8 20:20:28 2026 +0000 lib/ts_kmp: fix integer overflow in pattern length calculation commit 8cdf30813ea8ce881cecc08664144416dbdb3e16 upstream. The ts_kmp algorithm stores its prefix_tbl[] table and pattern in a single allocation sized from the pattern length. If the prefix_tbl[] size calculation wraps, the resulting allocation can be too small and subsequent pattern copies can overflow it. Fix this by rejecting zero-length patterns and by using overflow helpers before calculating the combined allocation size. This fixes a potential heap overflow. The pattern length calculation can wrap during a size_t addition, leading to an undersized allocation. Because the textsearch library is reachable from userspace via Netfilter's xt_string module, this is a security risk that should be backported to LTS kernels. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Josh Law <[email protected]> Reviewed-by: Andrew Morton <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alistair Popple <[email protected]> Date: Tue Mar 31 17:34:43 2026 +1100 lib: test_hmm: evict device pages on file close to avoid use-after-free commit 744dd97752ef1076a8d8672bb0d8aa2c7abc1144 upstream. Patch series "Minor hmm_test fixes and cleanups". Two bugfixes a cleanup for the HMM kernel selftests. These were mostly reported by Zenghui Yu with special thanks to Lorenzo for analysing and pointing out the problems. This patch (of 3): When dmirror_fops_release() is called it frees the dmirror struct but doesn't migrate device private pages back to system memory first. This leaves those pages with a dangling zone_device_data pointer to the freed dmirror. If a subsequent fault occurs on those pages (eg. during coredump) the dmirror_devmem_fault() callback dereferences the stale pointer causing a kernel panic. This was reported [1] when running mm/ksft_hmm.sh on arm64, where a test failure triggered SIGABRT and the resulting coredump walked the VMAs faulting in the stale device private pages. Fix this by calling dmirror_device_evict_chunk() for each devmem chunk in dmirror_fops_release() to migrate all device private pages back to system memory before freeing the dmirror struct. The function is moved earlier in the file to avoid a forward declaration. Link: https://lore.kernel.org/[email protected] Link: https://lore.kernel.org/[email protected] Fixes: b2ef9f5a5cb3 ("mm/hmm/test: add selftest driver for HMM") Signed-off-by: Alistair Popple <[email protected]> Reported-by: Zenghui Yu <[email protected]> Closes: https://lore.kernel.org/linux-mm/[email protected]/ Reviewed-by: Balbir Singh <[email protected]> Tested-by: Zenghui Yu <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: Jason Gunthorpe <[email protected]> Cc: Leon Romanovsky <[email protected]> Cc: Liam Howlett <[email protected]> Cc: Lorenzo Stoakes (Oracle) <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Mike Rapoport <[email protected]> Cc: Suren Baghdasaryan <[email protected]> Cc: Zenghui Yu <[email protected]> Cc: Matthew Brost <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Raphael Zimmer <[email protected]> Date: Wed Mar 18 18:09:03 2026 +0100 libceph: Prevent potential null-ptr-deref in ceph_handle_auth_reply() commit 5199c125d25aeae8615c4fc31652cc0fe624338e upstream. If a message of type CEPH_MSG_AUTH_REPLY contains a zero value for both protocol and result, this is currently not treated as an error. In case of ac->negotiating == true and ac->protocol > 0, this leads to setting ac->protocol = 0 and ac->ops = NULL. Thereafter, the check for ac->protocol != protocol returns false, and init_protocol() is not called. Subsequently, ac->ops->handle_reply() is called, which leads to a null pointer dereference, because ac->ops is still NULL. This patch changes the check for ac->protocol != protocol to !ac->protocol, as this also includes the case when the protocol was set to zero in the message. This causes the message to be treated as containing a bad auth protocol. Cc: [email protected] Signed-off-by: Raphael Zimmer <[email protected]> Reviewed-by: Ilya Dryomov <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Greg Kroah-Hartman <[email protected]> Date: Thu May 7 06:14:18 2026 +0200 Linux 7.0.4 Link: https://lore.kernel.org/r/[email protected] Tested-by: Brett A C Sheffield <[email protected]> Tested-by: Ronald Warsow <[email protected]> Tested-by: Peter Schneider <[email protected]> Tested-by: Salvatore Bonaccorso <[email protected]> Tested-by: Takeshi Ogasawara <[email protected]> Tested-by: Florian Fainelli <[email protected]> Tested-by: Ron Economos <[email protected]> Tested-by: Miguel Ojeda <[email protected]> Tested-by: Luna Jernberg <[email protected]> Tested-by: Mark Brown <[email protected]> Tested-by: Shuah Khan <[email protected]> Tested-by: Justin M. Forbes <[email protected]> Tested-by: Barry K. Nathan <[email protected]> Tested-by: Dileep Malepu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Greg Kroah-Hartman <[email protected]> Date: Wed Apr 22 15:45:12 2026 +0800 LoongArch: Add spectre boundry for syscall dispatch table commit 0c965d2784fbbd7f8e3b96d875c9cfdf7c00da3d upstream. 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: [email protected] Assisted-by: gkh_clanker_2000 Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tao Cui <[email protected]> Date: Thu Apr 9 18:56:36 2026 +0800 LoongArch: KVM: Use CSR_CRMD_PLV in kvm_arch_vcpu_in_kernel() commit da773ea3f59032f659bfc4c450ca86e384786168 upstream. The function reads LOONGARCH_CSR_CRMD but uses CSR_PRMD_PPLV to extract the privilege level. While both masks have the same value (0x3), CSR_CRMD_PLV is the semantically correct constant for CRMD. Cc: [email protected] Reviewed-by: Bibo Mao <[email protected]> Signed-off-by: Tao Cui <[email protected]> Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Huacai Chen <[email protected]> Date: Wed Apr 22 15:45:12 2026 +0800 LoongArch: Make arch_irq_work_has_interrupt() true only if IPI HW exist commit 02a6a1f9d77a816fbac01de9bfcd0e0914552f2f upstream. After commit 7c405fb3279b3924 ("rcu: Use an intermediate irq_work to start process_srcu()"), Loongson-2K0300/2K0500 fail to boot. Because IRQ_WORK need IPI but Loongson-2K0300/2K0500 don't have IPI HW. So make arch_irq_work_has_interrupt() return true only if IPI HW exist. Cc: [email protected] Reported-by: Binbin Zhou <[email protected]> Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Huacai Chen <[email protected]> Date: Wed Apr 22 15:45:12 2026 +0800 LoongArch: Show CPU vulnerabilites correctly commit 37e57e8ad96cdec4a57b55fd10bef50f7370a954 upstream. Most LoongArch processors are vulnerable to Spectre-V1 Proof-of-Concept (PoC). And the generic mechanism, __user pointer sanitization, can be used as a mitigation. This means to use array_index_nospec() to prevent out of boundry access in syscall and other critical paths. Implement the arch-specific cpu_show_spectre_v1() to show CPU Spectre-V1 vulnerabilites correctly. Cc: [email protected] Link: https://cc-sw.com/chinese-loongarch-architecture-evaluation-part-3-of-3/ Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Paul Moore <[email protected]> Date: Fri Dec 19 13:18:22 2025 -0500 lsm: add backing_file LSM hooks commit 6af36aeb147a06dea47c49859cd6ca5659aeb987 upstream. Stacked filesystems such as overlayfs do not currently provide the necessary mechanisms for LSMs to properly enforce access controls on the mmap() and mprotect() operations. In order to resolve this gap, a LSM security blob is being added to the backing_file struct and the following new LSM hooks are being created: security_backing_file_alloc() security_backing_file_free() security_mmap_backing_file() The first two hooks are to manage the lifecycle of the LSM security blob in the backing_file struct, while the third provides a new mmap() access control point for the underlying backing file. It is also expected that LSMs will likely want to update their security_file_mprotect() callback to address issues with their mprotect() controls, but that does not require a change to the security_file_mprotect() LSM hook. There are a three other small changes to support these new LSM hooks: * Pass the user file associated with a backing file down to alloc_empty_backing_file() so it can be included in the security_backing_file_alloc() hook. * Add getter and setter functions for the backing_file struct LSM blob as the backing_file struct remains private to fs/file_table.c. * Constify the file struct field in the LSM common_audit_data struct to better support LSMs that need to pass a const file struct pointer into the common LSM audit code. Thanks to Arnd Bergmann for identifying the missing EXPORT_SYMBOL_GPL() and supplying a fixup. Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Reviewed-by: Amir Goldstein <[email protected]> Reviewed-by: Serge Hallyn <[email protected]> Reviewed-by: Christian Brauner <[email protected]> Signed-off-by: Paul Moore <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yu Kuai <[email protected]> Date: Mon Feb 23 10:40:35 2026 +0800 md/md-llbitmap: raise barrier before state machine transition commit ef4ca3d4bf09716cff9ba00eb0351deadc8417ab upstream. Move the barrier raise operation before calling llbitmap_state_machine() in both llbitmap_start_write() and llbitmap_start_discard(). This ensures the barrier is in place before any state transitions occur, preventing potential race conditions where the state machine could complete before the barrier is properly raised. Cc: [email protected] Fixes: 5ab829f1971d ("md/md-llbitmap: introduce new lockless bitmap") Link: https://lore.kernel.org/linux-raid/[email protected] Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yu Kuai <[email protected]> Date: Mon Feb 23 10:40:34 2026 +0800 md/md-llbitmap: skip reading rdevs that are not in_sync commit 7701e68b5072faa03a8f30b4081dc16df9092381 upstream. When reading bitmap pages from member disks, the code iterates through all rdevs and attempts to read from the first available one. However, it only checks for raid_disk assignment and Faulty flag, missing the In_sync flag check. This can cause bitmap data to be read from spare disks that are still being rebuilt and don't have valid bitmap information yet. Reading stale or uninitialized bitmap data from such disks can lead to incorrect dirty bit tracking, potentially causing data corruption during recovery or normal operation. Add the In_sync flag check to ensure bitmap pages are only read from fully synchronized member disks that have valid bitmap data. Cc: [email protected] Fixes: 5ab829f1971d ("md/md-llbitmap: introduce new lockless bitmap") Link: https://lore.kernel.org/linux-raid/[email protected] Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Josh Hunt <[email protected]> Date: Mon Mar 2 19:56:19 2026 -0500 md/raid10: fix deadlock with check operation and nowait requests commit 7d96f3120a7fb7210d21b520c5b6f495da6ba436 upstream. When an array check is running it will raise the barrier at which point normal requests will become blocked and increment the nr_pending value to signal there is work pending inside of wait_barrier(). NOWAIT requests do not block and so will return immediately with an error, and additionally do not increment nr_pending in wait_barrier(). Upstream change commit 43806c3d5b9b ("raid10: cleanup memleak at raid10_make_request") added a call to raid_end_bio_io() to fix a memory leak when NOWAIT requests hit this condition. raid_end_bio_io() eventually calls allow_barrier() and it will unconditionally do an atomic_dec_and_test(&conf->nr_pending) even though the corresponding increment on nr_pending didn't happen in the NOWAIT case. This can be easily seen by starting a check operation while an application is doing nowait IO on the same array. This results in a deadlocked state due to nr_pending value underflowing and so the md resync thread gets stuck waiting for nr_pending to == 0. Output of r10conf state of the array when we hit this condition: crash> struct r10conf barrier = 1, nr_pending = { counter = -41 }, nr_waiting = 15, nr_queued = 0, Example of md_sync thread stuck waiting on raise_barrier() and other requests stuck in wait_barrier(): md1_resync [<0>] raise_barrier+0xce/0x1c0 [<0>] raid10_sync_request+0x1ca/0x1ed0 [<0>] md_do_sync+0x779/0x1110 [<0>] md_thread+0x90/0x160 [<0>] kthread+0xbe/0xf0 [<0>] ret_from_fork+0x34/0x50 [<0>] ret_from_fork_asm+0x1a/0x30 kworker/u1040:2+flush-253:4 [<0>] wait_barrier+0x1de/0x220 [<0>] regular_request_wait+0x30/0x180 [<0>] raid10_make_request+0x261/0x1000 [<0>] md_handle_request+0x13b/0x230 [<0>] __submit_bio+0x107/0x1f0 [<0>] submit_bio_noacct_nocheck+0x16f/0x390 [<0>] ext4_io_submit+0x24/0x40 [<0>] ext4_do_writepages+0x254/0xc80 [<0>] ext4_writepages+0x84/0x120 [<0>] do_writepages+0x7a/0x260 [<0>] __writeback_single_inode+0x3d/0x300 [<0>] writeback_sb_inodes+0x1dd/0x470 [<0>] __writeback_inodes_wb+0x4c/0xe0 [<0>] wb_writeback+0x18b/0x2d0 [<0>] wb_workfn+0x2a1/0x400 [<0>] process_one_work+0x149/0x330 [<0>] worker_thread+0x2d2/0x410 [<0>] kthread+0xbe/0xf0 [<0>] ret_from_fork+0x34/0x50 [<0>] ret_from_fork_asm+0x1a/0x30 Fixes: 43806c3d5b9b ("raid10: cleanup memleak at raid10_make_request") Cc: [email protected] Signed-off-by: Josh Hunt <[email protected]> Link: https://lore.kernel.org/linux-raid/[email protected] Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Chia-Ming Chang <[email protected]> Date: Thu Apr 2 14:14:06 2026 +0800 md/raid5: fix soft lockup in retry_aligned_read() commit 7f9f7c697474268d9ef9479df3ddfe7cdcfbbffc upstream. When retry_aligned_read() encounters an overlapped stripe, it releases the stripe via raid5_release_stripe() which puts it on the lockless released_stripes llist. In the next raid5d loop iteration, release_stripe_list() drains the stripe onto handle_list (since STRIPE_HANDLE is set by the original IO), but retry_aligned_read() runs before handle_active_stripes() and removes the stripe from handle_list via find_get_stripe() -> list_del_init(). This prevents handle_stripe() from ever processing the stripe to resolve the overlap, causing an infinite loop and soft lockup. Fix this by using __release_stripe() with temp_inactive_list instead of raid5_release_stripe() in the failure path, so the stripe does not go through the released_stripes llist. This allows raid5d to break out of its loop, and the overlap will be resolved when the stripe is eventually processed by handle_stripe(). Fixes: 773ca82fa1ee ("raid5: make release_stripe lockless") Cc: [email protected] Signed-off-by: FengWei Shih <[email protected]> Signed-off-by: Chia-Ming Chang <[email protected]> Link: https://lore.kernel.org/linux-raid/[email protected]/ Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Junrui Luo <[email protected]> Date: Sat Apr 4 15:44:35 2026 +0800 md/raid5: validate payload size before accessing journal metadata commit b0cc3ae97e893bf54bbce447f4e9fd2e0b88bff9 upstream. r5c_recovery_analyze_meta_block() and r5l_recovery_verify_data_checksum_for_mb() iterate over payloads in a journal metadata block using on-disk payload size fields without validating them against the remaining space in the metadata block. A corrupted journal contains payload sizes extending beyond the PAGE_SIZE boundary can cause out-of-bounds reads when accessing payload fields or computing offsets. Add bounds validation for each payload type to ensure the full payload fits within meta_size before processing. Fixes: b4c625c67362 ("md/r5cache: r5cache recovery: part 1") Cc: [email protected] Signed-off-by: Junrui Luo <[email protected]> Link: https://lore.kernel.org/linux-raid/SYBPR01MB78815E78D829BB86CD7C8015AF5FA@SYBPR01MB7881.ausprd01.prod.outlook.com/ Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ming Qian <[email protected]> Date: Fri Mar 6 14:59:50 2026 +0800 media: amphion: Fix race between m2m job_abort and device_run commit 8cd35ceadcfc8c5da2eb7f7ce24525ce9d4ee62e upstream. Fix kernel panic caused by race condition where v4l2_m2m_ctx_release() frees m2m_ctx while v4l2_m2m_try_run() is about to call device_run with the same context. Race sequence: v4l2_m2m_try_run(): v4l2_m2m_ctx_release(): lock/unlock v4l2_m2m_cancel_job() job_abort() v4l2_m2m_job_finish() kfree(m2m_ctx) <- frees ctx device_run() <- use-after-free crash at 0x538 Crash trace: Unable to handle kernel read from unreadable memory at virtual address 0000000000000538 v4l2_m2m_try_run+0x78/0x138 v4l2_m2m_device_run_work+0x14/0x20 The amphion vpu driver does not rely on the m2m framework's device_run callback to perform encode/decode operations. Fix the race by preventing m2m framework job scheduling entirely: - Add job_ready callback returning 0 (no jobs ready for m2m framework) - Remove job_abort callback to avoid the race condition Fixes: 3cd084519c6f ("media: amphion: add vpu v4l2 m2m support") Cc: [email protected] Signed-off-by: Ming Qian <[email protected]> Reviewed-by: Nicolas Dufresne <[email protected]> Signed-off-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Chen Ni <[email protected]> Date: Wed Feb 4 10:48:59 2026 +0800 media: i2c: imx219: Check return value of devm_gpiod_get_optional() in imx219_probe() commit 943b1f27a3eead21b22e2531a5432ea5910b60eb upstream. The devm_gpiod_get_optional() function may return an error pointer (ERR_PTR) in case of a genuine failure during GPIO acquisition, not just NULL which indicates the legitimate absence of an optional GPIO. Add an IS_ERR() check after the function call to catch such errors and propagate them to the probe function, ensuring the driver fails to load safely rather than proceeding with an invalid pointer. Fixes: 1283b3b8f82b ("media: i2c: Add driver for Sony IMX219 sensor") Cc: [email protected] Signed-off-by: Chen Ni <[email protected]> Reviewed-by: Dave Stevenson <[email protected]> Reviewed-by: Jai Luthra <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Fan Wu <[email protected]> Date: Wed Mar 4 03:19:34 2026 +0000 media: mtk-jpeg: fix use-after-free in release path due to uncancelled work commit 34c519feef3e4fcff1078dc8bdb25fbbbd10303f upstream. The mtk_jpeg_release() function frees the context structure (ctx) without first cancelling any pending or running work in ctx->jpeg_work. This creates a race window where the workqueue callback may still be accessing the context memory after it has been freed. Race condition: CPU 0 (release) CPU 1 (workqueue) ---------------- ------------------ close() mtk_jpeg_release() mtk_jpegenc_worker() ctx = work->data // accessing ctx kfree(ctx) // freed! access ctx // UAF! The work is queued via queue_work() during JPEG encode/decode operations (via mtk_jpeg_device_run). If the device is closed while work is pending or running, the work handler will access freed memory. Fix this by calling cancel_work_sync() BEFORE acquiring the mutex. This ordering is critical: if cancel_work_sync() is called after mutex_lock(), and the work handler also tries to acquire the same mutex, it would cause a deadlock. Note: The open error path does NOT need cancel_work_sync() because INIT_WORK() only initializes the work structure - it does not schedule it. Work is only scheduled later during ioctl operations. Fixes: 5fb1c2361e56 ("mtk-jpegenc: add jpeg encode worker interface") Cc: [email protected] Signed-off-by: Fan Wu <[email protected]> Reviewed-by: Nicolas Dufresne <[email protected]> Signed-off-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Oliver Neukum <[email protected]> Date: Wed Feb 11 19:11:51 2026 +0100 media: rc: igorplugusb: heed coherency rules commit eac69475b01fe1e861dfe3960b57fa95671c132e upstream. In a control request, the USB request structure can be subject to DMA on some HCs. Hence it must obey the rules for DMA coherency. Allocate it separately. Fixes: b1c97193c6437 ("[media] rc: port IgorPlug-USB to rc-core") Cc: [email protected] Signed-off-by: Oliver Neukum <[email protected]> Signed-off-by: Sean Young <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Michael Riesch <[email protected]> Date: Fri Feb 20 09:15:08 2026 +0100 media: rockchip: rkcif: comply with minimum number of buffers requirement commit 48c8292d4445088d8b3c9d639c7982744a94d819 upstream. Each stream requires CIF_REQ_BUFS_MIN=1 buffers to enable streaming. However, it failed with only one buffer provided. Comply with the minimum number of buffers requirement and accept exactly one buffer. Fixes: 501802e2ad51 ("media: rockchip: rkcif: add abstraction for dma blocks") Cc: [email protected] Tested-by: Paul Elder <[email protected]> Tested-by: Chen-Yu Tsai <[email protected]> Signed-off-by: Michael Riesch <[email protected]> Reviewed-by: Isaac Scott <[email protected]> Reviewed-by: Paul Elder <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Fri Feb 20 09:15:07 2026 +0100 media: rockchip: rkcif: fix off by one bugs commit e4056b84af0fc18c84b4e5741df04ecd8ca17973 upstream. Change these comparisons from > vs >= to avoid accessing one element beyond the end of the arrays. While at it, use ARRAY_SIZE instead of the _MAX enum values. Fixes: 1f2353f5a1af ("media: rockchip: rkcif: add support for rk3568 vicap mipi capture") Cc: [email protected] Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Michael Riesch <[email protected]> Reviewed-by: Paul Elder <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Tested-by: Chen-Yu Tsai <[email protected]> [fix cosmetic issues] Signed-off-by: Michael Riesch <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Barnabás Pőcze <[email protected]> Date: Thu Feb 12 16:41:56 2026 +0100 media: rzv2h-ivc: Fix AXIRX_VBLANK register write commit 6139d018f043a30274071d694276c5ce59fe62d0 upstream. According to the documentation there are writable reserved bits in the register and those should not be set to 0. So use `rzv2h_ivc_update_bits()` with a proper bitmask. Cc: [email protected] Fixes: f0b3984d821b ("media: platform: Add Renesas Input Video Control block driver") Reviewed-by: Daniel Scally <[email protected]> Signed-off-by: Barnabás Pőcze <[email protected]> Signed-off-by: Jacopo Mondi <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Daniel Scally <[email protected]> Date: Thu Feb 12 10:08:11 2026 +0000 media: rzv2h-ivc: Revise default VBLANK formula commit 38104fe60ebb6b6cb66e3e9ef0a5c12f1260b1bc upstream. The vertical blanking settings for the IVC block are dependent on settings in the ISP. This was originally set to calculate as the worst-case possible value, but it seems that this can cause the IVC block to hang. Instead calculate the vblank to match the default settings (which are currently all the driver sets anyway). Cc: [email protected] Fixes: f0b3984d821b ("media: platform: Add Renesas Input Video Control block driver") Signed-off-by: Daniel Scally <[email protected]> Signed-off-by: Jacopo Mondi <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alexander Usyskin <[email protected]> Date: Tue Apr 28 05:37:29 2026 -0400 mei: me: add nova lake point H DID [ Upstream commit a5a1804332afc7035d5c5b880548262e81d796bc ] Add Nova Lake H device id. Cc: stable <[email protected]> Co-developed-by: Tomas Winkler <[email protected]> Signed-off-by: Tomas Winkler <[email protected]> Signed-off-by: Alexander Usyskin <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alexander Usyskin <[email protected]> Date: Tue Apr 28 05:37:28 2026 -0400 mei: me: use PCI_DEVICE_DATA macro [ Upstream commit 9e7a2409ecf4d411b7cc91615b08f6a7576f0aaa ] Drop old local MEI_PCI_DEVICE macro and use common PCI_DEVICE_DATA instead. Update defines to adhere to current naming convention. Suggested-by: Andy Shevchenko <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Alexander Usyskin <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Stable-dep-of: a5a1804332af ("mei: me: add nova lake point H DID") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Brian Mak <[email protected]> Date: Wed Mar 25 15:30:24 2026 -0700 mfd: core: Preserve OF node when ACPI handle is present commit caa5a5d44d8ae4fd13b744857d66c9313b712d1f upstream. Switch device_set_node to set_primary_fwnode, so that the ACPI fwnode does not overwrite the of_node with NULL. This allows MFD children with both OF nodes and ACPI handles to have OF nodes again. Cc: [email protected] Fixes: 51e3b257099d ("mfd: core: Make use of device_set_node()") Signed-off-by: Brian Mak <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Marek Vasut <[email protected]> Date: Thu Jan 22 12:13:21 2026 +0100 mfd: stpmic1: Attempt system shutdown twice in case PMIC is confused commit ffdc5c51f8bcd0e5e8255ca275a0a3b958475d99 upstream. Attempt to shut down again, in case the first attempt failed. The STPMIC1 might get confused and the first regmap_update_bits() returns with -ETIMEDOUT / -110 . If that or similar transient failure occurs, try to shut down again. If the second attempt fails, there is some bigger problem, report it to user. Cc: [email protected] Fixes: 6e9df38f359a ("mfd: stpmic1: Add PMIC poweroff via sys-off handler") Signed-off-by: Marek Vasut <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tyllis Xu <[email protected]> Date: Sun Mar 8 00:21:08 2026 -0600 misc: ibmasm: fix OOB MMIO read in ibmasm_handle_mouse_interrupt() 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 <[email protected]> Fixes: 278d72ae8803 ("[PATCH] ibmasm driver: redesign handling of remote control events") Cc: [email protected] Cc: [email protected] Signed-off-by: Tyllis Xu <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kairui Song <[email protected]> Date: Mon Feb 16 22:58:02 2026 +0800 mm, swap: speed up hibernation allocation and writeout commit 396f57b5720024638dbb503f6a4abd988a49d815 upstream. Since commit 0ff67f990bd4 ("mm, swap: remove swap slot cache"), hibernation has been using the swap slot slow allocation path for simplification, which turns out might cause regression for some devices because the allocator now rotates clusters too often, leading to slower allocation and more random distribution of data. Fast allocation is not complex, so implement hibernation support as well. Test result with Samsung SSD 830 Series (SATA II, 3.0 Gbps) shows the performance is several times better [1]: 6.19: 324 seconds After this series: 35 seconds Link: https://lkml.kernel.org/r/[email protected] Link: https://lore.kernel.org/linux-mm/[email protected]/ [1] Signed-off-by: Kairui Song <[email protected]> Fixes: 0ff67f990bd4 ("mm, swap: remove swap slot cache") Reported-by: Carsten Grohmann <[email protected]> Closes: https://lore.kernel.org/linux-mm/[email protected]/ Cc: Baoquan He <[email protected]> Cc: Barry Song <[email protected]> Cc: Chris Li <[email protected]> Cc: Kemeng Shi <[email protected]> Cc: Nhat Pham <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Hao Ge <[email protected]> Date: Tue Mar 31 16:13:12 2026 +0800 mm/alloc_tag: clear codetag for pages allocated before page_ext initialization commit 6b1842775a460245e97d36d3a67d0cfba7c4ff79 upstream. Due to initialization ordering, page_ext is allocated and initialized relatively late during boot. Some pages have already been allocated and freed before page_ext becomes available, leaving their codetag uninitialized. A clear example is in init_section_page_ext(): alloc_page_ext() calls kmemleak_alloc(). If the slab cache has no free objects, it falls back to the buddy allocator to allocate memory. However, at this point page_ext is not yet fully initialized, so these newly allocated pages have no codetag set. These pages may later be reclaimed by KASAN, which causes the warning to trigger when they are freed because their codetag ref is still empty. Use a global array to track pages allocated before page_ext is fully initialized. The array size is fixed at 8192 entries, and will emit a warning if this limit is exceeded. When page_ext initialization completes, set their codetag to empty to avoid warnings when they are freed later. This warning is only observed with CONFIG_MEM_ALLOC_PROFILING_DEBUG=Y and mem_profiling_compressed disabled: [ 9.582133] ------------[ cut here ]------------ [ 9.582137] alloc_tag was not set [ 9.582139] WARNING: ./include/linux/alloc_tag.h:164 at __pgalloc_tag_sub+0x40f/0x550, CPU#5: systemd/1 [ 9.582190] CPU: 5 UID: 0 PID: 1 Comm: systemd Not tainted 7.0.0-rc4 #1 PREEMPT(lazy) [ 9.582192] Hardware name: Red Hat KVM, BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 9.582194] RIP: 0010:__pgalloc_tag_sub+0x40f/0x550 [ 9.582196] Code: 00 00 4c 29 e5 48 8b 05 1f 88 56 05 48 8d 4c ad 00 48 8d 2c c8 e9 87 fd ff ff 0f 0b 0f 0b e9 f3 fe ff ff 48 8d 3d 61 2f ed 03 <67> 48 0f b9 3a e9 b3 fd ff ff 0f 0b eb e4 e8 5e cd 14 02 4c 89 c7 [ 9.582197] RSP: 0018:ffffc9000001f940 EFLAGS: 00010246 [ 9.582200] RAX: dffffc0000000000 RBX: 1ffff92000003f2b RCX: 1ffff110200d806c [ 9.582201] RDX: ffff8881006c0360 RSI: 0000000000000004 RDI: ffffffff9bc7b460 [ 9.582202] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff3a62324 [ 9.582203] R10: ffffffff9d311923 R11: 0000000000000000 R12: ffffea0004001b00 [ 9.582204] R13: 0000000000002000 R14: ffffea0000000000 R15: ffff8881006c0360 [ 9.582206] FS: 00007ffbbcf2d940(0000) GS:ffff888450479000(0000) knlGS:0000000000000000 [ 9.582208] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 9.582210] CR2: 000055ee3aa260d0 CR3: 0000000148b67005 CR4: 0000000000770ef0 [ 9.582211] PKRU: 55555554 [ 9.582212] Call Trace: [ 9.582213] <TASK> [ 9.582214] ? __pfx___pgalloc_tag_sub+0x10/0x10 [ 9.582216] ? check_bytes_and_report+0x68/0x140 [ 9.582219] __free_frozen_pages+0x2e4/0x1150 [ 9.582221] ? __free_slab+0xc2/0x2b0 [ 9.582224] qlist_free_all+0x4c/0xf0 [ 9.582227] kasan_quarantine_reduce+0x15d/0x180 [ 9.582229] __kasan_slab_alloc+0x69/0x90 [ 9.582232] kmem_cache_alloc_noprof+0x14a/0x500 [ 9.582234] do_getname+0x96/0x310 [ 9.582237] do_readlinkat+0x91/0x2f0 [ 9.582239] ? __pfx_do_readlinkat+0x10/0x10 [ 9.582240] ? get_random_bytes_user+0x1df/0x2c0 [ 9.582244] __x64_sys_readlinkat+0x96/0x100 [ 9.582246] do_syscall_64+0xce/0x650 [ 9.582250] ? __x64_sys_getrandom+0x13a/0x1e0 [ 9.582252] ? __pfx___x64_sys_getrandom+0x10/0x10 [ 9.582254] ? do_syscall_64+0x114/0x650 [ 9.582255] ? ksys_read+0xfc/0x1d0 [ 9.582258] ? __pfx_ksys_read+0x10/0x10 [ 9.582260] ? do_syscall_64+0x114/0x650 [ 9.582262] ? do_syscall_64+0x114/0x650 [ 9.582264] ? __pfx_fput_close_sync+0x10/0x10 [ 9.582266] ? file_close_fd_locked+0x178/0x2a0 [ 9.582268] ? __x64_sys_faccessat2+0x96/0x100 [ 9.582269] ? __x64_sys_close+0x7d/0xd0 [ 9.582271] ? do_syscall_64+0x114/0x650 [ 9.582273] ? do_syscall_64+0x114/0x650 [ 9.582275] ? clear_bhb_loop+0x50/0xa0 [ 9.582277] ? clear_bhb_loop+0x50/0xa0 [ 9.582279] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 9.582280] RIP: 0033:0x7ffbbda345ee [ 9.582282] Code: 0f 1f 40 00 48 8b 15 29 38 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff c3 0f 1f 40 00 f3 0f 1e fa 49 89 ca b8 0b 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d fa 37 0d 00 f7 d8 64 89 01 48 [ 9.582284] RSP: 002b:00007ffe2ad8de58 EFLAGS: 00000202 ORIG_RAX: 000000000000010b [ 9.582286] RAX: ffffffffffffffda RBX: 000055ee3aa25570 RCX: 00007ffbbda345ee [ 9.582287] RDX: 000055ee3aa25570 RSI: 00007ffe2ad8dee0 RDI: 00000000ffffff9c [ 9.582288] RBP: 0000000000001000 R08: 0000000000000003 R09: 0000000000001001 [ 9.582289] R10: 0000000000001000 R11: 0000000000000202 R12: 0000000000000033 [ 9.582290] R13: 00007ffe2ad8dee0 R14: 00000000ffffff9c R15: 00007ffe2ad8deb0 [ 9.582292] </TASK> [ 9.582293] ---[ end trace 0000000000000000 ]--- Link: https://lore.kernel.org/[email protected] Fixes: dcfe378c81f72 ("lib: introduce support for page allocation tagging") Signed-off-by: Hao Ge <[email protected]> Suggested-by: Suren Baghdasaryan <[email protected]> Acked-by: Suren Baghdasaryan <[email protected]> Cc: Kent Overstreet <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: SeongJae Park <[email protected]> Date: Sat Apr 11 14:36:36 2026 -0700 mm/damon/core: disallow non-power of two min_region_sz on damon_start() commit 95093e5cb4c5b50a5b1a4b79f2942b62744bd66a upstream. Commit d8f867fa0825 ("mm/damon: add damon_ctx->min_sz_region") introduced a bug that allows unaligned DAMON region address ranges. Commit c80f46ac228b ("mm/damon/core: disallow non-power of two min_region_sz") fixed it, but only for damon_commit_ctx() use case. Still, DAMON sysfs interface can emit non-power of two min_region_sz via damon_start(). Fix the path by adding the is_power_of_2() check on damon_start(). The issue was discovered by sashiko [1]. Link: https://lore.kernel.org/[email protected] Link: https://lore.kernel.org/[email protected] [1] Fixes: d8f867fa0825 ("mm/damon: add damon_ctx->min_sz_region") Signed-off-by: SeongJae Park <[email protected]> Cc: <[email protected]> # 6.18.x Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: SeongJae Park <[email protected]> Date: Mon Apr 6 17:31:52 2026 -0700 mm/damon/core: disallow time-quota setting zero esz commit 8bbde987c2b84f80da0853f739f0a920386f8b99 upstream. When the throughput of a DAMOS scheme is very slow, DAMOS time quota can make the effective size quota smaller than damon_ctx->min_region_sz. In the case, damos_apply_scheme() will skip applying the action, because the action is tried at region level, which requires >=min_region_sz size. That is, the quota is effectively exceeded for the quota charge window. Because no action will be applied, the total_charged_sz and total_charged_ns are also not updated. damos_set_effective_quota() will try to update the effective size quota before starting the next charge window. However, because the total_charged_sz and total_charged_ns have not updated, the throughput and effective size quota are also not changed. Since effective size quota can only be decreased, other effective size quota update factors including DAMOS quota goals and size quota cannot make any change, either. As a result, the scheme is unexpectedly deactivated until the user notices and mitigates the situation. The users can mitigate this situation by changing the time quota online or re-install the scheme. While the mitigation is somewhat straightforward, finding the situation would be challenging, because DAMON is not providing good observabilities for that. Even if such observability is provided, doing the additional monitoring and the mitigation is somewhat cumbersome and not aligned to the intention of the time quota. The time quota was intended to help reduce the user's administration overhead. Fix the problem by setting time quota-modified effective size quota be at least min_region_sz always. The issue was discovered [1] by sashiko. Link: https://lore.kernel.org/[email protected] Link: https://lore.kernel.org/[email protected] [1] Fixes: 1cd243030059 ("mm/damon/schemes: implement time quota") Signed-off-by: SeongJae Park <[email protected]> Cc: <[email protected]> # 5.16.x Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: SeongJae Park <[email protected]> Date: Fri Mar 27 16:33:14 2026 -0700 mm/damon/core: fix damon_call() vs kdamond_fn() exit race commit 55da81663b9642dd046b26dd6f1baddbcf337c1e upstream. Patch series "mm/damon/core: fix damon_call()/damos_walk() vs kdmond exit race". damon_call() and damos_walk() can leak memory and/or deadlock when they race with kdamond terminations. Fix those. This patch (of 2); When kdamond_fn() main loop is finished, the function cancels all remaining damon_call() requests and unset the damon_ctx->kdamond so that API callers and API functions themselves can know the context is terminated. damon_call() adds the caller's request to the queue first. After that, it shows if the kdamond of the damon_ctx is still running (damon_ctx->kdamond is set). Only if the kdamond is running, damon_call() starts waiting for the kdamond's handling of the newly added request. The damon_call() requests registration and damon_ctx->kdamond unset are protected by different mutexes, though. Hence, damon_call() could race with damon_ctx->kdamond unset, and result in deadlocks. For example, let's suppose kdamond successfully finished the damon_call() requests cancelling. Right after that, damon_call() is called for the context. It registers the new request, and shows the context is still running, because damon_ctx->kdamond unset is not yet done. Hence the damon_call() caller starts waiting for the handling of the request. However, the kdamond is already on the termination steps, so it never handles the new request. As a result, the damon_call() caller threads infinitely waits. Fix this by introducing another damon_ctx field, namely call_controls_obsolete. It is protected by the damon_ctx->call_controls_lock, which protects damon_call() requests registration. Initialize (unset) it in kdamond_fn() before letting damon_start() returns and set it just before the cancelling of remaining damon_call() requests is executed. damon_call() reads the obsolete field under the lock and avoids adding a new request. After this change, only requests that are guaranteed to be handled or cancelled are registered. Hence the after-registration DAMON context termination check is no longer needed. Remove it together. Note that the deadlock will not happen when damon_call() is called for repeat mode request. In tis case, damon_call() returns instead of waiting for the handling when the request registration succeeds and it shows the kdamond is running. However, if the request also has dealloc_on_cancel, the request memory would be leaked. The issue is found by sashiko [1]. Link: https://lore.kernel.org/[email protected] Link: https://lore.kernel.org/[email protected] Link: https://lore.kernel.org/[email protected] [1] Fixes: 42b7491af14c ("mm/damon/core: introduce damon_call()") Signed-off-by: SeongJae Park <[email protected]> Cc: <[email protected]> # 6.14.x Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: SeongJae Park <[email protected]> Date: Fri Mar 27 16:33:15 2026 -0700 mm/damon/core: fix damos_walk() vs kdamond_fn() exit race commit 33c3f6c2b48cd84b441dba1ee3e62290e53930f4 upstream. When kdamond_fn() main loop is finished, the function cancels remaining damos_walk() request and unset the damon_ctx->kdamond so that API callers and API functions themselves can show the context is terminated. damos_walk() adds the caller's request to the queue first. After that, it shows if the kdamond of the damon_ctx is still running (damon_ctx->kdamond is set). Only if the kdamond is running, damos_walk() starts waiting for the kdamond's handling of the newly added request. The damos_walk() requests registration and damon_ctx->kdamond unset are protected by different mutexes, though. Hence, damos_walk() could race with damon_ctx->kdamond unset, and result in deadlocks. For example, let's suppose kdamond successfully finished the damow_walk() request cancelling. Right after that, damos_walk() is called for the context. It registers the new request, and shows the context is still running, because damon_ctx->kdamond unset is not yet done. Hence the damos_walk() caller starts waiting for the handling of the request. However, the kdamond is already on the termination steps, so it never handles the new request. As a result, the damos_walk() caller thread infinitely waits. Fix this by introducing another damon_ctx field, namely walk_control_obsolete. It is protected by the damon_ctx->walk_control_lock, which protects damos_walk() request registration. Initialize (unset) it in kdamond_fn() before letting damon_start() returns and set it just before the cancelling of the remaining damos_walk() request is executed. damos_walk() reads the obsolete field under the lock and avoids adding a new request. After this change, only requests that are guaranteed to be handled or cancelled are registered. Hence the after-registration DAMON context termination check is no longer needed. Remove it together. The issue is found by sashiko [1]. Link: https://lore.kernel.org/[email protected] Link: https://lore.kernel.org/[email protected] [1] Fixes: bf0eaba0ff9c ("mm/damon/core: implement damos_walk()") Signed-off-by: SeongJae Park <[email protected]> Cc: <[email protected]> # 6.14.x Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: SeongJae Park <[email protected]> Date: Sun Mar 29 08:23:05 2026 -0700 mm/damon/core: use time_in_range_open() for damos quota window start 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/[email protected] Link: https://lore.kernel.org/[email protected] [1] Fixes: ee801b7dd782 ("mm/damon/schemes: activate schemes based on a watermarks mechanism") Signed-off-by: SeongJae Park <[email protected]> Cc: <[email protected]> # 5.16.x Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: SeongJae Park <[email protected]> Date: Sat Mar 28 21:38:59 2026 -0700 mm/damon/core: validate damos_quota_goal->nid for node_mem_{used,free}_bp commit 40250b2dded0604a112be605f3828700d80ad7c2 upstream. Patch series "mm/damon/core: validate damos_quota_goal->nid". node_mem[cg]_{used,free}_bp DAMOS quota goals receive the node id. The node id is used for si_meminfo_node() and NODE_DATA() without proper validation. As a result, privileged users can trigger an out of bounds memory access using DAMON_SYSFS. Fix the issues. The issue was originally reported [1] with a fix by another author. The original author announced [2] that they will stop working including the fix that was still in the review stage. Hence I'm restarting this. This patch (of 2): Users can set damos_quota_goal->nid with arbitrary value for node_mem_{used,free}_bp. But DAMON core is using those for si_meminfo_node() without the validation of the value. This can result in out of bounds memory access. The issue can actually triggered using DAMON user-space tool (damo), like below. $ sudo ./damo start --damos_action stat \ --damos_quota_goal node_mem_used_bp 50% -1 \ --damos_quota_interval 1s $ sudo dmesg [...] [ 65.565986] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000098 Fix this issue by adding the validation of the given node. If an invalid node id is given, it returns 0% for used memory ratio, and 100% for free memory ratio. Link: https://lore.kernel.org/[email protected] Link: https://lore.kernel.org/[email protected] [1] Link: https://lore.kernel.org/[email protected] [2] Fixes: 0e1c773b501f ("mm/damon/core: introduce damos quota goal metrics for memory node utilization") Signed-off-by: SeongJae Park <[email protected]> Cc: <[email protected]> # 6.16.x Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: SeongJae Park <[email protected]> Date: Sat Mar 28 21:39:00 2026 -0700 mm/damon/core: validate damos_quota_goal->nid for node_memcg_{used,free}_bp commit a34dac6482e53e2c76944f25b1489b9b7da3a6e6 upstream. Users can set damos_quota_goal->nid with arbitrary value for node_memcg_{used,free}_bp. But DAMON core is using those for NODE-DATA() without a validation of the value. This can result in out of bounds memory access. The issue can actually triggered using DAMON user-space tool (damo), like below. $ sudo mkdir /sys/fs/cgroup/foo $ sudo ./damo start --damos_action stat --damos_quota_interval 1s \ --damos_quota_goal node_memcg_used_bp 50% -1 /foo $ sudo dmseg [...] [ 524.181426] Unable to handle kernel paging request at virtual address 0000000000002c00 Fix this issue by adding the validation of the given node id. If an invalid node id is given, it returns 0% for used memory ratio, and 100% for free memory ratio. Link: https://lore.kernel.org/[email protected] Fixes: b74a120bcf50 ("mm/damon/core: implement DAMOS_QUOTA_NODE_MEMCG_USED_BP") Signed-off-by: SeongJae Park <[email protected]> Cc: <[email protected]> # 6.19.x Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jackie Liu <[email protected]> Date: Tue Mar 31 18:15:53 2026 +0800 mm/damon/stat: fix memory leak on damon_start() failure in damon_stat_start() commit e04ed278d25bf15769800bf6e35c6737f137186f upstream. Destroy the DAMON context and reset the global pointer when damon_start() fails. Otherwise, the context allocated by damon_stat_build_ctx() is leaked, and the stale damon_stat_context pointer will be overwritten on the next enable attempt, making the old allocation permanently unreachable. Link: https://lore.kernel.org/[email protected] Fixes: 369c415e6073 ("mm/damon: introduce DAMON_STAT module") Signed-off-by: Jackie Liu <[email protected]> Reviewed-by: SeongJae Park <[email protected]> Cc: <[email protected]> # 6.17.x Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thorsten Blum <[email protected]> Date: Thu Apr 9 12:54:40 2026 +0200 mm/hugetlb: fix early boot crash on parameters without '=' separator commit c45b354911d01565156e38d7f6bc07edb51fc34c upstream. If hugepages, hugepagesz, or default_hugepagesz are specified on the kernel command line without the '=' separator, early parameter parsing passes NULL to hugetlb_add_param(), which dereferences it in strlen() and can crash the system during early boot. Reject NULL values in hugetlb_add_param() and return -EINVAL instead. Link: https://lore.kernel.org/[email protected] Fixes: 5b47c02967ab ("mm/hugetlb: convert cmdline parameters from setup to early") Signed-off-by: Thorsten Blum <[email protected]> Reviewed-by: Muchun Song <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: Frank van der Linden <[email protected]> Cc: Oscar Salvador <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Chenghao Duan <[email protected]> Date: Thu Mar 26 16:47:25 2026 +0800 mm/memfd_luo: fix physical address conversion in put_folios cleanup commit 3538f90ab89aaf302782b4b073a0aae66904cd67 upstream. In memfd_luo_retrieve_folios()'s put_folios cleanup path: 1. kho_restore_folio() expects a phys_addr_t (physical address) but receives a raw PFN (pfolio->pfn). This causes kho_restore_page() to check the wrong physical address (pfn << PAGE_SHIFT instead of the actual physical address). 2. This loop lacks the !pfolio->pfn check that exists in the main retrieval loop and memfd_luo_discard_folios(), which could incorrectly process sparse file holes where pfn=0. Fix by converting PFN to physical address with PFN_PHYS() and adding the !pfolio->pfn check, matching the pattern used elsewhere in this file. This issue was identified by the AI review. https://sashiko.dev/#/patchset/[email protected] Link: https://lore.kernel.org/[email protected] Fixes: b3749f174d68 ("mm: memfd_luo: allow preserving memfd") Signed-off-by: Chenghao Duan <[email protected]> Reviewed-by: Pasha Tatashin <[email protected]> Reviewed-by: Pratyush Yadav <[email protected]> Cc: Haoran Jiang <[email protected]> Cc: Mike Rapoport (Microsoft) <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jackie Liu <[email protected]> Date: Wed Apr 1 08:57:02 2026 +0800 mm/mempolicy: fix memory leaks in weighted_interleave_auto_store() commit 6fae274ce0e3109cbbc4c18b354eaace1f0af7d7 upstream. weighted_interleave_auto_store() fetches old_wi_state inside the if (!input) block only. This causes two memory leaks: 1. When a user writes "false" and the current mode is already manual, the function returns early without freeing the freshly allocated new_wi_state. 2. When a user writes "true", old_wi_state stays NULL because the fetch is skipped entirely. The old state is then overwritten by rcu_assign_pointer() but never freed, since the cleanup path is gated on old_wi_state being non-NULL. A user can trigger this repeatedly by writing "1" in a loop. Fix both leaks by moving the old_wi_state fetch before the input check, making it unconditional. This also allows a unified early return for both "true" and "false" when the requested mode matches the current mode. Link: https://lore.kernel.org/[email protected] Link: https://sashiko.dev/#/patchset/[email protected] Fixes: e341f9c3c841 ("mm/mempolicy: Weighted Interleave Auto-tuning") Signed-off-by: Jackie Liu <[email protected]> Reviewed-by: Joshua Hahn <[email protected]> Reviewed by: Donet Tom <[email protected]> Cc: Gregory Price <[email protected]> Cc: Alistair Popple <[email protected]> Cc: Byungchul Park <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: <[email protected]> # v6.16+ Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Harry Yoo (Oracle) <[email protected]> Date: Mon Apr 27 16:09:52 2026 +0900 mm/page_alloc: return NULL early from alloc_frozen_pages_nolock() in NMI on UP commit 620b46ed6ae17c8438d889c8c0cfddab36a1476c upstream. On UP kernels (!CONFIG_SMP), spin_trylock() is a no-op that unconditionally succeeds even when the lock is already held. As a result, alloc_frozen_pages_nolock() called from NMI context can re-enter rmqueue() and acquire the zone lock that the interrupted context is already holding, corrupting the freelists. With CONFIG_DEBUG_SPINLOCK on UP, the following BUG is triggered with the slub_kunit test module: BUG: spinlock trylock failure on UP on CPU#0, kunit_try_catch/243 [...] Call Trace: <NMI> dump_stack_lvl+0x3f/0x60 do_raw_spin_trylock+0x41/0x50 _raw_spin_trylock+0x24/0x50 rmqueue.isra.0+0x2a9/0xa70 get_page_from_freelist+0xeb/0x450 alloc_frozen_pages_nolock_noprof+0x111/0x1e0 allocate_slab+0x42a/0x500 ___slab_alloc+0xa7/0x4c0 kmalloc_nolock_noprof+0x164/0x310 [...] </NMI> Fix this by returning NULL early when invoked from NMI on a UP kernel. Link: https://lore.kernel.org/linux-mm/ad_cqe51pvr1WaDg@hyeyoo Cc: [email protected] Fixes: d7242af86434 ("mm: Introduce alloc_frozen_pages_nolock()") Signed-off-by: Harry Yoo (Oracle) <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Vlastimil Babka (SUSE) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Harry Yoo (Oracle) <[email protected]> Date: Mon Apr 27 16:09:53 2026 +0900 mm/slab: return NULL early from kmalloc_nolock() in NMI on UP commit 5b31044e649e3e54c2caef135c09b371c2fbcd08 upstream. On UP kernels (!CONFIG_SMP), spin_trylock() is a no-op that unconditionally succeeds even when the lock is already held. As a result, kmalloc_nolock() called from NMI context can re-enter the slab allocator and acquire n->list_lock that the interrupted context is already holding, corrupting slab state. With CONFIG_DEBUG_SPINLOCK on UP, the following BUG is triggered with the slub_kunit test module: BUG: spinlock trylock failure on UP on CPU#0, kunit_try_catch/243 [...] Call Trace: <NMI> dump_stack_lvl+0x3f/0x60 do_raw_spin_trylock+0x41/0x50 _raw_spin_trylock+0x24/0x50 get_from_partial_node+0x120/0x4d0 ___slab_alloc+0x8a/0x4c0 kmalloc_nolock_noprof+0x164/0x310 [...] </NMI> Fix this by returning NULL early when invoked from NMI on a UP kernel. Link: https://lore.kernel.org/linux-mm/ad_cqe51pvr1WaDg@hyeyoo Cc: [email protected] Fixes: af92793e52c3 ("slab: Introduce kmalloc_nolock() and kfree_nolock().") Signed-off-by: Harry Yoo (Oracle) <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Vlastimil Babka (SUSE) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Uladzislau Rezki (Sony) <[email protected]> Date: Mon Apr 13 21:26:46 2026 +0200 mm/vmalloc: take vmap_purge_lock in shrinker commit ec05f51f1e65bce95528543eb73fda56fd201d94 upstream. decay_va_pool_node() can be invoked concurrently from two paths: __purge_vmap_area_lazy() when pools are being purged, and the shrinker via vmap_node_shrink_scan(). However, decay_va_pool_node() is not safe to run concurrently, and the shrinker path currently lacks serialization, leading to races and possible leaks. Protect decay_va_pool_node() by taking vmap_purge_lock in the shrinker path to ensure serialization with purge users. Link: https://lore.kernel.org/[email protected] Fixes: 7679ba6b36db ("mm: vmalloc: add a shrinker to drain vmap pools") Signed-off-by: Uladzislau Rezki (Sony) <[email protected]> Reviewed-by: Baoquan He <[email protected]> Cc: chenyichong <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Matthew Brost <[email protected]> Date: Fri Apr 10 16:03:46 2026 -0700 mm/zone_device: do not touch device folio after calling ->folio_free() commit 39928984956037cabd304321cb8f342e47421db5 upstream. The contents of a device folio can immediately change after calling ->folio_free(), as the folio may be reallocated by a driver with a different order. Instead of touching the folio again to extract the pgmap, use the local stack variable when calling percpu_ref_put_many(). Link: https://lore.kernel.org/[email protected] Fixes: d245f9b4ab80 ("mm/zone_device: support large zone device private folios") Signed-off-by: Matthew Brost <[email protected]> Reviewed-by: Balbir Singh <[email protected]> Reviewed-by: Vishal Moola <[email protected]> Reviewed-by: Alistair Popple <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: Oscar Salvador <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Shigeru Yoshida <[email protected]> Date: Sat Mar 21 22:29:11 2026 +0900 mm/zsmalloc: copy KMSAN metadata in zs_page_migrate() commit 4fb61d95ad21c3b6f1c09f357ff49d70abb0535e upstream. zs_page_migrate() uses copy_page() to copy the contents of a zspage page during migration. However, copy_page() is not instrumented by KMSAN, so the shadow and origin metadata of the destination page are not updated. As a result, subsequent accesses to the migrated page are reported as use-after-free by KMSAN, despite the data being correctly copied. Add a kmsan_copy_page_meta() call after copy_page() to propagate the KMSAN metadata to the new page, matching what copy_highpage() does internally. Link: https://lkml.kernel.org/r/[email protected] Fixes: afb2d666d025 ("zsmalloc: use copy_page for full page copy") Signed-off-by: Shigeru Yoshida <[email protected]> Reviewed-by: Sergey Senozhatsky <[email protected]> Cc: Mark-PK Tsai <[email protected]> Cc: Minchan Kim <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Lorenzo Stoakes (Oracle) <[email protected]> Date: Wed Apr 29 01:36:20 2026 -0400 mm: avoid deadlock when holding rmap on mmap_prepare error [ Upstream commit f96e1d5f15b7c854a6a9ec1225d68a12fe7dcda6 ] Commit ac0a3fc9c07d ("mm: add ability to take further action in vm_area_desc") added the ability for drivers to instruct mm to take actions after the .mmap_prepare callback is complete. To make life simpler and safer, this is done before the VMA/mmap write lock is dropped but when the VMA is completely established. So on error, we simply munmap() the VMA. As part of this implementation, unfortunately a horrible hack had to be implemented to support some questionable behaviour hugetlb relies upon - that is that the file rmap lock is held until the operation is complete. The implementation, for convenience, did this in mmap_action_finish() so both the VMA and mmap_prepare compatibility layer paths would have this correctly handled. However, it turns out there is a mistake here - the rmap lock cannot be held on munmap, as free_pgtables() -> unlink_file_vma_batch_add() -> unlink_file_vma_batch_process() takes the file rmap lock. We therefore currently have a deadlock issue that might arise. Resolve this by leaving it to callers to handle the unmap. The compatibility layer does not support this rmap behaviour, so we simply have it unmap on error after calling mmap_action_complete(). In the VMA implementation, we only perform the unmap after the rmap lock is dropped. This resolves the issue by ensuring the rmap lock is always dropped when the unmap occurs. Link: https://lkml.kernel.org/r/d44248be9da68258b07c2c59d4e73485ee0ca943.1774045440.git.ljs@kernel.org Fixes: ac0a3fc9c07d ("mm: add ability to take further action in vm_area_desc") Signed-off-by: Lorenzo Stoakes (Oracle) <[email protected]> Acked-by: Vlastimil Babka (SUSE) <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Alexandre Torgue <[email protected]> Cc: Al Viro <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Bodo Stroesser <[email protected]> Cc: Christian Brauner <[email protected]> Cc: Clemens Ladisch <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: David Howells <[email protected]> Cc: Dexuan Cui <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Haiyang Zhang <[email protected]> Cc: Jan Kara <[email protected]> Cc: Jann Horn <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: K. Y. Srinivasan <[email protected]> Cc: Liam Howlett <[email protected]> Cc: Long Li <[email protected]> Cc: Marc Dionne <[email protected]> Cc: "Martin K. Petersen" <[email protected]> Cc: Maxime Coquelin <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Mike Rapoport <[email protected]> Cc: Miquel Raynal <[email protected]> Cc: Pedro Falcato <[email protected]> Cc: Richard Weinberger <[email protected]> Cc: Ryan Roberts <[email protected]> Cc: Suren Baghdasaryan <[email protected]> Cc: Vignesh Raghavendra <[email protected]> Cc: Vlastimil Babka (SUSE) <[email protected]> Cc: Wei Liu <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Lance Yang <[email protected]> Date: Wed Apr 1 21:10:32 2026 +0800 mm: fix deferred split queue races during migration commit 3bac01168982ec3e3bf87efdc1807c7933590a85 upstream. migrate_folio_move() records the deferred split queue state from src and replays it on dst. Replaying it after remove_migration_ptes(src, dst, 0) makes dst visible before it is requeued, so a concurrent rmap-removal path can mark dst partially mapped and trip the WARN in deferred_split_folio(). Move the requeue before remove_migration_ptes() so dst is back on the deferred split queue before it becomes visible again. Because migration still holds dst locked at that point, teach deferred_split_scan() to requeue a folio when folio_trylock() fails. Otherwise a fully mapped underused folio can be dequeued by the shrinker and silently lost from split_queue. [[email protected]: move the comment] Link: https://lkml.kernel.org/r/[email protected] Link: https://syzkaller.appspot.com/bug?extid=a7067a757858ac8eb085 Link: https://lkml.kernel.org/r/[email protected] Fixes: 8a8ca142a488 ("mm: migrate: requeue destination folio on deferred split queue") Signed-off-by: Lance Yang <[email protected]> Signed-off-by: Zi Yan <[email protected]> Reported-by: [email protected] Closes: https://lore.kernel.org/linux-mm/[email protected]/ Suggested-by: David Hildenbrand (Arm) <[email protected]> Acked-by: David Hildenbrand (Arm) <[email protected]> Acked-by: Zi Yan <[email protected]> Cc: Alistair Popple <[email protected]> Cc: Baolin Wang <[email protected]> Cc: Barry Song <[email protected]> Cc: Byungchul Park <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: Deepanshu Kartikey <[email protected]> Cc: Dev Jain <[email protected]> Cc: Gregory Price <[email protected]> Cc: "Huang, Ying" <[email protected]> Cc: Joshua Hahn <[email protected]> Cc: Lance Yang <[email protected]> Cc: Liam Howlett <[email protected]> Cc: Lorenzo Stoakes (Oracle) <[email protected]> Cc: Matthew Brost <[email protected]> Cc: Nico Pache <[email protected]> Cc: Rakie Kim <[email protected]> Cc: Ryan Roberts <[email protected]> Cc: Wei Yang <[email protected]> Cc: Ying Huang <[email protected]> Cc: Usama Arif <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Usama Arif <[email protected]> Date: Thu Mar 12 03:47:23 2026 -0700 mm: migrate: requeue destination folio on deferred split queue commit a2e0c0668a3486f96b86c50e02872c8e94fd4f9c upstream. During folio migration, __folio_migrate_mapping() removes the source folio from the deferred split queue, but the destination folio is never re-queued. This causes underutilized THPs to escape the shrinker after NUMA migration, since they silently drop off the deferred split list. Fix this by recording whether the source folio was on the deferred split queue and its partially mapped state before move_to_new_folio() unqueues it, and re-queuing the destination folio after a successful migration if it was. By the time migrate_folio_move() runs, partially mapped folios without a pin have already been split by migrate_pages_batch(). So only two cases remain on the deferred list at this point: 1. Partially mapped folios with a pin (split failed). 2. Fully mapped but potentially underused folios. The recorded partially_mapped state is forwarded to deferred_split_folio() so that the destination folio is correctly re-queued in both cases. Because THPs are removed from the deferred_list, THP shinker cannot split the underutilized THPs in time. As a result, users will show less free memory than before. Link: https://lkml.kernel.org/r/[email protected] Fixes: dafff3f4c850 ("mm: split underused THPs") Signed-off-by: Usama Arif <[email protected]> Reported-by: Johannes Weiner <[email protected]> Acked-by: Johannes Weiner <[email protected]> Acked-by: Zi Yan <[email protected]> Acked-by: David Hildenbrand (Arm) <[email protected]> Acked-by: SeongJae Park <[email protected]> Reviewed-by: Wei Yang <[email protected]> Cc: Alistair Popple <[email protected]> Cc: Byungchul Park <[email protected]> Cc: Gregory Price <[email protected]> Cc: "Huang, Ying" <[email protected]> Cc: Joshua Hahn <[email protected]> Cc: Matthew Brost <[email protected]> Cc: Matthew Wilcox (Oracle) <[email protected]> Cc: Nico Pache <[email protected]> Cc: Rakie Kim <[email protected]> Cc: Ying Huang <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Anthony Yznaga <[email protected]> Date: Tue Mar 10 08:58:20 2026 -0700 mm: prevent droppable mappings from being locked commit d239462787b072c78eb19fc1f155c3d411256282 upstream. Droppable mappings must not be lockable. There is a check for VMAs with VM_DROPPABLE set in mlock_fixup() along with checks for other types of unlockable VMAs which ensures this when calling mlock()/mlock2(). For mlockall(MCL_FUTURE), the check for unlockable VMAs is different. In apply_mlockall_flags(), if the flags parameter has MCL_FUTURE set, the current task's mm's default VMA flag field mm->def_flags has VM_LOCKED applied to it. VM_LOCKONFAULT is also applied if MCL_ONFAULT is also set. When these flags are set as default in this manner they are cleared in __mmap_complete() for new mappings that do not support mlock. A check for VM_DROPPABLE in __mmap_complete() is missing resulting in droppable mappings created with VM_LOCKED set. To fix this and reduce that chance of similar bugs in the future, introduce and use vma_supports_mlock(). Link: https://lkml.kernel.org/r/[email protected] Fixes: 9651fcedf7b9 ("mm: add MAP_DROPPABLE for designating always lazily freeable mappings") Signed-off-by: Anthony Yznaga <[email protected]> Suggested-by: David Hildenbrand <[email protected]> Acked-by: David Hildenbrand (Arm) <[email protected]> Reviewed-by: Pedro Falcato <[email protected]> Reviewed-by: Lorenzo Stoakes (Oracle) <[email protected]> Tested-by: Lorenzo Stoakes (Oracle) <[email protected]> Cc: Jann Horn <[email protected]> Cc: Jason A. Donenfeld <[email protected]> Cc: Liam Howlett <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Mike Rapoport <[email protected]> Cc: Shuah Khan <[email protected]> Cc: Suren Baghdasaryan <[email protected]> Cc: Vlastimil Babka <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Lorenzo Stoakes (Oracle) <[email protected]> Date: Wed Apr 29 01:36:19 2026 -0400 mm: various small mmap_prepare cleanups [ Upstream commit 3e4bb2706817710d9461394da8b75be79981586b ] Patch series "mm: expand mmap_prepare functionality and usage", v4. This series expands the mmap_prepare functionality, which is intended to replace the deprecated f_op->mmap hook which has been the source of bugs and security issues for some time. This series starts with some cleanup of existing mmap_prepare logic, then adds documentation for the mmap_prepare call to make it easier for filesystem and driver writers to understand how it works. It then importantly adds a vm_ops->mapped hook, a key feature that was missing from mmap_prepare previously - this is invoked when a driver which specifies mmap_prepare has successfully been mapped but not merged with another VMA. mmap_prepare is invoked prior to a merge being attempted, so you cannot manipulate state such as reference counts as if it were a new mapping. The vm_ops->mapped hook allows a driver to perform tasks required at this stage, and provides symmetry against subsequent vm_ops->open,close calls. The series uses this to correct the afs implementation which wrongly manipulated reference count at mmap_prepare time. It then adds an mmap_prepare equivalent of vm_iomap_memory() - mmap_action_simple_ioremap(), then uses this to update a number of drivers. It then splits out the mmap_prepare compatibility layer (which allows for invocation of mmap_prepare hooks in an mmap() hook) in such a way as to allow for more incremental implementation of mmap_prepare hooks. It then uses this to extend mmap_prepare usage in drivers. Finally it adds an mmap_prepare equivalent of vm_map_pages(), which lays the foundation for future work which will extend mmap_prepare to DMA coherent mappings. This patch (of 21): Rather than passing arbitrary fields, pass a vm_area_desc pointer to mmap prepare functions to mmap prepare, and an action and vma pointer to mmap complete in order to put all the action-specific logic in the function actually doing the work. Additionally, allow mmap prepare functions to return an error so we can error out as soon as possible if there is something logically incorrect in the input. Update remap_pfn_range_prepare() to properly check the input range for the CoW case. Also remove io_remap_pfn_range_complete(), as we can simply set up the fields correctly in io_remap_pfn_range_prepare() and use remap_pfn_range_complete() for this. While we're here, make remap_pfn_range_prepare_vma() a little neater, and pass mmap_action directly to call_action_complete(). Then, update compat_vma_mmap() to perform its logic directly, as __compat_vma_map() is not used by anything so we don't need to export it. Also update compat_vma_mmap() to use vfs_mmap_prepare() rather than calling the mmap_prepare op directly. Finally, update the VMA userland tests to reflect the changes. Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/99f408e4694f44ab12bdc55fe0bd9685d3bd1117.1774045440.git.ljs@kernel.org Signed-off-by: Lorenzo Stoakes (Oracle) <[email protected]> Acked-by: Vlastimil Babka (SUSE) <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Alexandre Torgue <[email protected]> Cc: Al Viro <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Bodo Stroesser <[email protected]> Cc: Christian Brauner <[email protected]> Cc: Clemens Ladisch <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: David Howells <[email protected]> Cc: Dexuan Cui <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Haiyang Zhang <[email protected]> Cc: Jan Kara <[email protected]> Cc: Jann Horn <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: K. Y. Srinivasan <[email protected]> Cc: Liam Howlett <[email protected]> Cc: Long Li <[email protected]> Cc: Marc Dionne <[email protected]> Cc: "Martin K. Petersen" <[email protected]> Cc: Maxime Coquelin <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Mike Rapoport <[email protected]> Cc: Miquel Raynal <[email protected]> Cc: Pedro Falcato <[email protected]> Cc: Richard Weinberger <[email protected]> Cc: Ryan Roberts <[email protected]> Cc: Suren Baghdasaryan <[email protected]> Cc: Vignesh Raghavendra <[email protected]> Cc: Wei Liu <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Stable-dep-of: f96e1d5f15b7 ("mm: avoid deadlock when holding rmap on mmap_prepare error") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bin Liu <[email protected]> Date: Wed Mar 25 08:49:47 2026 -0500 mmc: block: use single block write in retry commit c7c6d4f5103864f73ee3a78bfd6da241f84197dd upstream. Due to errata i2493[0], multi-block write would still fail in retries. With i2493, the MMC interface has the potential of write failures when issuing multi-block writes operating in HS200 mode with excessive IO supply noise. While the errata provides guidance in hardware design and layout to minimize the IO supply noise, in theory the write failure cannot be resolved in hardware. The software solution to ensure the data integrity is to add minimum 5us delay between block writes. Single-block write is the practical way to introduce the delay. This patch reuses recovery_mode flag, and switches to single-block write in retry when multi-block write fails. It covers both CQE and non-CQE cases. [0] https://www.ti.com/lit/pdf/sprz582 Cc: [email protected] Suggested-by: Jens Axboe <[email protected]> Signed-off-by: Bin Liu <[email protected]> Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Shawn Lin <[email protected]> Date: Wed Apr 8 15:18:49 2026 +0800 mmc: sdhci-of-dwcmshc: Disable clock before DLL configuration commit 6546a49bbe656981d99a389195560999058c89c4 upstream. According to the ASIC design recommendations, the clock must be disabled before operating the DLL to prevent glitches that could affect the internal digital logic. In extreme cases, failing to do so may cause the controller to malfunction completely. Adds a step to disable the clock before DLL configuration and re-enables it at the end. Fixes: 08f3dff799d4 ("mmc: sdhci-of-dwcmshc: add rockchip platform support") Cc: [email protected] Signed-off-by: Shawn Lin <[email protected]> Acked-by: Adrian Hunter <[email protected]> Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Joe Lawrence <[email protected]> Date: Wed Mar 4 20:52:37 2026 -0500 module.lds,codetag: force 0 sh_addr for sections commit 4afc71bba8b7d7841681e7647ae02f5079aaf28f upstream. Commit 1ba9f8979426 ("vmlinux.lds: Unify TEXT_MAIN, DATA_MAIN, and related macros") added .text and made .data, .bss, and .rodata sections unconditional in the module linker script, but without an explicit address like the other sections in the same file. When linking modules with ld.bfd -r, sections defined without an address inherit the location counter, resulting in non-zero sh_addr values in the .ko. Relocatable objects are expected to have sh_addr=0 for these sections and these non-zero addresses confuse elfutils and have been reported to cause segmentation faults in SystemTap [1]. Add the 0 address specifier to all sections in module.lds, including the .codetag.* sections via MOD_SEPARATE_CODETAG_SECTIONS macro. Link: https://sourceware.org/bugzilla/show_bug.cgi?id=33958 Fixes: 1ba9f8979426 ("vmlinux.lds: Unify TEXT_MAIN, DATA_MAIN, and related macros") Signed-off-by: Joe Lawrence <[email protected]> Reviewed-by: Petr Pavlu <[email protected]> Acked-by: Josh Poimboeuf <[email protected]> Signed-off-by: Sami Tolvanen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Helge Deller <[email protected]> Date: Tue Apr 7 22:07:22 2026 +0200 module.lds.S: Fix modules on 32-bit parisc architecture commit 1221365f55281349da4f4ba41c05b57cd15f5c28 upstream. On the 32-bit parisc architecture, we always used the -ffunction-sections compiler option to tell the compiler to put the functions into seperate text sections. This is necessary, otherwise "big" kernel modules like ext4 or ipv6 fail to load because some branches won't be able to reach their stubs. Commit 1ba9f8979426 ("vmlinux.lds: Unify TEXT_MAIN, DATA_MAIN, and related macros") broke this for parisc because all text sections will get unconditionally merged now. Introduce the ARCH_WANTS_MODULES_TEXT_SECTIONS config option which avoids the text section merge for modules, and fix this issue by enabling this option by default for 32-bit parisc. Fixes: 1ba9f8979426 ("vmlinux.lds: Unify TEXT_MAIN, DATA_MAIN, and related macros") Cc: Josh Poimboeuf <[email protected]> Cc: [email protected] # v6.19+ Suggested-by: Sami Tolvanen <[email protected]> Reviewed-by: Petr Pavlu <[email protected]> Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Gang Yan <[email protected]> Date: Mon Apr 20 18:19:23 2026 +0200 mptcp: sync the msk->sndbuf at accept() time commit fcf04b14334641f4b0b8647824480935e9416d52 upstream. On passive MPTCP connections, the msk sndbuf is not updated correctly. The root cause is an order issue in the accept path: - tcp_check_req() -> subflow_syn_recv_sock() -> mptcp_sk_clone_init() calls __mptcp_propagate_sndbuf() to copy the ssk sndbuf into msk - Later, tcp_child_process() -> tcp_init_transfer() -> tcp_sndbuf_expand() grows the ssk sndbuf. So __mptcp_propagate_sndbuf() runs before the ssk sndbuf has been expanded and the msk ends up with a much smaller sndbuf than the subflow: MPTCP: msk->sndbuf:20480, msk->first->sndbuf:2626560 Fix this by moving the __mptcp_propagate_sndbuf() call from mptcp_sk_clone_init() -- the ssk sndbuf is not yet finalized there -- to __mptcp_propagate_sndbuf() at accept() time, when the ssk sndbuf has been fully expanded by tcp_sndbuf_expand(). Fixes: 8005184fd1ca ("mptcp: refactor sndbuf auto-tuning") Cc: [email protected] Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/602 Signed-off-by: Gang Yan <[email protected]> Acked-by: Paolo Abeni <[email protected]> Reviewed-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/20260420-net-mptcp-sync-sndbuf-accept-v1-1-e3523e3aeb44@kernel.org Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: James Kim <[email protected]> Date: Mon Mar 9 15:05:12 2026 +0900 mtd: docg3: fix use-after-free in docg3_release() commit ca19808bc6fac7e29420d8508df569b346b3e339 upstream. In docg3_release(), the docg3 pointer is obtained from cascade->floors[0]->priv before the loop that calls doc_release_device() on each floor. doc_release_device() frees the docg3 struct via kfree(docg3) at line 1881. After the loop, docg3->cascade->bch dereferences the already-freed pointer. Fix this by accessing cascade->bch directly, which is equivalent since docg3->cascade points back to the same cascade struct, and is already available as a local variable. This also removes the now-unused docg3 local variable. Fixes: c8ae3f744ddc ("lib/bch: Rework a little bit the exported function names") Cc: [email protected] Signed-off-by: James Kim <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sanjaikumar V S <[email protected]> Date: Wed Mar 11 10:30:56 2026 +0000 mtd: spi-nor: sst: Fix write enable before AAI sequence commit a0f64241d3566a49c0a9b33ba7ae458ae22003a9 upstream. When writing to SST flash starting at an odd address, a single byte is first programmed using the byte program (BP) command. After this operation completes, the flash hardware automatically clears the Write Enable Latch (WEL) bit. If an AAI (Auto Address Increment) word program sequence follows, it requires WEL to be set. Without re-enabling writes, the AAI sequence fails. Add spi_nor_write_enable() after the odd-address byte program when more data needs to be written. Use a local boolean for clarity. Fixes: b199489d37b2 ("mtd: spi-nor: add the framework for SPI NOR") Cc: [email protected] Signed-off-by: Sanjaikumar V S <[email protected]> Tested-by: Hendrik Donner <[email protected]> Reviewed-by: Hendrik Donner <[email protected]> Signed-off-by: Pratyush Yadav (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Miquel Raynal <[email protected]> Date: Wed Mar 25 18:04:50 2026 +0100 mtd: spinand: winbond: Declare the QE bit on W25NxxJW commit 7866ce992cf0d3c3b50fe8bf4acb1dbb173a2304 upstream. Factory default for this bit is "set" (at least on the chips I have), but we must make sure it is actually set by Linux explicitly, as the bit is writable by an earlier stage. Fixes: 6a804fb72de5 ("mtd: spinand: winbond: add support for serial NAND flash") Cc: [email protected] Signed-off-by: Miquel Raynal <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ruijie Li <[email protected]> Date: Wed Apr 22 23:40:18 2026 +0800 net/smc: avoid early lgr access in smc_clc_wait_msg commit 5a8db80f721deee8e916c2cfdee78decda02ce4f upstream. A CLC decline can be received while the handshake is still in an early stage, before the connection has been associated with a link group. The decline handling in smc_clc_wait_msg() updates link-group level sync state for first-contact declines, but that state only exists after link group setup has completed. Guard the link-group update accordingly and keep the per-socket peer diagnosis handling unchanged. This preserves the existing sync_err handling for established link-group contexts and avoids touching link-group state before it is available. Fixes: 0cfdd8f92cac ("smc: connection and link group creation") Cc: [email protected] Reported-by: Yuan Tan <[email protected]> Reported-by: Yifan Wu <[email protected]> Reported-by: Juefei Pu <[email protected]> Reported-by: Xin Liu <[email protected]> Signed-off-by: Ruijie Li <[email protected]> Signed-off-by: Ren Wei <[email protected]> Reviewed-by: Dust Li <[email protected]> Link: https://patch.msgid.link/08c68a5c817acf198cce63d22517e232e8d60718.1776850759.git.ruijieli51@gmail.com Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zhengchuan Liang <[email protected]> Date: Mon Apr 13 17:08:46 2026 +0800 net: bridge: use a stable FDB dst snapshot in RCU readers commit df4601653201de21b487c3e7fffd464790cab808 upstream. Local FDB entries can be rewritten in place by `fdb_delete_local()`, which updates `f->dst` to another port or to `NULL` while keeping the entry alive. Several bridge RCU readers inspect `f->dst`, including `br_fdb_fillbuf()` through the `brforward_read()` sysfs path. These readers currently load `f->dst` multiple times and can therefore observe inconsistent values across the check and later dereference. In `br_fdb_fillbuf()`, this means a concurrent local-FDB update can change `f->dst` after the NULL check and before the `port_no` dereference, leading to a NULL-ptr-deref. Fix this by taking a single `READ_ONCE()` snapshot of `f->dst` in each affected RCU reader and using that snapshot for the rest of the access sequence. Also publish the in-place `f->dst` updates in `fdb_delete_local()` with `WRITE_ONCE()` so the readers and writer use matching access patterns. Fixes: 960b589f86c7 ("bridge: Properly check if local fdb entry can be deleted in br_fdb_change_mac_address") Cc: [email protected] Reported-by: Yifan Wu <[email protected]> Reported-by: Juefei Pu <[email protected]> Co-developed-by: Yuan Tan <[email protected]> Signed-off-by: Yuan Tan <[email protected]> Suggested-by: Xin Liu <[email protected]> Tested-by: Ren Wei <[email protected]> Signed-off-by: Zhengchuan Liang <[email protected]> Signed-off-by: Ren Wei <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Acked-by: Nikolay Aleksandrov <[email protected]> Link: https://patch.msgid.link/6570fabb85ecadb8baaf019efe856f407711c7b9.1776043229.git.zcliangcn@gmail.com Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zhengchuan Liang <[email protected]> Date: Sat Apr 11 23:10:26 2026 +0800 net: caif: clear client service pointer on teardown commit f7cf8ece8cee3c1ee361991470cdb1eb65ab02e8 upstream. `caif_connect()` can tear down an existing client after remote shutdown by calling `caif_disconnect_client()` followed by `caif_free_client()`. `caif_free_client()` releases the service layer referenced by `adap_layer->dn`, but leaves that pointer stale. When the socket is later destroyed, `caif_sock_destructor()` calls `caif_free_client()` again and dereferences the freed service pointer. Clear the client/service links before releasing the service object so repeated teardown becomes harmless. Fixes: 43e369210108 ("caif: Move refcount from service layer to sock and dev.") Cc: [email protected] Reported-by: Yifan Wu <[email protected]> Reported-by: Juefei Pu <[email protected]> Co-developed-by: Yuan Tan <[email protected]> Signed-off-by: Yuan Tan <[email protected]> Suggested-by: Xin Liu <[email protected]> Tested-by: Ren Wei <[email protected]> Signed-off-by: Zhengchuan Liang <[email protected]> Signed-off-by: Ren Wei <[email protected]> Link: https://patch.msgid.link/9f3d37847c0037568aae698ca23cd47c6691acb0.1775897577.git.zcliangcn@gmail.com Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Andrea Mayer <[email protected]> Date: Tue Apr 21 11:47:35 2026 +0200 net: ipv6: fix NOREF dst use in seg6 and rpl lwtunnels commit f9c52a6ba9780bd27e0bf4c044fd91c13c778b6e upstream. seg6_input_core() and rpl_input() call ip6_route_input() which sets a NOREF dst on the skb, then pass it to dst_cache_set_ip6() invoking dst_hold() unconditionally. On PREEMPT_RT, ksoftirqd is preemptible and a higher-priority task can release the underlying pcpu_rt between the lookup and the caching through a concurrent FIB lookup on a shared nexthop. Simplified race sequence: ksoftirqd/X higher-prio task (same CPU X) ----------- -------------------------------- seg6_input_core(,skb)/rpl_input(skb) dst_cache_get() -> miss ip6_route_input(skb) -> ip6_pol_route(,skb,flags) [RT6_LOOKUP_F_DST_NOREF in flags] -> FIB lookup resolves fib6_nh [nhid=N route] -> rt6_make_pcpu_route() [creates pcpu_rt, refcount=1] pcpu_rt->sernum = fib6_sernum [fib6_sernum=W] -> cmpxchg(fib6_nh.rt6i_pcpu, NULL, pcpu_rt) [slot was empty, store succeeds] -> skb_dst_set_noref(skb, dst) [dst is pcpu_rt, refcount still 1] rt_genid_bump_ipv6() -> bumps fib6_sernum [fib6_sernum from W to Z] ip6_route_output() -> ip6_pol_route() -> FIB lookup resolves fib6_nh [nhid=N] -> rt6_get_pcpu_route() pcpu_rt->sernum != fib6_sernum [W <> Z, stale] -> prev = xchg(rt6i_pcpu, NULL) -> dst_release(prev) [prev is pcpu_rt, refcount 1->0, dead] dst = skb_dst(skb) [dst is the dead pcpu_rt] dst_cache_set_ip6(dst) -> dst_hold() on dead dst -> WARN / use-after-free For the race to occur, ksoftirqd must be preemptible (PREEMPT_RT without PREEMPT_RT_NEEDS_BH_LOCK) and a concurrent task must be able to release the pcpu_rt. Shared nexthop objects provide such a path, as two routes pointing to the same nhid share the same fib6_nh and its rt6i_pcpu entry. Fix seg6_input_core() and rpl_input() by calling skb_dst_force() after ip6_route_input() to force the NOREF dst into a refcounted one before caching. The output path is not affected as ip6_route_output() already returns a refcounted dst. Fixes: af4a2209b134 ("ipv6: sr: use dst_cache in seg6_input") Fixes: a7a29f9c361f ("net: ipv6: add rpl sr tunnel") Cc: [email protected] Signed-off-by: Andrea Mayer <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: Justin Iurman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Marek Vasut <[email protected]> Date: Thu Apr 16 01:09:45 2026 +0200 net: ks8851: Avoid excess softirq scheduling commit 22230e68b2cf1ab6b027be8cf1198164a949c4fa upstream. The code injects a packet into netif_rx() repeatedly, which will add it to its internal NAPI and schedule a softirq, and process it. It is more efficient to queue multiple packets and process them all at the local_bh_enable() time. Reviewed-by: Sebastian Andrzej Siewior <[email protected]> Fixes: e0863634bf9f ("net: ks8851: Queue RX packets in IRQ handler instead of disabling BHs") Cc: [email protected] Signed-off-by: Marek Vasut <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Marek Vasut <[email protected]> Date: Thu Apr 16 01:09:44 2026 +0200 net: ks8851: Reinstate disabling of BHs around IRQ handler commit 5c9fcac3c872224316714d0d8914d9af16c76a6d upstream. If the driver executes ks8851_irq() AND a TX packet has been sent, then the driver enables TX queue via netif_wake_queue() which schedules TX softirq to queue packets for this device. If CONFIG_PREEMPT_RT=y is set AND a packet has also been received by the MAC, then ks8851_rx_pkts() calls netdev_alloc_skb_ip_align() to allocate SKBs for the received packets. If netdev_alloc_skb_ip_align() is called with BH enabled, then local_bh_enable() at the end of netdev_alloc_skb_ip_align() will trigger the pending softirq processing, which may ultimately call the .xmit callback ks8851_start_xmit_par(). The ks8851_start_xmit_par() will try to lock struct ks8851_net_par .lock spinlock, which is already locked by ks8851_irq() from which ks8851_start_xmit_par() was called. This leads to a deadlock, which is reported by the kernel, including a trace listed below. If CONFIG_PREEMPT_RT is not set, then since commit 0913ec336a6c0 ("net: ks8851: Fix deadlock with the SPI chip variant") the deadlock can also be triggered without received packet in the RX FIFO. The pending softirqs will be processed on return from spin_unlock_bh(&ks->statelock) in ks8851_irq(), which triggers the deadlock as well. Fix the problem by disabling BH around critical sections, including the IRQ handler, thus preventing the net_tx_action() softirq from triggering during these critical sections. The net_tx_action() softirq is triggered once BH are re-enabled and at the end of the IRQ handler, once all the other IRQ handler actions have been completed. __schedule from schedule_rtlock+0x1c/0x34 schedule_rtlock from rtlock_slowlock_locked+0x548/0x904 rtlock_slowlock_locked from rt_spin_lock+0x60/0x9c rt_spin_lock from ks8851_start_xmit_par+0x74/0x1a8 ks8851_start_xmit_par from netdev_start_xmit+0x20/0x44 netdev_start_xmit from dev_hard_start_xmit+0xd0/0x188 dev_hard_start_xmit from sch_direct_xmit+0xb8/0x25c sch_direct_xmit from __qdisc_run+0x1f8/0x4ec __qdisc_run from qdisc_run+0x1c/0x28 qdisc_run from net_tx_action+0x1f0/0x268 net_tx_action from handle_softirqs+0x1a4/0x270 handle_softirqs from __local_bh_enable_ip+0xcc/0xe0 __local_bh_enable_ip from __alloc_skb+0xd8/0x128 __alloc_skb from __netdev_alloc_skb+0x3c/0x19c __netdev_alloc_skb from ks8851_irq+0x388/0x4d4 ks8851_irq from irq_thread_fn+0x24/0x64 irq_thread_fn from irq_thread+0x178/0x28c irq_thread from kthread+0x12c/0x138 kthread from ret_from_fork+0x14/0x28 Reviewed-by: Sebastian Andrzej Siewior <[email protected]> Fixes: e0863634bf9f ("net: ks8851: Queue RX packets in IRQ handler instead of disabling BHs") Cc: [email protected] Signed-off-by: Marek Vasut <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yuan Zhaoming <[email protected]> Date: Fri Apr 17 22:13:40 2026 +0800 net: mctp: fix don't require received header reserved bits to be zero commit a663bac71a2f0b3ac6c373168ca57b2a6e6381aa upstream. From the MCTP Base specification (DSP0236 v1.2.1), the first byte of the MCTP header contains a 4 bit reserved field, and 4 bit version. On our current receive path, we require those 4 reserved bits to be zero, but the 9500-8i card is non-conformant, and may set these reserved bits. DSP0236 states that the reserved bits must be written as zero, and ignored when read. While the device might not conform to the former, we should accept these message to conform to the latter. Relax our check on the MCTP version byte to allow non-zero bits in the reserved field. Fixes: 889b7da23abf ("mctp: Add initial routing framework") Signed-off-by: Yuan Zhaoming <[email protected]> Cc: [email protected] Acked-by: Jeremy Kerr <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Manivannan Sadhasivam <[email protected]> Date: Thu Apr 9 23:04:16 2026 +0530 net: qrtr: ns: Fix use-after-free in driver remove() commit 7809fea20c9404bfcfa6112ec08d1fe1d3520beb upstream. In the remove callback, if a packet arrives after destroy_workqueue() is called, but before sock_release(), the qrtr_ns_data_ready() callback will try to queue the work, causing use-after-free issue. Fix this issue by saving the default 'sk_data_ready' callback during qrtr_ns_init() and use it to replace the qrtr_ns_data_ready() callback at the start of remove(). This ensures that even if a packet arrives after destroy_workqueue(), the work struct will not be dereferenced. Note that it is also required to ensure that the RX threads are completed before destroying the workqueue, because the threads could be using the qrtr_ns_data_ready() callback. Cc: [email protected] Fixes: 0c2204a4ad71 ("net: qrtr: Migrate nameservice to kernel from userspace") Signed-off-by: Manivannan Sadhasivam <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Manivannan Sadhasivam <[email protected]> Date: Thu Apr 9 23:04:14 2026 +0530 net: qrtr: ns: Free the node during ctrl_cmd_bye() commit 68efba36446a7774ea5b971257ade049272a07ac upstream. A node sends the BYE packet when it is about to go down. So the nameserver should advertise the removal of the node to all remote and local observers and free the node finally. But currently, the nameserver doesn't free the node memory even after processing the BYE packet. This causes the node memory to leak. Hence, remove the node from Xarray list and free the node memory during both success and failure case of ctrl_cmd_bye(). Cc: [email protected] Fixes: 0c2204a4ad71 ("net: qrtr: Migrate nameservice to kernel from userspace") Signed-off-by: Manivannan Sadhasivam <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Manivannan Sadhasivam <[email protected]> Date: Thu Apr 9 23:04:13 2026 +0530 net: qrtr: ns: Limit the maximum number of lookups commit 5640227d9a21c6a8be249a10677b832e7f40dc55 upstream. Current code does no bound checking on the number of lookups a client can perform. Though the code restricts the lookups to local clients, there is still a possibility of a malicious local client sending a flood of NEW_LOOKUP messages over the same socket. Fix this issue by limiting the maximum number of lookups to 64 globally. Since the nameserver allows only atmost one local observer, this global lookup count will ensure that the lookups stay within the limit. Note that, limit of 64 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased. Cc: [email protected] Fixes: 0c2204a4ad71 ("net: qrtr: Migrate nameservice to kernel from userspace") Signed-off-by: Manivannan Sadhasivam <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Manivannan Sadhasivam <[email protected]> Date: Thu Apr 9 23:04:12 2026 +0530 net: qrtr: ns: Limit the maximum server registration per node commit d5ee2ff98322337951c56398e79d51815acbf955 upstream. Current code does no bound checking on the number of servers added per node. A malicious client can flood NEW_SERVER messages and exhaust memory. Fix this issue by limiting the maximum number of server registrations to 256 per node. If the NEW_SERVER message is received for an old port, then don't restrict it as it will get replaced. While at it, also rate limit the error messages in the failure path of qrtr_ns_worker(). Note that the limit of 256 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased. Cc: [email protected] Fixes: 0c2204a4ad71 ("net: qrtr: Migrate nameservice to kernel from userspace") Reported-by: Yiming Qian <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Manivannan Sadhasivam <[email protected]> Date: Thu Apr 9 23:04:15 2026 +0530 net: qrtr: ns: Limit the total number of nodes commit 27d5e84e810b0849d08b9aec68e48570461ce313 upstream. Currently, the nameserver doesn't limit the number of nodes it handles. This can be an attack vector if a malicious client starts registering random nodes, leading to memory exhaustion. Hence, limit the maximum number of nodes to 64. Note that, limit of 64 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased. Cc: [email protected] Fixes: 0c2204a4ad71 ("net: qrtr: Migrate nameservice to kernel from userspace") Signed-off-by: Manivannan Sadhasivam <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ao Zhou <[email protected]> Date: Wed Apr 22 22:52:07 2026 +0800 net: rds: fix MR cleanup on copy error commit 8141a2dc70080eda1aedc0389ed2db2b292af5bd upstream. __rds_rdma_map() hands sg/pages ownership to the transport after get_mr() succeeds. If copying the generated cookie back to user space fails after that point, the error path must not free those resources again before dropping the MR reference. Remove the duplicate unpin/free from the put_user() failure branch so that MR teardown is handled only through the existing final cleanup path. Fixes: 0d4597c8c5ab ("net/rds: Track user mapped pages through special API") Cc: [email protected] Reported-by: Yuan Tan <[email protected]> Reported-by: Yifan Wu <[email protected]> Reported-by: Juefei Pu <[email protected]> Reported-by: Xin Liu <[email protected]> Signed-off-by: Ao Zhou <[email protected]> Signed-off-by: Ren Wei <[email protected]> Reviewed-by: Allison Henderson <[email protected]> Link: https://patch.msgid.link/79c8ef73ec8e5844d71038983940cc2943099baf.1776764247.git.draw51280@163.com Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Luxiao Xu <[email protected]> Date: Sat Apr 11 23:10:10 2026 +0800 net: strparser: fix skb_head leak in strp_abort_strp() commit fe72340daaf1af588be88056faf98965f39e6032 upstream. When the stream parser is aborted, for example after a message assembly timeout, it can still hold a reference to a partially assembled message in strp->skb_head. That skb is not released in strp_abort_strp(), which leaks the partially assembled message and can be triggered repeatedly to exhaust memory. Fix this by freeing strp->skb_head and resetting the parser state in the abort path. Leave strp_stop() unchanged so final cleanup still happens in strp_done() after the work and timer have been synchronized. Fixes: 43a0c6751a32 ("strparser: Stream parser for messages") Cc: [email protected] Reported-by: Yifan Wu <[email protected]> Reported-by: Juefei Pu <[email protected]> Co-developed-by: Yuan Tan <[email protected]> Signed-off-by: Yuan Tan <[email protected]> Suggested-by: Xin Liu <[email protected]> Tested-by: Yuan Tan <[email protected]> Signed-off-by: Luxiao Xu <[email protected]> Signed-off-by: Ren Wei <[email protected]> Link: https://patch.msgid.link/ade3857a9404999ce9a1c27ec523efc896072678.1775482694.git.rakukuip@gmail.com Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jiawen Wu <[email protected]> Date: Wed Apr 22 15:18:37 2026 +0800 net: txgbe: fix firmware version check commit c263f644add3d6ad81f9d62a99284fde408f0caa upstream. For the device SP, the firmware version is a 32-bit value where the lower 20 bits represent the base version number. And the customized firmware version populates the upper 12 bits with a specific identification number. For other devices AML 25G and 40G, the upper 12 bits of the firmware version is always non-zero, and they have other naming conventions. Only SP devices need to check this to tell if XPCS will work properly. So the judgement of MAC type is added here. And the original logic compared the entire 32-bit value against 0x20010, which caused the outdated base firmwares bypass the version check without a warning. Apply a mask 0xfffff to isolate the lower 20 bits for an accurate base version comparison. Fixes: ab928c24e6cd ("net: txgbe: add FW version warning") Cc: [email protected] Signed-off-by: Jiawen Wu <[email protected]> Reviewed-by: Jacob Keller <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jiawen Wu <[email protected]> Date: Tue Apr 7 17:40:41 2026 +0800 net: txgbe: fix RTNL assertion warning when remove module commit e159f05e12cc1111a3103b99375ddf0dfd0e7d63 upstream. For the copper NIC with external PHY, the driver called phylink_connect_phy() during probe and phylink_disconnect_phy() during remove. It caused an RTNL assertion warning in phylink_disconnect_phy() upon module remove. To fix this, add rtnl_lock() and rtnl_unlock() around the phylink_disconnect_phy() in remove function. ------------[ cut here ]------------ RTNL: assertion failed at drivers/net/phy/phylink.c (2351) WARNING: drivers/net/phy/phylink.c:2351 at phylink_disconnect_phy+0xd8/0xf0 [phylink], CPU#0: rmmod/4464 Modules linked in: ... CPU: 0 UID: 0 PID: 4464 Comm: rmmod Kdump: loaded Not tainted 7.0.0-rc4+ Hardware name: Micro-Star International Co., Ltd. MS-7E16/X670E GAMING PLUS WIFI (MS-7E16), BIOS 1.90 12/31/2024 RIP: 0010:phylink_disconnect_phy+0xe4/0xf0 [phylink] Code: 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 f6 31 ff e9 3a 38 8f e7 48 8d 3d 48 87 e2 ff ba 2f 09 00 00 48 c7 c6 c1 22 24 c0 <67> 48 0f b9 3a e9 34 ff ff ff 66 90 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffce7288363ac0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff89654b2a1a00 RCX: 0000000000000000 RDX: 000000000000092f RSI: ffffffffc02422c1 RDI: ffffffffc0239020 RBP: ffffce7288363ae8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8964c4022000 R13: ffff89654fce3028 R14: ffff89654ebb4000 R15: ffffffffc0226348 FS: 0000795e80d93780(0000) GS:ffff896c52857000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005b528b592000 CR3: 0000000170d0f000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: <TASK> txgbe_remove_phy+0xbb/0xd0 [txgbe] txgbe_remove+0x4c/0xb0 [txgbe] pci_device_remove+0x41/0xb0 device_remove+0x43/0x80 device_release_driver_internal+0x206/0x270 driver_detach+0x4a/0xa0 bus_remove_driver+0x83/0x120 driver_unregister+0x2f/0x60 pci_unregister_driver+0x40/0x90 txgbe_driver_exit+0x10/0x850 [txgbe] __do_sys_delete_module.isra.0+0x1c3/0x2f0 __x64_sys_delete_module+0x12/0x20 x64_sys_call+0x20c3/0x2390 do_syscall_64+0x11c/0x1500 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_syscall_64+0x15a/0x1500 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_fault+0x312/0x580 ? srso_alias_return_thunk+0x5/0xfbef5 ? __handle_mm_fault+0x9d5/0x1040 ? srso_alias_return_thunk+0x5/0xfbef5 ? count_memcg_events+0x101/0x1d0 ? srso_alias_return_thunk+0x5/0xfbef5 ? handle_mm_fault+0x1e8/0x2f0 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_user_addr_fault+0x2f8/0x820 ? srso_alias_return_thunk+0x5/0xfbef5 ? irqentry_exit+0xb2/0x600 ? srso_alias_return_thunk+0x5/0xfbef5 ? exc_page_fault+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: 02b2a6f91b90 ("net: txgbe: support copper NIC with external PHY") Cc: [email protected] Signed-off-by: Jiawen Wu <[email protected]> Reviewed-by: Russell King (Oracle) <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Breno Leitao <[email protected]> Date: Mon Apr 20 03:18:36 2026 -0700 netconsole: avoid out-of-bounds access on empty string in trim_newline() commit 7079c8c13f2d33992bc846240517d88f4ab07781 upstream. trim_newline() unconditionally dereferences s[len - 1] after computing len = strnlen(s, maxlen). When the string is empty, len is 0 and the expression underflows to s[(size_t)-1], reading (and potentially writing) one byte before the buffer. The two callers feed trim_newline() with the result of strscpy() from configfs store callbacks (dev_name_store, userdatum_value_store). configfs guarantees count >= 1 reaches the callback, but the byte itself can be NUL: a userspace write(fd, "\0", 1) leaves the destination empty after strscpy() and triggers the underflow. The OOB write only fires if the adjacent byte happens to be '\n', so this is not a security issue, but the access is undefined behaviour either way. This pattern is commonly flagged by LLM-based code reviewers. While it is not a security fix, the underlying access is undefined behaviour and the change is small and self-contained, so it is a reasonable candidate for the stable trees. Guard the dereference on a non-zero length. Fixes: ae001dc67907 ("net: netconsole: move newline trimming to function") Cc: [email protected] Signed-off-by: Breno Leitao <[email protected]> Reviewed-by: Gustavo Luiz Duarte <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kai Ma <[email protected]> Date: Wed Apr 22 22:54:18 2026 +0800 netfilter: reject zero shift in nft_bitwise commit fe11e5c40817b84abaa5d83bfb6586d8412bfd07 upstream. Reject zero shift operands for nft_bitwise left and right shift expressions during initialization. The carry propagation logic computes the carry from the adjacent 32-bit word using BITS_PER_TYPE(u32) - shift. A zero shift operand turns this into a 32-bit shift, which is undefined behaviour. Reject zero shift operands in the control plane, alongside the existing check for values greater than or equal to 32, so malformed rules never reach the packet path. Fixes: 567d746b55bc ("netfilter: bitwise: add support for shifts.") Cc: [email protected] Reported-by: Yuan Tan <[email protected]> Reported-by: Yifan Wu <[email protected]> Reported-by: Juefei Pu <[email protected]> Reported-by: Xin Liu <[email protected]> Signed-off-by: Kai Ma <[email protected]> Signed-off-by: Ren Wei <[email protected]> Reviewed-by: Fernando Fernandez Mancera <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tushar Sariya <[email protected]> Date: Sat Apr 4 11:58:03 2026 -0230 NFSv4.1: Apply session size limits on clone path commit 8c787b286f39c7584440b97b92f87cbe934c13ff upstream. nfs4_clone_server() builds a child nfs_server for same-server automounted submounts but never calls nfs4_session_limit_rwsize() or nfs4_session_limit_xasize() after nfs_clone_server(). This means the child mount can end up with rsize/wsize values that exceed the negotiated session channel limits, causing NFS4ERR_REQ_TOO_BIG and EIO on servers that enforce tight max_request_size budgets. Top-level mounts go through nfs4_server_common_setup() which calls these limiters after nfs_probe_server(). Apply the same clamping on the clone path for consistency. Fixes: 2b092175f5e3 ("NFS: Fix inheritance of the block sizes when automounting") Cc: [email protected] Signed-off-by: Tushar Sariya <[email protected]> Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tobias Gaertner <[email protected]> Date: Sun Mar 29 04:17:02 2026 -0700 ntfs3: add buffer boundary checks to run_unpack() commit b62567bca47408e6739dee75f02a2113548af875 upstream. run_unpack() checks `run_buf < run_last` at the top of the while loop but then reads size_size and offset_size bytes via run_unpack_s64() without verifying they fit within the remaining buffer. A crafted NTFS image with truncated run data in an MFT attribute triggers an OOB heap read of up to 15 bytes when the filesystem is mounted. Add boundary checks before each run_unpack_s64() call to ensure the declared field size does not exceed the remaining buffer. Found by fuzzing with a source-patched harness (LibAFL + QEMU). Fixes: 82cae269cfa95 ("fs/ntfs3: Add initialization of super block") Cc: [email protected] Signed-off-by: Tobias Gaertner <[email protected]> Signed-off-by: Konstantin Komarov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tobias Gaertner <[email protected]> Date: Sun Mar 29 04:17:03 2026 -0700 ntfs3: fix integer overflow in run_unpack() volume boundary check commit 984a415f019536ea2d24de9010744e5302a9a948 upstream. The volume boundary check `lcn + len > sbi->used.bitmap.nbits` uses raw addition which can wrap around for large lcn and len values, bypassing the validation. Use check_add_overflow() as is already done for the adjacent prev_lcn + dlcn and vcn64 + len checks added by commit 3ac37e100385 ("ntfs3: Fix integer overflow in run_unpack()"). Found by fuzzing with a source-patched harness (LibAFL + QEMU). Fixes: 82cae269cfa95 ("fs/ntfs3: Add initialization of super block") Cc: [email protected] Signed-off-by: Tobias Gaertner <[email protected]> Signed-off-by: Konstantin Komarov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Robert Beckett <[email protected]> Date: Fri Mar 20 19:22:09 2026 +0000 nvme-pci: add NVME_QUIRK_DISABLE_WRITE_ZEROES for Kingston OM3SGP4 commit a8eebf9699d69987cc49cec4e4fdb4111ab32423 upstream. The Kingston OM3SGP42048K2-A00 (PCI ID 2646:502f) firmware has a race condition when processing concurrent write zeroes and DSM (discard) commands, causing spurious "LBA Out of Range" errors and IOMMU page faults at address 0x0. The issue is reliably triggered by running two concurrent mkfs commands on different partitions of the same drive, which generates interleaved write zeroes and discard operations. Disable write zeroes for this device, matching the pattern used for other Kingston OM* drives that have similar firmware issues. Cc: [email protected] Signed-off-by: Robert Beckett <[email protected]> Assisted-by: claude-opus-4-6-v1 Signed-off-by: Keith Busch <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Robert Beckett <[email protected]> Date: Fri Mar 20 19:22:08 2026 +0000 nvme: respect NVME_QUIRK_DISABLE_WRITE_ZEROES when wzsl is set commit 40f0496b617b431f8d2dd94d7f785c1121f8a68a upstream. The NVM Command Set Identify Controller data may report a non-zero Write Zeroes Size Limit (wzsl). When present, nvme_init_non_mdts_limits() unconditionally overrides max_zeroes_sectors from wzsl, even if NVME_QUIRK_DISABLE_WRITE_ZEROES previously set it to zero. This effectively re-enables write zeroes for devices that need it disabled, defeating the quirk. Several Kingston OM* drives rely on this quirk to avoid firmware issues with write zeroes commands. Check for the quirk before applying the wzsl override. Fixes: 5befc7c26e5a ("nvme: implement non-mdts command limits") Cc: [email protected] Signed-off-by: Robert Beckett <[email protected]> Assisted-by: claude-opus-4-6-v1 Signed-off-by: Keith Busch <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Heming Zhao <[email protected]> Date: Thu Apr 2 21:43:27 2026 +0800 ocfs2: split transactions in dio completion to avoid credit exhaustion 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/[email protected] Signed-off-by: Heming Zhao <[email protected]> Suggested-by: Jan Kara <[email protected]> Suggested-by: Joseph Qi <[email protected]> Reviewed-by: Jan Kara <[email protected]> Reviewed-by: Joseph Qi <[email protected]> Cc: Mark Fasheh <[email protected]> Cc: Joel Becker <[email protected]> Cc: Junxiao Bi <[email protected]> Cc: Changwei Ge <[email protected]> Cc: Jun Piao <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Wentao Liang <[email protected]> Date: Thu Apr 9 02:22:33 2026 +0000 of: unittest: fix use-after-free in of_unittest_changeset() commit faecdd423c27f0d6090156a435ba9dbbac0eaddb upstream. The variable 'parent' is assigned the value of 'nchangeset' earlier in the function, meaning both point to the same struct device_node. The call to of_node_put(nchangeset) can decrement the reference count to zero and free the node if there are no other holders. After that, the code still uses 'parent' to check for the presence of a property and to read a string property, leading to a use-after-free. Fix this by moving the of_node_put() call after the last access to 'parent', avoiding the UAF. Fixes: 1c668ea65506 ("of: unittest: Use of_property_present()") Cc: [email protected] Signed-off-by: Wentao Liang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Rob Herring (Arm) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Wentao Liang <[email protected]> Date: Thu Apr 9 03:48:59 2026 +0000 of: unittest: fix use-after-free in testdrv_probe() 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: 26409dd04589 ("of: unittest: Add pci_dt_testdrv pci driver") Cc: [email protected] Signed-off-by: Wentao Liang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Rob Herring (Arm) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Helge Deller <[email protected]> Date: Tue Apr 7 23:56:28 2026 +0200 parisc: _llseek syscall is only available for 32-bit userspace commit da3680f564bd787ce974f9931e6e924d908b3b2a upstream. Cc: [email protected] Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Helge Deller <[email protected]> Date: Fri Apr 10 16:12:31 2026 +0200 parisc: Drop ip_fast_csum() inline assembly implementation commit 3dd31a370c1dccb580f729af7c580ccb1ae3c0c9 upstream. The assembly code of ip_fast_csum() triggers unaligned access warnings if the IP header isn't correctly aligned: Kernel: unaligned access to 0x173d22e76 in inet_gro_receive+0xbc/0x2e8 (iir 0x0e8810b6) Kernel: unaligned access to 0x173d22e7e in inet_gro_receive+0xc4/0x2e8 (iir 0x0e88109a) Kernel: unaligned access to 0x173d22e82 in inet_gro_receive+0xc8/0x2e8 (iir 0x0e90109d) Kernel: unaligned access to 0x173d22e7a in inet_gro_receive+0xd0/0x2e8 (iir 0x0e9810b8) Kernel: unaligned access to 0x173d22e86 in inet_gro_receive+0xdc/0x2e8 (iir 0x0e8810b8) We have the option to a) ignore the warnings, b) work around it by adding more code to check for alignment, or c) to switch to the generic implementation and rely on the compiler to optimize the code. Let's go with c), because a) isn't nice, and b) would effectively lead to an implementation which is basically equal to c). Signed-off-by: Helge Deller <[email protected]> Cc: [email protected] # v7.0+ Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Aksh Garg <[email protected]> Date: Thu Apr 2 14:25:45 2026 +0530 PCI: cadence: Use cdns_pcie_read_sz() for byte or word read access commit d9cf7154deed71a4f23e81101571c79cdc77be00 upstream. The commit 18ac51ae9df9 ("PCI: cadence: Implement capability search using PCI core APIs") assumed all the platforms using Cadence PCIe controller support byte and word register accesses. This is not true for all platforms (e.g., TI J721E SoC, which only supports dword register accesses). This causes capability searches via cdns_pcie_find_capability() to fail on such platforms. Fix this by using cdns_pcie_read_sz() for config read functions, which properly handles size-aligned accesses. Remove the now-unused byte and word read wrapper functions (cdns_pcie_readw and cdns_pcie_readb). Fixes: 18ac51ae9df9 ("PCI: cadence: Implement capability search using PCI core APIs") Signed-off-by: Aksh Garg <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Koichiro Den <[email protected]> Date: Thu Feb 26 17:41:39 2026 +0900 PCI: endpoint: pci-epf-ntb: Remove duplicate resource teardown commit 3446beddba450c8d6f9aca2f028712ac527fead3 upstream. epf_ntb_epc_destroy() duplicates the teardown that the caller is supposed to do later. This leads to an oops when .allow_link fails or when .drop_link is performed. Remove the helper. Also drop pci_epc_put(). EPC device refcounting is tied to configfs EPC group lifetime, and pci_epc_put() in the .drop_link path is sufficient. Fixes: 8b821cf76150 ("PCI: endpoint: Add EP function driver to provide NTB functionality") Signed-off-by: Koichiro Den <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Frank Li <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Daniel Hodges <[email protected]> Date: Fri Feb 6 15:05:29 2026 -0500 PCI: epf-mhi: Return 0, not remaining timeout, when eDMA ops complete commit 36bfc3642b19a98f1302aed4437c331df9b481f0 upstream. pci_epf_mhi_edma_read() and pci_epf_mhi_edma_write() start DMA operations and wait for completion with a timeout. On successful completion, they previously returned the remaining timeout, which callers may treat as an error. In particular, mhi_ep_ring_add_element(), which calls pci_epf_mhi_edma_write() via mhi_cntrl->write_sync(), interprets any non-zero return value as failure. Return 0 on success instead of the remaining timeout to prevent mhi_ep_ring_add_element() from treating successful completion as an error. Fixes: 7b99aaaddabb ("PCI: epf-mhi: Add eDMA support") Signed-off-by: Daniel Hodges <[email protected]> [mani: changed commit log as per https://lore.kernel.org/linux-pci/20260227191510.GA3904799@bhelgaas] Signed-off-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Krishna Chaitanya Chundru <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Franz Schnyder <[email protected]> Date: Wed Mar 25 10:31:16 2026 +0100 PCI: imx6: Fix reference clock source selection for i.MX95 commit 88cc4cbe08bba27bb58888d25d336774aa0ccab1 upstream. In the PCIe PHY init for the i.MX95, the reference clock source selection uses a conditional instead of always passing the mask. This currently breaks functionality if the internal refclk is used. To fix this issue, always pass IMX95_PCIE_REF_USE_PAD as the mask and clear bit if external refclk is not used. This essentially swaps the parameters. Fixes: d8574ce57d76 ("PCI: imx6: Add external reference clock input mode support") Signed-off-by: Franz Schnyder <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: Richard Zhu <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Richard Zhu <[email protected]> Date: Sat Feb 28 16:09:25 2026 +0800 PCI: imx6: Skip waiting for L2/L3 Ready on i.MX6SX commit 5f73cf1db829c21b7fd44a8d2587cd395b1b2d76 upstream. On i.MX6SX, the LTSSM registers become inaccessible after the PME_Turn_Off message is sent to the link. So there is no way to verify whether the link has entered L2/L3 Ready state or not. Hence, set IMX_PCIE_FLAG_SKIP_L23_READY flag for i.MX6SX SoC to skip the L2/L3 Ready state polling and let the DWC core wait for 10ms after sending the PME_Turn_Off message as per the PCIe spec r6.0, sec 5.3.3.2.1. Fixes: a528d1a72597 ("PCI: imx6: Use DWC common suspend resume method") Signed-off-by: Richard Zhu <[email protected]> [mani: commit log] Signed-off-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Frank Li <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Rong Bao <[email protected]> Date: Mon Apr 13 18:03:55 2026 +0800 perf annotate: Use jump__delete when freeing LoongArch jumps commit a355eefc36c4481188249b067832b40a2c45fa5c upstream. Currently, the initialization of loongarch_jump_ops does not contain an assignment to its .free field. This causes disasm_line__free() to fall through to ins_ops__delete() for LoongArch jump instructions. ins_ops__delete() will free ins_operands.source.raw and ins_operands.source.name, and these fields overlaps with ins_operands.jump.raw_comment and ins_operands.jump.raw_func_start. Since in loongarch_jump__parse(), these two fields are populated by strchr()-ing the same buffer, trying to free them will lead to undefined behavior. This invalid free usually leads to crashes: Process 1712902 (perf) of user 1000 dumped core. Stack trace of thread 1712902: #0 0x00007fffef155c58 n/a (libc.so.6 + 0x95c58) #1 0x00007fffef0f7a94 raise (libc.so.6 + 0x37a94) #2 0x00007fffef0dd6a8 abort (libc.so.6 + 0x1d6a8) #3 0x00007fffef145490 n/a (libc.so.6 + 0x85490) #4 0x00007fffef1646f4 n/a (libc.so.6 + 0xa46f4) #5 0x00007fffef164718 n/a (libc.so.6 + 0xa4718) #6 0x00005555583a6764 __zfree (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x106764) #7 0x000055555854fb70 disasm_line__free (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x2afb70) #8 0x000055555853d618 annotated_source__purge (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x29d618) #9 0x000055555852300c __hist_entry__tui_annotate (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x28300c) #10 0x0000555558526718 do_annotate (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x286718) #11 0x000055555852ed94 evsel__hists_browse (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x28ed94) #12 0x000055555831fdd0 cmd_report (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x7fdd0) #13 0x000055555839b644 handle_internal_command (/home/csmantle/dist/linux-arch/tools/perf/perf + 0xfb644) #14 0x00005555582fe6ac main (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x5e6ac) #15 0x00007fffef0ddd90 n/a (libc.so.6 + 0x1dd90) #16 0x00007fffef0ddf0c __libc_start_main (libc.so.6 + 0x1df0c) #17 0x00005555582fed10 _start (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x5ed10) ELF object binary architecture: LoongArch ... and it can be confirmed with Valgrind: ==1721834== Invalid free() / delete / delete[] / realloc() ==1721834== at 0x4EA9014: free (in /usr/lib/valgrind/vgpreload_memcheck-loongarch64-linux.so) ==1721834== by 0x4106287: __zfree (zalloc.c:13) ==1721834== by 0x42ADC8F: disasm_line__free (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x429B737: annotated_source__purge (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x42811EB: __hist_entry__tui_annotate (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x42848D7: do_annotate (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x428CF33: evsel__hists_browse (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== Address 0x7d34303 is 35 bytes inside a block of size 62 alloc'd ==1721834== at 0x4EA59B8: malloc (in /usr/lib/valgrind/vgpreload_memcheck-loongarch64-linux.so) ==1721834== by 0x6B80B6F: strdup (strdup.c:42) ==1721834== by 0x42AD917: disasm_line__new (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x42AE5A3: symbol__disassemble_objdump (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x42AF0A7: symbol__disassemble (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x429B3CF: symbol__annotate (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x429C233: symbol__annotate2 (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x42804D3: __hist_entry__tui_annotate (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x42848D7: do_annotate (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x428CF33: evsel__hists_browse (in /home/csmantle/dist/linux-arch/tools/perf/perf) This patch adds the missing free() specialization in loongarch_jump_ops, which prevents disasm_line__free() from invoking the default cleanup function. Fixes: fb7fd2a14a503b9a ("perf annotate: Move raw_comment and raw_func_start fields out of 'struct ins_operands'") Cc: [email protected] Cc: WANG Rui <[email protected]> Cc: Huacai Chen <[email protected]> Cc: WANG Xuerui <[email protected]> Cc: [email protected] Signed-off-by: Rong Bao <[email protected]> Tested-by: WANG Rui <[email protected]> Signed-off-by: Namhyung Kim <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: WANG Rui <[email protected]> Date: Tue Apr 14 08:51:52 2026 +0800 perf loongarch: Fix build failure with CONFIG_LIBDW_DWARF_UNWIND commit 841dbf4871c57ce2da18c4ea7ffac5487d0eda16 upstream. Building perf for LoongArch fails when CONFIG_LIBDW_DWARF_UNWIND is enabled because unwind-libdw.o is still referenced in arch/loongarch/util/Build. Fixes: e62fae9d9e8 ("perf unwind-libdw: Fix a cross-arch unwinding bug") Signed-off-by: WANG Rui <[email protected]> Acked-by: Huacai Chen <[email protected]> Signed-off-by: Namhyung Kim <[email protected]> Cc: Ben Hutchings <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Elson Serrao <[email protected]> Date: Tue Feb 17 12:11:30 2026 -0800 phy: qcom: m31-eusb2: clear PLL_EN during init commit 520a98bdf7ae0130e22d8adced3d69a2e211b41f upstream. The driver currently sets bit 0 of USB_PHY_CFG1 (PLL_EN) during PHY initialization. According to the M31 EUSB2 PHY hardware documentation, this bit is intended only for test/debug scenarios and does not control mission mode operation. Keeping PLL_EN asserted causes the PHY to draw additional current during USB bus suspend. Clearing this bit results in lower suspend power consumption without affecting normal operation. Update the driver to leave PLL_EN cleared as recommended by the hardware documentation. Fixes: 9c8504861cc4 ("phy: qcom: Add M31 based eUSB2 PHY driver") Cc: [email protected] Signed-off-by: Elson Serrao <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Fri Feb 20 18:49:39 2026 +0100 power: supply: axp288_charger: Do not cancel work before initializing it commit 658342fd75b582cbb06544d513171c3d645faead upstream. Driver registered devm handler to cancel_work_sync() before even the work was initialized, thus leading to possible warning from kernel/workqueue.c on (!work->func) check, if the error path was hit before the initialization happened. Use devm_work_autocancel() on each work item independently, which handles the initialization and handler to cancel work. Fixes: 165c2357744e ("power: supply: axp288_charger: Properly stop work on probe-error / remove") Cc: [email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Reviewed-by: Chen-Yu Tsai <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Petr Mladek <[email protected]> Date: Tue Apr 14 17:41:24 2026 +0200 printf: Compile the kunit test with DISABLE_BRANCH_PROFILING DISABLE_BRANCH_PROFILING commit 8901ac9d2c7eb8ed7ae5e749bf13ecb3b6062488 upstream. GCC < 12.1 can miscompile printf_kunit's errptr() test when branch profiling is enabled. BUILD_BUG_ON(IS_ERR(PTR)) is a constant false expression, but CONFIG_TRACE_BRANCH_PROFILING and CONFIG_PROFILE_ALL_BRANCHES make the IS_ERR() path side-effectful. GCC's IPA splitter can then outline the cold assert arm into errptr.part.* and leave that clone with an unconditional __compiletime_assert_*() call, causing a false build failure. This started showing up after test_hashed() became a macro and moved its local buffer into errptr(), which changed GCC's inlining and splitting decisions enough to expose the compiler bug. Workaround the problem by disabling the branch profiling for printf_kunit.o. It is a straightforward and acceptable solution. The workaround can be removed once the minimum GCC includes commit 76fe49423047 ("Fix tree-optimization/101941: IPA splitting out function with error attribute"), which first shipped in GCC 12.1. Fixes: 9bfa52dac27a ("printf: convert test_hashed into macro") Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Cc: [email protected] Acked-by: Tamir Duberstein <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Petr Mladek <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Viorel Suman (OSS) <[email protected]> Date: Wed Mar 11 14:33:09 2026 +0200 pwm: imx-tpm: Count the number of enabled channels in probe commit 3962c24f2d14e8a7f8a23f56b7ce320523947342 upstream. On a soft reset TPM PWM IP may preserve its internal state from previous runtime, therefore on a subsequent OS boot and driver probe "enable_count" value and TPM PWM IP internal channels "enabled" states may get unaligned. In consequence on a suspend/resume cycle the call "if (--tpm->enable_count == 0)" may lead to "enable_count" overflow the system being blocked from entering suspend due to: if (tpm->enable_count > 0) return -EBUSY; Fix the problem by counting the enabled channels in probe function. Signed-off-by: Viorel Suman (OSS) <[email protected]> Fixes: 738a1cfec2ed ("pwm: Add i.MX TPM PWM driver support") Link: https://patch.msgid.link/[email protected] Cc: [email protected] Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ryan Roberts <[email protected]> Date: Tue Mar 3 15:08:38 2026 +0000 randomize_kstack: Maintain kstack_offset per task commit 37beb42560165869838e7d91724f3e629db64129 upstream. kstack_offset was previously maintained per-cpu, but this caused a couple of issues. So let's instead make it per-task. Issue 1: add_random_kstack_offset() and choose_random_kstack_offset() expected and required to be called with interrupts and preemption disabled so that it could manipulate per-cpu state. But arm64, loongarch and risc-v are calling them with interrupts and preemption enabled. I don't _think_ this causes any functional issues, but it's certainly unexpected and could lead to manipulating the wrong cpu's state, which could cause a minor performance degradation due to bouncing the cache lines. By maintaining the state per-task those functions can safely be called in preemptible context. Issue 2: add_random_kstack_offset() is called before executing the syscall and expands the stack using a previously chosen random offset. choose_random_kstack_offset() is called after executing the syscall and chooses and stores a new random offset for the next syscall. With per-cpu storage for this offset, an attacker could force cpu migration during the execution of the syscall and prevent the offset from being updated for the original cpu such that it is predictable for the next syscall on that cpu. By maintaining the state per-task, this problem goes away because the per-task random offset is updated after the syscall regardless of which cpu it is executing on. Fixes: 39218ff4c625 ("stack: Optionally randomize kernel stack offset each syscall") Closes: https://lore.kernel.org/all/[email protected]/ Cc: [email protected] Acked-by: Mark Rutland <[email protected]> Signed-off-by: Ryan Roberts <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dawei Feng <[email protected]> Date: Sun Apr 19 17:03:48 2026 +0800 rbd: fix null-ptr-deref when device_add_disk() fails commit d1fef92e414433ca7b89abf85cb0df42b8d475eb upstream. do_rbd_add() publishes the device with device_add() before calling device_add_disk(). If device_add_disk() fails after device_add() succeeds, the error path calls rbd_free_disk() directly and then later falls through to rbd_dev_device_release(), which calls rbd_free_disk() again. This double teardown can leave blk-mq cleanup operating on invalid state and trigger a null-ptr-deref in __blk_mq_free_map_and_rqs(), reached from blk_mq_free_tag_set(). Fix this by following the normal remove ordering: call device_del() before rbd_dev_device_release() when device_add_disk() fails after device_add(). That keeps the teardown sequence consistent and avoids re-entering disk cleanup through the wrong path. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. We reproduced the bug on v7.0 with a real Ceph backend and a QEMU x86_64 guest booted with KASAN and CONFIG_FAILSLAB enabled. The reproducer confines failslab injections to the __add_disk() range and injects fail-nth while mapping an RBD image through /sys/bus/rbd/add_single_major. On the unpatched kernel, fail-nth=4 reliably triggered the fault: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 UID: 0 PID: 273 Comm: bash Not tainted 7.0.0-01247-gd60bc1401583 #6 PREEMPT(lazy) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 RIP: 0010:__blk_mq_free_map_and_rqs+0x8c/0x240 Code: 00 00 48 8b 6b 60 41 89 f4 49 c1 e4 03 4c 01 e5 45 85 ed 0f 85 0a 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 e9 48 c1 e9 03 <80> 3c 01 00 0f 85 31 01 00 00 4c 8b 6d 00 4d 85 ed 0f 84 e2 00 00 RSP: 0018:ff1100000ab0fac8 EFLAGS: 00000246 RAX: dffffc0000000000 RBX: ff1100000c4806a0 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000000 RDI: ff1100000c4806f4 RBP: 0000000000000000 R08: 0000000000000001 R09: ffe21c000189001b R10: ff1100000c4800df R11: ff1100006cf37be0 R12: 0000000000000000 R13: 0000000000000000 R14: ff1100000c480700 R15: ff1100000c480004 FS: 00007f0fbe8fe740(0000) GS:ff110000e5851000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe53473b2e0 CR3: 0000000012eef000 CR4: 00000000007516f0 PKRU: 55555554 Call Trace: <TASK> blk_mq_free_tag_set+0x77/0x460 do_rbd_add+0x1446/0x2b80 ? __pfx_do_rbd_add+0x10/0x10 ? lock_acquire+0x18c/0x300 ? find_held_lock+0x2b/0x80 ? sysfs_file_kobj+0xb6/0x1b0 ? __pfx_sysfs_kf_write+0x10/0x10 kernfs_fop_write_iter+0x2f4/0x4a0 vfs_write+0x98e/0x1000 ? expand_files+0x51f/0x850 ? __pfx_vfs_write+0x10/0x10 ksys_write+0xf2/0x1d0 ? __pfx_ksys_write+0x10/0x10 do_syscall_64+0x115/0x690 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f0fbea15907 Code: 10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24 RSP: 002b:00007ffe22346ea8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000058 RCX: 00007f0fbea15907 RDX: 0000000000000058 RSI: 0000563ace6c0ef0 RDI: 0000000000000001 RBP: 0000563ace6c0ef0 R08: 0000563ace6c0ef0 R09: 6b6435726d694141 R10: 5250337279762f78 R11: 0000000000000246 R12: 0000000000000058 R13: 00007f0fbeb1c780 R14: ff1100000c480700 R15: ff1100000c480004 </TASK> With this fix applied, rerunning the reproducer over fail-nth=1..256 yields no KASAN reports. [ idryomov: rename err_out_device_del -> err_out_device ] Cc: [email protected] Fixes: 27c97abc30e2 ("rbd: add add_disk() error handling") Signed-off-by: Zilin Guan <[email protected]> Signed-off-by: Dawei Feng <[email protected]> Reviewed-by: Ilya Dryomov <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Long Li <[email protected]> Date: Wed Mar 25 12:40:57 2026 -0700 RDMA/mana_ib: Disable RX steering on RSS QP destroy commit dbeb256e8dd87233d891b170c0b32a6466467036 upstream. When an RSS QP is destroyed (e.g. DPDK exit), mana_ib_destroy_qp_rss() destroys the RX WQ objects but does not disable vPort RX steering in firmware. This leaves stale steering configuration that still points to the destroyed RX objects. If traffic continues to arrive (e.g. peer VM is still transmitting) and the VF interface is subsequently brought up (mana_open), the firmware may deliver completions using stale CQ IDs from the old RX objects. These CQ IDs can be reused by the ethernet driver for new TX CQs, causing RX completions to land on TX CQs: WARNING: mana_poll_tx_cq+0x1b8/0x220 [mana] (is_sq == false) WARNING: mana_gd_process_eq_events+0x209/0x290 (cq_table lookup fails) Fix this by disabling vPort RX steering before destroying RX WQ objects. Note that mana_fence_rqs() cannot be used here because the fence completion is delivered on the CQ, which is polled by user-mode (e.g. DPDK) and not visible to the kernel driver. Refactor the disable logic into a shared mana_disable_vport_rx() in mana_en, exported for use by mana_ib, replacing the duplicate code. The ethernet driver's mana_dealloc_queues() is also updated to call this common function. Fixes: 0266a177631d ("RDMA/mana_ib: Add a driver for Microsoft Azure Network Adapter") Cc: [email protected] Signed-off-by: Long Li <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: hkbinbin <[email protected]> Date: Wed Apr 1 12:19:07 2026 +0000 RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv commit 7244491dab347f648e661da96dc0febadd9daec3 upstream. rxe_rcv() currently checks only that the incoming packet is at least header_size(pkt) bytes long before payload_size() is used. However, payload_size() subtracts both the attacker-controlled BTH pad field and RXE_ICRC_SIZE from pkt->paylen: payload_size = pkt->paylen - offset[RXE_PAYLOAD] - bth_pad(pkt) - RXE_ICRC_SIZE This means a short packet can still make payload_size() underflow even if it includes enough bytes for the fixed headers. Simply requiring header_size(pkt) + RXE_ICRC_SIZE is not sufficient either, because a packet with a forged non-zero BTH pad can still leave payload_size() negative and pass an underflowed value to later receive-path users. Fix this by validating pkt->paylen against the full minimum length required by payload_size(): header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE. Cc: [email protected] Fixes: 8700e3e7c485 ("Soft RoCE driver") Link: https://patch.msgid.link/r/[email protected] Signed-off-by: hkbinbin <[email protected]> Reviewed-by: Zhu Yanjun <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ben Levinsky <[email protected]> Date: Tue Mar 3 15:51:27 2026 -0800 remoteproc: xlnx: Only access buffer information if IPI is buffered commit 38dd6ccfdfbbe865569a52fe1ba9fa1478f672e6 upstream. In the receive callback check if message is NULL to prevent possibility of crash by NULL pointer dereferencing. Signed-off-by: Ben Levinsky <[email protected]> Signed-off-by: Tanmay Shah <[email protected]> Fixes: 5dfb28c257b7 ("remoteproc: xilinx: Add mailbox channels for rpmsg") Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mathieu Poirier <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tommaso Merciai <[email protected]> Date: Thu Mar 12 15:50:38 2026 +0100 reset: rzv2h-usb2phy: Keep PHY clock enabled for entire device lifetime commit 8889b289ce1bd11a5102b9617742a1b93bb4843e upstream. The driver was disabling the USB2 PHY clock immediately after register initialization in probe() and after each reset operation. This left the PHY unclocked even though it must remain active for USB functionality. The behavior appeared to work only when another driver (e.g., USB controller) had already enabled the clock, making operation unreliable and hardware-dependent. In configurations where this driver is the sole clock user, USB functionality would fail. Fix this by: - Enabling the clock once in probe() via pm_runtime_resume_and_get() - Removing all pm_runtime_put() calls from assert/deassert/status - Registering a devm cleanup action to release the clock at removal - Removed rzv2h_usbphy_assert_helper() and its call in rzv2h_usb2phy_reset_probe() This ensures the PHY clock remains enabled for the entire device lifetime, preventing instability and aligning with hardware requirements. Cc: [email protected] Fixes: e3911d7f865b ("reset: Add USB2PHY port reset driver for Renesas RZ/V2H(P)") Signed-off-by: Tommaso Merciai <[email protected]> Reviewed-by: Philipp Zabel <[email protected]> Signed-off-by: Philipp Zabel <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Rong Zhang <[email protected]> Date: Wed Mar 4 03:47:56 2026 +0800 Revert "ALSA: usb: Increase volume range that triggers a warning" commit 41d78cb724f4b40b7548af420ccfe524b14023bb upstream. UAC uses 2 bytes to store volume values, so the maximum volume range is 0xFFFF (65535, val = -32768/32767/1). The reverted commit bumpped the range of triggering the warning to > 65535, effectively making the range check a no-op. It didn't fix anything but covered any potential problems and deviated from the original intention of the range check. This reverts commit 6b971191fcfc9e3c2c0143eea22534f1f48dbb62. Fixes: 6b971191fcfc ("ALSA: usb: Increase volume range that triggers a warning") Cc: [email protected] Signed-off-by: Rong Zhang <[email protected]> Acked-by: Arun Raghavan <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Masami Hiramatsu (Google) <[email protected]> Date: Fri Apr 24 15:52:10 2026 +0900 ring-buffer: Do not double count the reader_page commit 92d5a606721f759ebebf448b3bd2b7a781d50bd0 upstream. Since the cpu_buffer->reader_page is updated if there are unwound pages. After that update, we should skip the page if it is the original reader_page, because the original reader_page is already checked. Cc: [email protected] Cc: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Cc: Ian Rogers <[email protected]> Link: https://patch.msgid.link/177701353063.2223789.1471163147644103306.stgit@mhiramat.tok.corp.google.com Fixes: ca296d32ece3 ("tracing: ring_buffer: Rewind persistent ring buffer on reboot") Signed-off-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Johan Hovold <[email protected]> Date: Tue Apr 7 14:27:17 2026 +0200 rtc: ntxec: fix OF node reference imbalance 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: 435af89786c6 ("rtc: New driver for RTC in Netronix embedded controller") Cc: [email protected] # 5.13 Cc: Jonathan Neuschäfer <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Alexandre Belloni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Keenan Dong <[email protected]> Date: Wed Apr 8 16:46:00 2026 +0800 rtmutex: Use waiter::task instead of current in remove_waiter() commit 3bfdc63936dd4773109b7b8c280c0f3b5ae7d349 upstream. remove_waiter() is used by the slowlock paths, but it is also used for proxy-lock rollback in rt_mutex_start_proxy_lock() when invoked from futex_requeue(). In the latter case waiter::task is not current, but remove_waiter() operates on current for the dequeue operation. That results in several problems: 1) the rbtree dequeue happens without waiter::task::pi_lock being held 2) the waiter task's pi_blocked_on state is not cleared, which leaves a dangling pointer primed for UAF around. 3) rt_mutex_adjust_prio_chain() operates on the wrong top priority waiter task Use waiter::task instead of current in all related operations in remove_waiter() to cure those problems. [ tglx: Fixup rt_mutex_adjust_prio_chain(), add a comment and amend the changelog ] Fixes: 8161239a8bcc ("rtmutex: Simplify PI algorithm and make highest prio task get lock") Reported-by: Yuan Tan <[email protected]> Reported-by: Yifan Wu <[email protected]> Reported-by: Juefei Pu <[email protected]> Reported-by: Xin Liu <[email protected]> Signed-off-by: Keenan Dong <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Danilo Krummrich <[email protected]> Date: Sat Mar 21 18:27:46 2026 +0100 rust: dma: remove DMA_ATTR_NO_KERNEL_MAPPING from public attrs commit 18fb5f1f0289b8217c0c43d54d12bccc201dd640 upstream. When DMA_ATTR_NO_KERNEL_MAPPING is passed to dma_alloc_attrs(), the returned CPU address is not a pointer to the allocated memory but an opaque handle (e.g. struct page *). Coherent<T> (or CoherentAllocation<T> respectively) stores this value as NonNull<T> and exposes methods that dereference it and even modify its contents. Remove the flag from the public attrs module such that drivers cannot pass it to Coherent<T> (or CoherentAllocation<T> respectively) in the first place. Instead DMA_ATTR_NO_KERNEL_MAPPING can be supported with an additional opaque type (e.g. CoherentHandle) which does not provide access to the allocated memory. Cc: [email protected] Fixes: ad2907b4e308 ("rust: add dma coherent allocator abstraction") Signed-off-by: Danilo Krummrich <[email protected]> Reviewed-by: Alice Ryhl <[email protected]> Reviewed-by: Alexandre Courbot <[email protected]> Reviewed-by: Gary Guo <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Alexandre Courbot <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Howells <[email protected]> Date: Wed Apr 22 17:14:34 2026 +0100 rxgk: Fix potential integer overflow in length check commit 6929350080f4da292d111a3b33e53138fee51cec upstream. Fix potential integer overflow in rxgk_extract_token() when checking the length of the ticket. Rather than rounding up the value to be tested (which might overflow), round down the size of the available data. Fixes: 2429a1976481 ("rxrpc: Fix untrusted unsigned subtract") Closes: https://sashiko.dev/#/patchset/20260408121252.2249051-1-dhowells%40redhat.com Signed-off-by: David Howells <[email protected]> cc: Marc Dionne <[email protected]> cc: Jeffrey Altman <[email protected]> cc: Simon Horman <[email protected]> cc: [email protected] cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Howells <[email protected]> Date: Wed Apr 22 17:14:33 2026 +0100 rxrpc: Fix conn-level packet handling to unshare RESPONSE packets commit 24481a7f573305706054c59e275371f8d0fe919f upstream. The security operations that verify the RESPONSE packets decrypt bits of it in place - however, the sk_buff may be shared with a packet sniffer, which would lead to the sniffer seeing an apparently corrupt packet (actually decrypted). Fix this by handing a copy of the packet off to the specific security handler if the packet was cloned. Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both") Closes: https://sashiko.dev/#/patchset/20260408121252.2249051-1-dhowells%40redhat.com Signed-off-by: David Howells <[email protected]> cc: Marc Dionne <[email protected]> cc: Jeffrey Altman <[email protected]> cc: Simon Horman <[email protected]> cc: [email protected] cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Howells <[email protected]> Date: Thu Apr 23 21:09:08 2026 +0100 rxrpc: Fix error handling in rxgk_extract_token() commit 3476c8bb960f48e49355d6f93fb7673211e0163f upstream. Fix a missing bit of error handling in rxgk_extract_token(): in the event that rxgk_decrypt_skb() returns -ENOMEM, it should just return that rather than continuing on (for anything else, it generates an abort). Fixes: 64863f4ca494 ("rxrpc: Fix unhandled errors in rxgk_verify_packet_integrity()") Closes: https://sashiko.dev/#/patchset/[email protected] Signed-off-by: David Howells <[email protected]> cc: Marc Dionne <[email protected]> cc: Jeffrey Altman <[email protected]> cc: Simon Horman <[email protected]> cc: [email protected] cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Howells <[email protected]> Date: Wed Apr 22 17:14:30 2026 +0100 rxrpc: Fix memory leaks in rxkad_verify_response() commit 34f61a07e0cdefaecd3ec03bb5fb22215643678f upstream. Fix rxkad_verify_response() to free the ticket and the server key under all circumstances by initialising the ticket pointer to NULL and then making all paths through the function after the first allocation has been done go through a single common epilogue that just releases everything - where all the releases skip on a NULL pointer. Fixes: 57af281e5389 ("rxrpc: Tidy up abort generation infrastructure") Fixes: ec832bd06d6f ("rxrpc: Don't retain the server key in the connection") Closes: https://sashiko.dev/#/patchset/20260408121252.2249051-1-dhowells%40redhat.com Signed-off-by: David Howells <[email protected]> cc: Marc Dionne <[email protected]> cc: Jeffrey Altman <[email protected]> cc: Simon Horman <[email protected]> cc: [email protected] cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Howells <[email protected]> Date: Wed Apr 22 17:14:32 2026 +0100 rxrpc: Fix potential UAF after skb_unshare() failure commit 1f2740150f904bfa60e4bad74d65add3ccb5e7f8 upstream. If skb_unshare() fails to unshare a packet due to allocation failure in rxrpc_input_packet(), the skb pointer in the parent (rxrpc_io_thread()) will be NULL'd out. This will likely cause the call to trace_rxrpc_rx_done() to oops. Fix this by moving the unsharing down to where rxrpc_input_call_event() calls rxrpc_input_call_packet(). There are a number of places prior to that where we ignore DATA packets for a variety of reasons (such as the call already being complete) for which an unshare is then avoided. And with that, rxrpc_input_packet() doesn't need to take a pointer to the pointer to the packet, so change that to just a pointer. Fixes: 2d1faf7a0ca3 ("rxrpc: Simplify skbuff accounting in receive path") Closes: https://sashiko.dev/#/patchset/20260408121252.2249051-1-dhowells%40redhat.com Signed-off-by: David Howells <[email protected]> cc: Marc Dionne <[email protected]> cc: Jeffrey Altman <[email protected]> cc: Simon Horman <[email protected]> cc: [email protected] cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Howells <[email protected]> Date: Thu Apr 23 21:09:07 2026 +0100 rxrpc: Fix re-decryption of RESPONSE packets commit 0422e7a4883f25101903f3e8105c0808aa5f4ce9 upstream. If a RESPONSE packet gets a temporary failure during processing, it may end up in a partially decrypted state - and then get requeued for a retry. Fix this by just discarding the packet; we will send another CHALLENGE packet and thereby elicit a further response. Similarly, discard an incoming CHALLENGE packet if we get an error whilst generating a RESPONSE; the server will send another CHALLENGE. Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both") Closes: https://sashiko.dev/#/patchset/[email protected] Signed-off-by: David Howells <[email protected]> cc: Marc Dionne <[email protected]> cc: Jeffrey Altman <[email protected]> cc: Simon Horman <[email protected]> cc: [email protected] cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Howells <[email protected]> Date: Wed Apr 22 17:14:31 2026 +0100 rxrpc: Fix rxkad crypto unalignment handling commit def304aae2edf321d2671fd6ca766a93c21f877e upstream. Fix handling of a packet with a misaligned crypto length. Also handle non-ENOMEM errors from decryption by aborting. Further, remove the WARN_ON_ONCE() so that it can't be remotely triggered (a trace line can still be emitted). Fixes: f93af41b9f5f ("rxrpc: Fix missing error checks for rxkad encryption/decryption failure") Closes: https://sashiko.dev/#/patchset/20260408121252.2249051-1-dhowells%40redhat.com Signed-off-by: David Howells <[email protected]> cc: Marc Dionne <[email protected]> cc: Jeffrey Altman <[email protected]> cc: Simon Horman <[email protected]> cc: [email protected] cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Howells <[email protected]> Date: Thu Apr 23 21:09:06 2026 +0100 rxrpc: Fix rxrpc_input_call_event() to only unshare DATA packets commit 55b2984c96c37f909bbfe8851f13152693951382 upstream. Fix rxrpc_input_call_event() to only unshare DATA packets and not ACK, ABORT, etc.. And with that, rxrpc_input_packet() doesn't need to take a pointer to the pointer to the packet, so change that to just a pointer. Fixes: 1f2740150f90 ("rxrpc: Fix potential UAF after skb_unshare() failure") Closes: https://sashiko.dev/#/patchset/[email protected] Signed-off-by: David Howells <[email protected]> cc: Marc Dionne <[email protected]> cc: Jeffrey Altman <[email protected]> cc: Simon Horman <[email protected]> cc: [email protected] cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Joseph Salisbury <[email protected]> Date: Fri Apr 3 17:00:14 2026 -0400 sched: Use u64 for bandwidth ratio calculations commit c6e80201e057dfb7253385e60bf541121bf5dc33 upstream. to_ratio() computes BW_SHIFT-scaled bandwidth ratios from u64 period and runtime values, but it returns unsigned long. tg_rt_schedulable() also stores the current group limit and the accumulated child sum in unsigned long. On 32-bit builds, large bandwidth ratios can be truncated and the RT group sum can wrap when enough siblings are present. That can let an overcommitted RT hierarchy pass the schedulability check, and it also narrows the helper result for other callers. Return u64 from to_ratio() and use u64 for the RT group totals so bandwidth ratios are preserved and compared at full width on both 32-bit and 64-bit builds. Fixes: b40b2e8eb521 ("sched: rt: multi level group constraints") Assisted-by: Codex:GPT-5 Signed-off-by: Joseph Salisbury <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Andrea Righi <[email protected]> Date: Wed Mar 25 22:21:00 2026 +0100 sched_ext: Documentation: Clarify ops.dispatch() role in task lifecycle commit a313357a346839d40b3a4dec393c71bf30cbb34c upstream. ops.dispatch() is invoked when a CPU becomes available. This can occur when a task voluntarily yields the CPU, exhausts its time slice, or is preempted for other reasons. If the task is still runnable, refilling its time slice in ops.dispatch() (either by the BPF scheduler or the sched_ext core) allows it to continue running without triggering ops.stopping(). However, this behavior is not clearly reflected in the current task lifecycle diagram. Update the diagram to better represent this interaction. Fixes: 9465f44d2df2 ("sched_ext: Documentation: Clarify time slice handling in task lifecycle") Cc: [email protected] # v6.17+ Signed-off-by: Andrea Righi <[email protected]> Signed-off-by: Tejun Heo <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yang Xiuwei <[email protected]> Date: Mon Mar 30 09:49:52 2026 +0800 scsi: sd: fix missing put_disk() when device_add(&disk_dev) fails commit 1e111c4b3a726df1254670a5cc4868cedb946d37 upstream. If device_add(&sdkp->disk_dev) fails, put_device() runs scsi_disk_release(), which frees the scsi_disk but leaves the gendisk referenced. The device_add_disk() error path in sd_probe() calls put_disk(gd); call put_disk(gd) here to mirror that cleanup. Fixes: 265dfe8ebbab ("scsi: sd: Free scsi_disk device via put_device()") Cc: [email protected] Reviewed-by: John Garry <[email protected]> Signed-off-by: Yang Xiuwei <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Andrea Mayer <[email protected]> Date: Sat Apr 18 18:28:38 2026 +0200 seg6: fix seg6 lwtunnel output redirect for L2 reduced encap mode commit ade67d5f588832c7ba131aadd4215a94ce0a15c8 upstream. When SEG6_IPTUN_MODE_L2ENCAP_RED (L2ENCAP_RED) was introduced, the condition in seg6_build_state() that excludes L2 encap modes from setting LWTUNNEL_STATE_OUTPUT_REDIRECT was not updated to account for the new mode. As a consequence, L2ENCAP_RED routes incorrectly trigger seg6_output() on the output path, where the packet is silently dropped because skb_mac_header_was_set() fails on L3 packets. Extend the check to also exclude L2ENCAP_RED, consistent with L2ENCAP. Fixes: 13f0296be8ec ("seg6: add support for SRv6 H.L2Encaps.Red behavior") Cc: [email protected] Signed-off-by: Andrea Mayer <[email protected]> Reviewed-by: Justin Iurman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mickaël Salaün <[email protected]> Date: Thu Apr 2 21:26:04 2026 +0200 selftests/landlock: Drain stale audit records on init commit 3647a4977fb73da385e5a29b9775a4749733470d upstream. Non-audit Landlock tests generate audit records as side effects when audit_enabled is non-zero (e.g. from boot configuration). These records accumulate in the kernel audit backlog while no audit daemon socket is open. When the next test opens a new netlink socket and registers as the audit daemon, the stale backlog is delivered, causing baseline record count checks to fail spuriously. Fix this by draining all pending records in audit_init() right after setting the receive timeout. The 1-usec SO_RCVTIMEO causes audit_recv() to return -EAGAIN once the backlog is empty, naturally terminating the drain loop. Domain deallocation records are emitted asynchronously from a work queue, so they may still arrive after the drain. Remove records.domain == 0 checks that are not preceded by audit_match_record() calls, which would otherwise consume stale records before the count. Document this constraint above audit_count_records(). Increasing the drain timeout to catch in-flight deallocation records was considered but rejected: a longer timeout adds latency to every audit_init() call even when no stale record is pending, and any fixed timeout is still not guaranteed to catch all records under load. Removing the unprotected checks is simpler and avoids the spurious failures. Cc: Günther Noack <[email protected]> Cc: [email protected] Fixes: 6a500b22971c ("selftests/landlock: Add tests for audit flags and domain IDs") Reviewed-by: Günther Noack <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mickaël Salaün <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mickaël Salaün <[email protected]> Date: Thu Apr 2 21:26:06 2026 +0200 selftests/landlock: Fix format warning for __u64 in net_test commit a060ac0b8c3345639f5f4a01e2c435d34adf7e3d upstream. On architectures where __u64 is unsigned long (e.g. powerpc64), using %llx to format a __u64 triggers a -Wformat warning because %llx expects unsigned long long. Cast the argument to unsigned long long. Cc: Günther Noack <[email protected]> Cc: [email protected] Fixes: a549d055a22e ("selftests/landlock: Add network tests") Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/r/[email protected]/ Reviewed-by: Günther Noack <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mickaël Salaün <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mickaël Salaün <[email protected]> Date: Thu Apr 2 21:26:02 2026 +0200 selftests/landlock: Fix snprintf truncation checks in audit helpers commit b566f7a4f0e4f15f78f2e5fac273fa954991e03a upstream. snprintf() returns the number of characters that would have been written, excluding the terminating NUL byte. When the output is truncated, this return value equals or exceeds the buffer size. Fix matches_log_domain_allocated() and matches_log_domain_deallocated() to detect truncation with ">=" instead of ">". Cc: Günther Noack <[email protected]> Cc: [email protected] Fixes: 6a500b22971c ("selftests/landlock: Add tests for audit flags and domain IDs") Reviewed-by: Günther Noack <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mickaël Salaün <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mickaël Salaün <[email protected]> Date: Thu Apr 2 21:26:05 2026 +0200 selftests/landlock: Skip stale records in audit_match_record() commit 07c2572a87573b2a2f0fd6b9f538cd1aeef2eee7 upstream. Domain deallocation records are emitted asynchronously from kworker threads (via free_ruleset_work()). Stale deallocation records from a previous test can arrive during the current test's deallocation read loop and be picked up by audit_match_record() instead of the expected record, causing a domain ID mismatch. The audit.layers test (which creates 16 nested domains) is particularly vulnerable because it reads 16 deallocation records in sequence, providing a large window for stale records to interleave. The same issue affects audit_flags.signal, where deallocation records from a previous test (audit.layers) can leak into the next test and be picked up by audit_match_record() instead of the expected record. Fix this by continuing to read records when the type matches but the content pattern does not. Stale records are silently consumed, and the loop only stops when both type and pattern match (or the socket times out with -EAGAIN). Additionally, extend matches_log_domain_deallocated() with an expected_domain_id parameter. When set, the regex pattern includes the specific domain ID as a literal hex value, so that deallocation records for a different domain do not match the pattern at all. This handles the case where the stale record has the same denial count as the expected one (e.g. both have denials=1), which the type+pattern loop alone cannot distinguish. Callers that already know the expected domain ID (from a prior denial or allocation record) now pass it to filter precisely. When expected_domain_id is set, matches_log_domain_deallocated() also temporarily increases the socket timeout to audit_tv_dom_drop (1 second) to wait for the asynchronous kworker deallocation, and restores audit_tv_default afterward. This removes the need for callers to manage the timeout switch manually. Cc: Günther Noack <[email protected]> Cc: [email protected] Fixes: 6a500b22971c ("selftests/landlock: Add tests for audit flags and domain IDs") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mickaël Salaün <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Simon Liebold <[email protected]> Date: Thu Mar 12 14:02:00 2026 +0000 selftests/mqueue: Fix incorrectly named file commit 64fac99037689020ad97e472ae898e96ea3616dc upstream. Commit 85506aca2eb4 ("selftests/mqueue: Set timeout to 180 seconds") intended to increase the timeout for mq_perf_tests from the default kselftest limit of 45 seconds to 180 seconds. Unfortunately, the file storing this information was incorrectly named `setting` instead of `settings`, causing the kselftest runner not to pick up the limit and keep using the default 45 seconds limit. Fix this by renaming it to `settings` to ensure that the kselftest runner uses the increased timeout of 180 seconds for this test. Fixes: 85506aca2eb4 ("selftests/mqueue: Set timeout to 180 seconds") Cc: <[email protected]> # 5.10.y Signed-off-by: Simon Liebold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Paul Moore <[email protected]> Date: Thu Jan 1 17:19:18 2026 -0500 selinux: fix overlayfs mmap() and mprotect() access checks commit 82544d36b1729153c8aeb179e84750f0c085d3b1 upstream. The existing SELinux security model for overlayfs is to allow access if the current task is able to access the top level file (the "user" file) and the mounter's credentials are sufficient to access the lower level file (the "backing" file). Unfortunately, the current code does not properly enforce these access controls for both mmap() and mprotect() operations on overlayfs filesystems. This patch makes use of the newly created security_mmap_backing_file() LSM hook to provide the missing backing file enforcement for mmap() operations, and leverages the backing file API and new LSM blob to provide the necessary information to properly enforce the mprotect() access controls. Cc: [email protected] Acked-by: Amir Goldstein <[email protected]> Signed-off-by: Paul Moore <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Marco Elver <[email protected]> Date: Thu Apr 16 15:25:07 2026 +0200 slub: fix data loss and overflow in krealloc() commit 082a6d03a2d685a83a332666b500ad3966349588 upstream. Commit 2cd8231796b5 ("mm/slub: allow to set node and align in k[v]realloc") introduced the ability to force a reallocation if the original object does not satisfy new alignment or NUMA node, even when the object is being shrunk. This introduced two bugs in the reallocation fallback path: 1. Data loss during NUMA migration: The jump to 'alloc_new' happens before 'ks' and 'orig_size' are initialized. As a result, the memcpy() in the 'alloc_new' block would copy 0 bytes into the new allocation. 2. Buffer overflow during shrinking: When shrinking an object while forcing a new alignment, 'new_size' is smaller than the old size. However, the memcpy() used the old size ('orig_size ?: ks'), leading to an out-of-bounds write. The same overflow bug exists in the kvrealloc() fallback path, where the old bucket size ksize(p) is copied into the new buffer without being bounded by the new size. A simple reproducer: // e.g. add to lkdtm as KREALLOC_SHRINK_OVERFLOW while (1) { void *p = kmalloc(128, GFP_KERNEL); p = krealloc_node_align(p, 64, 256, GFP_KERNEL, NUMA_NO_NODE); kfree(p); } demonstrates the issue: ================================================================== BUG: KFENCE: out-of-bounds write in memcpy_orig+0x68/0x130 Out-of-bounds write at 0xffff8883ad757038 (120B right of kfence-#47): memcpy_orig+0x68/0x130 krealloc_node_align_noprof+0x1c8/0x340 lkdtm_KREALLOC_SHRINK_OVERFLOW+0x8c/0xc0 [lkdtm] lkdtm_do_action+0x3a/0x60 [lkdtm] ... kfence-#47: 0xffff8883ad756fc0-0xffff8883ad756fff, size=64, cache=kmalloc-64 allocated by task 316 on cpu 7 at 97.680481s (0.021813s ago): krealloc_node_align_noprof+0x19c/0x340 lkdtm_KREALLOC_SHRINK_OVERFLOW+0x8c/0xc0 [lkdtm] lkdtm_do_action+0x3a/0x60 [lkdtm] ... ================================================================== Fix it by moving the old size calculation to the top of __do_krealloc() and bounding all copy lengths by the new allocation size. Fixes: 2cd8231796b5 ("mm/slub: allow to set node and align in k[v]realloc") Cc: [email protected] Reported-by: https://sashiko.dev/#/patchset/20260415143735.2974230-1-elver%40google.com Signed-off-by: Marco Elver <[email protected]> Link: https://patch.msgid.link/[email protected] Reviewed-by: Harry Yoo (Oracle) <[email protected]> Signed-off-by: Vlastimil Babka (SUSE) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Johan Hovold <[email protected]> Date: Fri Mar 27 11:43:04 2026 +0100 spi: ch341: fix memory leaks on probe failures commit b99e3ddb91b499d920e63a2daff8880be68cfe9e upstream. Make sure to deregister the controller, disable pins, and kill and free the RX URB on probe failures to mirror disconnect and avoid memory leaks and use-after-free. Also add an explicit URB kill on disconnect for symmetry (even if that is not strictly required as USB core would have stopped it in the current setup). Fixes: 8846739f52af ("spi: add ch341a usb2spi driver") Cc: [email protected] # 6.11 Cc: Johannes Thumshirn <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Johan Hovold <[email protected]> Date: Fri Apr 10 17:49:06 2026 +0200 spi: fix resource leaks on device setup failure commit db357034f7e0cf23f233f414a8508312dfe8fbbe upstream. Make sure to call controller cleanup() if spi_setup() fails while registering a device to avoid leaking any resources allocated by setup(). Fixes: c7299fea6769 ("spi: Fix spi device unregister flow") Cc: [email protected] # 5.13 Cc: Saravana Kannan <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Johan Hovold <[email protected]> Date: Tue Mar 24 09:23:22 2026 +0100 spi: imx: fix use-after-free on unbind 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: 307c897db762 ("spi: spi-imx: replace struct spi_imx_data::bitbang by pointer to struct spi_controller") Cc: [email protected] # 5.19 Acked-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thomas Weißschuh <[email protected]> Date: Fri Apr 3 18:31:02 2026 +0200 sysfs: attribute_group: Respect is_visible_const() when changing owner commit 9ce4a8c07b28cdd70f6ca38b60bf688c27dbbfb9 upstream. The call to grp->is_visible in sysfs_group_attrs_change_owner() was missed when support for is_visible_const() was added. Check for both is_visible variants there too. Fixes: 7dd9fdb4939b ("sysfs: attribute_group: enable const variants of is_visible()") Cc: [email protected] Reported-by: Michael Kelley <[email protected]> Closes: https://lore.kernel.org/lkml/SN6PR02MB4157D5F04608E4E3C21AB56ED45EA@SN6PR02MB4157.namprd02.prod.outlook.com/ Link: https://sashiko.dev/#/patchset/20260403-sysfs-const-hv-v2-0-8932ab8d41db%40weissschuh.net Signed-off-by: Thomas Weißschuh <[email protected]> Reviewed-by: Michael Kelley <[email protected]> Link: https://patch.msgid.link/20260403-sysfs-is_visible_const-fix-v1-1-f87f26071d2c@weissschuh.net Signed-off-by: Danilo Krummrich <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yiyang Chen <[email protected]> Date: Mon Mar 30 03:00:40 2026 +0800 taskstats: set version in TGID exit notifications commit 16c4f0211aaa1ec1422b11b59f64f1abe9009fc0 upstream. delay accounting started populating taskstats records with a valid version field via fill_pid() and fill_tgid(). Later, commit ad4ecbcba728 ("[PATCH] delay accounting taskstats interface send tgid once") changed the TGID exit path to send the cached signal->stats aggregate directly instead of building the outgoing record through fill_tgid(). Unlike fill_tgid(), fill_tgid_exit() only accumulates accounting data and never initializes stats->version. As a result, TGID exit notifications can reach userspace with version == 0 even though PID exit notifications and TASKSTATS_CMD_GET replies carry a valid taskstats version. This is easy to reproduce with `tools/accounting/getdelays.c`. I have a small follow-up patch for that tool which: 1. increases the receive buffer/message size so the pid+tgid combined exit notification is not dropped/truncated 2. prints `stats->version`. With that patch, the reproducer is: Terminal 1: ./getdelays -d -v -l -m 0 Terminal 2: taskset -c 0 python3 -c 'import threading,time; t=threading.Thread(target=time.sleep,args=(0.1,)); t.start(); t.join()' That produces both PID and TGID exit notifications for the same process. The PID exit record reports a valid taskstats version, while the TGID exit record reports `version 0`. This patch (of 2): Set stats->version = TASKSTATS_VERSION after copying the cached TGID aggregate into the outgoing netlink payload so all taskstats records are self-describing again. Link: https://lkml.kernel.org/r/ba83d934e59edd431b693607de573eb9ca059309.1774810498.git.cyyzero16@gmail.com Fixes: ad4ecbcba728 ("[PATCH] delay accounting taskstats interface send tgid once") Signed-off-by: Yiyang Chen <[email protected]> Cc: Balbir Singh <[email protected]> Cc: Dr. Thomas Orgis <[email protected]> Cc: Fan Yu <[email protected]> Cc: Wang Yaxin <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zhenzhong Wu <[email protected]> Date: Wed Apr 22 10:45:53 2026 +0800 tcp: call sk_data_ready() after listener migration commit 3864c6ba1e041bc75342353a70fa2a2c6f909923 upstream. When inet_csk_listen_stop() migrates an established child socket from a closing listener to another socket in the same SO_REUSEPORT group, the target listener gets a new accept-queue entry via inet_csk_reqsk_queue_add(), but that path never notifies the target listener's waiters. A nonblocking accept() still works because it checks the queue directly, but poll()/epoll_wait() waiters and blocking accept() callers can also remain asleep indefinitely. Call READ_ONCE(nsk->sk_data_ready)(nsk) after a successful migration in inet_csk_listen_stop(). However, after inet_csk_reqsk_queue_add() succeeds, the ref acquired in reuseport_migrate_sock() is effectively transferred to nreq->rsk_listener. Another CPU can then dequeue nreq via accept() or listener shutdown, hit reqsk_put(), and drop that listener ref. Since listeners are SOCK_RCU_FREE, wrap the post-queue_add() dereferences of nsk in rcu_read_lock()/rcu_read_unlock(), which also covers the existing sock_net(nsk) access in that path. The reqsk_timer_handler() path does not need the same changes for two reasons: half-open requests become readable only after the final ACK, where tcp_child_process() already wakes the listener; and once nreq is visible via inet_ehash_insert(), the success path no longer touches nsk directly. Fixes: 54b92e841937 ("tcp: Migrate TCP_ESTABLISHED/TCP_SYN_RECV sockets in accept queues.") Cc: [email protected] Suggested-by: Eric Dumazet <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Signed-off-by: Zhenzhong Wu <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Rafael J. Wysocki <[email protected]> Date: Tue Apr 7 15:55:19 2026 +0200 thermal: core: Fix thermal zone governor cleanup issues commit 41ff66baf81c6541f4f985dd7eac4494d03d9440 upstream. If thermal_zone_device_register_with_trips() fails after adding a thermal governor to the thermal zone being registered, the governor is not removed from it as appropriate which may lead to a memory leak. In turn, thermal_zone_device_unregister() calls thermal_set_governor() without acquiring the thermal zone lock beforehand which may race with a governor update via sysfs and may lead to a use-after-free in that case. Address these issues by adding two thermal_set_governor() calls, one to thermal_release() to remove the governor from the given thermal zone, and one to the thermal zone registration error path to cover failures preceding the thermal zone device registration. Fixes: e33df1d2f3a0 ("thermal: let governors have private data for each thermal zone") Cc: All applicable <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yiyang Chen <[email protected]> Date: Mon Mar 30 03:00:41 2026 +0800 tools/accounting: handle truncated taskstats netlink messages commit cc82b3dcc6a8fa259fbda12ab00d6fc00908a49e upstream. procacct and getdelays use a fixed receive buffer for taskstats generic netlink messages. A multi-threaded process exit can emit a single PID+TGID notification large enough to exceed that buffer on newer kernels. Switch to recvmsg() so MSG_TRUNC is detected explicitly, increase the message buffer size, and report truncated datagrams clearly instead of misparsing them as fatal netlink errors. Also print the taskstats version in debug output to make version mismatches easier to diagnose while inspecting taskstats traffic. Link: https://lkml.kernel.org/r/520308bb4cbbaf8dc2c7296b5f60f11e12fb30a5.1774810498.git.cyyzero16@gmail.com Signed-off-by: Yiyang Chen <[email protected]> Cc: Balbir Singh <[email protected]> Cc: Dr. Thomas Orgis <[email protected]> Cc: Fan Yu <[email protected]> Cc: Wang Yaxin <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Gunnar Kudrjavets <[email protected]> Date: Wed Apr 15 03:00:03 2026 +0300 tpm2-sessions: Fix missing tpm_buf_destroy() in tpm2_read_public() commit f0f75a3d98b7959a8677b6363e23190f3018636b upstream. tpm2_read_public() calls tpm_buf_init() but fails to call tpm_buf_destroy() on two exit paths, leaking a page allocation: 1. When name_size() returns an error (unrecognized hash algorithm), the function returns directly without destroying the buffer. 2. On the success path, the buffer is never destroyed before returning. All other error paths in the function correctly call tpm_buf_destroy() before returning. Fix both by adding the missing tpm_buf_destroy() calls. Cc: [email protected] # v6.19+ Fixes: bda1cbf73c6e ("tpm2-sessions: Fix tpm2_read_public range checks") Signed-off-by: Gunnar Kudrjavets <[email protected]> Reviewed-by: Justinien Bouron <[email protected]> Reviewed-by: Paul Menzel <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Arnd Bergmann <[email protected]> Date: Fri Mar 22 14:22:48 2024 +0100 tpm: avoid -Wunused-but-set-variable commit 6f1d4d2ecfcd1b577dc87350ea965fe81f272e83 upstream. Outside of the EFI tpm code, the TPM_MEMREMAP()/TPM_MEMUNMAP functions are defined as trivial macros, leading to the mapping_size variable ending up unused: In file included from drivers/char/tpm/tpm-sysfs.c:16: In file included from drivers/char/tpm/tpm.h:28: include/linux/tpm_eventlog.h:167:6: error: variable 'mapping_size' set but not used [-Werror,-Wunused-but-set-variable] 167 | int mapping_size; Turn the stubs into inline functions to avoid this warning. Cc: [email protected] # v5.3+ Fixes: c46f3405692d ("tpm: Reserve the TPM final events table") Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Thorsten Blum <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Gunnar Kudrjavets <[email protected]> Date: Wed Apr 8 12:00:27 2026 +0300 tpm: Fix auth session leak in tpm2_get_random() error path commit 666c1a2ca603d8314231200bf8bbb3a81bd64c6b upstream. When tpm_buf_fill_hmac_session() fails inside the do-while loop in tpm2_get_random(), the function returns directly after destroying the buffer, without ending the auth session via tpm2_end_auth_session(). This leaks the TPM auth session resource. All other error paths within the loop correctly reach the 'out' label which calls both tpm_buf_destroy() and tpm2_end_auth_session(). Fix this by replacing the early return with a goto to the existing 'out' label, which already handles both cleanup operations. The redundant tpm_buf_destroy() call is removed since 'out' takes care of it. Cc: [email protected] # v6.19+ Fixes: 6e9722e9a7bf ("tpm2-sessions: Fix out of range indexing in name_size") Signed-off-by: Gunnar Kudrjavets <[email protected]> Reviewed-by: Justinien Bouron <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jacqueline Wong <[email protected]> Date: Wed Apr 15 16:00:05 2026 +0000 tpm: tpm_tis: add error logging for data transfer commit 0471921e2d1043dcc6de5cffb49dd37709521abe upstream. Add logging to more easily determine reason for transmit failure Cc: [email protected] # v6.6+ Fixes: 280db21e153d8 ("tpm_tis: Resend command to recover from data transfer errors") Signed-off-by: Jacqueline Wong <[email protected]> Signed-off-by: Jordan Hand <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jacqueline Wong <[email protected]> Date: Wed Apr 15 16:00:06 2026 +0000 tpm: tpm_tis: stop transmit if retries are exhausted 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: [email protected] # v6.6+ Fixes: 280db21e153d8 ("tpm_tis: Resend command to recover from data transfer errors") Signed-off-by: Jacqueline Wong <[email protected]> Signed-off-by: Jordan Hand <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Gunnar Kudrjavets <[email protected]> Date: Thu Apr 9 17:20:54 2026 +0000 tpm: Use kfree_sensitive() to free auth session in tpm_dev_release() commit c424d2664f08c77f08b4580b5f0cbaabf7c229b2 upstream. tpm_dev_release() uses plain kfree() to free chip->auth, which contains sensitive cryptographic material including HMAC session keys, nonces, and passphrase data (struct tpm2_auth). Every other code path that frees this structure uses kfree_sensitive() to zero the memory before releasing it: both tpm2_end_auth_session() and tpm_buf_check_hmac_response() do so. The tpm_dev_release() path is the only one that does not, leaving key material in freed slab memory until it is eventually overwritten. Use kfree_sensitive() for consistency with the rest of the driver and to ensure session keys are scrubbed during device teardown. Cc: [email protected] # v6.10+ Fixes: 699e3efd6c64 ("tpm: Add HMAC session start and end functions") Signed-off-by: Gunnar Kudrjavets <[email protected]> Reviewed-by: Justinien Bouron <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Masami Hiramatsu (Google) <[email protected]> Date: Mon Apr 20 23:00:48 2026 +0900 tracing/fprobe: Reject registration of a registered fprobe before init commit 6ad51ada17ed80c9a5f205b4c01c424cac8b0d46 upstream. Reject registration of a registered fprobe which is on the fprobe hash table before initializing fprobe. The add_fprobe_hash() checks this re-register fprobe, but since fprobe_init() clears hlist_array field, it is too late to check it. It has to check the re-registration before touncing fprobe. Link: https://lore.kernel.org/all/177669364845.132053.18375367916162315835.stgit@mhiramat.tok.corp.google.com/ Fixes: 4346ba160409 ("fprobe: Rewrite fprobe on function-graph tracer") Cc: [email protected] Signed-off-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Seohyeon Maeng <[email protected]> Date: Tue Mar 10 17:16:52 2026 +0900 udf: fix partition descriptor append bookkeeping commit 08841b06fa64d8edbd1a21ca6e613420c90cc4b8 upstream. Mounting a crafted UDF image with repeated partition descriptors can trigger a heap out-of-bounds write in part_descs_loc[]. handle_partition_descriptor() deduplicates entries by partition number, but appended slots never record partnum. As a result duplicate Partition Descriptors are appended repeatedly and num_part_descs keeps growing. Once the table is full, the growth path still sizes the allocation from partnum even though inserts are indexed by num_part_descs. If partnum is already aligned to PART_DESC_ALLOC_STEP, ALIGN(partnum, step) can keep the old capacity and the next append writes past the end of the table. Store partnum in the appended slot and size growth from the next append count so deduplication and capacity tracking follow the same model. Fixes: ee4af50ca94f ("udf: Fix mounting of Win7 created UDF filesystems") Cc: [email protected] Signed-off-by: Seohyeon Maeng <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jan Kara <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Michael Bommarito <[email protected]> Date: Wed Apr 8 03:01:02 2026 -0400 um: drivers: call kernel_strrchr() explicitly in cow_user.c 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: 2c51a4bc0233 ("um: fix strrchr() problems") Suggested-by: Johannes Berg <[email protected]> Cc: [email protected] Assisted-by: Claude:claude-opus-4-6 Assisted-by: Codex:gpt-5-4 Signed-off-by: Michael Bommarito <[email protected]> Link: https://patch.msgid.link/[email protected] [remove unnecessary 'extern'] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Xu Yang <[email protected]> Date: Thu Apr 2 15:14:56 2026 +0800 usb: chipidea: core: allow ci_irq_handler() handle both ID and VBUS change 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 <[email protected]> Fixes: e1b5d2bed67c ("usb: chipidea: core: handle usb role switch in a common way") Cc: [email protected] Signed-off-by: Xu Yang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Xu Yang <[email protected]> Date: Thu Apr 2 15:14:57 2026 +0800 usb: chipidea: otg: not wait vbus drop if use role_switch 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: e1b5d2bed67c ("usb: chipidea: core: handle usb role switch in a common way") Cc: [email protected] Acked-by: Peter Chen <[email protected]> Reviewed-by: Jun Li <[email protected]> Signed-off-by: Xu Yang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Michal Pecio <[email protected]> Date: Thu Apr 2 16:13:42 2026 +0300 usb: xhci: Make usb_host_endpoint.hcpriv survive endpoint_disable() 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: 18b74067ac78 ("xhci: Fix use-after-free regression in xhci clear hub TT implementation") Cc: [email protected] Signed-off-by: Michal Pecio <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Denis M. Karpov <[email protected]> Date: Thu Apr 9 13:33:45 2026 +0300 userfaultfd: allow registration of ranges below mmap_min_addr 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/[email protected] Fixes: 86039bd3b4e6 ("userfaultfd: add new syscall to provide memory externalization") Signed-off-by: Denis M. Karpov <[email protected]> Reviewed-by: Lorenzo Stoakes <[email protected]> Acked-by: Harry Yoo (Oracle) <[email protected]> Reviewed-by: Pedro Falcato <[email protected]> Reviewed-by: Liam R. Howlett <[email protected]> Reviewed-by: Mike Rapoport (Microsoft) <[email protected]> Cc: Alexander Viro <[email protected]> Cc: Al Viro <[email protected]> Cc: Christian Brauner <[email protected]> Cc: Jan Kara <[email protected]> Cc: Jann Horn <[email protected]> Cc: Peter Xu <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Prasanna Kumar T S M <[email protected]> Date: Fri Apr 17 14:27:56 2026 -0600 vfio/cdx: Fix NULL pointer dereference in interrupt trigger path commit 5ea5880764cbb164afb17a62e76ca75dc371409d upstream. Add validation to ensure MSI is configured before accessing cdx_irqs array in vfio_cdx_set_msi_trigger(). Without this check, userspace can trigger a NULL pointer dereference by calling VFIO_DEVICE_SET_IRQS with VFIO_IRQ_SET_DATA_BOOL or VFIO_IRQ_SET_DATA_NONE flags before ever setting up interrupts via VFIO_IRQ_SET_DATA_EVENTFD. The vfio_cdx_msi_enable() function allocates the cdx_irqs array and sets config_msi to 1 only when called through the EVENTFD path. The trigger loop (for DATA_BOOL/DATA_NONE) assumed this had already been done, but there was no enforcement of this call ordering. This matches the protection used in the PCI VFIO driver where vfio_pci_set_msi_trigger() checks irq_is() before the trigger loop. Fixes: 848e447e000c ("vfio/cdx: add interrupt support") Cc: [email protected] Signed-off-by: Prasanna Kumar T S M <[email protected]> Acked-by: Nipun Gupta <[email protected]> Signed-off-by: Alex Williamson <[email protected]> Acked-by: Nikhil Agarwal <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alex Williamson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alex Williamson <[email protected]> Date: Fri Apr 17 14:27:57 2026 -0600 vfio/cdx: Serialize VFIO_DEVICE_SET_IRQS with a per-device mutex commit 670e8864b1a218d72f08db40d0103adf38fa1d9b upstream. vfio_cdx_set_msi_trigger() reads vdev->config_msi and operates on the vdev->cdx_irqs array based on its value, but provides no serialization against concurrent VFIO_DEVICE_SET_IRQS ioctls. Two callers can race such that one observes config_msi as set while another clears it and frees cdx_irqs via vfio_cdx_msi_disable(), resulting in a use-after-free of the cdx_irqs array. Add a cdx_irqs_lock mutex to struct vfio_cdx_device and acquire it in vfio_cdx_set_msi_trigger(), which is the single chokepoint through which all updates to config_msi, cdx_irqs, and msi_count flow, covering both the ioctl path and the close-device cleanup path. This keeps the test of config_msi atomic with the subsequent enable, disable, or trigger operations. Drop the pre-call !cdx_irqs test from vfio_cdx_irqs_cleanup() as part of this change: the optimization it provided is redundant with the !config_msi early-return inside vfio_cdx_msi_disable(), and leaving the test in place would be an unsynchronized read of state the new lock is meant to protect. Fixes: 848e447e000c ("vfio/cdx: add interrupt support") Cc: [email protected] Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Alex Williamson <[email protected]> Acked-by: Nikhil Agarwal <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alex Williamson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alex Williamson <[email protected]> Date: Tue Apr 14 14:06:19 2026 -0600 vfio/virtio: Convert list_lock from spinlock to mutex commit 903570835f12b7436ca0edb0a9ed351c0349121e upstream. The list_lock spinlock with IRQ disabling was copied from the mlx5 vfio-pci variant driver, where it is justified by a hardirq async command completion callback that accesses the protected lists. The virtio driver has no such interrupt context usage; all list_lock acquisitions occur in process context via file read/write operations or state transitions under state_mutex. Convert list_lock to a mutex to be consistent with peer vfio-pci variant drivers (hisilicon, pds, qat, xe) which all use mutexes for equivalent migration data protection. This also fixes a mismatched spin_lock()/spin_unlock_irq() pair in virtiovf_read_device_context_chunk() that could incorrectly enable interrupts. Reported-by: Jinhui Guo <[email protected]> Closes: https://lore.kernel.org/all/[email protected] Fixes: 0bbc82e4ec79 ("vfio/virtio: Add support for the basic live migration functionality") Cc: [email protected] Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Alex Williamson <[email protected]> Reviewed-by: Yishai Hadas <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alex Williamson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Michał Winiarski <[email protected]> Date: Sat Apr 11 00:49:48 2026 +0200 vfio/xe: Add a missing vfio_pci_core_release_dev() commit 493c7eff3c2ffa94ce3c5e62172948a1e38b491e upstream. The driver is implementing its own .release(), which means that it needs to call vfio_pci_core_release_dev(). Add the missing call. Fixes: 1f5556ec8b9ef ("vfio/xe: Add device specific vfio_pci driver variant for Intel graphics") Reported-by: Niklas Schnelle <[email protected]> Closes: https://lore.kernel.org/kvm/[email protected]/ Cc: [email protected] Signed-off-by: Michał Winiarski <[email protected]> Reviewed-by: Niklas Schnelle <[email protected]> Reviewed-by: Kevin Tian <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alex Williamson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Manish Honap <[email protected]> Date: Tue Mar 17 10:44:02 2026 +0530 vfio: selftests: Fix VLA initialisation in vfio_pci_irq_set() commit 4f42d716707654134789a0205a050b0d022be948 upstream. C does not permit an initialiser expression on a variable-length array (C99 Section 6.7.9 constraint: "The type of the entity to be initialized shall not be a variable length array type"). vfio_pci_irq_set() declared: u8 buf[sizeof(struct vfio_irq_set) + sizeof(int) * count] = {}; where `count` is a runtime function parameter, making `buf` a VLA. GCC rejects this with (tried with GCC-9.4.0): error: variable-sized object may not be initialized Fix by removing the `= {}` initialiser and inserting an explicit memset() immediately after the declaration. memset() on a VLA is perfectly legal and achieves the same zero-initialisation on all conforming C implementations. Fixes: 19faf6fd969c ("vfio: selftests: Add a helper library for VFIO selftests") Cc: [email protected] Reviewed-by: Dave Jiang <[email protected]> Reviewed-by: David Matlack <[email protected]> Signed-off-by: Manish Honap <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alex Williamson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Marco Elver <[email protected]> Date: Mon Apr 20 13:47:26 2026 +0200 vmalloc: fix buffer overflow in vrealloc_node_align() commit 82d1f01292d3f09bf063f829f8ab8de12b4280a1 upstream. Commit 4c5d3365882d ("mm/vmalloc: allow to set node and align in vrealloc") added the ability to force a new allocation if the current pointer is on the wrong NUMA node, or if an alignment constraint is not met, even if the user is shrinking the allocation. On this path (need_realloc), the code allocates a new object of 'size' bytes and then memcpy()s 'old_size' bytes into it. If the request is to shrink the object (size < old_size), this results in an out-of-bounds write on the new buffer. Fix this by bounding the copy length by the new allocation size. Link: https://lore.kernel.org/[email protected] Fixes: 4c5d3365882d ("mm/vmalloc: allow to set node and align in vrealloc") Signed-off-by: Marco Elver <[email protected]> Reported-by: Harry Yoo (Oracle) <[email protected]> Reviewed-by: Uladzislau Rezki (Sony) <[email protected]> Acked-by: Vlastimil Babka (SUSE) <[email protected]> Reviewed-by: Harry Yoo (Oracle) <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sean Wang <[email protected]> Date: Thu Apr 30 12:07:21 2026 -0400 wifi: mt76: mt792x: describe USB WFSYS reset with a descriptor [ Upstream commit e6f48512c1ceebcd1ce6bb83df3b3d56a261507d ] Prepare mt792xu_wfsys_reset() for chips that share the same USB WFSYS reset flow but use different register definitions. This is a pure refactor of the current mt7921u path and keeps the reset sequence unchanged. Signed-off-by: Sean Wang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Stable-dep-of: 56154fef47d1 ("wifi: mt76: mt792x: fix mt7925u USB WFSYS reset handling") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sean Wang <[email protected]> Date: Thu Apr 30 12:07:22 2026 -0400 wifi: mt76: mt792x: fix mt7925u USB WFSYS reset handling [ Upstream commit 56154fef47d104effa9f29ed3db4f805cbc0d640 ] mt7925u uses different reset/status registers from mt7921u. Reusing the mt7921u register set causes the WFSYS reset to fail. Add a chip-specific descriptor in mt792xu_wfsys_reset() to select the correct registers and fix mt7925u failing to initialize after a warm reboot. Fixes: d28e1a48952e ("wifi: mt76: mt792x: introduce mt792x-usb module") Cc: [email protected] Signed-off-by: Sean Wang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Daniel Hodges <[email protected]> Date: Fri Feb 6 14:44:01 2026 -0500 wifi: mwifiex: fix use-after-free in mwifiex_adapter_cleanup() commit ae5e95d4157481693be2317e3ffcd84e36010cbb upstream. The mwifiex_adapter_cleanup() function uses timer_delete() (non-synchronous) for the wakeup_timer before the adapter structure is freed. This is incorrect because timer_delete() does not wait for any running timer callback to complete. If the wakeup_timer callback (wakeup_timer_fn) is executing when mwifiex_adapter_cleanup() is called, the callback will continue to access adapter fields (adapter->hw_status, adapter->if_ops.card_reset, etc.) which may be freed by mwifiex_free_adapter() called later in the mwifiex_remove_card() path. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning. Fixes: 4636187da60b ("mwifiex: add wakeup timer based recovery mechanism") Cc: [email protected] Signed-off-by: Daniel Hodges <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yi Cong <[email protected]> Date: Fri Mar 6 15:16:27 2026 +0800 wifi: rtl8xxxu: fix potential use of uninitialized value commit f8a2fc809bfeb49130709b31a4d357a049f28547 upstream. The local variables 'mcs' and 'nss' in rtl8xxxu_update_ra_report() are passed to rtl8xxxu_desc_to_mcsrate() as output parameters. If the helper function encounters an unhandled rate index, it may return without setting these values, leading to the use of uninitialized stack data. Remove the helper rtl8xxxu_desc_to_mcsrate() and inline the logic into rtl8xxxu_update_ra_report(). This fixes the use of uninitialized 'mcs' and 'nss' variables for legacy rates. The new implementation explicitly handles: - Legacy rates: Set bitrate only. - HT rates (MCS0-15): Set MCS flags, index, and NSS (1 or 2) directly. - Invalid rates: Return early. Fixes: 7de16123d9e2 ("wifi: rtl8xxxu: Introduce rtl8xxxu_update_ra_report") Cc: [email protected] Suggested-by: Ping-Ke Shih <[email protected]> Signed-off-by: Yi Cong <[email protected]> Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Fedor Pchelkin <[email protected]> Date: Fri Feb 20 12:47:30 2026 +0300 wifi: rtw88: check for PCI upstream bridge existence 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: 24f5e38a13b5 ("rtw88: Disable PCIe ASPM while doing NAPI poll on 8821CE") Cc: [email protected] Signed-off-by: Fedor Pchelkin <[email protected]> Acked-by: Ping-Ke Shih <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dave Hansen <[email protected]> Date: Tue Apr 21 09:31:36 2026 -0700 x86/cpu: Disable FRED when PTI is forced on commit 932d922285ef4d0d655a6f5def2779ae86ca0d73 upstream. FRED and PTI were never intended to work together. No FRED hardware is vulnerable to Meltdown and all of it should have LASS anyway. Nevertheless, if you boot a system with pti=on and fred=on, the kernel tries to do what is asked of it and dies a horrible death on the first attempt to run userspace (since it never switches to the user page tables). Disable FRED when PTI is forced on, and print a warning about it. A quick brain dump about what a FRED+PTI implementation would look like is below. I'm not sure it would make any sense to do it, but never say never. All I know is that it's way too complicated to be worth it today. <brain dump> The SWITCH_TO_USER/KERNEL_CR3 bits are simple to fix (or at least we have the assembly tools to do it already), as is sticking the FRED entry text in .entry.text (it's not in there today). The nasty part is the stacks. Today, the CPU pops into the kernel on MSR_IA32_FRED_RSP0 which is normal old kernel memory and not mapped to userspace. The hardware pushes gunk on to MSR_IA32_FRED_RSP0, which is currently the task stacks. MSR_IA32_FRED_RSP0 would need to point elsewhere, probably cpu_entry_stack(). Then, start playing games with stacks on entry/exit, including copying gunk to and from the task stack. While I'd *like* to have PTI everywhere, I'm not sure it's worth mucking up the FRED code with PTI kludges. If a user wants fast entry/exit, they use FRED. If you want PTI (and sekuritay), you certainly don't care about fast entry and FRED isn't going to help you *all* that much, so you can just stay with the IDT. Plus, FRED hardware should have LASS which gives you a similar security profile to PTI without the CR3 munging. </brain dump> Reported-by: Gayatri Kammela <[email protected]> Signed-off-by: Dave Hansen <[email protected]> Reviewed-by: Borislav Petkov (AMD) <[email protected]> Tested-by: Maciej Wieczor-Retman <[email protected]> Cc:[email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Rick Edgecombe <[email protected]> Date: Thu Apr 9 11:43:30 2026 -0700 x86/shstk: Prevent deadlock during shstk sigreturn commit 9874b2917b9fbc30956fee209d3c4aa47201c64e upstream. During sigreturn the shadow stack signal frame is popped. The kernel does this by reading the shadow stack using normal read accesses. When it can't assume the memory is shadow stack, it takes extra steps to makes sure it is reading actual shadow stack memory and not other normal readable memory. It does this by holding the mmap read lock while doing the access and checking the flags of the VMA. Unfortunately that is not safe. If the read of the shadow stack sigframe hits a page fault, the fault handler will try to recursively grab another mmap read lock. This normally works ok, but if a writer on another CPU is also waiting, the second read lock could fail and cause a deadlock. Fix this by not holding mmap lock during the read access to userspace. Instead use mmap_lock_speculate_...() to watch for changes between dropping mmap lock and the userspace access. Retry if anything grabbed an mmap write lock in between and could have changed the VMA. These mmap_lock_speculate_...() helpers use mm::mm_lock_seq, which is only available when PER_VMA_LOCK is configured. So make X86_USER_SHADOW_STACK depend on it. On x86, PER_VMA_LOCK is a default configuration for SMP kernels. So drop support for the other configs under the assumption that the !SMP shadow stack user base does not exist. Currently there is a check that skips the lookup work when the SSP can be assumed to be on a shadow stack. While reorganizing the function, remove the optimization to make the tricky code flows more common, such that issues like this cannot escape detection for so long. Fixes: 7fad2a432cd3 ("x86/shstk: Check that signal frame is shadow stack mem") Suggested-by: Linus Torvalds <[email protected]> Signed-off-by: Rick Edgecombe <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Dave Hansen <[email protected]> Reviewed-by: Thomas Gleixner <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Haoxiang Li <[email protected]> Date: Wed Apr 1 12:02:41 2026 +0800 xfs: fix a resource leak in xfs_alloc_buftarg() commit 29a7b2614357393b176ef06ba5bc3ff5afc8df69 upstream. In the error path, call fs_put_dax() to drop the DAX device reference. Fixes: 6f643c57d57c ("xfs: implement ->notify_failure() for XFS") Cc: [email protected] Signed-off-by: Haoxiang Li <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Hans Holmberg <[email protected]> Date: Wed Mar 25 13:43:12 2026 +0100 xfs: start gc on zonegc_low_space attribute updates commit 181ea4e2de422aa0a66f355bd59bccccdd169826 upstream. Start gc if the agressiveness of zone garbage collection is changed by the user (if the file system is not read only). Without this change, the new setting will not be taken into account until the gc thread is woken up by e.g. a write. Cc: [email protected] # v6.15 Fixes: 845abeb1f06a8a ("xfs: add tunable threshold parameter for triggering zone GC") Signed-off-by: Hans Holmberg <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Damien Le Moal <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sergey Senozhatsky <[email protected]> Date: Tue Mar 31 16:42:44 2026 +0900 zram: do not forget to endio for partial discard requests 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/[email protected] Fixes: 0120dd6e4e20 ("zram: make zram_bio_discard more self-contained") Signed-off-by: Sergey Senozhatsky <[email protected]> Reported-by: Qu Wenruo <[email protected]> Closes: https://lore.kernel.org/linux-block/[email protected] Tested-by: Qu Wenruo <[email protected]> Reported-by: Avinesh Kumar <[email protected]> Closes: https://bugzilla.suse.com/show_bug.cgi?id=1256530 Reviewed-by: Christoph Hellwig <[email protected]> Cc: Brian Geffon <[email protected]> Cc: Jens Axboe <[email protected]> Cc: Minchan Kim <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>