- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10 V1 0/5] Fix CVE-2026-90329
by Yao Yiqi 24 Sep '26

24 Sep '26

5 commits in total. PATCH 3 for CVE fix, PATCH 1 and 2 as stable dependencies, PATCH 4 and 5 as fix. Dan Carpenter (1): HID: fix an error code in hid_check_device_match() Dmitry Torokhov (2): HID: split apart hid_device_probe to make logic more apparent HID: ensure timely release of driver-allocated resources Vitaly Kuznetsov (1): HID: hyperv: streamline driver probe to avoid devres issues Yousef Alhouseen (1): HID: synchronize input before cleaning up a failed probe drivers/hid/hid-core.c | 120 ++++++++++++++++++++++++--------------- drivers/hid/hid-hyperv.c | 58 +++++++++++++------ include/linux/hid.h | 1 + 3 files changed, 115 insertions(+), 64 deletions(-) -- 2.34.1

2 6

[PATCH OLK-6.6] mm: fix bad page state in remap_try_huge_pmd() on non-empty PMD entry
by Jinjiang Tu 24 Sep '26

24 Sep '26

remap_try_huge_pmd() called pmd_free_pte_page() to free an existing PTE page table when the PMD entry was present. However, pmd_free_pte_page() uses the kernel page-table free path, which is not appropriate for user mappings. When the PMD entry is non-empty, this results in the underlying page being freed through the kernel page-table free path (__pmd_free_pte_page -> __free_pages -> free_unref_page), corrupting page state and triggering: BUG: Bad page state in process drv_hlt_dsmi_te pfn:809a2b04 page: refcount:0 mapcount:0 ... page_type: 0xfffffdff(table) page dumped because: nonzero mapcount Call trace: bad_page+0xa0/0x1f8 free_unref_page+0xb58/0x1050 __pmd_free_pte_page.part.0+0x10c/0x1f8 pmd_free_pte_page+0x4c/0x78 remap_try_huge_pmd+0x134/0x468 remap_pfn_range_internal+0x334/0x690 remap_pfn_range_try_pmd+0xb4/0x138 When the PMD entry is non-empty, fall back to 4K granularity mapping instead of attempting to free the page table. Rather than simply switching to the user page table free path, the original logic is dropped entirely because it assumes the PTE table is empty without actually checking. If a driver maps the same range repeatedly, the PTE table may still contain valid entries, and freeing it would silently destroy existing mappings without any error. Falling back to 4K granularity avoids both the wrong free path and the risk of silently corrupting existing mappings. Fixes: 923e224a1246 ("mm: introduce remap_pfn_range_try_pmd() for PMD-level hugepage mapping") --- mm/memory.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/mm/memory.c b/mm/memory.c index f98116b7b23e..7fc3eebcf1ea 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -2605,18 +2605,24 @@ static int remap_try_huge_pmd(struct mm_struct *mm, pmd_t *pmd, if (!IS_ALIGNED(pfn, HPAGE_PMD_NR)) return 0; - if (pmd_present(*pmd) && !pmd_free_pte_page(pmd, addr)) + if (!pmd_none(*pmd)) return 0; pgtable = pte_alloc_one(mm); if (unlikely(!pgtable)) return 0; - mm_inc_nr_ptes(mm); ptl = pmd_lock(mm, pmd); + if (!pmd_none(*pmd)) { + spin_unlock(ptl); + pte_free(mm, pgtable); + return 0; + } + set_pmd_at(mm, addr, pmd, pmd_mkspecial(pmd_mkhuge(pfn_pmd(pfn, prot)))); pgtable_trans_huge_deposit(mm, pmd, pgtable); spin_unlock(ptl); + mm_inc_nr_ptes(mm); return 1; } -- 2.43.0

2 1

[PATCH openEuler-1.0-LTS] mm/rmap: fix missing barrier between anon_vma init and vma->anon_vma publish
by Jinjiang Tu 24 Sep '26

24 Sep '26

mainline inclusion from mainline-v7.3 commit b6ac0b3f6013c168f22cad97e79967accacb08e1 category: bugfix bugzilla: https://gitcode.com/openeuler/kernel/issues/10048 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- On arm64 server, we find that a task trying to grab the anon_vma lock triggers hungtask. INFO: task main:2354726 blocked for more than 120 seconds. Tainted: G E 5.10.0-0021.aarch64 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:main state:D stack: 0 pid:2354726 ppid:2350673 flags:0x00000a01 Call trace: __switch_to+0x7c/0xbc __schedule+0x3b4/0x8a0 schedule+0x50/0xe0 rwsem_down_write_slowpath+0x3cc/0x6cc down_write+0x60/0x260 __anon_vma_prepare+0x6c/0x210 do_anonymous_page+0x258/0x660 handle_pte_fault+0x188/0x214 __handle_mm_fault+0x1b0/0x380 handle_mm_fault+0xf4/0x284 do_page_fault+0x19c/0x494 do_translation_fault+0xcc/0xf8 do_mem_abort+0x48/0xac el0_da+0x44/0x80 el0_sync_handler+0x88/0xb4 el0_sync+0x160/0x180 After analyzing the vmcore, we found the anon_vma->root->rwsem.count is -1. There is another anon_vma whose anon_vma->root->rwsem.count is 1, the anon_vma->root->rwsem.owner shows the lock is held, but the stack of the task shows the task doesn't hold the anon_vma lock. After adding more debugging info, we found __anon_vma_prepare() reuses anon_vma and triggers the UAF of anon_vma->root due to missing memory barrier, leading to locking and unlocking two different anon_vma->root, thus leading to an anon_vma will never be unlocked, and another anon_vma couldn't be locked anymore. This race requires two adjacent VMAs that are not merged but are anon_vma-compatible (e.g., they differ in VMA_ACCESS_FLAGS that can be changed by mprotect()). Two threads fault on each VMA concurrently, both calling __anon_vma_prepare() with only mmap_lock held for reading. THREAD A THREAD B __anon_vma_prepare __anon_vma_prepare find_mergeable_anon_vma() -> NULL anon_vma = anon_vma_alloc(); anon_vma->root = anon_vma; // the two stores may be reordered vma->anon_vma = anon_vma; // finds A's anon_vma anon_vma = find_mergeable_anon_vma(vma); anon_vma_lock_write(anon_vma); // may still see the old root down_write(&anon_vma->root->rwsem); anon_vma_unlock_write(anon_vma); // see the new root, never unlock old up_write(&anon_vma->root->rwsem); thread A triggers page fault and calls __anon_vma_prepare() to prepare anon_vma for the faulting vma. __anon_vma_prepare() allocates and initializes a new anon_vma, and then publishes it to the vma with a plain store. anon_vma_prepare() only requires the mmap_lock to be held for reading, so two threads can fault on adjacent VMAs at the same time. While thread A publishes a new anon_vma, thread B could find the anon_vma via find_mergeable_anon_vma() and then locks anon_vma->root->rwsem. The store to anon_vma->root in anon_vma_alloc() and the store to vma->anon_vma can be reordered. The anon_vma_lock_write() and spin_lock() only provide acquire semantics, which do not prevent prior stores from being reordered after them. The release semantics of the corresponding spin_unlock() and anon_vma_unlock_write() come too late, the store to vma->anon_vma is already published before they take effect. As a result, thread B can observe the following order: vma->anon_vma = anon_vma; anon_vma->root = anon_vma; The anon_vma slab is SLAB_TYPESAFE_BY_RCU, so a newly allocated anon_vma may reuse memory from a previously freed one. The constructor (anon_vma_ctor) does not reset anon_vma->root, and __put_anon_vma() doesn't clear it either, so the old root value persists until anon_vma_alloc() overwrites it. If that store isn't visible, thread B reads a root that points to the old anon_vma and locks it. As a result, thread B can call anon_vma_lock_write() with the old root, and call anon_vma_unlock_write() with the new root, leading to an anon_vma will never be unlocked, and another anon_vma couldn't be locked anymore (its count is dropped from 0 to -1 due to wrong unlock). To fix it, change the plain store `vma->anon_vma = anon_vma` to store release, so that the fields of anon_vma are visible before anon_vma is published to vma->anon_vma. At read side, the load of anon_vma and anon_vma->root have address dependency. According to Documentation/memory-barriers.txt and some investigations, only Alpha needs address-dependency barriers and it has been handled by READ_ONCE() in reusable_anon_vma(). We reproduced this issue in v5.10 with KSM enabled. The kernel doesn't merge commit cf7e7a3503df ("mm: prevent KSM from breaking VMA merging for new VMAs"), so there are many adjacent VMAs that aren't merged but are compatible for anon_vma. Without this fix, our production environment could reproduce this issue about 2-5 times each month. After adding a smp_mb() before anon_vma_lock_write(anon_vma) in __anon_vma_prepare(), which is different to this patch, this issue hasn't been reproduced for one month. Link: https://lore.kernel.org/20260908122924.554373-1-tujinjiang@huawei.com Fixes: 5c341ee1dfc8 ("mm: track the root (oldest) anon_vma") Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Reviewed-by: Lance Yang <lance.yang(a)linux.dev> Reviewed-by: Lorenzo Stoakes (ARM) <ljs(a)kernel.org> Acked-by: David Hildenbrand (Arm) <david(a)kernel.org> Acked-by: Vlastimil Babka (SUSE) <vbabka(a)kernel.org> Cc: Minchan Kim <minchan(a)kernel.org> Cc: Harry Yoo <harry(a)kernel.org> Cc: Hiroyouki Kamezawa <kamezawa.hiroyu(a)jp.fujitsu.com> Cc: Jann Horn <jannh(a)google.com> Cc: Jinjiang Tu <tujinjiang(a)huawei.com> Cc: Kefeng Wang <wangkefeng.wang(a)huawei.com> Cc: Larry Woodman <lwoodman(a)redhat.com> Cc: Liam R. Howlett <liam(a)infradead.org> Cc: Nanyong Sun <sunnanyong(a)huawei.com> Cc: Rik van Riel <riel(a)surriel.com> Cc: <stable(a)vger.kernel.org> Conflicts: mm/rmap.c mm/mmap.c mm/vma.c [Context conflicts.] Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- mm/mmap.c | 7 +++++++ mm/rmap.c | 6 +++++- 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/mm/mmap.c b/mm/mmap.c index ad643f9dd3a4..7b1e9c28a4cf 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -1235,6 +1235,13 @@ static int anon_vma_compatible(struct vm_area_struct *a, struct vm_area_struct * * acceptable for merging, so we can do all of this optimistically. But * we do that READ_ONCE() to make sure that we never re-load the pointer. * + * The READ_ONCE() establishes an address dependency between anon_vma and + * any access to its fields, which pairs with the assignment to + * vma->anon_vma performed with release semantics in __anon_vma_prepare(). + * + * This is especially important as anon_vma's are SLAB_TYPESAFE_BY_RCU so + * accessing an uninitialised anon_vma's fields may result in a UAF. + * * IOW: that the "list_is_singular()" test on the anon_vma_chain only * matters for the 'stable anon_vma' case (ie the thing we want to avoid * is to return an anon_vma that is "complex" due to having gone through diff --git a/mm/rmap.c b/mm/rmap.c index e6724fd0617c..78ca23c32cb9 100644 --- a/mm/rmap.c +++ b/mm/rmap.c @@ -199,7 +199,11 @@ int __anon_vma_prepare(struct vm_area_struct *vma) /* page_table_lock to protect against threads */ spin_lock(&mm->page_table_lock); if (likely(!vma->anon_vma)) { - vma->anon_vma = anon_vma; + /* + * Make anon_vma fields visible before anon_vma is published. + * Paired with an address dependency in reusable_anon_vma(). + */ + smp_store_release(&vma->anon_vma, anon_vma); anon_vma_chain_link(vma, avc, anon_vma); anon_vma->num_active_vmas++; allocated = NULL; -- 2.43.0

2 1

[PATCH OLK-6.6] mm/rmap: fix missing barrier between anon_vma init and vma->anon_vma publish
by Jinjiang Tu 24 Sep '26

24 Sep '26

mainline inclusion from mainline-v7.3 commit b6ac0b3f6013c168f22cad97e79967accacb08e1 category: bugfix bugzilla: https://gitcode.com/openeuler/kernel/issues/10048 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- On arm64 server, we find that a task trying to grab the anon_vma lock triggers hungtask. INFO: task main:2354726 blocked for more than 120 seconds. Tainted: G E 5.10.0-0021.aarch64 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:main state:D stack: 0 pid:2354726 ppid:2350673 flags:0x00000a01 Call trace: __switch_to+0x7c/0xbc __schedule+0x3b4/0x8a0 schedule+0x50/0xe0 rwsem_down_write_slowpath+0x3cc/0x6cc down_write+0x60/0x260 __anon_vma_prepare+0x6c/0x210 do_anonymous_page+0x258/0x660 handle_pte_fault+0x188/0x214 __handle_mm_fault+0x1b0/0x380 handle_mm_fault+0xf4/0x284 do_page_fault+0x19c/0x494 do_translation_fault+0xcc/0xf8 do_mem_abort+0x48/0xac el0_da+0x44/0x80 el0_sync_handler+0x88/0xb4 el0_sync+0x160/0x180 After analyzing the vmcore, we found the anon_vma->root->rwsem.count is -1. There is another anon_vma whose anon_vma->root->rwsem.count is 1, the anon_vma->root->rwsem.owner shows the lock is held, but the stack of the task shows the task doesn't hold the anon_vma lock. After adding more debugging info, we found __anon_vma_prepare() reuses anon_vma and triggers the UAF of anon_vma->root due to missing memory barrier, leading to locking and unlocking two different anon_vma->root, thus leading to an anon_vma will never be unlocked, and another anon_vma couldn't be locked anymore. This race requires two adjacent VMAs that are not merged but are anon_vma-compatible (e.g., they differ in VMA_ACCESS_FLAGS that can be changed by mprotect()). Two threads fault on each VMA concurrently, both calling __anon_vma_prepare() with only mmap_lock held for reading. THREAD A THREAD B __anon_vma_prepare __anon_vma_prepare find_mergeable_anon_vma() -> NULL anon_vma = anon_vma_alloc(); anon_vma->root = anon_vma; // the two stores may be reordered vma->anon_vma = anon_vma; // finds A's anon_vma anon_vma = find_mergeable_anon_vma(vma); anon_vma_lock_write(anon_vma); // may still see the old root down_write(&anon_vma->root->rwsem); anon_vma_unlock_write(anon_vma); // see the new root, never unlock old up_write(&anon_vma->root->rwsem); thread A triggers page fault and calls __anon_vma_prepare() to prepare anon_vma for the faulting vma. __anon_vma_prepare() allocates and initializes a new anon_vma, and then publishes it to the vma with a plain store. anon_vma_prepare() only requires the mmap_lock to be held for reading, so two threads can fault on adjacent VMAs at the same time. While thread A publishes a new anon_vma, thread B could find the anon_vma via find_mergeable_anon_vma() and then locks anon_vma->root->rwsem. The store to anon_vma->root in anon_vma_alloc() and the store to vma->anon_vma can be reordered. The anon_vma_lock_write() and spin_lock() only provide acquire semantics, which do not prevent prior stores from being reordered after them. The release semantics of the corresponding spin_unlock() and anon_vma_unlock_write() come too late, the store to vma->anon_vma is already published before they take effect. As a result, thread B can observe the following order: vma->anon_vma = anon_vma; anon_vma->root = anon_vma; The anon_vma slab is SLAB_TYPESAFE_BY_RCU, so a newly allocated anon_vma may reuse memory from a previously freed one. The constructor (anon_vma_ctor) does not reset anon_vma->root, and __put_anon_vma() doesn't clear it either, so the old root value persists until anon_vma_alloc() overwrites it. If that store isn't visible, thread B reads a root that points to the old anon_vma and locks it. As a result, thread B can call anon_vma_lock_write() with the old root, and call anon_vma_unlock_write() with the new root, leading to an anon_vma will never be unlocked, and another anon_vma couldn't be locked anymore (its count is dropped from 0 to -1 due to wrong unlock). To fix it, change the plain store `vma->anon_vma = anon_vma` to store release, so that the fields of anon_vma are visible before anon_vma is published to vma->anon_vma. At read side, the load of anon_vma and anon_vma->root have address dependency. According to Documentation/memory-barriers.txt and some investigations, only Alpha needs address-dependency barriers and it has been handled by READ_ONCE() in reusable_anon_vma(). We reproduced this issue in v5.10 with KSM enabled. The kernel doesn't merge commit cf7e7a3503df ("mm: prevent KSM from breaking VMA merging for new VMAs"), so there are many adjacent VMAs that aren't merged but are compatible for anon_vma. Without this fix, our production environment could reproduce this issue about 2-5 times each month. After adding a smp_mb() before anon_vma_lock_write(anon_vma) in __anon_vma_prepare(), which is different to this patch, this issue hasn't been reproduced for one month. Link: https://lore.kernel.org/20260908122924.554373-1-tujinjiang@huawei.com Fixes: 5c341ee1dfc8 ("mm: track the root (oldest) anon_vma") Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Reviewed-by: Lance Yang <lance.yang(a)linux.dev> Reviewed-by: Lorenzo Stoakes (ARM) <ljs(a)kernel.org> Acked-by: David Hildenbrand (Arm) <david(a)kernel.org> Acked-by: Vlastimil Babka (SUSE) <vbabka(a)kernel.org> Cc: Minchan Kim <minchan(a)kernel.org> Cc: Harry Yoo <harry(a)kernel.org> Cc: Hiroyouki Kamezawa <kamezawa.hiroyu(a)jp.fujitsu.com> Cc: Jann Horn <jannh(a)google.com> Cc: Jinjiang Tu <tujinjiang(a)huawei.com> Cc: Kefeng Wang <wangkefeng.wang(a)huawei.com> Cc: Larry Woodman <lwoodman(a)redhat.com> Cc: Liam R. Howlett <liam(a)infradead.org> Cc: Nanyong Sun <sunnanyong(a)huawei.com> Cc: Rik van Riel <riel(a)surriel.com> Cc: <stable(a)vger.kernel.org> Conflicts: mm/rmap.c mm/mmap.c mm/vma.c [Context conflicts.] Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- mm/mmap.c | 7 +++++++ mm/rmap.c | 6 +++++- 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/mm/mmap.c b/mm/mmap.c index 669bc1b74b35..7b0ba4395441 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -1170,6 +1170,13 @@ static int anon_vma_compatible(struct vm_area_struct *a, struct vm_area_struct * * acceptable for merging, so we can do all of this optimistically. But * we do that READ_ONCE() to make sure that we never re-load the pointer. * + * The READ_ONCE() establishes an address dependency between anon_vma and + * any access to its fields, which pairs with the assignment to + * vma->anon_vma performed with release semantics in __anon_vma_prepare(). + * + * This is especially important as anon_vma's are SLAB_TYPESAFE_BY_RCU so + * accessing an uninitialised anon_vma's fields may result in a UAF. + * * IOW: that the "list_is_singular()" test on the anon_vma_chain only * matters for the 'stable anon_vma' case (ie the thing we want to avoid * is to return an anon_vma that is "complex" due to having gone through diff --git a/mm/rmap.c b/mm/rmap.c index ad0213898dcd..12718f5ed9d2 100644 --- a/mm/rmap.c +++ b/mm/rmap.c @@ -210,7 +210,11 @@ int __anon_vma_prepare(struct vm_area_struct *vma) /* page_table_lock to protect against threads */ spin_lock(&mm->page_table_lock); if (likely(!vma->anon_vma)) { - vma->anon_vma = anon_vma; + /* + * Make anon_vma fields visible before anon_vma is published. + * Paired with an address dependency in reusable_anon_vma(). + */ + smp_store_release(&vma->anon_vma, anon_vma); anon_vma_chain_link(vma, avc, anon_vma); anon_vma->num_active_vmas++; allocated = NULL; -- 2.43.0

2 1

[PATCH OLK-5.10] mm/rmap: fix missing barrier between anon_vma init and vma->anon_vma publish
by Jinjiang Tu 24 Sep '26

24 Sep '26

mainline inclusion from mainline-v7.3 commit b6ac0b3f6013c168f22cad97e79967accacb08e1 category: bugfix bugzilla: https://gitcode.com/openeuler/kernel/issues/10048 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- On arm64 server, we find that a task trying to grab the anon_vma lock triggers hungtask. INFO: task main:2354726 blocked for more than 120 seconds. Tainted: G E 5.10.0-0021.aarch64 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:main state:D stack: 0 pid:2354726 ppid:2350673 flags:0x00000a01 Call trace: __switch_to+0x7c/0xbc __schedule+0x3b4/0x8a0 schedule+0x50/0xe0 rwsem_down_write_slowpath+0x3cc/0x6cc down_write+0x60/0x260 __anon_vma_prepare+0x6c/0x210 do_anonymous_page+0x258/0x660 handle_pte_fault+0x188/0x214 __handle_mm_fault+0x1b0/0x380 handle_mm_fault+0xf4/0x284 do_page_fault+0x19c/0x494 do_translation_fault+0xcc/0xf8 do_mem_abort+0x48/0xac el0_da+0x44/0x80 el0_sync_handler+0x88/0xb4 el0_sync+0x160/0x180 After analyzing the vmcore, we found the anon_vma->root->rwsem.count is -1. There is another anon_vma whose anon_vma->root->rwsem.count is 1, the anon_vma->root->rwsem.owner shows the lock is held, but the stack of the task shows the task doesn't hold the anon_vma lock. After adding more debugging info, we found __anon_vma_prepare() reuses anon_vma and triggers the UAF of anon_vma->root due to missing memory barrier, leading to locking and unlocking two different anon_vma->root, thus leading to an anon_vma will never be unlocked, and another anon_vma couldn't be locked anymore. This race requires two adjacent VMAs that are not merged but are anon_vma-compatible (e.g., they differ in VMA_ACCESS_FLAGS that can be changed by mprotect()). Two threads fault on each VMA concurrently, both calling __anon_vma_prepare() with only mmap_lock held for reading. THREAD A THREAD B __anon_vma_prepare __anon_vma_prepare find_mergeable_anon_vma() -> NULL anon_vma = anon_vma_alloc(); anon_vma->root = anon_vma; // the two stores may be reordered vma->anon_vma = anon_vma; // finds A's anon_vma anon_vma = find_mergeable_anon_vma(vma); anon_vma_lock_write(anon_vma); // may still see the old root down_write(&anon_vma->root->rwsem); anon_vma_unlock_write(anon_vma); // see the new root, never unlock old up_write(&anon_vma->root->rwsem); thread A triggers page fault and calls __anon_vma_prepare() to prepare anon_vma for the faulting vma. __anon_vma_prepare() allocates and initializes a new anon_vma, and then publishes it to the vma with a plain store. anon_vma_prepare() only requires the mmap_lock to be held for reading, so two threads can fault on adjacent VMAs at the same time. While thread A publishes a new anon_vma, thread B could find the anon_vma via find_mergeable_anon_vma() and then locks anon_vma->root->rwsem. The store to anon_vma->root in anon_vma_alloc() and the store to vma->anon_vma can be reordered. The anon_vma_lock_write() and spin_lock() only provide acquire semantics, which do not prevent prior stores from being reordered after them. The release semantics of the corresponding spin_unlock() and anon_vma_unlock_write() come too late, the store to vma->anon_vma is already published before they take effect. As a result, thread B can observe the following order: vma->anon_vma = anon_vma; anon_vma->root = anon_vma; The anon_vma slab is SLAB_TYPESAFE_BY_RCU, so a newly allocated anon_vma may reuse memory from a previously freed one. The constructor (anon_vma_ctor) does not reset anon_vma->root, and __put_anon_vma() doesn't clear it either, so the old root value persists until anon_vma_alloc() overwrites it. If that store isn't visible, thread B reads a root that points to the old anon_vma and locks it. As a result, thread B can call anon_vma_lock_write() with the old root, and call anon_vma_unlock_write() with the new root, leading to an anon_vma will never be unlocked, and another anon_vma couldn't be locked anymore (its count is dropped from 0 to -1 due to wrong unlock). To fix it, change the plain store `vma->anon_vma = anon_vma` to store release, so that the fields of anon_vma are visible before anon_vma is published to vma->anon_vma. At read side, the load of anon_vma and anon_vma->root have address dependency. According to Documentation/memory-barriers.txt and some investigations, only Alpha needs address-dependency barriers and it has been handled by READ_ONCE() in reusable_anon_vma(). We reproduced this issue in v5.10 with KSM enabled. The kernel doesn't merge commit cf7e7a3503df ("mm: prevent KSM from breaking VMA merging for new VMAs"), so there are many adjacent VMAs that aren't merged but are compatible for anon_vma. Without this fix, our production environment could reproduce this issue about 2-5 times each month. After adding a smp_mb() before anon_vma_lock_write(anon_vma) in __anon_vma_prepare(), which is different to this patch, this issue hasn't been reproduced for one month. Link: https://lore.kernel.org/20260908122924.554373-1-tujinjiang@huawei.com Fixes: 5c341ee1dfc8 ("mm: track the root (oldest) anon_vma") Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Reviewed-by: Lance Yang <lance.yang(a)linux.dev> Reviewed-by: Lorenzo Stoakes (ARM) <ljs(a)kernel.org> Acked-by: David Hildenbrand (Arm) <david(a)kernel.org> Acked-by: Vlastimil Babka (SUSE) <vbabka(a)kernel.org> Cc: Minchan Kim <minchan(a)kernel.org> Cc: Harry Yoo <harry(a)kernel.org> Cc: Hiroyouki Kamezawa <kamezawa.hiroyu(a)jp.fujitsu.com> Cc: Jann Horn <jannh(a)google.com> Cc: Jinjiang Tu <tujinjiang(a)huawei.com> Cc: Kefeng Wang <wangkefeng.wang(a)huawei.com> Cc: Larry Woodman <lwoodman(a)redhat.com> Cc: Liam R. Howlett <liam(a)infradead.org> Cc: Nanyong Sun <sunnanyong(a)huawei.com> Cc: Rik van Riel <riel(a)surriel.com> Cc: <stable(a)vger.kernel.org> Conflicts: mm/rmap.c mm/mmap.c mm/vma.c [Context conflicts.] Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- mm/mmap.c | 7 +++++++ mm/rmap.c | 6 +++++- 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/mm/mmap.c b/mm/mmap.c index c0262befcaae..604c0c877c5c 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -1300,6 +1300,13 @@ static int anon_vma_compatible(struct vm_area_struct *a, struct vm_area_struct * * acceptable for merging, so we can do all of this optimistically. But * we do that READ_ONCE() to make sure that we never re-load the pointer. * + * The READ_ONCE() establishes an address dependency between anon_vma and + * any access to its fields, which pairs with the assignment to + * vma->anon_vma performed with release semantics in __anon_vma_prepare(). + * + * This is especially important as anon_vma's are SLAB_TYPESAFE_BY_RCU so + * accessing an uninitialised anon_vma's fields may result in a UAF. + * * IOW: that the "list_is_singular()" test on the anon_vma_chain only * matters for the 'stable anon_vma' case (ie the thing we want to avoid * is to return an anon_vma that is "complex" due to having gone through diff --git a/mm/rmap.c b/mm/rmap.c index 150803a7ffb5..fb07b2b32a91 100644 --- a/mm/rmap.c +++ b/mm/rmap.c @@ -206,7 +206,11 @@ int __anon_vma_prepare(struct vm_area_struct *vma) /* page_table_lock to protect against threads */ spin_lock(&mm->page_table_lock); if (likely(!vma->anon_vma)) { - vma->anon_vma = anon_vma; + /* + * Make anon_vma fields visible before anon_vma is published. + * Paired with an address dependency in reusable_anon_vma(). + */ + smp_store_release(&vma->anon_vma, anon_vma); anon_vma_chain_link(vma, avc, anon_vma); anon_vma->num_active_vmas++; allocated = NULL; -- 2.43.0

2 1

[PATCH OLK-6.6 0/2] CVE-2026-89713
by Yang Erkun 24 Sep '26

24 Sep '26

Chuck Lever (1): NFSD: check truncate permission under inode lock NeilBrown (1): nfsd: Pass 'cred' instead of 'rqstp' to some functions. fs/nfsd/auth.c | 14 +++++++------- fs/nfsd/auth.h | 2 +- fs/nfsd/export.h | 3 ++- fs/nfsd/nfs4state.c | 3 ++- fs/nfsd/nfsfh.c | 6 +++--- fs/nfsd/nfsproc.c | 9 +++++---- fs/nfsd/vfs.c | 45 +++++++++++++++++++++++++++------------------ fs/nfsd/vfs.h | 4 ++-- 8 files changed, 49 insertions(+), 37 deletions(-) -- 2.52.0

2 3

[PATCH OLK-6.6] scsi: qla2xxx: Zero SFP DMA buffer in FRU/I2C bsg handlers
by Pan Taixi 24 Sep '26

24 Sep '26

From: Nilesh Javali <njavali(a)marvell.com> stable inclusion from stable-v6.6.157 commit 84bde5ce4038d9ad811e5c994305bbfcbd7a9f79 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/19080 CVE: CVE-2026-89865 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit b47d4a1547d9ef21b2e9d1a739fe2204d4be05dc upstream. The FRU and I2C bsg handlers stage their transfer in a DMA_POOL_SIZE (256-byte) bounce buffer obtained from dma_pool_alloc(), which does not zero the allocation. They initialize only a few leading bytes before handing the buffer to qla2x00_write_sfp(). qla2x00_write_sfp() can override the transfer length with a user-supplied value: if (len == 1) opt |= BIT_0; if (opt & BIT_0) len = *sfp; *sfp is the first byte of the (user-controlled) payload, so len can grow up to 255. The device then DMA-reads len bytes from the 256-byte pool buffer. Since only a small prefix was written (e.g. MAX_FRU_SIZE == 36 bytes for a FRU version, one byte for a FRU status register), the hardware reads past the initialized region and writes up to ~219 bytes of stale DMA-pool heap memory to the device flash. Allocate the buffer with dma_pool_zalloc() in all five FRU/I2C handlers so any bytes beyond the initialized data are zero rather than stale heap contents. Fixes: 697a4bc69159 ("[SCSI] qla2xxx: Provide method for updating I2C attached VPD.") Fixes: 9ebb5d9c69f1 ("[SCSI] qla2xxx: Add I2C BSG interface.") Cc: stable(a)vger.kernel.org Reported-by: Sashiko <sashiko-dev(a)google.com> Signed-off-by: Nilesh Javali <njavali(a)marvell.com> Link: https://patch.msgid.link/20260730155838.2119230-32-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) <mkp(a)kernel.org> Conflicts: drivers/scsi/qla2xxx/qla_bsg.c [Context conflicts due to aa51b8115a6a ("scsi: qla2xxx: Zero-init bsg stack buffers to avoid info leak")] Signed-off-by: Pan Taixi <pantaixi1(a)huawei.com> --- drivers/scsi/qla2xxx/qla_bsg.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/scsi/qla2xxx/qla_bsg.c b/drivers/scsi/qla2xxx/qla_bsg.c index b372bcb9ba04..55e98f39ed16 100644 --- a/drivers/scsi/qla2xxx/qla_bsg.c +++ b/drivers/scsi/qla2xxx/qla_bsg.c @@ -1563,11 +1563,11 @@ qla2x00_update_fru_versions(struct bsg_job *bsg_job) uint8_t bsg[DMA_POOL_SIZE] = {}; struct qla_image_version_list *list = (void *)bsg; struct qla_image_version *image; uint32_t count; dma_addr_t sfp_dma; - void *sfp = dma_pool_alloc(ha->s_dma_pool, GFP_KERNEL, &sfp_dma); + void *sfp = dma_pool_zalloc(ha->s_dma_pool, GFP_KERNEL, &sfp_dma); if (!sfp) { bsg_reply->reply_data.vendor_reply.vendor_rsp[0] = EXT_STATUS_NO_MEMORY; goto done; @@ -1614,11 +1614,11 @@ qla2x00_read_fru_status(struct bsg_job *bsg_job) struct qla_hw_data *ha = vha->hw; int rval = 0; uint8_t bsg[DMA_POOL_SIZE] = {}; struct qla_status_reg *sr = (void *)bsg; dma_addr_t sfp_dma; - uint8_t *sfp = dma_pool_alloc(ha->s_dma_pool, GFP_KERNEL, &sfp_dma); + uint8_t *sfp = dma_pool_zalloc(ha->s_dma_pool, GFP_KERNEL, &sfp_dma); if (!sfp) { bsg_reply->reply_data.vendor_reply.vendor_rsp[0] = EXT_STATUS_NO_MEMORY; goto done; @@ -1665,11 +1665,11 @@ qla2x00_write_fru_status(struct bsg_job *bsg_job) struct qla_hw_data *ha = vha->hw; int rval = 0; uint8_t bsg[DMA_POOL_SIZE] = {}; struct qla_status_reg *sr = (void *)bsg; dma_addr_t sfp_dma; - uint8_t *sfp = dma_pool_alloc(ha->s_dma_pool, GFP_KERNEL, &sfp_dma); + uint8_t *sfp = dma_pool_zalloc(ha->s_dma_pool, GFP_KERNEL, &sfp_dma); if (!sfp) { bsg_reply->reply_data.vendor_reply.vendor_rsp[0] = EXT_STATUS_NO_MEMORY; goto done; @@ -1712,11 +1712,11 @@ qla2x00_write_i2c(struct bsg_job *bsg_job) struct qla_hw_data *ha = vha->hw; int rval = 0; uint8_t bsg[DMA_POOL_SIZE] = {}; struct qla_i2c_access *i2c = (void *)bsg; dma_addr_t sfp_dma; - uint8_t *sfp = dma_pool_alloc(ha->s_dma_pool, GFP_KERNEL, &sfp_dma); + uint8_t *sfp = dma_pool_zalloc(ha->s_dma_pool, GFP_KERNEL, &sfp_dma); if (!sfp) { bsg_reply->reply_data.vendor_reply.vendor_rsp[0] = EXT_STATUS_NO_MEMORY; goto done; @@ -1758,11 +1758,11 @@ qla2x00_read_i2c(struct bsg_job *bsg_job) struct qla_hw_data *ha = vha->hw; int rval = 0; uint8_t bsg[DMA_POOL_SIZE] = {}; struct qla_i2c_access *i2c = (void *)bsg; dma_addr_t sfp_dma; - uint8_t *sfp = dma_pool_alloc(ha->s_dma_pool, GFP_KERNEL, &sfp_dma); + uint8_t *sfp = dma_pool_zalloc(ha->s_dma_pool, GFP_KERNEL, &sfp_dma); if (!sfp) { bsg_reply->reply_data.vendor_reply.vendor_rsp[0] = EXT_STATUS_NO_MEMORY; goto done; -- 2.34.1

2 1

[PATCH OLK-6.6] [Backport] media: cec: core: Fix kmemleak due to missed rc_free_device() call
by Tang Hui 24 Sep '26

24 Sep '26

From: Jonas Karlman <jonas(a)kwiboo.se> stable inclusion from stable-v6.6.157 commit 954ee95a03b4d31d4505591bfaba02c24b75776b category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/19091 CVE: CVE-2026-89900 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit a24ba0653f7154e671dc8d2bf64682ab2d042792 upstream. The commit dccc0c3ddf8f ("media: rc: fix race between unregister and urb/irq callbacks") removed the implicit call to rc_free_device() from rc_unregister_device(). However, the commit missed to remove the NULL assignment of adap->rc that is now causing rc_free_device() to never be called on an allocated rc device. kmemleak reports following after e.g. dw-hdmi unbind: unreferenced object 0xffff00010ac10000 (size 4096): comm "kworker/u16:1", pid 39, jiffies 4294897739 hex dump (first 32 bytes): 20 23 4b 0a 01 00 ff ff 08 00 c1 0a 01 00 ff ff #K............. 08 00 c1 0a 01 00 ff ff 00 00 00 00 00 00 00 00 ................ backtrace (crc e11baccc): kmemleak_alloc+0x38/0x44 __kmalloc_cache_noprof+0x4a8/0x5e0 rc_allocate_device+0x48/0x2a0 cec_allocate_adapter+0x3ac/0x800 dw_hdmi_cec_probe+0x264/0x634 platform_probe+0xc0/0x188 really_probe+0x4a4/0x8e0 __driver_probe_device+0x2f8/0x440 driver_probe_device+0x60/0x160 __device_attach_driver+0x1a0/0x2a0 bus_for_each_drv+0x100/0x1a0 __device_attach+0x174/0x350 device_initial_probe+0x90/0xb0 bus_probe_device+0x4c/0x120 device_add+0xdec/0x116c platform_device_add+0x354/0x598 Remove the assignment of adap->rc to NULL to let cec_delete_adapter() free the allocated rc device after last user of the cec device exits to fix the kmemleak. Fixes: dccc0c3ddf8f ("media: rc: fix race between unregister and urb/irq callbacks") Cc: stable(a)vger.kernel.org Signed-off-by: Jonas Karlman <jonas(a)kwiboo.se> Signed-off-by: Hans Verkuil <hverkuil+cisco(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Co-authored-by: BackportAgent(a)deepseek-v4.1-flash Signed-off-by: Hulk Robot <hulkrobot(a)huawei.com> Signed-off-by: Tang Hui <tanghui20(a)huawei.com> --- drivers/media/cec/core/cec-core.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/media/cec/core/cec-core.c b/drivers/media/cec/core/cec-core.c index 74dff5f8d3365..db07bc64cd672 100644 --- a/drivers/media/cec/core/cec-core.c +++ b/drivers/media/cec/core/cec-core.c @@ -399,9 +399,7 @@ void cec_unregister_adapter(struct cec_adapter *adap) return; #ifdef CONFIG_MEDIA_CEC_RC - /* Note: rc_unregister also calls rc_free */ rc_unregister_device(adap->rc); - adap->rc = NULL; #endif debugfs_remove_recursive(adap->cec_dir); #ifdef CONFIG_CEC_NOTIFIER -- 2.34.1

2 1

[PATCH OLK-6.6] fs: fix user path of nested backing files
by Yang Erkun 24 Sep '26

24 Sep '26

From: Baokun Li <libaokun(a)linux.alibaba.com> mainline inclusion from mainline-v7.3-rc1 commit f2381b546e7e6a35c9fcee0d0ccb6c042a9aeb5d category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/19027 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- backing_file_open() derives the path to be stored in the new backing file from user_file->f_path. This is incorrect when user_file itself is a backing file, which is the case for nested stacking filesystems, e.g. overlayfs mounts where the lowerdir of one overlayfs is the merged directory of another. Since commit def3ae83da02 ("fs: store real path instead of fake path in backing file f_path") the f_path of a backing file holds the real path of the intermediate layer, not the path that the user opened. Commit 924577e4f6ca ("ovl: Fix nested backing file paths") fixed this for such configurations by passing file_user_path() from ovl_open_realfile(). However, commit 6af36aeb147a ("lsm: add backing_file LSM hooks") changed the first argument of backing_file_open() from the user path back to the user file and derived the path from user_file->f_path again, silently re-introducing the problem. As a result, files mapped through a nested overlayfs show the wrong path in /proc/<pid>/maps and in perf/ftrace mmap records. For example, with two nested overlayfs mounts: mkdir -p /ovl/{lower,upper,work,merged} /ovl/nested echo hello > /ovl/lower/foo mount -t overlay overlay \ -o lowerdir=/ovl/lower,upperdir=/ovl/upper,workdir=/ovl/work \ /ovl/merged # at least two lowerdirs are needed when upperdir is nonexistent mount -t overlay overlay \ -o lowerdir=/ovl/merged:/ovl/lower /ovl/nested mapping /ovl/nested/foo shows a disconnected path instead of the user path: # readlink /proc/self/fd/3 /ovl/nested/foo # grep foo /proc/self/maps 7f6e2c100000-7f6e2c101000 r--s 00000000 00:24 15813027 /foo The bogus path is derived from the f_path of the intermediate backing file, whose mount is a private clone that d_path() cannot resolve. Fix this by using file_user_path(), which returns the outermost user-visible path for backing files and falls back to &user_file->f_path for regular files. This restores the behavior of commit 924577e4f6ca ("ovl: Fix nested backing file paths") for overlayfs and also fixes the same problem for the other backing_file_open() callers, fuse passthrough and erofs ishare, when their user file is itself a backing file. backing_tmpfile_open() has the same pattern but is not affected: it is only called by ovl_create_tmpfile() for the upper layer, and another overlayfs is rejected as upperdir by the DCACHE_OP_REAL check in ovl_mount_dir_check(), so its user_file can never be a backing file. Fixes: 6af36aeb147a ("lsm: add backing_file LSM hooks") Cc: stable(a)vger.kernel.org Signed-off-by: Baokun Li <libaokun(a)linux.alibaba.com> Link: https://patch.msgid.link/20260804034204.3487077-1-libaokun@linux.alibaba.com Tested-by: Paul Moore <paul(a)paul-moore.com> Signed-off-by: Christian Brauner (Amutable) <brauner(a)kernel.org> Conflicts: fs/backing-file.c [Context conflicts] Signed-off-by: Yang Erkun <yangerkun(a)huawei.com> --- fs/backing-file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/backing-file.c b/fs/backing-file.c index d363f47b3236..3a35b0224e32 100644 --- a/fs/backing-file.c +++ b/fs/backing-file.c @@ -34,7 +34,7 @@ struct file *backing_file_open(const struct file *user_file, int flags, const struct path *real_path, const struct cred *cred) { - const struct path *user_path = &user_file->f_path; + const struct path *user_path = file_user_path(user_file); struct file *f; int error; -- 2.52.0

2 1

[PATCH OLK-5.10] fs: fix user path of nested backing files
by Yang Erkun 24 Sep '26

24 Sep '26

From: Baokun Li <libaokun(a)linux.alibaba.com> mainline inclusion from mainline-v7.3-rc1 commit f2381b546e7e6a35c9fcee0d0ccb6c042a9aeb5d category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/19027 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- backing_file_open() derives the path to be stored in the new backing file from user_file->f_path. This is incorrect when user_file itself is a backing file, which is the case for nested stacking filesystems, e.g. overlayfs mounts where the lowerdir of one overlayfs is the merged directory of another. Since commit def3ae83da02 ("fs: store real path instead of fake path in backing file f_path") the f_path of a backing file holds the real path of the intermediate layer, not the path that the user opened. Commit 924577e4f6ca ("ovl: Fix nested backing file paths") fixed this for such configurations by passing file_user_path() from ovl_open_realfile(). However, commit 6af36aeb147a ("lsm: add backing_file LSM hooks") changed the first argument of backing_file_open() from the user path back to the user file and derived the path from user_file->f_path again, silently re-introducing the problem. As a result, files mapped through a nested overlayfs show the wrong path in /proc/<pid>/maps and in perf/ftrace mmap records. For example, with two nested overlayfs mounts: mkdir -p /ovl/{lower,upper,work,merged} /ovl/nested echo hello > /ovl/lower/foo mount -t overlay overlay \ -o lowerdir=/ovl/lower,upperdir=/ovl/upper,workdir=/ovl/work \ /ovl/merged # at least two lowerdirs are needed when upperdir is nonexistent mount -t overlay overlay \ -o lowerdir=/ovl/merged:/ovl/lower /ovl/nested mapping /ovl/nested/foo shows a disconnected path instead of the user path: # readlink /proc/self/fd/3 /ovl/nested/foo # grep foo /proc/self/maps 7f6e2c100000-7f6e2c101000 r--s 00000000 00:24 15813027 /foo The bogus path is derived from the f_path of the intermediate backing file, whose mount is a private clone that d_path() cannot resolve. Fix this by using file_user_path(), which returns the outermost user-visible path for backing files and falls back to &user_file->f_path for regular files. This restores the behavior of commit 924577e4f6ca ("ovl: Fix nested backing file paths") for overlayfs and also fixes the same problem for the other backing_file_open() callers, fuse passthrough and erofs ishare, when their user file is itself a backing file. backing_tmpfile_open() has the same pattern but is not affected: it is only called by ovl_create_tmpfile() for the upper layer, and another overlayfs is rejected as upperdir by the DCACHE_OP_REAL check in ovl_mount_dir_check(), so its user_file can never be a backing file. Fixes: 6af36aeb147a ("lsm: add backing_file LSM hooks") Cc: stable(a)vger.kernel.org Signed-off-by: Baokun Li <libaokun(a)linux.alibaba.com> Link: https://patch.msgid.link/20260804034204.3487077-1-libaokun@linux.alibaba.com Tested-by: Paul Moore <paul(a)paul-moore.com> Signed-off-by: Christian Brauner (Amutable) <brauner(a)kernel.org> Conflicts: fs/open.c [Upstream commit f2381b546e7e moved backing_file_open() into fs/backing-file.c, which does not exist in this tree; backing_file_open() still lives in fs/open.c here, so the same one-line change (use file_user_path() instead of user_file->f_path) was applied there.] Signed-off-by: Yang Erkun <yangerkun(a)huawei.com> --- fs/open.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/open.c b/fs/open.c index 44ffd83872d0..2efd2b15c48f 100644 --- a/fs/open.c +++ b/fs/open.c @@ -988,7 +988,7 @@ struct file *backing_file_open(const struct file *user_file, int flags, const struct path *real_path, const struct cred *cred) { - const struct path *user_path = &user_file->f_path; + const struct path *user_path = file_user_path(user_file); struct file *f; int error; -- 2.52.0

2 1