Linux-stable-mirror

linux-stable-mirror@lists.linaro.org

172 participants
124009 discussions

[PATCH v2] powerpc: Add reloc_offset() to font bitmap pointer used for bootx_printf()

by Finn Thain

Since Linux v6.7, booting using BootX on an Old World PowerMac produces an early crash. Stan Johnson writes, "the symptoms are that the screen goes blank and the backlight stays on, and the system freezes (Linux doesn't boot)." Further testing revealed that the failure can be avoided by disabling CONFIG_BOOTX_TEXT. Bisection revealed that the regression was caused by a change to the font bitmap pointer that's used when btext_init() begins painting characters on the display, early in the boot process. Christophe Leroy explains, "before kernel text is relocated to its final location ... data is addressed with an offset which is added to the Global Offset Table (GOT) entries at the start of bootx_init() by function reloc_got2(). But the pointers that are located inside a structure are not referenced in the GOT and are therefore not updated by reloc_got2(). It is therefore needed to apply the offset manually by using PTRRELOC() macro." Cc: Cedar Maxwell <cedarmaxwell(a)mac.com> Cc: Stan Johnson <userm57(a)yahoo.com> Cc: "Dr. David Alan Gilbert" <linux(a)treblig.org> Cc: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> Cc: stable(a)vger.kernel.org Link: https://lists.debian.org/debian-powerpc/2025/10/msg00111.html Link: https://lore.kernel.org/linuxppc-dev/d81ddca8-c5ee-d583-d579-02b19ed95301@y… Reported-by: Cedar Maxwell <cedarmaxwell(a)mac.com> Closes: https://lists.debian.org/debian-powerpc/2025/09/msg00031.html Bisected-by: Stan Johnson <userm57(a)yahoo.com> Tested-by: Stan Johnson <userm57(a)yahoo.com> Fixes: 0ebc7feae79a ("powerpc: Use shared font data") Suggested-by: Christophe Leroy <christophe.leroy(a)csgroup.eu> Signed-off-by: Finn Thain <fthain(a)linux-m68k.org> --- Changed since v1: - Improved commit log entry to better explain the need for PTRRELOC(). --- arch/powerpc/kernel/btext.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/btext.c b/arch/powerpc/kernel/btext.c index 7f63f1cdc6c3..ca00c4824e31 100644 --- a/arch/powerpc/kernel/btext.c +++ b/arch/powerpc/kernel/btext.c @@ -20,6 +20,7 @@ #include <asm/io.h> #include <asm/processor.h> #include <asm/udbg.h> +#include <asm/setup.h> #define NO_SCROLL @@ -463,7 +464,7 @@ static noinline void draw_byte(unsigned char c, long locX, long locY) { unsigned char *base = calc_base(locX << 3, locY << 4); unsigned int font_index = c * 16; - const unsigned char *font = font_sun_8x16.data + font_index; + const unsigned char *font = PTRRELOC(font_sun_8x16.data) + font_index; int rb = dispDeviceRowBytes; rmci_maybe_on(); -- 2.49.1

1 week, 3 days

[PATCH] SUNRPC: auth_gss: fix memory leaks in XDR decoding error paths

by Chuck Lever

From: Chuck Lever <chuck.lever(a)oracle.com> The gssx_dec_ctx(), gssx_dec_status(), and gssx_dec_name() functions allocate memory via gssx_dec_buffer(), which calls kmemdup(). When a subsequent decode operation fails, these functions return immediately without freeing previously allocated buffers, causing memory leaks. The leak in gssx_dec_ctx() is particularly relevant because the caller (gssp_accept_sec_context_upcall) initializes several buffer length fields to non-zero values, resulting in memory allocation: struct gssx_ctx rctxh = { .exported_context_token.len = GSSX_max_output_handle_sz, .mech.len = GSS_OID_MAX_LEN, .src_name.display_name.len = GSSX_max_princ_sz, .targ_name.display_name.len = GSSX_max_princ_sz }; If, for example, gssx_dec_name() succeeds for src_name but fails for targ_name, the memory allocated for exported_context_token, mech, and src_name.display_name remains unreferenced and cannot be reclaimed. Add error handling with goto-based cleanup to free any previously allocated buffers before returning an error. Reported-by: Xingjing Deng <micro6947(a)gmail.com> Closes: https://lore.kernel.org/linux-nfs/CAK+ZN9qttsFDu6h1FoqGadXjMx1QXqPMoYQ=6O9R… Fixes: 1d658336b05f ("SUNRPC: Add RPC based upcall mechanism for RPCGSS auth") Cc: stable(a)vger.kernel.org Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> --- net/sunrpc/auth_gss/gss_rpc_xdr.c | 82 ++++++++++++++++++++++++------- 1 file changed, 64 insertions(+), 18 deletions(-) diff --git a/net/sunrpc/auth_gss/gss_rpc_xdr.c b/net/sunrpc/auth_gss/gss_rpc_xdr.c index 7d2cdc2bd374..f320c0a8e604 100644 --- a/net/sunrpc/auth_gss/gss_rpc_xdr.c +++ b/net/sunrpc/auth_gss/gss_rpc_xdr.c @@ -320,29 +320,47 @@ static int gssx_dec_status(struct xdr_stream *xdr, /* status->minor_status */ p = xdr_inline_decode(xdr, 8); - if (unlikely(p == NULL)) - return -ENOSPC; + if (unlikely(p == NULL)) { + err = -ENOSPC; + goto out_free_mech; + } p = xdr_decode_hyper(p, &status->minor_status); /* status->major_status_string */ err = gssx_dec_buffer(xdr, &status->major_status_string); if (err) - return err; + goto out_free_mech; /* status->minor_status_string */ err = gssx_dec_buffer(xdr, &status->minor_status_string); if (err) - return err; + goto out_free_major_status_string; /* status->server_ctx */ err = gssx_dec_buffer(xdr, &status->server_ctx); if (err) - return err; + goto out_free_minor_status_string; /* we assume we have no options for now, so simply consume them */ /* status->options */ err = dummy_dec_opt_array(xdr, &status->options); + if (err) + goto out_free_server_ctx; + return 0; + +out_free_server_ctx: + kfree(status->server_ctx.data); + status->server_ctx.data = NULL; +out_free_minor_status_string: + kfree(status->minor_status_string.data); + status->minor_status_string.data = NULL; +out_free_major_status_string: + kfree(status->major_status_string.data); + status->major_status_string.data = NULL; +out_free_mech: + kfree(status->mech.data); + status->mech.data = NULL; return err; } @@ -505,28 +523,35 @@ static int gssx_dec_name(struct xdr_stream *xdr, /* name->name_type */ err = gssx_dec_buffer(xdr, &dummy_netobj); if (err) - return err; + goto out_free_display_name; /* name->exported_name */ err = gssx_dec_buffer(xdr, &dummy_netobj); if (err) - return err; + goto out_free_display_name; /* name->exported_composite_name */ err = gssx_dec_buffer(xdr, &dummy_netobj); if (err) - return err; + goto out_free_display_name; /* we assume we have no attributes for now, so simply consume them */ /* name->name_attributes */ err = dummy_dec_nameattr_array(xdr, &dummy_name_attr_array); if (err) - return err; + goto out_free_display_name; /* we assume we have no options for now, so simply consume them */ /* name->extensions */ err = dummy_dec_opt_array(xdr, &dummy_option_array); + if (err) + goto out_free_display_name; + return 0; + +out_free_display_name: + kfree(name->display_name.data); + name->display_name.data = NULL; return err; } @@ -649,32 +674,34 @@ static int gssx_dec_ctx(struct xdr_stream *xdr, /* ctx->state */ err = gssx_dec_buffer(xdr, &ctx->state); if (err) - return err; + goto out_free_exported_context_token; /* ctx->need_release */ err = gssx_dec_bool(xdr, &ctx->need_release); if (err) - return err; + goto out_free_state; /* ctx->mech */ err = gssx_dec_buffer(xdr, &ctx->mech); if (err) - return err; + goto out_free_state; /* ctx->src_name */ err = gssx_dec_name(xdr, &ctx->src_name); if (err) - return err; + goto out_free_mech; /* ctx->targ_name */ err = gssx_dec_name(xdr, &ctx->targ_name); if (err) - return err; + goto out_free_src_name; /* ctx->lifetime */ p = xdr_inline_decode(xdr, 8+8); - if (unlikely(p == NULL)) - return -ENOSPC; + if (unlikely(p == NULL)) { + err = -ENOSPC; + goto out_free_targ_name; + } p = xdr_decode_hyper(p, &ctx->lifetime); /* ctx->ctx_flags */ @@ -683,17 +710,36 @@ static int gssx_dec_ctx(struct xdr_stream *xdr, /* ctx->locally_initiated */ err = gssx_dec_bool(xdr, &ctx->locally_initiated); if (err) - return err; + goto out_free_targ_name; /* ctx->open */ err = gssx_dec_bool(xdr, &ctx->open); if (err) - return err; + goto out_free_targ_name; /* we assume we have no options for now, so simply consume them */ /* ctx->options */ err = dummy_dec_opt_array(xdr, &ctx->options); + if (err) + goto out_free_targ_name; + return 0; + +out_free_targ_name: + kfree(ctx->targ_name.display_name.data); + ctx->targ_name.display_name.data = NULL; +out_free_src_name: + kfree(ctx->src_name.display_name.data); + ctx->src_name.display_name.data = NULL; +out_free_mech: + kfree(ctx->mech.data); + ctx->mech.data = NULL; +out_free_state: + kfree(ctx->state.data); + ctx->state.data = NULL; +out_free_exported_context_token: + kfree(ctx->exported_context_token.data); + ctx->exported_context_token.data = NULL; return err; } -- 2.52.0

1 week, 4 days

Re: [REGRESSION] erofs: new file-backed stacking limit breaks container overlay use case in 6.12.63

by Gao Xiang

Hi Alekséi, On 2025/12/26 20:17, Alekséi Naidénov wrote: > Hello, > > I am reporting a regression in the 6.12 stable series related to EROFS > file-backed mounts. > > After updating from Linux 6.12.62 to 6.12.63, a previously working setup > using OSTree-backed composefs mounts as Podman rootfs no longer works. > > The regression appears to be caused by the following commit: > > 34447aeedbaea8f9aad3da5b07030a1c0e124639 ("erofs: limit the level of fs > stacking for file-backed mounts") > (backport of upstream commit d53cd891f0e4311889349fff3a784dc552f814b9) > > ## Setup description > > We use OSTree to materialize filesystem trees, which are mounted via > composefs (EROFS + overlayfs) as a read-only filesystem. This mounted > composefs tree is then used as a Podman rootfs, with Podman mounting a > writable overlayfs on top for each container. > > This setup worked correctly on Linux 6.12.62 and earlier. The following issue just tracks this: https://github.com/coreos/fedora-coreos-tracker/issues/2087 I don't think more information is needed, but I really think the EROFS commit is needed to avoid kernel stack overflow due to nested fses. > > In short, the stacking looks like: > > EROFS (file-backed) > -> composefs (EROFS + overlayfs with ostree repo as datadir, read-only) > -> Podman rootfs overlays (RW upperdir) > > There is no recursive or self-stacking of EROFS. Yes, but there are two overlayfs + one file-backed EROFS already, and it exceeds FILESYSTEM_MAX_STACK_DEPTH. That is overlayfs refuses to mount the nested fses. Thanks, Gao Xiang

1 week, 4 days

[REGRESSION] erofs: new file-backed stacking limit breaks container overlay use case in 6.12.63

by Alekséi Naidénov

Hello, I am reporting a regression in the 6.12 stable series related to EROFS file-backed mounts. After updating from Linux 6.12.62 to 6.12.63, a previously working setup using OSTree-backed composefs mounts as Podman rootfs no longer works. The regression appears to be caused by the following commit: 34447aeedbaea8f9aad3da5b07030a1c0e124639 ("erofs: limit the level of fs stacking for file-backed mounts") (backport of upstream commit d53cd891f0e4311889349fff3a784dc552f814b9) ## Setup description We use OSTree to materialize filesystem trees, which are mounted via composefs (EROFS + overlayfs) as a read-only filesystem. This mounted composefs tree is then used as a Podman rootfs, with Podman mounting a writable overlayfs on top for each container. This setup worked correctly on Linux 6.12.62 and earlier. In short, the stacking looks like: EROFS (file-backed) -> composefs (EROFS + overlayfs with ostree repo as datadir, read-only) -> Podman rootfs overlays (RW upperdir) There is no recursive or self-stacking of EROFS. ## Working case (6.12.62) The composefs mount exists and Podman can successfully start a container using it as rootfs. Example composefs mount: ❯ mount | grep a31550cc69eef0e3227fa700623250592711fdfd51b5403a74288b55e89e7e8c a31550cc69eef0e3227fa700623250592711fdfd51b5403a74288b55e89e7e8c on /home/growler/.local/share/containers/ostree/a31550cc69eef0e3227fa700623250592711fdfd51b5403a74288b55e89e7e8c type overlay (ro,noatime,lowerdir+=/proc/self/fd/10,datadir+=/proc/self/fd/7,redirect_dir=on,metacopy=on) (lowedir is a handle for the erofs file-backed mount, datadir is a handle for the ostree repository objects directory) Running Podman: ❯ podman run --rm -it --rootfs $HOME/.local/share/containers/ostree/a31550cc69eef0e3227fa700623250592711fdfd51b5403a74288b55e89e7e8c:O bash -l root@d691e785bba3:/# uname -a Linux d691e785bba3 6.12.62 #1-NixOS SMP PREEMPT_DYNAMIC Fri Dec 12 17:37:22 UTC 2025 x86_64 GNU/Linux root@d691e785bba3:/# (succeed) ## Failing case (6.12.63) After upgrading to 6.12.63, the same command fails when Podman tries to create the writable overlay on top of the composefs mount. Error: ❯ podman run --rm -it --rootfs $HOME/.local/share/containers/ostree/a31550cc69eef0e3227fa700623250592711fdfd51b5403a74288b55e89e7e8c:O bash -l Error: rootfs-overlay: creating overlay failed "/home/growler/.local/share/containers/ostree/a31550cc69eef0e3227fa700623250592711fdfd51b5403a74288b55e89e7e8c" from native overlay: mount overlay:/home/growler/.local/share/containers/storage/overlay-containers/a0851294d6b5b18062d4f5316032ee84d7bae700ea7d12c5be949d9e1999b0a1/rootfs/merge, flags: 0x4, data: lowerdir=/home/growler/.local/share/containers/ostree/a31550cc69eef0e3227fa700623250592711fdfd51b5403a74288b55e89e7e8c,upperdir=/home/growler/.local/share/containers/storage/overlay-containers/a0851294d6b5b18062d4f5316032ee84d7bae700ea7d12c5be949d9e1999b0a1/rootfs/upper,workdir=/home/growler/.local/share/containers/storage/overlay-containers/a0851294d6b5b18062d4f5316032ee84d7bae700ea7d12c5be949d9e1999b0a1/rootfs/work,userxattr: invalid argument ❯ uname -a Linux ci-node-09 6.12.63 #1-NixOS SMP PREEMPT_DYNAMIC Thu Dec 18 12:55:23 UTC 2025 x86_64 GNU/Linux ## Expected behavior Using a composefs (EROFS + overlayfs) read-only mount as the lowerdir for a container rootfs overlay should continue to work as it did in 6.12.62. ## Actual behavior Overlayfs mounting fails with EINVAL when stacking on top of the composefs mount backed by EROFS. ## Notes The setup does not involve recursive EROFS mounting or unbounded stacking depth. It appears the new stacking limit rejects this valid and previously supported container use case. Please let me know if further details or testing would be helpful. Thank you, -- Alekséi Nadénov

1 week, 4 days

[PATCH 6.6.y 0/2] fix push_nsh() validation + silence selftest warnings

by Adrian Yip

Hi maintainers, This is a v6.6 backport mainly for an upstream commit `5ace7ef87f05 net: openvswitch: fix middle attribute validation in push_nsh() action`. I built the kernel then tested it with selftest. The selftest that ran with a a bunch of SyntaxWarning. Example: /ovs-dpctl.py:598: SyntaxWarning: invalid escape sequence '\d' actstr, ":", "(\d+)", int, False /ovs-dpctl.py:601: SyntaxWarning: invalid escape sequence '\d' actstr, "-", "(\d+)", int, False /ovs-dpctl.py:505: SyntaxWarning: invalid escape sequence '\d' elif parse_starts_block(actstr, "^(\d+)", False, True): This error was then easily fixed with another minimal backport for the file tools/testing/selftests/net/openvswitch/ovs-dpctl.py. Hence the series. Both patches was applied cleanly and was tested with selftest and passed though the timeout had to be increased for drop_reason to pass. Adrian Moreno (1): selftests: openvswitch: Fix escape chars in regexp. Ilya Maximets (1): net: openvswitch: fix middle attribute validation in push_nsh() action net/openvswitch/flow_netlink.c | 13 ++++++++++--- .../selftests/net/openvswitch/ovs-dpctl.py | 16 ++++++++-------- 2 files changed, 18 insertions(+), 11 deletions(-) -- 2.52.0

1 week, 4 days

[BUG] net/sunrpc/auth_gss: Memory leak in gssx_dec_status/gssx_dec_buffer

by Xingjing Deng

A potential memory leak exists in the gssx_dec_status function (in net/sunrpc/auth_gss/gss_rpc_xdr.c) and its dependent gssx_dec_buffer function. The leak occurs when gssx_dec_buffer allocates memory via kmemdup for gssx_buffer fields, but the allocated memory is not freed in error paths of the chained decoding process in gssx_dec_status. The gssx_dec_buffer function allocates memory using kmemdup when buf->data is NULL (to store decoded XDR buffer data). This allocation is not paired with a release mechanism in case of subsequent decoding failures. gssx_dec_status sequentially decodes multiple gssx_buffer fields (e.g., mech, major_status_string, minor_status_string, server_ctx) by calling gssx_dec_buffer. If a later decoding step fails (e.g., gssx_dec_buffer returns -ENOSPC or -ENOMEM), the function immediately returns the error without freeing the memory allocated for earlier gssx_buffer fields. This results in persistent kernel memory leaks. This memory allocation is conditional. I traced upward through the callers gssx_dec_status and found that it is ultimately invoked by the interface gssx_dec_accept_sec_context. Although I have not identified the specific code execution path that triggers this memory leak, I believe this coding pattern is highly prone to causing confusion between callers and callees, which in turn leads to memory leaks. Relevant code links: https://github.com/torvalds/linux/blob/ccd1cdca5cd433c8a5dff78b69a79b31d9b7… https://github.com/torvalds/linux/blob/ccd1cdca5cd433c8a5dff78b69a79b31d9b7… I have searched Bugzilla, lore.kernel.org, and client.linux-nfs.org, but no related issues were found.

1 week, 4 days

[PATCH v6.6] genirq/irq_sim: Initialize work context pointers properly

by Rahul Sharma

From: Gyeyoung Baek <gye976(a)gmail.com> [ Upstream commit 8a2277a3c9e4cc5398f80821afe7ecbe9bdf2819 ] Initialize `ops` member's pointers properly by using kzalloc() instead of kmalloc() when allocating the simulation work context. Otherwise the pointers contain random content leading to invalid dereferencing. Signed-off-by: Gyeyoung Baek <gye976(a)gmail.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Link: https://lore.kernel.org/all/20250612124827.63259-1-gye976@gmail.com [ The context change is due to the commit 011f583781fa ("genirq/irq_sim: add an extended irq_sim initializer") which is irrelevant to the logic of this patch. ] Signed-off-by: Rahul Sharma <black.hawk(a)163.com> --- kernel/irq/irq_sim.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/irq/irq_sim.c b/kernel/irq/irq_sim.c index dd76323ea3fd..bde31468c19d 100644 --- a/kernel/irq/irq_sim.c +++ b/kernel/irq/irq_sim.c @@ -166,7 +166,7 @@ struct irq_domain *irq_domain_create_sim(struct fwnode_handle *fwnode, { struct irq_sim_work_ctx *work_ctx; - work_ctx = kmalloc(sizeof(*work_ctx), GFP_KERNEL); + work_ctx = kzalloc(sizeof(*work_ctx), GFP_KERNEL); if (!work_ctx) goto err_out; -- 2.34.1

1 week, 4 days

Tools factory from China

by decii＠pachatool.com

1 week, 4 days

[PATCH] ext4: xattr: fix wrong search.here in clone_block

by Jinchao Wang

syzbot reported a KASAN out-of-bounds Read in ext4_xattr_set_entry()[1]. When xattr_find_entry() returns -ENODATA, search.here still points to the position after the last valid entry. ext4_xattr_block_set() clones the xattr block because the original block maybe shared and must not be modified in place. In the clone_block, search.here is recomputed unconditionally from the old offset, which may place it past search.first. This results in a negative reset size and an out-of-bounds memmove() in ext4_xattr_set_entry(). Fix this by initializing search.here correctly when search.not_found is set. [1] https://syzkaller.appspot.com/bug?extid=f792df426ff0f5ceb8d1 Fixes: fd48e9acdf2 (ext4: Unindent codeblock in ext4_xattr_block_set) Cc: stable(a)vger.kernel.org Reported-by: syzbot+f792df426ff0f5ceb8d1(a)syzkaller.appspotmail.com Signed-off-by: Jinchao Wang <wangjinchao600(a)gmail.com> --- fs/ext4/xattr.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c index 2e02efbddaac..cc30abeb7f30 100644 --- a/fs/ext4/xattr.c +++ b/fs/ext4/xattr.c @@ -1980,7 +1980,10 @@ ext4_xattr_block_set(handle_t *handle, struct inode *inode, goto cleanup; s->first = ENTRY(header(s->base)+1); header(s->base)->h_refcount = cpu_to_le32(1); - s->here = ENTRY(s->base + offset); + if (s->not_found) + s->here = s->first; + else + s->here = ENTRY(s->base + offset); s->end = s->base + bs->bh->b_size; /* -- 2.43.0

1 week, 4 days

[PATCH v2] io_uring: fix filename leak in __io_openat_prep()

by Prithvi Tambewagh

__io_openat_prep() allocates a struct filename using getname(). However, for the condition of the file being installed in the fixed file table as well as having O_CLOEXEC flag set, the function returns early. At that point, the request doesn't have REQ_F_NEED_CLEANUP flag set. Due to this, the memory for the newly allocated struct filename is not cleaned up, causing a memory leak. Fix this by setting the REQ_F_NEED_CLEANUP for the request just after the successful getname() call, so that when the request is torn down, the filename will be cleaned up, along with other resources needing cleanup. Reported-by: syzbot+00e61c43eb5e4740438f(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=00e61c43eb5e4740438f Tested-by: syzbot+00e61c43eb5e4740438f(a)syzkaller.appspotmail.com Cc: stable(a)vger.kernel.org Signed-off-by: Prithvi Tambewagh <activprithvi(a)gmail.com> --- io_uring/openclose.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/io_uring/openclose.c b/io_uring/openclose.c index bfeb91b31bba..15dde9bd6ff6 100644 --- a/io_uring/openclose.c +++ b/io_uring/openclose.c @@ -73,13 +73,13 @@ static int __io_openat_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe open->filename = NULL; return ret; } + req->flags |= REQ_F_NEED_CLEANUP; open->file_slot = READ_ONCE(sqe->file_index); if (open->file_slot && (open->how.flags & O_CLOEXEC)) return -EINVAL; open->nofile = rlimit(RLIMIT_NOFILE); - req->flags |= REQ_F_NEED_CLEANUP; if (io_openat_force_async(open)) req->flags |= REQ_F_FORCE_ASYNC; return 0; base-commit: b927546677c876e26eba308550207c2ddf812a43 -- 2.34.1

1 week, 5 days

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror