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

[PATCH] afs: Fix potential null pointer dereference in afs_put_server

by Zhen Ni

afs_put_server() accessed server->debug_id before the NULL check, which could lead to a null pointer dereference. Move the debug_id assignment, ensuring we never dereference a NULL server pointer. Fixes: 2757a4dc1849 ("afs: Fix access after dec in put functions") Cc: stable(a)vger.kernel.org Signed-off-by: Zhen Ni <zhen.ni(a)easystack.cn> --- fs/afs/server.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/afs/server.c b/fs/afs/server.c index a97562f831eb..c4428ebddb1d 100644 --- a/fs/afs/server.c +++ b/fs/afs/server.c @@ -331,13 +331,14 @@ struct afs_server *afs_use_server(struct afs_server *server, bool activate, void afs_put_server(struct afs_net *net, struct afs_server *server, enum afs_server_trace reason) { - unsigned int a, debug_id = server->debug_id; + unsigned int a, debug_id; bool zero; int r; if (!server) return; + debug_id = server->debug_id; a = atomic_read(&server->active); zero = __refcount_dec_and_test(&server->ref, &r); trace_afs_server(debug_id, r - 1, a, reason); -- 2.20.1

1 month, 1 week

4
3
0 0

Re: Confirmation on EOL for Linux 5.4 Stable Kernel

by Joseph Salisbury

On 9/24/25 13:41, Joseph Salisbury wrote: > Hi Greg/Sasha, > > I am reaching out to confirm the projected EOL for the Linux 5.4 > stable kernel. > > According to the information listed on kernel.org [0], the EOL is > currently slated for December 2025. We are using this projection for > planning, so we would be grateful if you could confirm it is still > accurate. > > Thank you very much for your time and for all the work you do in > maintaining the stable kernel releases! > > Thanks, > > Joe Salisbury > > > [0] https://www.kernel.org/category/releases.html Sorry, I forgot to CC stable for the wider audience. Doing that now.

1 month, 1 week

2
1
0 0

[PATCH v2] crypto: af_alg - Fix incorrect boolean values in af_alg_ctx

by Eric Biggers

Commit 1b34cbbf4f01 ("crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg") changed some fields from bool to 1-bit bitfields of type u32. However, some assignments to these fields, specifically 'more' and 'merge', assign values greater than 1. These relied on C's implicit conversion to bool, such that zero becomes false and nonzero becomes true. With a 1-bit bitfields of type u32 instead, mod 2 of the value is taken instead, resulting in 0 being assigned in some cases when 1 was intended. Fix this by restoring the bool type. Fixes: 1b34cbbf4f01 ("crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg") Cc: stable(a)vger.kernel.org Signed-off-by: Eric Biggers <ebiggers(a)kernel.org> --- v2: keep the bitfields and just change the type, as suggested by Linus include/crypto/if_alg.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/crypto/if_alg.h b/include/crypto/if_alg.h index 0c70f3a555750..107b797c33ecf 100644 --- a/include/crypto/if_alg.h +++ b/include/crypto/if_alg.h @@ -150,11 +150,11 @@ struct af_alg_ctx { struct crypto_wait wait; size_t used; atomic_t rcvused; - u32 more:1, + bool more:1, merge:1, enc:1, write:1, init:1; base-commit: cec1e6e5d1ab33403b809f79cd20d6aff124ccfe -- 2.51.0

1 month, 1 week

3
2
0 0

[PATCH RESEND] scsi: hpsa: Fix potential memory leak in hpsa_big_passthru_ioctl()

by Thorsten Blum

Replace kmalloc() followed by copy_from_user() with memdup_user() to fix a memory leak that occurs when copy_from_user(buff[sg_used],,) fails and the 'cleanup1:' path does not free the memory for 'buff[sg_used]'. Using memdup_user() avoids this by freeing the memory internally. Since memdup_user() already allocates memory, use kzalloc() in the else branch instead of manually zeroing 'buff[sg_used]' using memset(0). Cc: stable(a)vger.kernel.org Fixes: edd163687ea5 ("[SCSI] hpsa: add driver for HP Smart Array controllers.") Signed-off-by: Thorsten Blum <thorsten.blum(a)linux.dev> --- drivers/scsi/hpsa.c | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c index c73a71ac3c29..1c6161d0b85c 100644 --- a/drivers/scsi/hpsa.c +++ b/drivers/scsi/hpsa.c @@ -6522,18 +6522,21 @@ static int hpsa_big_passthru_ioctl(struct ctlr_info *h, while (left) { sz = (left > ioc->malloc_size) ? ioc->malloc_size : left; buff_size[sg_used] = sz; - buff[sg_used] = kmalloc(sz, GFP_KERNEL); - if (buff[sg_used] == NULL) { - status = -ENOMEM; - goto cleanup1; - } + if (ioc->Request.Type.Direction & XFER_WRITE) { - if (copy_from_user(buff[sg_used], data_ptr, sz)) { - status = -EFAULT; + buff[sg_used] = memdup_user(data_ptr, sz); + if (IS_ERR(buff[sg_used])) { + status = PTR_ERR(buff[sg_used]); goto cleanup1; } - } else - memset(buff[sg_used], 0, sz); + } else { + buff[sg_used] = kzalloc(sz, GFP_KERNEL); + if (!buff[sg_used]) { + status = -ENOMEM; + goto cleanup1; + } + } + left -= sz; data_ptr += sz; sg_used++; -- 2.51.0

1 month, 1 week

3
2
0 0

WTF: patch "[PATCH] LoongArch: KVM: Remove unused returns and semicolons" was seriously submitted to be applied to the 6.16-stable tree?

by gregkh＠linuxfoundation.org

The patch below was submitted to be applied to the 6.16-stable tree. I fail to see how this patch meets the stable kernel rules as found at Documentation/process/stable-kernel-rules.rst. I could be totally wrong, and if so, please respond to <stable(a)vger.kernel.org> and let me know why this patch should be applied. Otherwise, it is now dropped from my patch queues, never to be seen again. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 091b29d53fe645781c5c1f405bc9fcd50ce5792b Mon Sep 17 00:00:00 2001 From: Tao Cui <cuitao(a)kylinos.cn> Date: Thu, 18 Sep 2025 19:44:22 +0800 Subject: [PATCH] LoongArch: KVM: Remove unused returns and semicolons The default branch has already handled all undefined cases, so the final return statement is redundant. Redundant semicolons are removed, too. Cc: stable(a)vger.kernel.org Reviewed-by: Bibo Mao <maobibo(a)loongson.cn> Signed-off-by: Tao Cui <cuitao(a)kylinos.cn> Signed-off-by: Huacai Chen <chenhuacai(a)loongson.cn> diff --git a/arch/loongarch/kvm/exit.c b/arch/loongarch/kvm/exit.c index 2ce41f93b2a4..6c9c7de7226b 100644 --- a/arch/loongarch/kvm/exit.c +++ b/arch/loongarch/kvm/exit.c @@ -778,10 +778,8 @@ static long kvm_save_notify(struct kvm_vcpu *vcpu) return 0; default: return KVM_HCALL_INVALID_CODE; - }; - - return KVM_HCALL_INVALID_CODE; -}; + } +} /* * kvm_handle_lsx_disabled() - Guest used LSX while disabled in root.

1 month, 1 week

2
1
0 0

[PATCH AUTOSEL 6.16-6.1] btrfs: ref-verify: handle damaged extent root tree

by Sasha Levin

From: David Sterba <dsterba(a)suse.com> [ Upstream commit ed4e6b5d644c4dd2bc2872ffec036b7da0ec2e27 ] Syzbot hits a problem with enabled ref-verify, ignorebadroots and a fuzzed/damaged extent tree. There's no fallback option like in other places that can deal with it so disable the whole ref-verify as it is just a debugging feature. Reported-by: syzbot+9c3e0cdfbfe351b0bc0e(a)syzkaller.appspotmail.com Link: https://lore.kernel.org/all/0000000000001b6052062139be1c@google.com/ Reviewed-by: Qu Wenruo <wqu(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: Based on my exhaustive analysis of the commit, code changes, and extensive research through multiple specialized agents, here is my determination: ## **Backport Status: YES** This commit should be backported to stable kernel trees v5.11 and later. ## Detailed Explanation ### Nature of the Fix The commit fixes a **NULL pointer dereference** that occurs when mounting a corrupted BTRFS filesystem with both `rescue=ignorebadroots` and `ref_verify` options enabled. The code change adds a critical IS_ERR() check: ```c + extent_root = btrfs_extent_root(fs_info, 0); + /* If the extent tree is damaged we cannot ignore it (IGNOREBADROOTS). */ + if (IS_ERR(extent_root)) { + btrfs_warn(fs_info, "ref-verify: extent tree not available, disabling"); + btrfs_clear_opt(fs_info->mount_opt, REF_VERIFY); + return 0; + } ``` Previously, the code immediately used `extent_root` without checking if it was valid, causing a crash at line `eb = btrfs_read_lock_root_node(extent_root)`. ### Why It Qualifies for Stable Backport 1. **Fixes a Real Bug**: Prevents kernel panic during filesystem mount operations 2. **Small and Contained**: Only 7 lines of defensive code added 3. **No Side Effects**: Simply disables the debug feature gracefully instead of crashing 4. **Follows Stable Rules**: - Important bugfix (prevents crashes) - Minimal risk (simple NULL check) - Confined to subsystem (BTRFS ref-verify) ### Specific Code Analysis The fix properly handles the interaction between two features introduced at different times: - **ref-verify**: Debug feature from v4.15 (2017) - **IGNOREBADROOTS**: Recovery option from v5.11 (2020) The incompatibility wasn't caught until syzbot fuzzing discovered it. The fix: - Checks if `btrfs_extent_root()` returns an error (damaged extent tree) - Gracefully disables ref-verify with a warning message - Allows mount to proceed for recovery purposes - Returns success (0) to continue mounting ### Risk Assessment **Extremely Low Risk**: - Pattern already exists in 7+ other places in BTRFS for IGNOREBADROOTS handling - ref-verify is a debug feature (`CONFIG_BTRFS_FS_REF_VERIFY=n` by default) - Not enabled in production kernels (Ubuntu, RHEL, SUSE) - Clean cherry-pick expected to v5.11+ - Syzbot tested and verified the fix ### Comparison with Similar Commits My research found similar BTRFS NULL-check fixes routinely backported: - Commit 6aecd91a5c5b: Similar fix for scrub with IGNOREBADROOTS - Multiple IS_ERR() checks added throughout disk-io.c for root tree handling - Pattern of "disable debug feature on error" is established in ref- verify.c ### Conclusion While this primarily affects debug configurations, it meets all criteria for stable backporting: - Prevents kernel crashes (primary stable criterion) - Simple, obviously correct fix - Helps filesystem recovery operations - Zero regression risk - Follows established BTRFS error handling patterns The commit should be backported to **stable kernels v5.11 through v6.5** (kernels where both IGNOREBADROOTS and ref-verify coexist). fs/btrfs/ref-verify.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/ref-verify.c b/fs/btrfs/ref-verify.c index 2928abf7eb827..fc46190d26c8e 100644 --- a/fs/btrfs/ref-verify.c +++ b/fs/btrfs/ref-verify.c @@ -998,11 +998,18 @@ int btrfs_build_ref_tree(struct btrfs_fs_info *fs_info) if (!btrfs_test_opt(fs_info, REF_VERIFY)) return 0; + extent_root = btrfs_extent_root(fs_info, 0); + /* If the extent tree is damaged we cannot ignore it (IGNOREBADROOTS). */ + if (IS_ERR(extent_root)) { + btrfs_warn(fs_info, "ref-verify: extent tree not available, disabling"); + btrfs_clear_opt(fs_info->mount_opt, REF_VERIFY); + return 0; + } + path = btrfs_alloc_path(); if (!path) return -ENOMEM; - extent_root = btrfs_extent_root(fs_info, 0); eb = btrfs_read_lock_root_node(extent_root); level = btrfs_header_level(eb); path->nodes[level] = eb; -- 2.51.0

1 month, 1 week

2
13
0 0

+ lib-genalloc-fix-device-leak-in-of_gen_pool_get.patch added to mm-nonmm-unstable branch

by Andrew Morton

The patch titled Subject: lib/genalloc: fix device leak in of_gen_pool_get() has been added to the -mm mm-nonmm-unstable branch. Its filename is lib-genalloc-fix-device-leak-in-of_gen_pool_get.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-nonmm-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Johan Hovold <johan(a)kernel.org> Subject: lib/genalloc: fix device leak in of_gen_pool_get() Date: Wed, 24 Sep 2025 10:02:07 +0200 Make sure to drop the reference taken when looking up the genpool platform device in of_gen_pool_get() before returning the pool. Note that holding a reference to a device does typically not prevent its devres managed resources from being released so there is no point in keeping the reference. Link: https://lkml.kernel.org/r/20250924080207.18006-1-johan@kernel.org Fixes: 9375db07adea ("genalloc: add devres support, allow to find a managed pool by device") Signed-off-by: Johan Hovold <johan(a)kernel.org> Cc: Philipp Zabel <p.zabel(a)pengutronix.de> Cc: Vladimir Zapolskiy <vz(a)mleia.com> Cc: <stable(a)vger.kernel.org> [3.10+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- lib/genalloc.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/lib/genalloc.c~lib-genalloc-fix-device-leak-in-of_gen_pool_get +++ a/lib/genalloc.c @@ -899,8 +899,11 @@ struct gen_pool *of_gen_pool_get(struct if (!name) name = of_node_full_name(np_pool); } - if (pdev) + if (pdev) { pool = gen_pool_get(&pdev->dev, name); + put_device(&pdev->dev); + } + of_node_put(np_pool); return pool; _ Patches currently in -mm which might be from johan(a)kernel.org are lib-genalloc-fix-device-leak-in-of_gen_pool_get.patch

1 month, 1 week

1
0
0 0

+ mm-memblock-correct-totalram_pages-accounting-with-kmsan.patch added to mm-new branch

by Andrew Morton

The patch titled Subject: mm/memblock: correct totalram_pages accounting with KMSAN has been added to the -mm mm-new branch. Its filename is mm-memblock-correct-totalram_pages-accounting-with-kmsan.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-new branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Note, mm-new is a provisional staging ground for work-in-progress patches, and acceptance into mm-new is a notification for others take notice and to finish up reviews. Please do not hesitate to respond to review feedback and post updated versions to replace or incrementally fixup patches in mm-new. Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Alexander Potapenko <glider(a)google.com> Subject: mm/memblock: correct totalram_pages accounting with KMSAN Date: Wed, 24 Sep 2025 12:03:01 +0200 When KMSAN is enabled, `kmsan_memblock_free_pages()` can hold back pages for metadata instead of returning them to the early allocator. The callers, however, would unconditionally increment `totalram_pages`, assuming the pages were always freed. This resulted in an incorrect calculation of the total available RAM, causing the kernel to believe it had more memory than it actually did. This patch refactors `memblock_free_pages()` to return the number of pages it successfully frees. If KMSAN stashes the pages, the function now returns 0; otherwise, it returns the number of pages in the block. The callers in `memblock.c` have been updated to use this return value, ensuring that `totalram_pages` is incremented only by the number of pages actually returned to the allocator. This corrects the total RAM accounting when KMSAN is active. Link: https://lkml.kernel.org/r/20250924100301.1558645-1-glider@google.com Fixes: 3c2065098260 ("init: kmsan: call KMSAN initialization routines") Signed-off-by: Alexander Potapenko <glider(a)google.com> Reviewed-by: David Hildenbrand <david(a)redhat.com> Cc: Aleksandr Nogikh <nogikh(a)google.com> Cc: Dmitriy Vyukov <dvyukov(a)google.com> Cc: Marco Elver <elver(a)google.com> Cc: Markus Elfring <Markus.Elfring(a)web.de> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/internal.h | 4 ++-- mm/memblock.c | 21 +++++++++++---------- mm/mm_init.c | 9 +++++---- 3 files changed, 18 insertions(+), 16 deletions(-) --- a/mm/internal.h~mm-memblock-correct-totalram_pages-accounting-with-kmsan +++ a/mm/internal.h @@ -742,8 +742,8 @@ static inline void clear_zone_contiguous extern int __isolate_free_page(struct page *page, unsigned int order); extern void __putback_isolated_page(struct page *page, unsigned int order, int mt); -extern void memblock_free_pages(struct page *page, unsigned long pfn, - unsigned int order); +unsigned long memblock_free_pages(struct page *page, unsigned long pfn, + unsigned int order); extern void __free_pages_core(struct page *page, unsigned int order, enum meminit_context context); --- a/mm/memblock.c~mm-memblock-correct-totalram_pages-accounting-with-kmsan +++ a/mm/memblock.c @@ -1826,6 +1826,7 @@ void *__init __memblock_alloc_or_panic(p void __init memblock_free_late(phys_addr_t base, phys_addr_t size) { phys_addr_t cursor, end; + unsigned long freed_pages = 0; end = base + size - 1; memblock_dbg("%s: [%pa-%pa] %pS\n", @@ -1834,10 +1835,9 @@ void __init memblock_free_late(phys_addr cursor = PFN_UP(base); end = PFN_DOWN(base + size); - for (; cursor < end; cursor++) { - memblock_free_pages(pfn_to_page(cursor), cursor, 0); - totalram_pages_inc(); - } + for (; cursor < end; cursor++) + freed_pages += memblock_free_pages(pfn_to_page(cursor), cursor, 0); + totalram_pages_add(freed_pages); } /* @@ -2259,9 +2259,11 @@ static void __init free_unused_memmap(vo #endif } -static void __init __free_pages_memory(unsigned long start, unsigned long end) +static unsigned long __init __free_pages_memory(unsigned long start, + unsigned long end) { int order; + unsigned long freed = 0; while (start < end) { /* @@ -2279,14 +2281,15 @@ static void __init __free_pages_memory(u while (start + (1UL << order) > end) order--; - memblock_free_pages(pfn_to_page(start), start, order); + freed += memblock_free_pages(pfn_to_page(start), start, order); start += (1UL << order); } + return freed; } static unsigned long __init __free_memory_core(phys_addr_t start, - phys_addr_t end) + phys_addr_t end) { unsigned long start_pfn = PFN_UP(start); unsigned long end_pfn = PFN_DOWN(end); @@ -2297,9 +2300,7 @@ static unsigned long __init __free_memor if (start_pfn >= end_pfn) return 0; - __free_pages_memory(start_pfn, end_pfn); - - return end_pfn - start_pfn; + return __free_pages_memory(start_pfn, end_pfn); } static void __init memmap_init_reserved_pages(void) --- a/mm/mm_init.c~mm-memblock-correct-totalram_pages-accounting-with-kmsan +++ a/mm/mm_init.c @@ -2547,24 +2547,25 @@ void *__init alloc_large_system_hash(con return table; } -void __init memblock_free_pages(struct page *page, unsigned long pfn, - unsigned int order) +unsigned long __init memblock_free_pages(struct page *page, unsigned long pfn, + unsigned int order) { if (IS_ENABLED(CONFIG_DEFERRED_STRUCT_PAGE_INIT)) { int nid = early_pfn_to_nid(pfn); if (!early_page_initialised(pfn, nid)) - return; + return 0; } if (!kmsan_memblock_free_pages(page, order)) { /* KMSAN will take care of these pages. */ - return; + return 0; } /* pages were reserved and not allocated */ clear_page_tag_ref(page); __free_pages_core(page, order, MEMINIT_EARLY); + return 1UL << order; } DEFINE_STATIC_KEY_MAYBE(CONFIG_INIT_ON_ALLOC_DEFAULT_ON, init_on_alloc); _ Patches currently in -mm which might be from glider(a)google.com are mm-memblock-correct-totalram_pages-accounting-with-kmsan.patch

1 month, 1 week

1
0
0 0

+ mm-swap-check-for-stable-address-space-before-operating-on-the-vma.patch added to mm-new branch

by Andrew Morton

The patch titled Subject: mm: swap: check for stable address space before operating on the VMA has been added to the -mm mm-new branch. Its filename is mm-swap-check-for-stable-address-space-before-operating-on-the-vma.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-new branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Note, mm-new is a provisional staging ground for work-in-progress patches, and acceptance into mm-new is a notification for others take notice and to finish up reviews. Please do not hesitate to respond to review feedback and post updated versions to replace or incrementally fixup patches in mm-new. Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Charan Teja Kalla <charan.kalla(a)oss.qualcomm.com> Subject: mm: swap: check for stable address space before operating on the VMA Date: Wed, 24 Sep 2025 23:41:38 +0530 It is possible to hit a zero entry while traversing the vmas in unuse_mm() called from swapoff path and accessing it causes the OOPS: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000446--> Loading the memory from offset 0x40 on the XA_ZERO_ENTRY as address. Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault The issue is manifested from the below race between the fork() on a process and swapoff: fork(dup_mmap()) swapoff(unuse_mm) --------------- ----------------- 1) Identical mtree is built using __mt_dup(). 2) copy_pte_range()--> copy_nonpresent_pte(): The dst mm is added into the mmlist to be visible to the swapoff operation. 3) Fatal signal is sent to the parent process(which is the current during the fork) thus skip the duplication of the vmas and mark the vma range with XA_ZERO_ENTRY as a marker for this process that helps during exit_mmap(). 4) swapoff is tried on the 'mm' added to the 'mmlist' as part of the 2. 5) unuse_mm(), that iterates through the vma's of this 'mm' will hit the non-NULL zero entry and operating on this zero entry as a vma is resulting into the oops. The proper fix would be around not exposing this partially-valid tree to others when droping the mmap lock, which is being solved with [1]. A simpler solution would be checking for MMF_UNSTABLE, as it is set if mm_struct is not fully initialized in dup_mmap(). Thanks to Liam/Lorenzo/David for all the suggestions in fixing this issue. Link: https://lkml.kernel.org/r/20250924181138.1762750-1-charan.kalla@oss.qualcom… Link: https://lore.kernel.org/all/20250815191031.3769540-1-Liam.Howlett@oracle.co… [1] Fixes: d24062914837 ("fork: use __mt_dup() to duplicate maple tree in dup_mmap()") Signed-off-by: Charan Teja Kalla <charan.kalla(a)oss.qualcomm.com> Suggested-by: David Hildenbrand <david(a)redhat.com> Cc: Baoquan He <bhe(a)redhat.com> Cc: Barry Song <baohua(a)kernel.org> Cc: Chris Li <chrisl(a)kernel.org> Cc: Kairui Song <kasong(a)tencent.com> Cc: Kemeng Shi <shikemeng(a)huaweicloud.com> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Nhat Pham <nphamcs(a)gmail.com> Cc: Peng Zhang <zhangpeng.00(a)bytedance.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/swapfile.c | 3 +++ 1 file changed, 3 insertions(+) --- a/mm/swapfile.c~mm-swap-check-for-stable-address-space-before-operating-on-the-vma +++ a/mm/swapfile.c @@ -2389,6 +2389,8 @@ static int unuse_mm(struct mm_struct *mm VMA_ITERATOR(vmi, mm, 0); mmap_read_lock(mm); + if (check_stable_address_space(mm)) + goto unlock; for_each_vma(vmi, vma) { if (vma->anon_vma && !is_vm_hugetlb_page(vma)) { ret = unuse_vma(vma, type); @@ -2398,6 +2400,7 @@ static int unuse_mm(struct mm_struct *mm cond_resched(); } +unlock: mmap_read_unlock(mm); return ret; } _ Patches currently in -mm which might be from charan.kalla(a)oss.qualcomm.com are mm-swap-check-for-stable-address-space-before-operating-on-the-vma.patch

1 month, 1 week

1
0
0 0

[PATCH] crypto: af_alg - Fix incorrect boolean values in af_alg_ctx

by Eric Biggers

Commit 1b34cbbf4f01 ("crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg") changed some fields from bool to 1-bit bitfields. However, some assignments to these fields, specifically 'more' and 'merge', assign values greater than 1. These relied on C's implicit conversion to bool, such that zero becomes false and nonzero becomes true. With a 1-bit bitfield instead, mod 2 of the value is taken instead, resulting in 0 being assigned in some cases when 1 was intended. Fix this by restoring the bool type. Fixes: 1b34cbbf4f01 ("crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg") Cc: stable(a)vger.kernel.org Signed-off-by: Eric Biggers <ebiggers(a)kernel.org> --- include/crypto/if_alg.h | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/include/crypto/if_alg.h b/include/crypto/if_alg.h index 0c70f3a55575..02fb7c1d9ef7 100644 --- a/include/crypto/if_alg.h +++ b/include/crypto/if_alg.h @@ -150,15 +150,15 @@ struct af_alg_ctx { struct crypto_wait wait; size_t used; atomic_t rcvused; - u32 more:1, - merge:1, - enc:1, - write:1, - init:1; + bool more; + bool merge; + bool enc; + bool write; + bool init; unsigned int len; unsigned int inflight; }; base-commit: cec1e6e5d1ab33403b809f79cd20d6aff124ccfe -- 2.51.0.536.g15c5d4f767-goog

1 month, 1 week

2
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror