From: Greg Kroah-Hartman Date: Tue, 17 Mar 2026 09:28:26 +0000 (+0100) Subject: 6.6-stable patches X-Git-Tag: v6.18.19~65 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=6dce797159ca82304883d6f26510550979f7d227;p=thirdparty%2Fkernel%2Fstable-queue.git 6.6-stable patches added patches: asoc-qcom-qdsp6-fix-q6apm-remove-ordering-during-adsp-stop-and-start.patch ceph-fix-i_nlink-underrun-during-async-unlink.patch ceph-fix-memory-leaks-in-ceph_mdsc_build_path.patch kprobes-avoid-crash-when-rmmod-insmod-after-ftrace-killed.patch libceph-admit-message-frames-only-in-ceph_con_s_open-state.patch libceph-fix-potential-out-of-bounds-access-in-ceph_handle_auth_reply.patch libceph-prevent-potential-out-of-bounds-reads-in-process_message_header.patch libceph-reject-preamble-if-control-segment-is-empty.patch libceph-use-u32-for-non-negative-values-in-ceph_monmap_decode.patch mm-kfence-disable-kfence-upon-kasan-hw-tags-enablement.patch mm-tracing-rss_stat-ensure-curr-is-false-from-kthread-context.patch mmc-core-avoid-bitfield-rmw-for-claim-retune-flags.patch mmc-mmci-fix-device_node-reference-leak-in-of_get_dml_pipe_index.patch tipc-fix-divide-by-zero-in-tipc_sk_filter_connect.patch --- diff --git a/queue-6.6/asoc-qcom-qdsp6-fix-q6apm-remove-ordering-during-adsp-stop-and-start.patch b/queue-6.6/asoc-qcom-qdsp6-fix-q6apm-remove-ordering-during-adsp-stop-and-start.patch new file mode 100644 index 0000000000..8299f27c9c --- /dev/null +++ b/queue-6.6/asoc-qcom-qdsp6-fix-q6apm-remove-ordering-during-adsp-stop-and-start.patch @@ -0,0 +1,126 @@ +From d6db827b430bdcca3976cebca7bd69cca03cde2c Mon Sep 17 00:00:00 2001 +From: Ravi Hothi +Date: Fri, 27 Feb 2026 20:15:34 +0530 +Subject: ASoC: qcom: qdsp6: Fix q6apm remove ordering during ADSP stop and start + +From: Ravi Hothi + +commit d6db827b430bdcca3976cebca7bd69cca03cde2c upstream. + +During ADSP stop and start, the kernel crashes due to the order in which +ASoC components are removed. + +On ADSP stop, the q6apm-audio .remove callback unloads topology and removes +PCM runtimes during ASoC teardown. This deletes the RTDs that contain the +q6apm DAI components before their removal pass runs, leaving those +components still linked to the card and causing crashes on the next rebind. + +Fix this by ensuring that all dependent (child) components are removed +first, and the q6apm component is removed last. + +[ 48.105720] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0 +[ 48.114763] Mem abort info: +[ 48.117650] ESR = 0x0000000096000004 +[ 48.121526] EC = 0x25: DABT (current EL), IL = 32 bits +[ 48.127010] SET = 0, FnV = 0 +[ 48.130172] EA = 0, S1PTW = 0 +[ 48.133415] FSC = 0x04: level 0 translation fault +[ 48.138446] Data abort info: +[ 48.141422] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 +[ 48.147079] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 +[ 48.152354] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 +[ 48.157859] user pgtable: 4k pages, 48-bit VAs, pgdp=00000001173cf000 +[ 48.164517] [00000000000000d0] pgd=0000000000000000, p4d=0000000000000000 +[ 48.171530] Internal error: Oops: 0000000096000004 [#1] SMP +[ 48.177348] Modules linked in: q6prm_clocks q6apm_lpass_dais q6apm_dai snd_q6dsp_common q6prm snd_q6apm 8021q garp mrp stp llc snd_soc_hdmi_codec apr pdr_interface phy_qcom_edp fastrpc qcom_pd_mapper rpmsg_ctrl qrtr_smd rpmsg_char qcom_pdr_msg qcom_iris v4l2_mem2mem videobuf2_dma_contig ath11k_pci msm ubwc_config at24 ath11k videobuf2_memops mac80211 ocmem videobuf2_v4l2 libarc4 drm_gpuvm mhi qrtr videodev drm_exec snd_soc_sc8280xp gpu_sched videobuf2_common nvmem_qcom_spmi_sdam snd_soc_qcom_sdw drm_dp_aux_bus qcom_q6v5_pas qcom_spmi_temp_alarm snd_soc_qcom_common rtc_pm8xxx qcom_pon drm_display_helper cec qcom_pil_info qcom_stats soundwire_bus drm_client_lib mc dispcc0_sa8775p videocc_sa8775p qcom_q6v5 camcc_sa8775p snd_soc_dmic phy_qcom_sgmii_eth snd_soc_max98357a i2c_qcom_geni snd_soc_core dwmac_qcom_ethqos llcc_qcom icc_bwmon qcom_sysmon snd_compress qcom_refgen_regulator coresight_stm stmmac_platform snd_pcm_dmaengine qcom_common coresight_tmc stmmac coresight_replicator qcom_glink_smem coresight_cti stm_core +[ 48.177444] coresight_funnel snd_pcm ufs_qcom phy_qcom_qmp_usb gpi phy_qcom_snps_femto_v2 coresight phy_qcom_qmp_ufs qcom_wdt gpucc_sa8775p pcs_xpcs mdt_loader qcom_ice icc_osm_l3 qmi_helpers snd_timer snd soundcore display_connector qcom_rng nvmem_reboot_mode drm_kms_helper phy_qcom_qmp_pcie sha256 cfg80211 rfkill socinfo fuse drm backlight ipv6 +[ 48.301059] CPU: 2 UID: 0 PID: 293 Comm: kworker/u32:2 Not tainted 6.19.0-rc6-dirty #10 PREEMPT +[ 48.310081] Hardware name: Qualcomm Technologies, Inc. Lemans EVK (DT) +[ 48.316782] Workqueue: pdr_notifier_wq pdr_notifier_work [pdr_interface] +[ 48.323672] pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) +[ 48.330825] pc : mutex_lock+0xc/0x54 +[ 48.334514] lr : soc_dapm_shutdown_dapm+0x44/0x174 [snd_soc_core] +[ 48.340794] sp : ffff800084ddb7b0 +[ 48.344207] x29: ffff800084ddb7b0 x28: ffff00009cd9cf30 x27: ffff00009cd9cc00 +[ 48.351544] x26: ffff000099610190 x25: ffffa31d2f19c810 x24: ffffa31d2f185098 +[ 48.358869] x23: ffff800084ddb7f8 x22: 0000000000000000 x21: 00000000000000d0 +[ 48.366198] x20: ffff00009ba6c338 x19: ffff00009ba6c338 x18: 00000000ffffffff +[ 48.373528] x17: 000000040044ffff x16: ffffa31d4ae6dca8 x15: 072007740775076f +[ 48.380853] x14: 0765076d07690774 x13: 00313a323a656369 x12: 767265733a637673 +[ 48.388182] x11: 00000000000003f9 x10: ffffa31d4c7dea98 x9 : 0000000000000001 +[ 48.395519] x8 : ffff00009a2aadc0 x7 : 0000000000000003 x6 : 0000000000000000 +[ 48.402854] x5 : 0000000000000000 x4 : 0000000000000028 x3 : ffff000ef397a698 +[ 48.410180] x2 : ffff00009a2aadc0 x1 : 0000000000000000 x0 : 00000000000000d0 +[ 48.417506] Call trace: +[ 48.420025] mutex_lock+0xc/0x54 (P) +[ 48.423712] snd_soc_dapm_shutdown+0x44/0xbc [snd_soc_core] +[ 48.429447] soc_cleanup_card_resources+0x30/0x2c0 [snd_soc_core] +[ 48.435719] snd_soc_bind_card+0x4dc/0xcc0 [snd_soc_core] +[ 48.441278] snd_soc_add_component+0x27c/0x2c8 [snd_soc_core] +[ 48.447192] snd_soc_register_component+0x9c/0xf4 [snd_soc_core] +[ 48.453371] devm_snd_soc_register_component+0x64/0xc4 [snd_soc_core] +[ 48.459994] apm_probe+0xb4/0x110 [snd_q6apm] +[ 48.464479] apr_device_probe+0x24/0x40 [apr] +[ 48.468964] really_probe+0xbc/0x298 +[ 48.472651] __driver_probe_device+0x78/0x12c +[ 48.477132] driver_probe_device+0x40/0x160 +[ 48.481435] __device_attach_driver+0xb8/0x134 +[ 48.486011] bus_for_each_drv+0x80/0xdc +[ 48.489964] __device_attach+0xa8/0x1b0 +[ 48.493916] device_initial_probe+0x50/0x54 +[ 48.498219] bus_probe_device+0x38/0xa0 +[ 48.502170] device_add+0x590/0x760 +[ 48.505761] device_register+0x20/0x30 +[ 48.509623] of_register_apr_devices+0x1d8/0x318 [apr] +[ 48.514905] apr_pd_status+0x2c/0x54 [apr] +[ 48.519114] pdr_notifier_work+0x8c/0xe0 [pdr_interface] +[ 48.524570] process_one_work+0x150/0x294 +[ 48.528692] worker_thread+0x2d8/0x3d8 +[ 48.532551] kthread+0x130/0x204 +[ 48.535874] ret_from_fork+0x10/0x20 +[ 48.539559] Code: d65f03c0 d5384102 d503201f d2800001 (c8e17c02) +[ 48.545823] ---[ end trace 0000000000000000 ]--- + +Fixes: 5477518b8a0e ("ASoC: qdsp6: audioreach: add q6apm support") +Cc: stable@vger.kernel.org +Signed-off-by: Ravi Hothi +Reviewed-by: Srinivas Kandagatla +Link: https://patch.msgid.link/20260227144534.278568-1-ravi.hothi@oss.qualcomm.com +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman +--- + sound/soc/qcom/qdsp6/q6apm-dai.c | 1 + + sound/soc/qcom/qdsp6/q6apm-lpass-dais.c | 1 + + sound/soc/qcom/qdsp6/q6apm.c | 1 + + 3 files changed, 3 insertions(+) + +--- a/sound/soc/qcom/qdsp6/q6apm-dai.c ++++ b/sound/soc/qcom/qdsp6/q6apm-dai.c +@@ -841,6 +841,7 @@ static const struct snd_soc_component_dr + .ack = q6apm_dai_ack, + .compress_ops = &q6apm_dai_compress_ops, + .use_dai_pcm_id = true, ++ .remove_order = SND_SOC_COMP_ORDER_EARLY, + }; + + static int q6apm_dai_probe(struct platform_device *pdev) +--- a/sound/soc/qcom/qdsp6/q6apm-lpass-dais.c ++++ b/sound/soc/qcom/qdsp6/q6apm-lpass-dais.c +@@ -272,6 +272,7 @@ static const struct snd_soc_component_dr + .of_xlate_dai_name = q6dsp_audio_ports_of_xlate_dai_name, + .be_pcm_base = AUDIOREACH_BE_PCM_BASE, + .use_dai_pcm_id = true, ++ .remove_order = SND_SOC_COMP_ORDER_FIRST, + }; + + static int q6apm_lpass_dai_dev_probe(struct platform_device *pdev) +--- a/sound/soc/qcom/qdsp6/q6apm.c ++++ b/sound/soc/qcom/qdsp6/q6apm.c +@@ -732,6 +732,7 @@ static const struct snd_soc_component_dr + .name = APM_AUDIO_DRV_NAME, + .probe = q6apm_audio_probe, + .remove = q6apm_audio_remove, ++ .remove_order = SND_SOC_COMP_ORDER_LAST, + }; + + static int apm_probe(gpr_device_t *gdev) diff --git a/queue-6.6/ceph-fix-i_nlink-underrun-during-async-unlink.patch b/queue-6.6/ceph-fix-i_nlink-underrun-during-async-unlink.patch new file mode 100644 index 0000000000..8c52223d16 --- /dev/null +++ b/queue-6.6/ceph-fix-i_nlink-underrun-during-async-unlink.patch @@ -0,0 +1,121 @@ +From ce0123cbb4a40a2f1bbb815f292b26e96088639f Mon Sep 17 00:00:00 2001 +From: Max Kellermann +Date: Fri, 5 Sep 2025 23:15:30 +0200 +Subject: ceph: fix i_nlink underrun during async unlink + +From: Max Kellermann + +commit ce0123cbb4a40a2f1bbb815f292b26e96088639f upstream. + +During async unlink, we drop the `i_nlink` counter before we receive +the completion (that will eventually update the `i_nlink`) because "we +assume that the unlink will succeed". That is not a bad idea, but it +races against deletions by other clients (or against the completion of +our own unlink) and can lead to an underrun which emits a WARNING like +this one: + + WARNING: CPU: 85 PID: 25093 at fs/inode.c:407 drop_nlink+0x50/0x68 + Modules linked in: + CPU: 85 UID: 3221252029 PID: 25093 Comm: php-cgi8.1 Not tainted 6.14.11-cm4all1-ampere #655 + Hardware name: Supermicro ARS-110M-NR/R12SPD-A, BIOS 1.1b 10/17/2023 + pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) + pc : drop_nlink+0x50/0x68 + lr : ceph_unlink+0x6c4/0x720 + sp : ffff80012173bc90 + x29: ffff80012173bc90 x28: ffff086d0a45aaf8 x27: ffff0871d0eb5680 + x26: ffff087f2a64a718 x25: 0000020000000180 x24: 0000000061c88647 + x23: 0000000000000002 x22: ffff07ff9236d800 x21: 0000000000001203 + x20: ffff07ff9237b000 x19: ffff088b8296afc0 x18: 00000000f3c93365 + x17: 0000000000070000 x16: ffff08faffcbdfe8 x15: ffff08faffcbdfec + x14: 0000000000000000 x13: 45445f65645f3037 x12: 34385f6369706f74 + x11: 0000a2653104bb20 x10: ffffd85f26d73290 x9 : ffffd85f25664f94 + x8 : 00000000000000c0 x7 : 0000000000000000 x6 : 0000000000000002 + x5 : 0000000000000081 x4 : 0000000000000481 x3 : 0000000000000000 + x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff08727d3f91e8 + Call trace: + drop_nlink+0x50/0x68 (P) + vfs_unlink+0xb0/0x2e8 + do_unlinkat+0x204/0x288 + __arm64_sys_unlinkat+0x3c/0x80 + invoke_syscall.constprop.0+0x54/0xe8 + do_el0_svc+0xa4/0xc8 + el0_svc+0x18/0x58 + el0t_64_sync_handler+0x104/0x130 + el0t_64_sync+0x154/0x158 + +In ceph_unlink(), a call to ceph_mdsc_submit_request() submits the +CEPH_MDS_OP_UNLINK to the MDS, but does not wait for completion. + +Meanwhile, between this call and the following drop_nlink() call, a +worker thread may process a CEPH_CAP_OP_IMPORT, CEPH_CAP_OP_GRANT or +just a CEPH_MSG_CLIENT_REPLY (the latter of which could be our own +completion). These will lead to a set_nlink() call, updating the +`i_nlink` counter to the value received from the MDS. If that new +`i_nlink` value happens to be zero, it is illegal to decrement it +further. But that is exactly what ceph_unlink() will do then. + +The WARNING can be reproduced this way: + +1. Force async unlink; only the async code path is affected. Having + no real clue about Ceph internals, I was unable to find out why the + MDS wouldn't give me the "Fxr" capabilities, so I patched + get_caps_for_async_unlink() to always succeed. + + (Note that the WARNING dump above was found on an unpatched kernel, + without this kludge - this is not a theoretical bug.) + +2. Add a sleep call after ceph_mdsc_submit_request() so the unlink + completion gets handled by a worker thread before drop_nlink() is + called. This guarantees that the `i_nlink` is already zero before + drop_nlink() runs. + +The solution is to skip the counter decrement when it is already zero, +but doing so without a lock is still racy (TOCTOU). Since +ceph_fill_inode() and handle_cap_grant() both hold the +`ceph_inode_info.i_ceph_lock` spinlock while set_nlink() runs, this +seems like the proper lock to protect the `i_nlink` updates. + +I found prior art in NFS and SMB (using `inode.i_lock`) and AFS (using +`afs_vnode.cb_lock`). All three have the zero check as well. + +Cc: stable@vger.kernel.org +Fixes: 2ccb45462aea ("ceph: perform asynchronous unlink if we have sufficient caps") +Signed-off-by: Max Kellermann +Reviewed-by: Viacheslav Dubeyko +Signed-off-by: Ilya Dryomov +Signed-off-by: Greg Kroah-Hartman +--- + fs/ceph/dir.c | 15 ++++++++++++++- + 1 file changed, 14 insertions(+), 1 deletion(-) + +--- a/fs/ceph/dir.c ++++ b/fs/ceph/dir.c +@@ -1292,6 +1292,7 @@ static int ceph_unlink(struct inode *dir + struct ceph_fs_client *fsc = ceph_sb_to_fs_client(dir->i_sb); + struct ceph_mds_client *mdsc = fsc->mdsc; + struct inode *inode = d_inode(dentry); ++ struct ceph_inode_info *ci = ceph_inode(inode); + struct ceph_mds_request *req; + bool try_async = ceph_test_mount_opt(fsc, ASYNC_DIROPS); + int err = -EROFS; +@@ -1349,7 +1350,19 @@ retry: + * We have enough caps, so we assume that the unlink + * will succeed. Fix up the target inode and dcache. + */ +- drop_nlink(inode); ++ ++ /* ++ * Protect the i_nlink update with i_ceph_lock ++ * to precent racing against ceph_fill_inode() ++ * handling our completion on a worker thread ++ * and don't decrement if i_nlink has already ++ * been updated to zero by this completion. ++ */ ++ spin_lock(&ci->i_ceph_lock); ++ if (inode->i_nlink > 0) ++ drop_nlink(inode); ++ spin_unlock(&ci->i_ceph_lock); ++ + d_delete(dentry); + } else { + spin_lock(&fsc->async_unlink_conflict_lock); diff --git a/queue-6.6/ceph-fix-memory-leaks-in-ceph_mdsc_build_path.patch b/queue-6.6/ceph-fix-memory-leaks-in-ceph_mdsc_build_path.patch new file mode 100644 index 0000000000..10d45201b6 --- /dev/null +++ b/queue-6.6/ceph-fix-memory-leaks-in-ceph_mdsc_build_path.patch @@ -0,0 +1,51 @@ +From 040d159a45ded7f33201421a81df0aa2a86e5a0b Mon Sep 17 00:00:00 2001 +From: Max Kellermann +Date: Tue, 24 Feb 2026 14:26:57 +0100 +Subject: ceph: fix memory leaks in ceph_mdsc_build_path() + +From: Max Kellermann + +commit 040d159a45ded7f33201421a81df0aa2a86e5a0b upstream. + +Add __putname() calls to error code paths that did not free the "path" +pointer obtained by __getname(). If ownership of this pointer is not +passed to the caller via path_info.path, the function must free it +before returning. + +Cc: stable@vger.kernel.org +Fixes: 3fd945a79e14 ("ceph: encode encrypted name in ceph_mdsc_build_path and dentry release") +Fixes: 550f7ca98ee0 ("ceph: give up on paths longer than PATH_MAX") +Signed-off-by: Max Kellermann +Reviewed-by: Viacheslav Dubeyko +Signed-off-by: Ilya Dryomov +Signed-off-by: Greg Kroah-Hartman +--- + fs/ceph/mds_client.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/fs/ceph/mds_client.c ++++ b/fs/ceph/mds_client.c +@@ -2672,6 +2672,7 @@ retry: + if (ret < 0) { + dput(parent); + dput(cur); ++ __putname(path); + return ERR_PTR(ret); + } + +@@ -2681,6 +2682,7 @@ retry: + if (len < 0) { + dput(parent); + dput(cur); ++ __putname(path); + return ERR_PTR(len); + } + } +@@ -2717,6 +2719,7 @@ retry: + * cannot ever succeed. Creating paths that long is + * possible with Ceph, but Linux cannot use them. + */ ++ __putname(path); + return ERR_PTR(-ENAMETOOLONG); + } + diff --git a/queue-6.6/kprobes-avoid-crash-when-rmmod-insmod-after-ftrace-killed.patch b/queue-6.6/kprobes-avoid-crash-when-rmmod-insmod-after-ftrace-killed.patch new file mode 100644 index 0000000000..c9e18ccf3d --- /dev/null +++ b/queue-6.6/kprobes-avoid-crash-when-rmmod-insmod-after-ftrace-killed.patch @@ -0,0 +1,67 @@ +From e113f0b46d19626ec15388bcb91432c9a4fd6261 Mon Sep 17 00:00:00 2001 +From: "Masami Hiramatsu (Google)" +Date: Fri, 13 Mar 2026 23:14:14 +0900 +Subject: kprobes: avoid crash when rmmod/insmod after ftrace killed + +From: Masami Hiramatsu (Google) + +commit e113f0b46d19626ec15388bcb91432c9a4fd6261 upstream. + +After we hit ftrace is killed by some errors, the kernel crash if +we remove modules in which kprobe probes. + +BUG: unable to handle page fault for address: fffffbfff805000d +PGD 817fcc067 P4D 817fcc067 PUD 817fc8067 PMD 101555067 PTE 0 +Oops: Oops: 0000 [#1] SMP KASAN PTI +CPU: 4 UID: 0 PID: 2012 Comm: rmmod Tainted: G W OE +Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE +RIP: 0010:kprobes_module_callback+0x89/0x790 +RSP: 0018:ffff88812e157d30 EFLAGS: 00010a02 +RAX: 1ffffffff805000d RBX: dffffc0000000000 RCX: ffffffff86a8de90 +RDX: ffffed1025c2af9b RSI: 0000000000000008 RDI: ffffffffc0280068 +RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed1025c2af9a +R10: ffff88812e157cd7 R11: 205d323130325420 R12: 0000000000000002 +R13: ffffffffc0290488 R14: 0000000000000002 R15: ffffffffc0280040 +FS: 00007fbc450dd740(0000) GS:ffff888420331000(0000) knlGS:0000000000000000 +CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +CR2: fffffbfff805000d CR3: 000000010f624000 CR4: 00000000000006f0 +Call Trace: + + notifier_call_chain+0xc6/0x280 + blocking_notifier_call_chain+0x60/0x90 + __do_sys_delete_module.constprop.0+0x32a/0x4e0 + do_syscall_64+0x5d/0xfa0 + entry_SYSCALL_64_after_hwframe+0x76/0x7e + +This is because the kprobe on ftrace does not correctly handles +the kprobe_ftrace_disabled flag set by ftrace_kill(). + +To prevent this error, check kprobe_ftrace_disabled in +__disarm_kprobe_ftrace() and skip all ftrace related operations. + +Link: https://lore.kernel.org/all/176473947565.1727781.13110060700668331950.stgit@mhiramat.tok.corp.google.com/ + +Reported-by: Ye Bin +Closes: https://lore.kernel.org/all/20251125020536.2484381-1-yebin@huaweicloud.com/ +Fixes: ae6aa16fdc16 ("kprobes: introduce ftrace based optimization") +Cc: stable@vger.kernel.org +Signed-off-by: Masami Hiramatsu (Google) +Acked-by: Steven Rostedt (Google) +Signed-off-by: Greg Kroah-Hartman +--- + kernel/kprobes.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/kernel/kprobes.c ++++ b/kernel/kprobes.c +@@ -1114,6 +1114,10 @@ static int __disarm_kprobe_ftrace(struct + int ret; + + lockdep_assert_held(&kprobe_mutex); ++ if (unlikely(kprobe_ftrace_disabled)) { ++ /* Now ftrace is disabled forever, disarm is already done. */ ++ return 0; ++ } + + if (*cnt == 1) { + ret = unregister_ftrace_function(ops); diff --git a/queue-6.6/libceph-admit-message-frames-only-in-ceph_con_s_open-state.patch b/queue-6.6/libceph-admit-message-frames-only-in-ceph_con_s_open-state.patch new file mode 100644 index 0000000000..667cf53ea7 --- /dev/null +++ b/queue-6.6/libceph-admit-message-frames-only-in-ceph_con_s_open-state.patch @@ -0,0 +1,37 @@ +From a5a373705081d7cc6363e16990e2361b0b362314 Mon Sep 17 00:00:00 2001 +From: Ilya Dryomov +Date: Sun, 8 Mar 2026 17:57:23 +0100 +Subject: libceph: admit message frames only in CEPH_CON_S_OPEN state + +From: Ilya Dryomov + +commit a5a373705081d7cc6363e16990e2361b0b362314 upstream. + +Similar checks are performed for all control frames, but an early check +for message frames was missing. process_message() is already set up to +terminate the loop in case the state changes while con->ops->dispatch() +handler is being executed. + +Cc: stable@vger.kernel.org +Signed-off-by: Ilya Dryomov +Reviewed-by: Alex Markuze +Reviewed-by: Viacheslav Dubeyko +Signed-off-by: Greg Kroah-Hartman +--- + net/ceph/messenger_v2.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/net/ceph/messenger_v2.c ++++ b/net/ceph/messenger_v2.c +@@ -2940,6 +2940,11 @@ static int __handle_control(struct ceph_ + if (con->v2.in_desc.fd_tag != FRAME_TAG_MESSAGE) + return process_control(con, p, end); + ++ if (con->state != CEPH_CON_S_OPEN) { ++ con->error_msg = "protocol error, unexpected message"; ++ return -EINVAL; ++ } ++ + ret = process_message_header(con, p, end); + if (ret < 0) + return ret; diff --git a/queue-6.6/libceph-fix-potential-out-of-bounds-access-in-ceph_handle_auth_reply.patch b/queue-6.6/libceph-fix-potential-out-of-bounds-access-in-ceph_handle_auth_reply.patch new file mode 100644 index 0000000000..39635615a1 --- /dev/null +++ b/queue-6.6/libceph-fix-potential-out-of-bounds-access-in-ceph_handle_auth_reply.patch @@ -0,0 +1,122 @@ +From b282c43ed156ae15ea76748fc15cd5c39dc9ab72 Mon Sep 17 00:00:00 2001 +From: Raphael Zimmer +Date: Tue, 10 Mar 2026 15:28:15 +0100 +Subject: libceph: Fix potential out-of-bounds access in ceph_handle_auth_reply() + +From: Raphael Zimmer + +commit b282c43ed156ae15ea76748fc15cd5c39dc9ab72 upstream. + +This patch fixes an out-of-bounds access in ceph_handle_auth_reply() +that can be triggered by a message of type CEPH_MSG_AUTH_REPLY. In +ceph_handle_auth_reply(), the value of the payload_len field of such a +message is stored in a variable of type int. A value greater than +INT_MAX leads to an integer overflow and is interpreted as a negative +value. This leads to decrementing the pointer address by this value and +subsequently accessing it because ceph_decode_need() only checks that +the memory access does not exceed the end address of the allocation. + +This patch fixes the issue by changing the data type of payload_len to +u32. Additionally, the data type of result_msg_len is changed to u32, +as it is also a variable holding a non-negative length. + +Also, an additional layer of sanity checks is introduced, ensuring that +directly after reading it from the message, payload_len and +result_msg_len are not greater than the overall segment length. + +BUG: KASAN: slab-out-of-bounds in ceph_handle_auth_reply+0x642/0x7a0 [libceph] +Read of size 4 at addr ffff88811404df14 by task kworker/20:1/262 + +CPU: 20 UID: 0 PID: 262 Comm: kworker/20:1 Not tainted 6.19.2 #5 PREEMPT(voluntary) +Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 +Workqueue: ceph-msgr ceph_con_workfn [libceph] +Call Trace: + + dump_stack_lvl+0x76/0xa0 + print_report+0xd1/0x620 + ? __pfx__raw_spin_lock_irqsave+0x10/0x10 + ? kasan_complete_mode_report_info+0x72/0x210 + kasan_report+0xe7/0x130 + ? ceph_handle_auth_reply+0x642/0x7a0 [libceph] + ? ceph_handle_auth_reply+0x642/0x7a0 [libceph] + __asan_report_load_n_noabort+0xf/0x20 + ceph_handle_auth_reply+0x642/0x7a0 [libceph] + mon_dispatch+0x973/0x23d0 [libceph] + ? apparmor_socket_recvmsg+0x6b/0xa0 + ? __pfx_mon_dispatch+0x10/0x10 [libceph] + ? __kasan_check_write+0x14/0x30i + ? mutex_unlock+0x7f/0xd0 + ? __pfx_mutex_unlock+0x10/0x10 + ? __pfx_do_recvmsg+0x10/0x10 [libceph] + ceph_con_process_message+0x1f1/0x650 [libceph] + process_message+0x1e/0x450 [libceph] + ceph_con_v2_try_read+0x2e48/0x6c80 [libceph] + ? __pfx_ceph_con_v2_try_read+0x10/0x10 [libceph] + ? save_fpregs_to_fpstate+0xb0/0x230 + ? raw_spin_rq_unlock+0x17/0xa0 + ? finish_task_switch.isra.0+0x13b/0x760 + ? __switch_to+0x385/0xda0 + ? __kasan_check_write+0x14/0x30 + ? mutex_lock+0x8d/0xe0 + ? __pfx_mutex_lock+0x10/0x10 + ceph_con_workfn+0x248/0x10c0 [libceph] + process_one_work+0x629/0xf80 + ? __kasan_check_write+0x14/0x30 + worker_thread+0x87f/0x1570 + ? __pfx__raw_spin_lock_irqsave+0x10/0x10 + ? __pfx_try_to_wake_up+0x10/0x10 + ? kasan_print_address_stack_frame+0x1f7/0x280 + ? __pfx_worker_thread+0x10/0x10 + kthread+0x396/0x830 + ? __pfx__raw_spin_lock_irq+0x10/0x10 + ? __pfx_kthread+0x10/0x10 + ? __kasan_check_write+0x14/0x30 + ? recalc_sigpending+0x180/0x210 + ? __pfx_kthread+0x10/0x10 + ret_from_fork+0x3f7/0x610 + ? __pfx_ret_from_fork+0x10/0x10 + ? __switch_to+0x385/0xda0 + ? __pfx_kthread+0x10/0x10 + ret_from_fork_asm+0x1a/0x30 + + +[ idryomov: replace if statements with ceph_decode_need() for + payload_len and result_msg_len ] + +Cc: stable@vger.kernel.org +Signed-off-by: Raphael Zimmer +Reviewed-by: Viacheslav Dubeyko +Reviewed-by: Ilya Dryomov +Signed-off-by: Ilya Dryomov +Signed-off-by: Greg Kroah-Hartman +--- + net/ceph/auth.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/net/ceph/auth.c ++++ b/net/ceph/auth.c +@@ -205,9 +205,9 @@ int ceph_handle_auth_reply(struct ceph_a + s32 result; + u64 global_id; + void *payload, *payload_end; +- int payload_len; ++ u32 payload_len; + char *result_msg; +- int result_msg_len; ++ u32 result_msg_len; + int ret = -EINVAL; + + mutex_lock(&ac->mutex); +@@ -217,10 +217,12 @@ int ceph_handle_auth_reply(struct ceph_a + result = ceph_decode_32(&p); + global_id = ceph_decode_64(&p); + payload_len = ceph_decode_32(&p); ++ ceph_decode_need(&p, end, payload_len, bad); + payload = p; + p += payload_len; + ceph_decode_need(&p, end, sizeof(u32), bad); + result_msg_len = ceph_decode_32(&p); ++ ceph_decode_need(&p, end, result_msg_len, bad); + result_msg = p; + p += result_msg_len; + if (p != end) diff --git a/queue-6.6/libceph-prevent-potential-out-of-bounds-reads-in-process_message_header.patch b/queue-6.6/libceph-prevent-potential-out-of-bounds-reads-in-process_message_header.patch new file mode 100644 index 0000000000..44bceedb7c --- /dev/null +++ b/queue-6.6/libceph-prevent-potential-out-of-bounds-reads-in-process_message_header.patch @@ -0,0 +1,56 @@ +From 69fb5d91bba44ecf7eb80530b85fa4fb028921d5 Mon Sep 17 00:00:00 2001 +From: Ilya Dryomov +Date: Sun, 8 Mar 2026 17:38:00 +0100 +Subject: libceph: prevent potential out-of-bounds reads in process_message_header() + +From: Ilya Dryomov + +commit 69fb5d91bba44ecf7eb80530b85fa4fb028921d5 upstream. + +If the message frame is (maliciously) corrupted in a way that the +length of the control segment ends up being less than the size of the +message header or a different frame is made to look like a message +frame, out-of-bounds reads may ensue in process_message_header(). + +Perform an explicit bounds check before decoding the message header. + +Cc: stable@vger.kernel.org +Reported-by: Raphael Zimmer +Signed-off-by: Ilya Dryomov +Reviewed-by: Alex Markuze +Reviewed-by: Viacheslav Dubeyko +Signed-off-by: Greg Kroah-Hartman +--- + net/ceph/messenger_v2.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +--- a/net/ceph/messenger_v2.c ++++ b/net/ceph/messenger_v2.c +@@ -2868,12 +2868,15 @@ static int process_message_header(struct + void *p, void *end) + { + struct ceph_frame_desc *desc = &con->v2.in_desc; +- struct ceph_msg_header2 *hdr2 = p; ++ struct ceph_msg_header2 *hdr2; + struct ceph_msg_header hdr; + int skip; + int ret; + u64 seq; + ++ ceph_decode_need(&p, end, sizeof(*hdr2), bad); ++ hdr2 = p; ++ + /* verify seq# */ + seq = le64_to_cpu(hdr2->seq); + if ((s64)seq - (s64)con->in_seq < 1) { +@@ -2904,6 +2907,10 @@ static int process_message_header(struct + WARN_ON(!con->in_msg); + WARN_ON(con->in_msg->con != con); + return 1; ++ ++bad: ++ pr_err("failed to decode message header\n"); ++ return -EINVAL; + } + + static int process_message(struct ceph_connection *con) diff --git a/queue-6.6/libceph-reject-preamble-if-control-segment-is-empty.patch b/queue-6.6/libceph-reject-preamble-if-control-segment-is-empty.patch new file mode 100644 index 0000000000..3440362797 --- /dev/null +++ b/queue-6.6/libceph-reject-preamble-if-control-segment-is-empty.patch @@ -0,0 +1,74 @@ +From c4c22b846eceff05b1129b8844a80310e55a7f87 Mon Sep 17 00:00:00 2001 +From: Ilya Dryomov +Date: Sun, 8 Mar 2026 20:01:27 +0100 +Subject: libceph: reject preamble if control segment is empty + +From: Ilya Dryomov + +commit c4c22b846eceff05b1129b8844a80310e55a7f87 upstream. + +While head_onwire_len() has a branch to handle ctrl_len == 0 case, +prepare_read_control() always sets up a kvec for the CRC meaning that +a non-empty control segment is effectively assumed. All frames that +clients deal with meet that assumption, so let's make it official and +treat the preamble with an empty control segment as malformed. + +Cc: stable@vger.kernel.org +Signed-off-by: Ilya Dryomov +Reviewed-by: Alex Markuze +Signed-off-by: Greg Kroah-Hartman +--- + net/ceph/messenger_v2.c | 17 ++++++++--------- + 1 file changed, 8 insertions(+), 9 deletions(-) + +--- a/net/ceph/messenger_v2.c ++++ b/net/ceph/messenger_v2.c +@@ -392,7 +392,7 @@ static int head_onwire_len(int ctrl_len, + int head_len; + int rem_len; + +- BUG_ON(ctrl_len < 0 || ctrl_len > CEPH_MSG_MAX_CONTROL_LEN); ++ BUG_ON(ctrl_len < 1 || ctrl_len > CEPH_MSG_MAX_CONTROL_LEN); + + if (secure) { + head_len = CEPH_PREAMBLE_SECURE_LEN; +@@ -401,9 +401,7 @@ static int head_onwire_len(int ctrl_len, + head_len += padded_len(rem_len) + CEPH_GCM_TAG_LEN; + } + } else { +- head_len = CEPH_PREAMBLE_PLAIN_LEN; +- if (ctrl_len) +- head_len += ctrl_len + CEPH_CRC_LEN; ++ head_len = CEPH_PREAMBLE_PLAIN_LEN + ctrl_len + CEPH_CRC_LEN; + } + return head_len; + } +@@ -528,11 +526,16 @@ static int decode_preamble(void *p, stru + desc->fd_aligns[i] = ceph_decode_16(&p); + } + +- if (desc->fd_lens[0] < 0 || ++ /* ++ * This would fire for FRAME_TAG_WAIT (it has one empty ++ * segment), but we should never get it as client. ++ */ ++ if (desc->fd_lens[0] < 1 || + desc->fd_lens[0] > CEPH_MSG_MAX_CONTROL_LEN) { + pr_err("bad control segment length %d\n", desc->fd_lens[0]); + return -EINVAL; + } ++ + if (desc->fd_lens[1] < 0 || + desc->fd_lens[1] > CEPH_MSG_MAX_FRONT_LEN) { + pr_err("bad front segment length %d\n", desc->fd_lens[1]); +@@ -549,10 +552,6 @@ static int decode_preamble(void *p, stru + return -EINVAL; + } + +- /* +- * This would fire for FRAME_TAG_WAIT (it has one empty +- * segment), but we should never get it as client. +- */ + if (!desc->fd_lens[desc->fd_seg_cnt - 1]) { + pr_err("last segment empty, segment count %d\n", + desc->fd_seg_cnt); diff --git a/queue-6.6/libceph-use-u32-for-non-negative-values-in-ceph_monmap_decode.patch b/queue-6.6/libceph-use-u32-for-non-negative-values-in-ceph_monmap_decode.patch new file mode 100644 index 0000000000..904b0f20f9 --- /dev/null +++ b/queue-6.6/libceph-use-u32-for-non-negative-values-in-ceph_monmap_decode.patch @@ -0,0 +1,56 @@ +From 770444611f047dbfd4517ec0bc1b179d40c2f346 Mon Sep 17 00:00:00 2001 +From: Raphael Zimmer +Date: Thu, 26 Feb 2026 16:07:31 +0100 +Subject: libceph: Use u32 for non-negative values in ceph_monmap_decode() + +From: Raphael Zimmer + +commit 770444611f047dbfd4517ec0bc1b179d40c2f346 upstream. + +This patch fixes unnecessary implicit conversions that change signedness +of blob_len and num_mon in ceph_monmap_decode(). +Currently blob_len and num_mon are (signed) int variables. They are used +to hold values that are always non-negative and get assigned in +ceph_decode_32_safe(), which is meant to assign u32 values. Both +variables are subsequently used as unsigned values, and the value of +num_mon is further assigned to monmap->num_mon, which is of type u32. +Therefore, both variables should be of type u32. This is especially +relevant for num_mon. If the value read from the incoming message is +very large, it is interpreted as a negative value, and the check for +num_mon > CEPH_MAX_MON does not catch it. This leads to the attempt to +allocate a very large chunk of memory for monmap, which will most likely +fail. In this case, an unnecessary attempt to allocate memory is +performed, and -ENOMEM is returned instead of -EINVAL. + +Cc: stable@vger.kernel.org +Signed-off-by: Raphael Zimmer +Reviewed-by: Viacheslav Dubeyko +Reviewed-by: Ilya Dryomov +Signed-off-by: Ilya Dryomov +Signed-off-by: Greg Kroah-Hartman +--- + net/ceph/mon_client.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/net/ceph/mon_client.c ++++ b/net/ceph/mon_client.c +@@ -72,8 +72,8 @@ static struct ceph_monmap *ceph_monmap_d + struct ceph_monmap *monmap = NULL; + struct ceph_fsid fsid; + u32 struct_len; +- int blob_len; +- int num_mon; ++ u32 blob_len; ++ u32 num_mon; + u8 struct_v; + u32 epoch; + int ret; +@@ -112,7 +112,7 @@ static struct ceph_monmap *ceph_monmap_d + } + ceph_decode_32_safe(p, end, num_mon, e_inval); + +- dout("%s fsid %pU epoch %u num_mon %d\n", __func__, &fsid, epoch, ++ dout("%s fsid %pU epoch %u num_mon %u\n", __func__, &fsid, epoch, + num_mon); + if (num_mon > CEPH_MAX_MON) + goto e_inval; diff --git a/queue-6.6/mm-kfence-disable-kfence-upon-kasan-hw-tags-enablement.patch b/queue-6.6/mm-kfence-disable-kfence-upon-kasan-hw-tags-enablement.patch new file mode 100644 index 0000000000..1f4fbdd93e --- /dev/null +++ b/queue-6.6/mm-kfence-disable-kfence-upon-kasan-hw-tags-enablement.patch @@ -0,0 +1,67 @@ +From 09833d99db36d74456a4d13eb29c32d56ff8f2b6 Mon Sep 17 00:00:00 2001 +From: Alexander Potapenko +Date: Fri, 13 Feb 2026 10:54:10 +0100 +Subject: mm/kfence: disable KFENCE upon KASAN HW tags enablement + +From: Alexander Potapenko + +commit 09833d99db36d74456a4d13eb29c32d56ff8f2b6 upstream. + +KFENCE does not currently support KASAN hardware tags. As a result, the +two features are incompatible when enabled simultaneously. + +Given that MTE provides deterministic protection and KFENCE is a +sampling-based debugging tool, prioritize the stronger hardware +protections. Disable KFENCE initialization and free the pre-allocated +pool if KASAN hardware tags are detected to ensure the system maintains +the security guarantees provided by MTE. + +Link: https://lkml.kernel.org/r/20260213095410.1862978-1-glider@google.com +Fixes: 0ce20dd84089 ("mm: add Kernel Electric-Fence infrastructure") +Signed-off-by: Alexander Potapenko +Suggested-by: Marco Elver +Reviewed-by: Marco Elver +Cc: Andrey Konovalov +Cc: Andrey Ryabinin +Cc: Dmitry Vyukov +Cc: Ernesto Martinez Garcia +Cc: Greg KH +Cc: Kees Cook +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + mm/kfence/core.c | 15 +++++++++++++++ + 1 file changed, 15 insertions(+) + +--- a/mm/kfence/core.c ++++ b/mm/kfence/core.c +@@ -13,6 +13,7 @@ + #include + #include + #include ++#include + #include + #include + #include +@@ -862,6 +863,20 @@ void __init kfence_alloc_pool_and_metada + return; + + /* ++ * If KASAN hardware tags are enabled, disable KFENCE, because it ++ * does not support MTE yet. ++ */ ++ if (kasan_hw_tags_enabled()) { ++ pr_info("disabled as KASAN HW tags are enabled\n"); ++ if (__kfence_pool) { ++ memblock_free(__kfence_pool, KFENCE_POOL_SIZE); ++ __kfence_pool = NULL; ++ } ++ kfence_sample_interval = 0; ++ return; ++ } ++ ++ /* + * If the pool has already been initialized by arch, there is no need to + * re-allocate the memory pool. + */ diff --git a/queue-6.6/mm-tracing-rss_stat-ensure-curr-is-false-from-kthread-context.patch b/queue-6.6/mm-tracing-rss_stat-ensure-curr-is-false-from-kthread-context.patch new file mode 100644 index 0000000000..22ecdbd673 --- /dev/null +++ b/queue-6.6/mm-tracing-rss_stat-ensure-curr-is-false-from-kthread-context.patch @@ -0,0 +1,79 @@ +From 079c24d5690262e83ee476e2a548e416f3237511 Mon Sep 17 00:00:00 2001 +From: Kalesh Singh +Date: Thu, 19 Feb 2026 15:36:56 -0800 +Subject: mm/tracing: rss_stat: ensure curr is false from kthread context + +From: Kalesh Singh + +commit 079c24d5690262e83ee476e2a548e416f3237511 upstream. + +The rss_stat trace event allows userspace tools, like Perfetto [1], to +inspect per-process RSS metric changes over time. + +The curr field was introduced to rss_stat in commit e4dcad204d3a +("rss_stat: add support to detect RSS updates of external mm"). Its +intent is to indicate whether the RSS update is for the mm_struct of the +current execution context; and is set to false when operating on a remote +mm_struct (e.g., via kswapd or a direct reclaimer). + +However, an issue arises when a kernel thread temporarily adopts a user +process's mm_struct. Kernel threads do not have their own mm_struct and +normally have current->mm set to NULL. To operate on user memory, they +can "borrow" a memory context using kthread_use_mm(), which sets +current->mm to the user process's mm. + +This can be observed, for example, in the USB Function Filesystem (FFS) +driver. The ffs_user_copy_worker() handles AIO completions and uses +kthread_use_mm() to copy data to a user-space buffer. If a page fault +occurs during this copy, the fault handler executes in the kthread's +context. + +At this point, current is the kthread, but current->mm points to the user +process's mm. Since the rss_stat event (from the page fault) is for that +same mm, the condition current->mm == mm becomes true, causing curr to be +incorrectly set to true when the trace event is emitted. + +This is misleading because it suggests the mm belongs to the kthread, +confusing userspace tools that track per-process RSS changes and +corrupting their mm_id-to-process association. + +Fix this by ensuring curr is always false when the trace event is emitted +from a kthread context by checking for the PF_KTHREAD flag. + +Link: https://lkml.kernel.org/r/20260219233708.1971199-1-kaleshsingh@google.com +Link: https://perfetto.dev/ [1] +Fixes: e4dcad204d3a ("rss_stat: add support to detect RSS updates of external mm") +Signed-off-by: Kalesh Singh +Acked-by: Zi Yan +Acked-by: SeongJae Park +Reviewed-by: Pedro Falcato +Cc: "David Hildenbrand (Arm)" +Cc: Joel Fernandes +Cc: Lorenzo Stoakes +Cc: Minchan Kim +Cc: Steven Rostedt +Cc: Suren Baghdasaryan +Cc: [5.10+] +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + include/trace/events/kmem.h | 8 +++++++- + 1 file changed, 7 insertions(+), 1 deletion(-) + +--- a/include/trace/events/kmem.h ++++ b/include/trace/events/kmem.h +@@ -359,7 +359,13 @@ TRACE_EVENT(rss_stat, + + TP_fast_assign( + __entry->mm_id = mm_ptr_to_hash(mm); +- __entry->curr = !!(current->mm == mm); ++ /* ++ * curr is true if the mm matches the current task's mm_struct. ++ * Since kthreads (PF_KTHREAD) have no mm_struct of their own ++ * but can borrow one via kthread_use_mm(), we must filter them ++ * out to avoid incorrectly attributing the RSS update to them. ++ */ ++ __entry->curr = current->mm == mm && !(current->flags & PF_KTHREAD); + __entry->member = member; + __entry->size = (percpu_counter_sum_positive(&mm->rss_stat[member]) + << PAGE_SHIFT); diff --git a/queue-6.6/mmc-core-avoid-bitfield-rmw-for-claim-retune-flags.patch b/queue-6.6/mmc-core-avoid-bitfield-rmw-for-claim-retune-flags.patch new file mode 100644 index 0000000000..02c84f88a9 --- /dev/null +++ b/queue-6.6/mmc-core-avoid-bitfield-rmw-for-claim-retune-flags.patch @@ -0,0 +1,59 @@ +From 901084c51a0a8fb42a3f37d2e9c62083c495f824 Mon Sep 17 00:00:00 2001 +From: Penghe Geng +Date: Thu, 19 Feb 2026 15:29:54 -0500 +Subject: mmc: core: Avoid bitfield RMW for claim/retune flags + +From: Penghe Geng + +commit 901084c51a0a8fb42a3f37d2e9c62083c495f824 upstream. + +Move claimed and retune control flags out of the bitfield word to +avoid unrelated RMW side effects in asynchronous contexts. + +The host->claimed bit shared a word with retune flags. Writes to claimed +in __mmc_claim_host() or retune_now in mmc_mq_queue_rq() can overwrite +other bits when concurrent updates happen in other contexts, triggering +spurious WARN_ON(!host->claimed). Convert claimed, can_retune, +retune_now and retune_paused to bool to remove shared-word coupling. + +Fixes: 6c0cedd1ef952 ("mmc: core: Introduce host claiming by context") +Fixes: 1e8e55b67030c ("mmc: block: Add CQE support") +Cc: stable@vger.kernel.org +Suggested-by: Adrian Hunter +Signed-off-by: Penghe Geng +Acked-by: Adrian Hunter +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + include/linux/mmc/host.h | 9 +++++---- + 1 file changed, 5 insertions(+), 4 deletions(-) + +--- a/include/linux/mmc/host.h ++++ b/include/linux/mmc/host.h +@@ -446,14 +446,12 @@ struct mmc_host { + + struct mmc_ios ios; /* current io bus settings */ + ++ bool claimed; /* host exclusively claimed */ ++ + /* group bitfields together to minimize padding */ + unsigned int use_spi_crc:1; +- unsigned int claimed:1; /* host exclusively claimed */ + unsigned int doing_init_tune:1; /* initial tuning in progress */ +- unsigned int can_retune:1; /* re-tuning can be used */ + unsigned int doing_retune:1; /* re-tuning in progress */ +- unsigned int retune_now:1; /* do re-tuning at next req */ +- unsigned int retune_paused:1; /* re-tuning is temporarily disabled */ + unsigned int retune_crc_disable:1; /* don't trigger retune upon crc */ + unsigned int can_dma_map_merge:1; /* merging can be used */ + unsigned int vqmmc_enabled:1; /* vqmmc regulator is enabled */ +@@ -461,6 +459,9 @@ struct mmc_host { + int rescan_disable; /* disable card detection */ + int rescan_entered; /* used with nonremovable devices */ + ++ bool can_retune; /* re-tuning can be used */ ++ bool retune_now; /* do re-tuning at next req */ ++ bool retune_paused; /* re-tuning is temporarily disabled */ + int need_retune; /* re-tuning is needed */ + int hold_retune; /* hold off re-tuning */ + unsigned int retune_period; /* re-tuning period in secs */ diff --git a/queue-6.6/mmc-mmci-fix-device_node-reference-leak-in-of_get_dml_pipe_index.patch b/queue-6.6/mmc-mmci-fix-device_node-reference-leak-in-of_get_dml_pipe_index.patch new file mode 100644 index 0000000000..22233f3dc2 --- /dev/null +++ b/queue-6.6/mmc-mmci-fix-device_node-reference-leak-in-of_get_dml_pipe_index.patch @@ -0,0 +1,32 @@ +From af12e64ae0661546e8b4f5d30d55c5f53a11efe7 Mon Sep 17 00:00:00 2001 +From: Felix Gu +Date: Tue, 20 Jan 2026 22:26:46 +0800 +Subject: mmc: mmci: Fix device_node reference leak in of_get_dml_pipe_index() + +From: Felix Gu + +commit af12e64ae0661546e8b4f5d30d55c5f53a11efe7 upstream. + +When calling of_parse_phandle_with_args(), the caller is responsible +to call of_node_put() to release the reference of device node. +In of_get_dml_pipe_index(), it does not release the reference. + +Fixes: 9cb15142d0e3 ("mmc: mmci: Add qcom dml support to the driver.") +Signed-off-by: Felix Gu +Cc: stable@vger.kernel.org +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mmc/host/mmci_qcom_dml.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/mmc/host/mmci_qcom_dml.c ++++ b/drivers/mmc/host/mmci_qcom_dml.c +@@ -109,6 +109,7 @@ static int of_get_dml_pipe_index(struct + &dma_spec)) + return -ENODEV; + ++ of_node_put(dma_spec.np); + if (dma_spec.args_count) + return dma_spec.args[0]; + diff --git a/queue-6.6/series b/queue-6.6/series index 0e882198e3..0340fe29de 100644 --- a/queue-6.6/series +++ b/queue-6.6/series @@ -284,3 +284,17 @@ usb-class-cdc-wdm-fix-reordering-issue-in-read-code-path.patch usb-renesas_usbhs-fix-use-after-free-in-isr-during-device-removal.patch usb-mdc800-handle-signal-and-read-racing.patch usb-image-mdc800-kill-download-urb-on-timeout.patch +mm-tracing-rss_stat-ensure-curr-is-false-from-kthread-context.patch +mmc-mmci-fix-device_node-reference-leak-in-of_get_dml_pipe_index.patch +mm-kfence-disable-kfence-upon-kasan-hw-tags-enablement.patch +mmc-core-avoid-bitfield-rmw-for-claim-retune-flags.patch +asoc-qcom-qdsp6-fix-q6apm-remove-ordering-during-adsp-stop-and-start.patch +tipc-fix-divide-by-zero-in-tipc_sk_filter_connect.patch +kprobes-avoid-crash-when-rmmod-insmod-after-ftrace-killed.patch +libceph-fix-potential-out-of-bounds-access-in-ceph_handle_auth_reply.patch +libceph-reject-preamble-if-control-segment-is-empty.patch +libceph-prevent-potential-out-of-bounds-reads-in-process_message_header.patch +libceph-use-u32-for-non-negative-values-in-ceph_monmap_decode.patch +libceph-admit-message-frames-only-in-ceph_con_s_open-state.patch +ceph-fix-i_nlink-underrun-during-async-unlink.patch +ceph-fix-memory-leaks-in-ceph_mdsc_build_path.patch diff --git a/queue-6.6/tipc-fix-divide-by-zero-in-tipc_sk_filter_connect.patch b/queue-6.6/tipc-fix-divide-by-zero-in-tipc_sk_filter_connect.patch new file mode 100644 index 0000000000..96ed02e37c --- /dev/null +++ b/queue-6.6/tipc-fix-divide-by-zero-in-tipc_sk_filter_connect.patch @@ -0,0 +1,55 @@ +From 6c5a9baa15de240e747263aba435a0951da8d8d2 Mon Sep 17 00:00:00 2001 +From: Mehul Rao +Date: Tue, 10 Mar 2026 13:07:30 -0400 +Subject: tipc: fix divide-by-zero in tipc_sk_filter_connect() + +From: Mehul Rao + +commit 6c5a9baa15de240e747263aba435a0951da8d8d2 upstream. + +A user can set conn_timeout to any value via +setsockopt(TIPC_CONN_TIMEOUT), including values less than 4. When a +SYN is rejected with TIPC_ERR_OVERLOAD and the retry path in +tipc_sk_filter_connect() executes: + + delay %= (tsk->conn_timeout / 4); + +If conn_timeout is in the range [0, 3], the integer division yields 0, +and the modulo operation triggers a divide-by-zero exception, causing a +kernel oops/panic. + +Fix this by clamping conn_timeout to a minimum of 4 at the point of use +in tipc_sk_filter_connect(). + +Oops: divide error: 0000 [#1] SMP KASAN NOPTI +CPU: 0 UID: 0 PID: 119 Comm: poc-F144 Not tainted 7.0.0-rc2+ +RIP: 0010:tipc_sk_filter_rcv (net/tipc/socket.c:2236 net/tipc/socket.c:2362) +Call Trace: + tipc_sk_backlog_rcv (include/linux/instrumented.h:82 include/linux/atomic/atomic-instrumented.h:32 include/net/sock.h:2357 net/tipc/socket.c:2406) + __release_sock (include/net/sock.h:1185 net/core/sock.c:3213) + release_sock (net/core/sock.c:3797) + tipc_connect (net/tipc/socket.c:2570) + __sys_connect (include/linux/file.h:62 include/linux/file.h:83 net/socket.c:2098) + +Fixes: 6787927475e5 ("tipc: buffer overflow handling in listener socket") +Cc: stable@vger.kernel.org +Signed-off-by: Mehul Rao +Reviewed-by: Tung Nguyen +Link: https://patch.msgid.link/20260310170730.28841-1-mehulrao@gmail.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/tipc/socket.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/net/tipc/socket.c ++++ b/net/tipc/socket.c +@@ -2238,6 +2238,8 @@ static bool tipc_sk_filter_connect(struc + if (skb_queue_empty(&sk->sk_write_queue)) + break; + get_random_bytes(&delay, 2); ++ if (tsk->conn_timeout < 4) ++ tsk->conn_timeout = 4; + delay %= (tsk->conn_timeout / 4); + delay = msecs_to_jiffies(delay + 100); + sk_reset_timer(sk, &sk->sk_timer, jiffies + delay);