Linux-stable-mirror

linux-stable-mirror@lists.linaro.org

81 participants
123768 discussions

[PATCH] arm64/mm: Fix annotated branch unbootable kernel

by Breno Leitao

The arm64 kernel doesn't boot with annotated branches (PROFILE_ANNOTATED_BRANCHES) enabled and CONFIG_DEBUG_VIRTUAL together. Bisecting it, I found that disabling branch profiling in arch/arm64/mm solved the problem. Narrowing down a bit further, I found that physaddr.c is the file that needs to have branch profiling disabled to get the machine to boot. I suspect that it might invoke some ftrace helper very early in the boot process and ftrace is still not enabled(!?). Disable branch profiling for physaddr.o to allow booting an arm64 machine with CONFIG_PROFILE_ANNOTATED_BRANCHES and CONFIG_DEBUG_VIRTUAL together. Cc: stable(a)vger.kernel.org Fixes: ec6d06efb0bac ("arm64: Add support for CONFIG_DEBUG_VIRTUAL") Signed-off-by: Breno Leitao <leitao(a)debian.org> --- Another approach is to disable profiling on all arch/arm64 code, similarly to x86, where DISABLE_BRANCH_PROFILING is called for all arch/x86 code. See commit 2cbb20b008dba ("tracing: Disable branch profiling in noinstr code"). --- arch/arm64/mm/Makefile | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/arch/arm64/mm/Makefile b/arch/arm64/mm/Makefile index c26489cf96cd..8bfe2451ea26 100644 --- a/arch/arm64/mm/Makefile +++ b/arch/arm64/mm/Makefile @@ -14,5 +14,10 @@ obj-$(CONFIG_ARM64_MTE) += mteswap.o obj-$(CONFIG_ARM64_GCS) += gcs.o KASAN_SANITIZE_physaddr.o += n +# Branch profiling isn't noinstr-safe +ifdef CONFIG_TRACE_BRANCH_PROFILING +CFLAGS_physaddr.o += -DDISABLE_BRANCH_PROFILING +endif + obj-$(CONFIG_KASAN) += kasan_init.o KASAN_SANITIZE_kasan_init.o := n --- base-commit: c8ebd433459bcbf068682b09544e830acd7ed222 change-id: 20251231-annotated-75de3f33cd7b Best regards, -- Breno Leitao <leitao(a)debian.org>

4 days, 4 hours

[PATCH] clk: clk-apple-nco: Add "apple,t8103-nco" compatible

by Janne Grunau

After discussion with the devicetree maintainers we agreed to not extend lists with the generic compatible "apple,nco" anymore [1]. Use "apple,t8103-nco" as base compatible as it is the SoC the driver and bindings were written for. [1]: https://lore.kernel.org/asahi/12ab93b7-1fc2-4ce0-926e-c8141cfe81bf@kernel.o… Fixes: 6641057d5dba ("clk: clk-apple-nco: Add driver for Apple NCO") Cc: stable(a)vger.kernel.org Acked-by: Stephen Boyd <sboyd(a)kernel.org> Reviewed-by: Neal Gompa <neal(a)gompa.dev> Signed-off-by: Janne Grunau <j(a)jannau.net> --- This is split off from the v1 series adding Apple M2 Pro/Max/Ultra device trees in [2]. Changes compared to that series: - add "Fixes:" and "Cc: stable" for handling this as fix adding a device id - add Neal's and Stephen's trailers --- drivers/clk/clk-apple-nco.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clk/clk-apple-nco.c b/drivers/clk/clk-apple-nco.c index d3ced4a0f029ec0440ff42d49d31e314fdf86846..434c067968bbc1afdb5c9216277486bf826666c2 100644 --- a/drivers/clk/clk-apple-nco.c +++ b/drivers/clk/clk-apple-nco.c @@ -320,6 +320,7 @@ static int applnco_probe(struct platform_device *pdev) } static const struct of_device_id applnco_ids[] = { + { .compatible = "apple,t8103-nco" }, { .compatible = "apple,nco" }, { } }; --- base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8 change-id: 20251231-clk-apple-nco-t8103-base-compat-dea037ecce88 Best regards, -- Janne Grunau <j(a)jannau.net>

4 days, 5 hours

[PATCH 1/2] nvmem: Drop OF node reference on nvmem_add_one_cell() failure

by Krzysztof Kozlowski

If nvmem_add_one_cell() failed, the ownership of "child" (or "info.np"), thus its OF reference, is not passed further and function should clean up by putting the reference it got via earlier of_node_get(). Note that this is independent of references obtained via for_each_child_of_node() loop. Fixes: 50014d659617 ("nvmem: core: use nvmem_add_one_cell() in nvmem_add_cells_from_of()") Cc: <stable(a)vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)oss.qualcomm.com> --- drivers/nvmem/core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c index 387c88c55259..ff68fd5ad3d6 100644 --- a/drivers/nvmem/core.c +++ b/drivers/nvmem/core.c @@ -831,6 +831,7 @@ static int nvmem_add_cells_from_dt(struct nvmem_device *nvmem, struct device_nod kfree(info.name); if (ret) { of_node_put(child); + of_node_put(info.np); return ret; } } -- 2.51.0

4 days, 5 hours

[PATCH] spmi: apple: Add "apple,t8103-spmi" compatible

by Janne Grunau

After discussion with the devicetree maintainers we agreed to not extend lists with the generic compatible "apple,spmi" anymore [1]. Use "apple,t8103-spmi" as base compatible as it is the SoC the driver and bindings were written for. [1]: https://lore.kernel.org/asahi/12ab93b7-1fc2-4ce0-926e-c8141cfe81bf@kernel.o… Fixes: 77ca75e80c71 ("spmi: add a spmi driver for Apple SoC") Cc: stable(a)vger.kernel.org Reviewed-by: Neal Gompa <neal(a)gompa.dev> Signed-off-by: Janne Grunau <j(a)jannau.net> --- This is split off from the v1 series adding Apple M2 Pro/Max/Ultra device trees in [2]. 2: https://lore.kernel.org/r/20250828-dt-apple-t6020-v1-0-507ba4c4b98e@jannau.… --- drivers/spmi/spmi-apple-controller.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/spmi/spmi-apple-controller.c b/drivers/spmi/spmi-apple-controller.c index 697b3e8bb023566f17911fc222666d84f5e14c91..87e3ee9d4f2aa5517808827f5dd365055c08446a 100644 --- a/drivers/spmi/spmi-apple-controller.c +++ b/drivers/spmi/spmi-apple-controller.c @@ -149,6 +149,7 @@ static int apple_spmi_probe(struct platform_device *pdev) } static const struct of_device_id apple_spmi_match_table[] = { + { .compatible = "apple,t8103-spmi", }, { .compatible = "apple,spmi", }, {} }; --- base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8 change-id: 20251231-spmi-apple-t8103-base-compat-e7c1b862b9a4 Best regards, -- Janne Grunau <j(a)jannau.net>

4 days, 6 hours

[PATCH] nvme-apple: Add "apple,t8103-nvme-ans2" as compatible

by Janne Grunau

After discussion with the devicetree maintainers we agreed to not extend lists with the generic compatible "apple,nvme-ans2" anymore [1]. Add "apple,t8103-nvme-ans2" as fallback compatible as it is the SoC the driver and bindings were written for. [1]: https://lore.kernel.org/asahi/12ab93b7-1fc2-4ce0-926e-c8141cfe81bf@kernel.o… Cc: stable(a)vger.kernel.org # v6.18+ Fixes: 5bd2927aceba ("nvme-apple: Add initial Apple SoC NVMe driver") Reviewed-by: Neal Gompa <neal(a)gompa.dev> Signed-off-by: Janne Grunau <j(a)jannau.net> --- This is split off from the v1 series adding Apple M2 Pro/Max/Ultra device trees in [2]. Handling this as fix adding a device id only for v6.18+ for two reasons. apple_nvme_of_match gained hw_data in v6.18 and device trees using this compatible were only added in v6.18. 2: https://lore.kernel.org/r/20250828-dt-apple-t6020-v1-0-507ba4c4b98e@jannau.… Changes compared to the patch in that series: - rebased onto v6.19-rc1 since commit 04d8ecf37b5e ("nvme: apple: Add Apple A11 support") introduced hw data for the match table --- drivers/nvme/host/apple.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/nvme/host/apple.c b/drivers/nvme/host/apple.c index 15b3d07f8ccdd023cd3be75eedd349b747c1ecad..ed61b97fde59f7e02664798d9c2612ac16307f5c 100644 --- a/drivers/nvme/host/apple.c +++ b/drivers/nvme/host/apple.c @@ -1704,6 +1704,7 @@ static const struct apple_nvme_hw apple_nvme_t8103_hw = { static const struct of_device_id apple_nvme_of_match[] = { { .compatible = "apple,t8015-nvme-ans2", .data = &apple_nvme_t8015_hw }, + { .compatible = "apple,t8103-nvme-ans2", .data = &apple_nvme_t8103_hw }, { .compatible = "apple,nvme-ans2", .data = &apple_nvme_t8103_hw }, {}, }; --- base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8 change-id: 20251026-nvme-apple-t8103-base-compat-358ba0564f76 Best regards, -- Janne Grunau <j(a)jannau.net>

4 days, 7 hours

[PATCH v5.10] ovl: Use "buf" flexible array for memcpy() destination

by Shivani Agarwal

From: Kees Cook <keescook(a)chromium.org> commit cf8aa9bf97cadf85745506c6a3e244b22c268d63 upstream. The "buf" flexible array needs to be the memcpy() destination to avoid false positive run-time warning from the recent FORTIFY_SOURCE hardening: memcpy: detected field-spanning write (size 93) of single field "&fh->fb" at fs/overlayfs/export.c:799 (size 21) Reported-by: syzbot+9d14351a171d0d1c7955(a)syzkaller.appspotmail.com Link: https://lore.kernel.org/all/000000000000763a6c05e95a5985@google.com/ Signed-off-by: Kees Cook <keescook(a)chromium.org> Reviewed-by: Gustavo A. R. Silva <gustavoars(a)kernel.org> Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> [Shivani: Modified to apply on 5.10.y] Signed-off-by: Shivani Agarwal <shivani.agarwal(a)broadcom.com> --- fs/overlayfs/export.c | 2 +- fs/overlayfs/overlayfs.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/overlayfs/export.c b/fs/overlayfs/export.c index f98128317..dd3e1969e 100644 --- a/fs/overlayfs/export.c +++ b/fs/overlayfs/export.c @@ -788,7 +788,7 @@ static struct ovl_fh *ovl_fid_to_fh(struct fid *fid, int buflen, int fh_type) return ERR_PTR(-ENOMEM); /* Copy unaligned inner fh into aligned buffer */ - memcpy(&fh->fb, fid, buflen - OVL_FH_WIRE_OFFSET); + memcpy(fh->buf, fid, buflen - OVL_FH_WIRE_OFFSET); return fh; } diff --git a/fs/overlayfs/overlayfs.h b/fs/overlayfs/overlayfs.h index 87b7a4a74..5ac968f70 100644 --- a/fs/overlayfs/overlayfs.h +++ b/fs/overlayfs/overlayfs.h @@ -104,7 +104,7 @@ struct ovl_fh { u8 padding[3]; /* make sure fb.fid is 32bit aligned */ union { struct ovl_fb fb; - u8 buf[0]; + DECLARE_FLEX_ARRAY(u8, buf); }; } __packed; -- 2.40.4

4 days, 7 hours

[PATCH] rtl8xxxu: fix slab-out-of-bounds in rtl8xxxu_sta_add

by Ali Tariq

The driver does not set hw->sta_data_size, which causes mac80211 to allocate insufficient space for driver private station data in __sta_info_alloc(). When rtl8xxxu_sta_add() accesses members of struct rtl8xxxu_sta_info through sta->drv_priv, this results in a slab-out-of-bounds write. KASAN report on RISC-V (VisionFive 2) with RTL8192EU adapter: BUG: KASAN: slab-out-of-bounds in rtl8xxxu_sta_add+0x31c/0x346 Write of size 8 at addr ffffffd6d3e9ae88 by task kworker/u16:0/12 Set hw->sta_data_size to sizeof(struct rtl8xxxu_sta_info) during probe, similar to how hw->vif_data_size is configured. This ensures mac80211 allocates sufficient space for the driver's per-station private data. Tested on StarFive VisionFive 2 v1.2A board. Fixes: eef55f1545c9 ("wifi: rtl8xxxu: support multiple interfaces in {add,remove}_interface()") Cc: stable(a)vger.kernel.org Signed-off-by: Ali Tariq <alitariq45892(a)gmail.com> --- drivers/net/wireless/realtek/rtl8xxxu/core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/wireless/realtek/rtl8xxxu/core.c b/drivers/net/wireless/realtek/rtl8xxxu/core.c index c06ad064f37c..f9a527f6a175 100644 --- a/drivers/net/wireless/realtek/rtl8xxxu/core.c +++ b/drivers/net/wireless/realtek/rtl8xxxu/core.c @@ -7826,6 +7826,7 @@ static int rtl8xxxu_probe(struct usb_interface *interface, goto err_set_intfdata; hw->vif_data_size = sizeof(struct rtl8xxxu_vif); + hw->sta_data_size = sizeof(struct rtl8xxxu_sta_info); hw->wiphy->max_scan_ssids = 1; hw->wiphy->max_scan_ie_len = IEEE80211_MAX_DATA_LEN; -- 2.43.0

4 days, 9 hours

[PATCH v2 0/3] Address page fault in ima_restore_measurement_list()

by Harshit Mogalapalli

On x86_64: When the second-stage kernel is booted via kexec with a limiting command line such as "mem=<size>" we observe a pafe fault that happens. BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) – not-present page This happens on x86_64 only, as this is already fixed in aarch64 in commit: cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds") V1: https://lore.kernel.org/all/20251112193005.3772542-1-harshit.m.mogalapalli@… V1 attempted to do a similar sanity check in x86_64. Borislav suggested to add a generic helper ima_validate_range() which could then be used for both OF based and x86_64. Testing information: -------------------- On x86_64: With latest 6.19-rc2 based, we could reproduce the issue, and patched kernel works fine. (with mem=8G on a 16G memory machine) Thanks for the reviews on V1. V1 -> V2: - Patch 1: Add a generic helper "ima_validate_range()" - Patch 2: Use this new helper in drivers/of/kexec.c -> No functional change. - Patch 3: Fix the page fault by doing sanity check with "ima_validate_range()" Thanks, Harshit Harshit Mogalapalli (3): ima: Add ima_validate_range() for previous kernel IMA buffer of/kexec: refactor ima_get_kexec_buffer() to use ima_validate_range() x86/kexec: Add a sanity check on previous kernel's ima kexec buffer arch/x86/kernel/setup.c | 6 +++++ drivers/of/kexec.c | 15 +++---------- include/linux/ima.h | 1 + security/integrity/ima/ima_kexec.c | 35 ++++++++++++++++++++++++++++++ 4 files changed, 45 insertions(+), 12 deletions(-) -- 2.50.1

4 days, 11 hours

[PATCH] libceph: Reset sparse-read on fault

by Sam Edwards

When a fault occurs, the connection is abandoned, reestablished, and any pending operations are retried. The OSD client tracks the progress of a sparse-read reply using a separate state machine, largely independent of the messenger's state. If a connection is lost mid-payload or the sparse-read state machine returns an error, the sparse-read state is not reset. The OSD client will then interpret the beginning of a new reply as the continuation of the old one. If this makes the sparse-read machinery enter a failure state, it may never recover, producing loops like: libceph: [0] got 0 extents libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on read libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on read Therefore, reset the sparse-read state in osd_fault(), ensuring retries start from a clean state. Cc: stable(a)vger.kernel.org Signed-off-by: Sam Edwards <CFSworks(a)gmail.com> --- net/ceph/osd_client.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/ceph/osd_client.c b/net/ceph/osd_client.c index 3667319b949d..1a7be2f615dc 100644 --- a/net/ceph/osd_client.c +++ b/net/ceph/osd_client.c @@ -4281,6 +4281,9 @@ static void osd_fault(struct ceph_connection *con) goto out_unlock; } + osd->o_sparse_op_idx = -1; + ceph_init_sparse_read(&osd->o_sparse_read); + if (!reopen_osd(osd)) kick_osd_requests(osd); maybe_request_map(osdc); -- 2.51.2

4 days, 13 hours

FAILED: patch "[PATCH] NFSD: Clear SECLABEL in the suppattr_exclcreat bitmap" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 27d17641cacfedd816789b75d342430f6b912bd2 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025122920-sequence-vixen-bb32@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 27d17641cacfedd816789b75d342430f6b912bd2 Mon Sep 17 00:00:00 2001 From: Chuck Lever <chuck.lever(a)oracle.com> Date: Mon, 17 Nov 2025 11:00:49 -0500 Subject: [PATCH] NFSD: Clear SECLABEL in the suppattr_exclcreat bitmap >From RFC 8881: 5.8.1.14. Attribute 75: suppattr_exclcreat > The bit vector that would set all REQUIRED and RECOMMENDED > attributes that are supported by the EXCLUSIVE4_1 method of file > creation via the OPEN operation. The scope of this attribute > applies to all objects with a matching fsid. There's nothing in RFC 8881 that states that suppattr_exclcreat is or is not allowed to contain bits for attributes that are clear in the reported supported_attrs bitmask. But it doesn't make sense for an NFS server to indicate that it /doesn't/ implement an attribute, but then also indicate that clients /are/ allowed to set that attribute using OPEN(create) with EXCLUSIVE4_1. Ensure that the SECURITY_LABEL and ACL bits are not set in the suppattr_exclcreat bitmask when they are also not set in the supported_attrs bitmask. Fixes: 8c18f2052e75 ("nfsd41: SUPPATTR_EXCLCREAT attribute") Cc: stable(a)vger.kernel.org Reviewed-by: Jeff Layton <jlayton(a)kernel.org> Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> diff --git a/fs/nfsd/nfs4xdr.c b/fs/nfsd/nfs4xdr.c index 30ce5851fe4c..51ef97c25456 100644 --- a/fs/nfsd/nfs4xdr.c +++ b/fs/nfsd/nfs4xdr.c @@ -3375,6 +3375,11 @@ static __be32 nfsd4_encode_fattr4_suppattr_exclcreat(struct xdr_stream *xdr, u32 supp[3]; memcpy(supp, nfsd_suppattrs[resp->cstate.minorversion], sizeof(supp)); + if (!IS_POSIXACL(d_inode(args->dentry))) + supp[0] &= ~FATTR4_WORD0_ACL; + if (!args->contextsupport) + supp[2] &= ~FATTR4_WORD2_SECURITY_LABEL; + supp[0] &= NFSD_SUPPATTR_EXCLCREAT_WORD0; supp[1] &= NFSD_SUPPATTR_EXCLCREAT_WORD1; supp[2] &= NFSD_SUPPATTR_EXCLCREAT_WORD2;

4 days, 13 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror