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
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
Dear linux-fbdev, stable,
On Mon, Oct 20, 2025 at 09:47:01PM +0800, Junjie Cao wrote:
> bit_putcs_aligned()/unaligned() derived the glyph pointer from the
> character value masked by 0xff/0x1ff, which may exceed the actual font's
> glyph count and read past the end of the built-in font array.
> Clamp the index to the actual glyph count before computing the address.
>
> This fixes a global out-of-bounds read reported by syzbot.
>
> Reported-by: syzbot+793cf822d213be1a74f2(a)syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=793cf822d213be1a74f2
> Tested-by: syzbot+793cf822d213be1a74f2(a)syzkaller.appspotmail.com
> Signed-off-by: Junjie Cao <junjie.cao(a)intel.com>
This commit is applied to v5.10.247 and causes a regression: when
switching VT with ctrl-alt-f2 the screen is blank or completely filled
with angle characters, then new text is not appearing (or not visible).
This commit is found with git bisect from v5.10.246 to v5.10.247:
0998a6cb232674408a03e8561dc15aa266b2f53b is the first bad commit
commit 0998a6cb232674408a03e8561dc15aa266b2f53b
Author: Junjie Cao <junjie.cao(a)intel.com>
AuthorDate: 2025-10-20 21:47:01 +0800
Commit: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
CommitDate: 2025-12-07 06:08:07 +0900
fbdev: bitblit: bound-check glyph index in bit_putcs*
commit 18c4ef4e765a798b47980555ed665d78b71aeadf upstream.
bit_putcs_aligned()/unaligned() derived the glyph pointer from the
character value masked by 0xff/0x1ff, which may exceed the actual font's
glyph count and read past the end of the built-in font array.
Clamp the index to the actual glyph count before computing the address.
This fixes a global out-of-bounds read reported by syzbot.
Reported-by: syzbot+793cf822d213be1a74f2(a)syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=793cf822d213be1a74f2
Tested-by: syzbot+793cf822d213be1a74f2(a)syzkaller.appspotmail.com
Signed-off-by: Junjie Cao <junjie.cao(a)intel.com>
Reviewed-by: Thomas Zimmermann <tzimmermann(a)suse.de>
Signed-off-by: Helge Deller <deller(a)gmx.de>
Cc: stable(a)vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
drivers/video/fbdev/core/bitblit.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
The minimal reproducer in cli, after kernel is booted:
date >/dev/tty2; chvt 2
and the date does not appear.
Thanks,
#regzbot introduced: 0998a6cb232674408a03e8561dc15aa266b2f53b
> ---
> v1: https://lore.kernel.org/linux-fbdev/5d237d1a-a528-4205-a4d8-71709134f1e1@su…
> v1 -> v2:
> - Fix indentation and add blank line after declarations with the .pl helper
> - No functional changes
>
> drivers/video/fbdev/core/bitblit.c | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/bitblit.c b/drivers/video/fbdev/core/bitblit.c
> index 9d2e59796c3e..085ffb44c51a 100644
> --- a/drivers/video/fbdev/core/bitblit.c
> +++ b/drivers/video/fbdev/core/bitblit.c
> @@ -79,12 +79,16 @@ static inline void bit_putcs_aligned(struct vc_data *vc, struct fb_info *info,
> struct fb_image *image, u8 *buf, u8 *dst)
> {
> u16 charmask = vc->vc_hi_font_mask ? 0x1ff : 0xff;
> + unsigned int charcnt = vc->vc_font.charcount;
> u32 idx = vc->vc_font.width >> 3;
> u8 *src;
>
> while (cnt--) {
> - src = vc->vc_font.data + (scr_readw(s++)&
> - charmask)*cellsize;
> + u16 ch = scr_readw(s++) & charmask;
> +
> + if (ch >= charcnt)
> + ch = 0;
> + src = vc->vc_font.data + (unsigned int)ch * cellsize;
>
> if (attr) {
> update_attr(buf, src, attr, vc);
> @@ -112,14 +116,18 @@ static inline void bit_putcs_unaligned(struct vc_data *vc,
> u8 *dst)
> {
> u16 charmask = vc->vc_hi_font_mask ? 0x1ff : 0xff;
> + unsigned int charcnt = vc->vc_font.charcount;
> u32 shift_low = 0, mod = vc->vc_font.width % 8;
> u32 shift_high = 8;
> u32 idx = vc->vc_font.width >> 3;
> u8 *src;
>
> while (cnt--) {
> - src = vc->vc_font.data + (scr_readw(s++)&
> - charmask)*cellsize;
> + u16 ch = scr_readw(s++) & charmask;
> +
> + if (ch >= charcnt)
> + ch = 0;
> + src = vc->vc_font.data + (unsigned int)ch * cellsize;
>
> if (attr) {
> update_attr(buf, src, attr, vc);
> --
> 2.48.1
>
When software issues a Cache Maintenance Operation (CMO) targeting a
dirty cache line, the CPU and DSU cluster may optimize the operation by
combining the CopyBack Write and CMO into a single combined CopyBack
Write plus CMO transaction presented to the interconnect (MCN).
For these combined transactions, the MCN splits the operation into two
separate transactions, one Write and one CMO, and then propagates the
write and optionally the CMO to the downstream memory system or external
Point of Serialization (PoS).
However, the MCN may return an early CompCMO response to the DSU cluster
before the corresponding Write and CMO transactions have completed at
the external PoS or downstream memory. As a result, stale data may be
observed by external observers that are directly connected to the
external PoS or downstream memory.
This erratum affects any system topology in which the following
conditions apply:
- The Point of Serialization (PoS) is located downstream of the
interconnect.
- A downstream observer accesses memory directly, bypassing the
interconnect.
Conditions:
This erratum occurs only when all of the following conditions are met:
1. Software executes a data cache maintenance operation, specifically,
a clean or invalidate by virtual address (DC CVAC, DC CIVAC, or DC
IVAC), that hits on unique dirty data in the CPU or DSU cache. This
results in a combined CopyBack and CMO being issued to the
interconnect.
2. The interconnect splits the combined transaction into separate Write
and CMO transactions and returns an early completion response to the
CPU or DSU before the write has completed at the downstream memory
or PoS.
3. A downstream observer accesses the affected memory address after the
early completion response is issued but before the actual memory
write has completed. This allows the observer to read stale data
that has not yet been updated at the PoS or downstream memory.
The implementation of workaround put a second loop of CMOs at the same
virtual address whose operation meet erratum conditions to wait until
cache data be cleaned to PoC.. This way of implementation mitigates
performance panalty compared to purly duplicate orignial CMO.
Cc: stable(a)vger.kernel.org # 6.12.x
Signed-off-by: Lucas Wei <lucaswei(a)google.com>
---
Documentation/arch/arm64/silicon-errata.rst | 3 ++
arch/arm64/Kconfig | 19 +++++++++++++
arch/arm64/include/asm/assembler.h | 10 +++++++
arch/arm64/kernel/cpu_errata.c | 31 +++++++++++++++++++++
arch/arm64/mm/cache.S | 13 ++++++++-
arch/arm64/tools/cpucaps | 1 +
6 files changed, 76 insertions(+), 1 deletion(-)
diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst
index a7ec57060f64..98efdf528719 100644
--- a/Documentation/arch/arm64/silicon-errata.rst
+++ b/Documentation/arch/arm64/silicon-errata.rst
@@ -213,6 +213,9 @@ stable kernels.
| ARM | GIC-700 | #2941627 | ARM64_ERRATUM_2941627 |
+----------------+-----------------+-----------------+-----------------------------+
+----------------+-----------------+-----------------+-----------------------------+
+| ARM | SI L1 | #4311569 | ARM64_ERRATUM_4311569 |
++----------------+-----------------+-----------------+-----------------------------+
++----------------+-----------------+-----------------+-----------------------------+
| Broadcom | Brahma-B53 | N/A | ARM64_ERRATUM_845719 |
+----------------+-----------------+-----------------+-----------------------------+
| Broadcom | Brahma-B53 | N/A | ARM64_ERRATUM_843419 |
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 93173f0a09c7..89326bb26f48 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1155,6 +1155,25 @@ config ARM64_ERRATUM_3194386
If unsure, say Y.
+config ARM64_ERRATUM_4311569
+ bool "SI L1: 4311569: workaround for premature CMO completion erratum"
+ default y
+ help
+ This option adds the workaround for ARM SI L1 erratum 4311569.
+
+ The erratum of SI L1 can cause an early response to a combined write
+ and cache maintenance operation (WR+CMO) before the operation is fully
+ completed to the Point of Serialization (POS).
+ This can result in a non-I/O coherent agent observing stale data,
+ potentially leading to system instability or incorrect behavior.
+
+ Enabling this option implements a software workaround by inserting a
+ second loop of Cache Maintenance Operation (CMO) immediately following the
+ end of function to do CMOs. This ensures that the data is correctly serialized
+ before the buffer is handed off to a non-coherent agent.
+
+ If unsure, say Y.
+
config CAVIUM_ERRATUM_22375
bool "Cavium erratum 22375, 24313"
default y
diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
index f0ca7196f6fa..d3d46e5f7188 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -381,6 +381,9 @@ alternative_endif
.macro dcache_by_myline_op op, domain, start, end, linesz, tmp, fixup
sub \tmp, \linesz, #1
bic \start, \start, \tmp
+alternative_if ARM64_WORKAROUND_4311569
+ mov \tmp, \start
+alternative_else_nop_endif
.Ldcache_op\@:
.ifc \op, cvau
__dcache_op_workaround_clean_cache \op, \start
@@ -402,6 +405,13 @@ alternative_endif
add \start, \start, \linesz
cmp \start, \end
b.lo .Ldcache_op\@
+alternative_if ARM64_WORKAROUND_4311569
+ .ifnc \op, cvau
+ mov \start, \tmp
+ mov \tmp, xzr
+ cbnz \start, .Ldcache_op\@
+ .endif
+alternative_else_nop_endif
dsb \domain
_cond_uaccess_extable .Ldcache_op\@, \fixup
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 8cb3b575a031..c69678c512f1 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -141,6 +141,30 @@ has_mismatched_cache_type(const struct arm64_cpu_capabilities *entry,
return (ctr_real != sys) && (ctr_raw != sys);
}
+#ifdef CONFIG_ARM64_ERRATUM_4311569
+DEFINE_STATIC_KEY_FALSE(arm_si_l1_workaround_4311569);
+static int __init early_arm_si_l1_workaround_4311569_cfg(char *arg)
+{
+ static_branch_enable(&arm_si_l1_workaround_4311569);
+ pr_info("Enabling cache maintenance workaround for ARM SI-L1 erratum 4311569\n");
+
+ return 0;
+}
+early_param("arm_si_l1_workaround_4311569", early_arm_si_l1_workaround_4311569_cfg);
+
+/*
+ * We have some earlier use cases to call cache maintenance operation functions, for example,
+ * dcache_inval_poc() and dcache_clean_poc() in head.S, before making decision to turn on this
+ * workaround. Since the scope of this workaround is limited to non-coherent DMA agents, its
+ * safe to have the workaround off by default.
+ */
+static bool
+need_arm_si_l1_workaround_4311569(const struct arm64_cpu_capabilities *entry, int scope)
+{
+ return static_branch_unlikely(&arm_si_l1_workaround_4311569);
+}
+#endif
+
static void
cpu_enable_trap_ctr_access(const struct arm64_cpu_capabilities *cap)
{
@@ -870,6 +894,13 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
ERRATA_MIDR_RANGE_LIST(erratum_spec_ssbs_list),
},
#endif
+#ifdef CONFIG_ARM64_ERRATUM_4311569
+ {
+ .capability = ARM64_WORKAROUND_4311569,
+ .type = ARM64_CPUCAP_SYSTEM_FEATURE,
+ .matches = need_arm_si_l1_workaround_4311569,
+ },
+#endif
#ifdef CONFIG_ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD
{
.desc = "ARM errata 2966298, 3117295",
diff --git a/arch/arm64/mm/cache.S b/arch/arm64/mm/cache.S
index 503567c864fd..ddf0097624ed 100644
--- a/arch/arm64/mm/cache.S
+++ b/arch/arm64/mm/cache.S
@@ -143,9 +143,14 @@ SYM_FUNC_END(dcache_clean_pou)
* - end - kernel end address of region
*/
SYM_FUNC_START(__pi_dcache_inval_poc)
+alternative_if ARM64_WORKAROUND_4311569
+ mov x4, x0
+ mov x5, x1
+ mov x6, #1
+alternative_else_nop_endif
dcache_line_size x2, x3
sub x3, x2, #1
- tst x1, x3 // end cache line aligned?
+again: tst x1, x3 // end cache line aligned?
bic x1, x1, x3
b.eq 1f
dc civac, x1 // clean & invalidate D / U line
@@ -158,6 +163,12 @@ SYM_FUNC_START(__pi_dcache_inval_poc)
3: add x0, x0, x2
cmp x0, x1
b.lo 2b
+alternative_if ARM64_WORKAROUND_4311569
+ mov x0, x4
+ mov x1, x5
+ sub x6, x6, #1
+ cbz x6, again
+alternative_else_nop_endif
dsb sy
ret
SYM_FUNC_END(__pi_dcache_inval_poc)
diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
index 0fac75f01534..856b6cf6e71e 100644
--- a/arch/arm64/tools/cpucaps
+++ b/arch/arm64/tools/cpucaps
@@ -103,6 +103,7 @@ WORKAROUND_2077057
WORKAROUND_2457168
WORKAROUND_2645198
WORKAROUND_2658417
+WORKAROUND_4311569
WORKAROUND_AMPERE_AC03_CPU_38
WORKAROUND_AMPERE_AC04_CPU_23
WORKAROUND_TRBE_OVERWRITE_FILL_MODE
--
2.52.0.358.g0dd7633a29-goog
The reference obtained by calling usb_get_dev() is not released in the
gpio_mpsse_probe() error paths. Fix that by using device managed helper
functions. Also remove the usb_put_dev() call in the disconnect function
since now it will be released automatically.
Cc: stable(a)vger.kernel.org
Fixes: c46a74ff05c0 ("gpio: add support for FTDI's MPSSE as GPIO")
Signed-off-by: Abdun Nihaal <nihaal(a)cse.iitm.ac.in>
---
Compile tested only. Not tested on real hardware.
v1->v2:
- Switched to use devm_add_action_or_reset() to avoid unnecessary gotos,
as suggested by Bartosz Golaszewski.
Link to v1: https://lore.kernel.org/all/20251223065306.131008-1-nihaal@cse.iitm.ac.in/
drivers/gpio/gpio-mpsse.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-mpsse.c b/drivers/gpio/gpio-mpsse.c
index ace652ba4df1..12191aeb6566 100644
--- a/drivers/gpio/gpio-mpsse.c
+++ b/drivers/gpio/gpio-mpsse.c
@@ -548,6 +548,13 @@ static void gpio_mpsse_ida_remove(void *data)
ida_free(&gpio_mpsse_ida, priv->id);
}
+static void gpio_mpsse_usb_put_dev(void *data)
+{
+ struct mpsse_priv *priv = data;
+
+ usb_put_dev(priv->udev);
+}
+
static int mpsse_init_valid_mask(struct gpio_chip *chip,
unsigned long *valid_mask,
unsigned int ngpios)
@@ -592,6 +599,10 @@ static int gpio_mpsse_probe(struct usb_interface *interface,
INIT_LIST_HEAD(&priv->workers);
priv->udev = usb_get_dev(interface_to_usbdev(interface));
+ err = devm_add_action_or_reset(dev, gpio_mpsse_usb_put_dev, priv);
+ if (err)
+ return err;
+
priv->intf = interface;
priv->intf_id = interface->cur_altsetting->desc.bInterfaceNumber;
@@ -713,7 +724,6 @@ static void gpio_mpsse_disconnect(struct usb_interface *intf)
priv->intf = NULL;
usb_set_intfdata(intf, NULL);
- usb_put_dev(priv->udev);
}
static struct usb_driver gpio_mpsse_driver = {
--
2.43.0
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
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.