- Linux-stable-mirror - lists.linaro.org

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

2 days, 21 hours

1
0
0 0

[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

2 days, 23 hours

1
0
0 0

[PATCH 1/5] x86, fpu: introduce fpu_load_guest_fpstate()

by Paolo Bonzini

Create a variant of fpregs_lock_and_load() that KVM can use in its vCPU entry code after preemption has been disabled. While basing it on the existing logic in vcpu_enter_guest(), ensure that fpregs_assert_state_consistent() always runs and sprinkle a few more assertions. Cc: stable(a)vger.kernel.org Fixes: 820a6ee944e7 ("kvm: x86: Add emulation for IA32_XFD", 2022-01-14) Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> --- arch/x86/include/asm/fpu/api.h | 1 + arch/x86/kernel/fpu/core.c | 17 +++++++++++++++++ arch/x86/kvm/x86.c | 8 +------- 3 files changed, 19 insertions(+), 7 deletions(-) diff --git a/arch/x86/include/asm/fpu/api.h b/arch/x86/include/asm/fpu/api.h index cd6f194a912b..0820b2621416 100644 --- a/arch/x86/include/asm/fpu/api.h +++ b/arch/x86/include/asm/fpu/api.h @@ -147,6 +147,7 @@ extern void *get_xsave_addr(struct xregs_state *xsave, int xfeature_nr); /* KVM specific functions */ extern bool fpu_alloc_guest_fpstate(struct fpu_guest *gfpu); extern void fpu_free_guest_fpstate(struct fpu_guest *gfpu); +extern void fpu_load_guest_fpstate(struct fpu_guest *gfpu); extern int fpu_swap_kvm_fpstate(struct fpu_guest *gfpu, bool enter_guest); extern int fpu_enable_guest_xfd_features(struct fpu_guest *guest_fpu, u64 xfeatures); diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c index 3ab27fb86618..a480fa8c65d5 100644 --- a/arch/x86/kernel/fpu/core.c +++ b/arch/x86/kernel/fpu/core.c @@ -878,6 +878,23 @@ void fpregs_lock_and_load(void) fpregs_assert_state_consistent(); } +void fpu_load_guest_fpstate(struct fpu_guest *gfpu) +{ +#ifdef CONFIG_X86_DEBUG_FPU + struct fpu *fpu = x86_task_fpu(current); + WARN_ON_ONCE(gfpu->fpstate != fpu->fpstate); +#endif + + lockdep_assert_preemption_disabled(); + if (test_thread_flag(TIF_NEED_FPU_LOAD)) + fpregs_restore_userregs(); + + fpregs_assert_state_consistent(); + if (gfpu->xfd_err) + wrmsrq(MSR_IA32_XFD_ERR, gfpu->xfd_err); +} +EXPORT_SYMBOL_FOR_KVM(fpu_load_guest_fpstate); + #ifdef CONFIG_X86_DEBUG_FPU /* * If current FPU state according to its tracking (loaded FPU context on this diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index ff8812f3a129..01d95192dfc5 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -11300,13 +11300,7 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu) kvm_make_request(KVM_REQ_EVENT, vcpu); } - fpregs_assert_state_consistent(); - if (test_thread_flag(TIF_NEED_FPU_LOAD)) - switch_fpu_return(); - - if (vcpu->arch.guest_fpu.xfd_err) - wrmsrq(MSR_IA32_XFD_ERR, vcpu->arch.guest_fpu.xfd_err); - + fpu_load_guest_fpstate(&vcpu->arch.guest_fpu); kvm_load_xfeatures(vcpu, true); if (unlikely(vcpu->arch.switch_db_regs && -- 2.52.0

3 days, 4 hours

2
1
0 0

[PATCH v2] gpio: mpsse: fix reference leak in gpio_mpsse_probe() error paths

by Abdun Nihaal

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

3 days, 5 hours

1
0
0 0

[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

3 days, 5 hours

1
2
0 0

[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.

3 days, 6 hours

1
0
0 0

[PATCH] ext4: publish jinode after initialization

by Li Chen

ext4_inode_attach_jinode() publishes ei->jinode to concurrent users. It assigned ei->jinode before calling jbd2_journal_init_jbd_inode(). This allows another thread to observe a non-NULL jinode with i_vfs_inode still unset. The fast commit flush path can then pass this jinode to jbd2_wait_inode_data(), which dereferences i_vfs_inode->i_mapping and may crash. Below is the crash I observe: ``` BUG: unable to handle page fault for address: 000000010beb47f4 PGD 110e51067 P4D 110e51067 PUD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 4850 Comm: fc_fsync_bench_ Not tainted 6.18.0-00764-g795a690c06a5 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 RIP: 0010:xas_find_marked+0x3d/0x2e0 Code: e0 03 48 83 f8 02 0f 84 f0 01 00 00 48 8b 47 08 48 89 c3 48 39 c6 0f 82 fd 01 00 00 48 85 c9 74 3d 48 83 f9 03 77 63 4c 8b 0f <49> 8b 71 08 48 c7 47 18 00 00 00 00 48 89 f1 83 e1 03 48 83 f9 02 RSP: 0018:ffffbbee806e7bf0 EFLAGS: 00010246 RAX: 000000000010beb4 RBX: 000000000010beb4 RCX: 0000000000000003 RDX: 0000000000000001 RSI: 0000002000300000 RDI: ffffbbee806e7c10 RBP: 0000000000000001 R08: 0000002000300000 R09: 000000010beb47ec R10: ffff9ea494590090 R11: 0000000000000000 R12: 0000002000300000 R13: ffffbbee806e7c90 R14: ffff9ea494513788 R15: ffffbbee806e7c88 FS: 00007fc2f9e3e6c0(0000) GS:ffff9ea6b1444000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000010beb47f4 CR3: 0000000119ac5000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> filemap_get_folios_tag+0x87/0x2a0 __filemap_fdatawait_range+0x5f/0xd0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __schedule+0x3e7/0x10c0 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 ? cap_safe_nice+0x37/0x70 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 filemap_fdatawait_range_keep_errors+0x12/0x40 ext4_fc_commit+0x697/0x8b0 ? ext4_file_write_iter+0x64b/0x950 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 ? vfs_write+0x356/0x480 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ext4_sync_file+0xf7/0x370 do_fsync+0x3b/0x80 ? syscall_trace_enter+0x108/0x1d0 __x64_sys_fdatasync+0x16/0x20 do_syscall_64+0x62/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ... ``` To fix this issue, initialize the jbd2_inode first and only then publish the pointer with smp_store_release(). Use smp_load_acquire() at the read sites to pair with the release and ensure the initialized fields are visible. On x86 (TSO), the crash should primarily be due to the logical early publish window (another CPU can run between the store and initialization). x86 also relies on compiler ordering; the acquire/release helpers include the necessary compiler barriers while keeping the fast-path cheap. On weakly-ordered architectures (e.g. arm64/ppc), plain "init; store ptr" is not sufficient: without release/acquire, a reader may observe the pointer while still missing prior initialization stores. The explicit pairing makes this publish/consume relationship correct under LKMM. Fixes: a361293f5fede ("jbd2: Fix oops in jbd2_journal_file_inode()") Cc: stable(a)vger.kernel.org Signed-off-by: Li Chen <me(a)linux.beauty> --- fs/ext4/ext4_jbd2.h | 18 ++++++++++++++---- fs/ext4/fast_commit.c | 9 +++++++-- fs/ext4/inode.c | 15 +++++++++++---- fs/ext4/super.c | 10 +++++++--- 4 files changed, 39 insertions(+), 13 deletions(-) diff --git a/fs/ext4/ext4_jbd2.h b/fs/ext4/ext4_jbd2.h index 63d17c5201b5..3bc79b894130 100644 --- a/fs/ext4/ext4_jbd2.h +++ b/fs/ext4/ext4_jbd2.h @@ -336,18 +336,28 @@ static inline int ext4_journal_force_commit(journal_t *journal) static inline int ext4_jbd2_inode_add_write(handle_t *handle, struct inode *inode, loff_t start_byte, loff_t length) { - if (ext4_handle_valid(handle)) + if (ext4_handle_valid(handle)) { + struct jbd2_inode *jinode; + + /* Pairs with smp_store_release() in ext4_inode_attach_jinode(). */ + jinode = smp_load_acquire(&EXT4_I(inode)->jinode); return jbd2_journal_inode_ranged_write(handle, - EXT4_I(inode)->jinode, start_byte, length); + jinode, start_byte, length); + } return 0; } static inline int ext4_jbd2_inode_add_wait(handle_t *handle, struct inode *inode, loff_t start_byte, loff_t length) { - if (ext4_handle_valid(handle)) + if (ext4_handle_valid(handle)) { + struct jbd2_inode *jinode; + + /* Pairs with smp_store_release() in ext4_inode_attach_jinode(). */ + jinode = smp_load_acquire(&EXT4_I(inode)->jinode); return jbd2_journal_inode_ranged_wait(handle, - EXT4_I(inode)->jinode, start_byte, length); + jinode, start_byte, length); + } return 0; } diff --git a/fs/ext4/fast_commit.c b/fs/ext4/fast_commit.c index a6e79b3f1b48..3f148c048a6f 100644 --- a/fs/ext4/fast_commit.c +++ b/fs/ext4/fast_commit.c @@ -1087,16 +1087,21 @@ static int ext4_fc_flush_data(journal_t *journal) struct super_block *sb = journal->j_private; struct ext4_sb_info *sbi = EXT4_SB(sb); struct ext4_inode_info *ei; + struct jbd2_inode *jinode; int ret = 0; list_for_each_entry(ei, &sbi->s_fc_q[FC_Q_MAIN], i_fc_list) { - ret = jbd2_submit_inode_data(journal, ei->jinode); + /* Pairs with smp_store_release() in ext4_inode_attach_jinode(). */ + jinode = smp_load_acquire(&ei->jinode); + ret = jbd2_submit_inode_data(journal, jinode); if (ret) return ret; } list_for_each_entry(ei, &sbi->s_fc_q[FC_Q_MAIN], i_fc_list) { - ret = jbd2_wait_inode_data(journal, ei->jinode); + /* Pairs with smp_store_release() in ext4_inode_attach_jinode(). */ + jinode = smp_load_acquire(&ei->jinode); + ret = jbd2_wait_inode_data(journal, jinode); if (ret) return ret; } diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 78ea864fa8cd..74b189c10f2b 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -126,6 +126,9 @@ void ext4_inode_csum_set(struct inode *inode, struct ext4_inode *raw, static inline int ext4_begin_ordered_truncate(struct inode *inode, loff_t new_size) { + /* Pairs with smp_store_release() in ext4_inode_attach_jinode(). */ + struct jbd2_inode *jinode = smp_load_acquire(&EXT4_I(inode)->jinode); + trace_ext4_begin_ordered_truncate(inode, new_size); /* * If jinode is zero, then we never opened the file for @@ -133,10 +136,10 @@ static inline int ext4_begin_ordered_truncate(struct inode *inode, * jbd2_journal_begin_ordered_truncate() since there's no * outstanding writes we need to flush. */ - if (!EXT4_I(inode)->jinode) + if (!jinode) return 0; return jbd2_journal_begin_ordered_truncate(EXT4_JOURNAL(inode), - EXT4_I(inode)->jinode, + jinode, new_size); } @@ -4497,8 +4500,12 @@ int ext4_inode_attach_jinode(struct inode *inode) spin_unlock(&inode->i_lock); return -ENOMEM; } - ei->jinode = jinode; - jbd2_journal_init_jbd_inode(ei->jinode, inode); + jbd2_journal_init_jbd_inode(jinode, inode); + /* + * Publish ->jinode only after it is fully initialized so that + * readers never observe a partially initialized jbd2_inode. + */ + smp_store_release(&ei->jinode, jinode); jinode = NULL; } spin_unlock(&inode->i_lock); diff --git a/fs/ext4/super.c b/fs/ext4/super.c index 43f1ac6e8559..a3f015129c00 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -1513,16 +1513,20 @@ static void destroy_inodecache(void) void ext4_clear_inode(struct inode *inode) { + struct jbd2_inode *jinode; + ext4_fc_del(inode); invalidate_inode_buffers(inode); clear_inode(inode); ext4_discard_preallocations(inode); ext4_es_remove_extent(inode, 0, EXT_MAX_BLOCKS); dquot_drop(inode); - if (EXT4_I(inode)->jinode) { + /* Pairs with smp_store_release() in ext4_inode_attach_jinode(). */ + jinode = smp_load_acquire(&EXT4_I(inode)->jinode); + if (jinode) { jbd2_journal_release_jbd_inode(EXT4_JOURNAL(inode), - EXT4_I(inode)->jinode); - jbd2_free_inode(EXT4_I(inode)->jinode); + jinode); + jbd2_free_inode(jinode); EXT4_I(inode)->jinode = NULL; } fscrypt_put_encryption_info(inode); -- 2.52.0

3 days, 6 hours

1
0
0 0

[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

3 days, 9 hours

2
1
0 0

[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

3 days, 9 hours

1
0
0 0

Tools factory from China

by decii＠pachatool.com

3 days, 10 hours

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror