January 2025 - Linux-stable-mirror

[PATCH v1 1/2] mm: Clear uffd-wp PTE/PMD state on mremap()

by Ryan Roberts

When mremap()ing a memory region previously registered with userfaultfd as write-protected but without UFFD_FEATURE_EVENT_REMAP, an inconsistency in flag clearing leads to a mismatch between the vma flags (which have uffd-wp cleared) and the pte/pmd flags (which do not have uffd-wp cleared). This mismatch causes a subsequent mprotect(PROT_WRITE) to trigger a warning in page_table_check_pte_flags() due to setting the pte to writable while uffd-wp is still set. Fix this by always explicitly clearing the uffd-wp pte/pmd flags on any such mremap() so that the values are consistent with the existing clearing of VM_UFFD_WP. Be careful to clear the logical flag regardless of its physical form; a PTE bit, a swap PTE bit, or a PTE marker. Cover PTE, huge PMD and hugetlb paths. Co-developed-by: Mikołaj Lenczewski <miko.lenczewski(a)arm.com> Signed-off-by: Mikołaj Lenczewski <miko.lenczewski(a)arm.com> Signed-off-by: Ryan Roberts <ryan.roberts(a)arm.com> Closes: https://lore.kernel.org/linux-mm/810b44a8-d2ae-4107-b665-5a42eae2d948@arm.c… Fixes: 63b2d4174c4a ("userfaultfd: wp: add the writeprotect API to userfaultfd ioctl") Cc: stable(a)vger.kernel.org --- include/linux/userfaultfd_k.h | 12 ++++++++++++ mm/huge_memory.c | 12 ++++++++++++ mm/hugetlb.c | 14 +++++++++++++- mm/mremap.c | 32 +++++++++++++++++++++++++++++++- 4 files changed, 68 insertions(+), 2 deletions(-) diff --git a/include/linux/userfaultfd_k.h b/include/linux/userfaultfd_k.h index cb40f1a1d081..75342022d144 100644 --- a/include/linux/userfaultfd_k.h +++ b/include/linux/userfaultfd_k.h @@ -247,6 +247,13 @@ static inline bool vma_can_userfault(struct vm_area_struct *vma, vma_is_shmem(vma); } +static inline bool vma_has_uffd_without_event_remap(struct vm_area_struct *vma) +{ + struct userfaultfd_ctx *uffd_ctx = vma->vm_userfaultfd_ctx.ctx; + + return uffd_ctx && (uffd_ctx->features & UFFD_FEATURE_EVENT_REMAP) == 0; +} + extern int dup_userfaultfd(struct vm_area_struct *, struct list_head *); extern void dup_userfaultfd_complete(struct list_head *); void dup_userfaultfd_fail(struct list_head *); @@ -402,6 +409,11 @@ static inline bool userfaultfd_wp_async(struct vm_area_struct *vma) return false; } +static inline bool vma_has_uffd_without_event_remap(struct vm_area_struct *vma) +{ + return false; +} + #endif /* CONFIG_USERFAULTFD */ static inline bool userfaultfd_wp_use_markers(struct vm_area_struct *vma) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index c89aed1510f1..2654a9548749 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -2212,6 +2212,16 @@ static pmd_t move_soft_dirty_pmd(pmd_t pmd) return pmd; } +static pmd_t clear_uffd_wp_pmd(pmd_t pmd) +{ + if (pmd_present(pmd)) + pmd = pmd_clear_uffd_wp(pmd); + else if (is_swap_pmd(pmd)) + pmd = pmd_swp_clear_uffd_wp(pmd); + + return pmd; +} + bool move_huge_pmd(struct vm_area_struct *vma, unsigned long old_addr, unsigned long new_addr, pmd_t *old_pmd, pmd_t *new_pmd) { @@ -2250,6 +2260,8 @@ bool move_huge_pmd(struct vm_area_struct *vma, unsigned long old_addr, pgtable_trans_huge_deposit(mm, new_pmd, pgtable); } pmd = move_soft_dirty_pmd(pmd); + if (vma_has_uffd_without_event_remap(vma)) + pmd = clear_uffd_wp_pmd(pmd); set_pmd_at(mm, new_addr, new_pmd, pmd); if (force_flush) flush_pmd_tlb_range(vma, old_addr, old_addr + PMD_SIZE); diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 354eec6f7e84..cdbc55d5384f 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -5454,6 +5454,7 @@ static void move_huge_pte(struct vm_area_struct *vma, unsigned long old_addr, unsigned long new_addr, pte_t *src_pte, pte_t *dst_pte, unsigned long sz) { + bool need_clear_uffd_wp = vma_has_uffd_without_event_remap(vma); struct hstate *h = hstate_vma(vma); struct mm_struct *mm = vma->vm_mm; spinlock_t *src_ptl, *dst_ptl; @@ -5470,7 +5471,18 @@ static void move_huge_pte(struct vm_area_struct *vma, unsigned long old_addr, spin_lock_nested(src_ptl, SINGLE_DEPTH_NESTING); pte = huge_ptep_get_and_clear(mm, old_addr, src_pte); - set_huge_pte_at(mm, new_addr, dst_pte, pte, sz); + + if (need_clear_uffd_wp && pte_marker_uffd_wp(pte)) + huge_pte_clear(mm, new_addr, dst_pte, sz); + else { + if (need_clear_uffd_wp) { + if (pte_present(pte)) + pte = huge_pte_clear_uffd_wp(pte); + else if (is_swap_pte(pte)) + pte = pte_swp_clear_uffd_wp(pte); + } + set_huge_pte_at(mm, new_addr, dst_pte, pte, sz); + } if (src_ptl != dst_ptl) spin_unlock(src_ptl); diff --git a/mm/mremap.c b/mm/mremap.c index 60473413836b..cff7f552f909 100644 --- a/mm/mremap.c +++ b/mm/mremap.c @@ -138,6 +138,7 @@ static int move_ptes(struct vm_area_struct *vma, pmd_t *old_pmd, struct vm_area_struct *new_vma, pmd_t *new_pmd, unsigned long new_addr, bool need_rmap_locks) { + bool need_clear_uffd_wp = vma_has_uffd_without_event_remap(vma); struct mm_struct *mm = vma->vm_mm; pte_t *old_pte, *new_pte, pte; pmd_t dummy_pmdval; @@ -216,7 +217,18 @@ static int move_ptes(struct vm_area_struct *vma, pmd_t *old_pmd, force_flush = true; pte = move_pte(pte, old_addr, new_addr); pte = move_soft_dirty_pte(pte); - set_pte_at(mm, new_addr, new_pte, pte); + + if (need_clear_uffd_wp && pte_marker_uffd_wp(pte)) + pte_clear(mm, new_addr, new_pte); + else { + if (need_clear_uffd_wp) { + if (pte_present(pte)) + pte = pte_clear_uffd_wp(pte); + else if (is_swap_pte(pte)) + pte = pte_swp_clear_uffd_wp(pte); + } + set_pte_at(mm, new_addr, new_pte, pte); + } } arch_leave_lazy_mmu_mode(); @@ -278,6 +290,15 @@ static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr, if (WARN_ON_ONCE(!pmd_none(*new_pmd))) return false; + /* If this pmd belongs to a uffd vma with remap events disabled, we need + * to ensure that the uffd-wp state is cleared from all pgtables. This + * means recursing into lower page tables in move_page_tables(), and we + * can reuse the existing code if we simply treat the entry as "not + * moved". + */ + if (vma_has_uffd_without_event_remap(vma)) + return false; + /* * We don't have to worry about the ordering of src and dst * ptlocks because exclusive mmap_lock prevents deadlock. @@ -333,6 +354,15 @@ static bool move_normal_pud(struct vm_area_struct *vma, unsigned long old_addr, if (WARN_ON_ONCE(!pud_none(*new_pud))) return false; + /* If this pud belongs to a uffd vma with remap events disabled, we need + * to ensure that the uffd-wp state is cleared from all pgtables. This + * means recursing into lower page tables in move_page_tables(), and we + * can reuse the existing code if we simply treat the entry as "not + * moved". + */ + if (vma_has_uffd_without_event_remap(vma)) + return false; + /* * We don't have to worry about the ordering of src and dst * ptlocks because exclusive mmap_lock prevents deadlock. -- 2.43.0

2 months, 3 weeks

5
12
0 0

[PATCH v2 RESEND] PCI: fix reference leak in pci_alloc_child_bus()

by Ma Ke

When device_register(&child->dev) failed, calling put_device() to explicitly release child->dev. Otherwise, it could cause double free problem. device_register() includes device_add(). As comment of device_add() says, 'if device_add() succeeds, you should call device_del() when you want to get rid of it. If device_add() has not succeeded, use only put_device() to drop the reference count'. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 4f535093cf8f ("PCI: Put pci_dev in device tree as early as possible") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- Changes in v2: - added the bug description about the comment of device_add(); - fixed the patch as suggestions; - added Cc and Fixes table. --- drivers/pci/probe.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 2e81ab0f5a25..ae12f92c6a9d 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -1174,7 +1174,10 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus *parent, add_dev: pci_set_bus_msi_domain(child); ret = device_register(&child->dev); - WARN_ON(ret < 0); + if (WARN_ON(ret < 0)) { + put_device(&child->dev); + return NULL; + } pcibios_add_bus(child); -- 2.25.1

2 months, 3 weeks

2
1
0 0

[REGRESSION] kernel panic at bitmap_get_stats+0x2b/0xa0 since 6.12

by Harshit Mogalapalli

Hi all, We started seeing panic during boot cycle on 6.12 upstream kernel. Data points: * This is reproducible on 6.12.9 * Also reproducible on 6.13 from yesterday. * Not reproducible on 6.11 So I looked at commits between 6.11-> 6.12 , and narrowed it down to a patch series which made changed to md-bitmap.c https://lore.kernel.org/all/20240826074452.1490072-1-yukuai1@huaweicloud.co… After narrowing down further: it is narrowed down to this commit ec6bb299c7c3 md/md-bitmap: add 'sync_size' into struct md_bitmap_stats #regzbot introduced: ec6bb299c7c3 Also, the panic points to the middle line below: sb = kmap_local_page(bitmap->storage.sb_page); * stats->sync_size = le64_to_cpu(sb->sync_size); kunmap_local(sb); Call trace is as follows: [ 21.427462] Oops: general protection fault, probably for non-canonical address 0x8730d3f80000028: 0000 [#1] PREEMPT SMP NOPTI [ 21.440104] CPU: 56 UID: 0 PID: 1531 Comm: mdadm Not tainted 6.13.0-master.20250121.ol8.x86_64 #1 [ 21.450019] Hardware name: Oracle Corporation ORACLE SERVER X9-2L/ASM,MTHRBD,2U, BIOS 62110100 07/15/2024 [ 21.460710] RIP: 0010:bitmap_get_stats+0x2b/0xa0 [ 21.465872] Code: 0f 1e fa 0f 1f 44 00 00 48 89 f2 48 85 ff 74 7d 48 8b 4f 50 48 2b 0d dc 9f e5 00 48 8b 35 e5 9f e5 00 48 c1 f9 06 48 c1 e1 0c <48> 8b 4c 31 28 48 89 4a 20 48 8b 4f 18 48 89 4a 10 48 8b 4f 10 48 [ 21.486849] RSP: 0018:ff3e5f658fc3fb18 EFLAGS: 00010206 [ 21.492690] RAX: ffffffff8d17d660 RBX: ff27d0600af69690 RCX: 094b3d0000000000 [ 21.500663] RDX: ff3e5f658fc3fb28 RSI: ff27d03f80000000 RDI: ff27d06008cd9c00 [ 21.507233] mlx5_core 0000:b1:00.0: Rate limit: 127 rates are supported, range: 0Mbps to 97656Mbps [ 21.508629] RBP: ff27d0604a737418 R08: 0000000000000000 R09: 0000000000000000 [ 21.508631] R10: 0000000000000000 R11: 0000000000000000 R12: 00000000012c2000 [ 21.508631] R13: ff27d0604a737018 R14: ff27d0604a737000 R15: ff27d0604a737018 [ 21.508632] FS: 00007f61a01c98c0(0000) GS:ff27d07f7f600000(0000) knlGS:0000000000000000 [ 21.508634] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 21.508635] CR2: 000056503c28f458 CR3: 00000020c000c004 CR4: 0000000000771ef0 [ 21.518772] mlx5_core 0000:b1:00.0: E-Switch: Total vports 27, per vport: max uc(128) max mc(2048) [ 21.526600] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 21.526601] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 21.526602] PKRU: 55555554 [ 21.526603] Call Trace: [ 21.526604] <TASK> [ 21.535111] mlx5_core 0000:b1:00.0: Flow counters bulk query buffer size increased, bulk_query_len(8) [ 21.542533] ? show_trace_log_lvl+0x1b0/0x300 [ 21.542537] ? show_trace_log_lvl+0x1b0/0x300 [ 21.556126] mlx5_core 0000:b1:00.0: mlx5_pcie_event:301:(pid 529): PCIe slot advertised sufficient power (27W). [ 21.557983] ? md_seq_show+0x2d2/0x5b0 [ 21.557988] ? __die_body.cold+0x8/0x12 [ 21.641128] ? die_addr+0x3c/0x60 [ 21.645080] ? exc_general_protection+0x17d/0x400 [ 21.650574] ? asm_exc_general_protection+0x26/0x30 [ 21.656267] ? __pfx_bitmap_get_stats+0x10/0x10 [ 21.661568] ? bitmap_get_stats+0x2b/0xa0 [ 21.666277] md_seq_show+0x2d2/0x5b0 [ 21.670507] seq_read_iter+0x2b9/0x470 [ 21.674924] seq_read+0x12f/0x180 [ 21.678853] proc_reg_read+0x57/0xb0 [ 21.683074] vfs_read+0xf6/0x380 [ 21.686902] ? __seccomp_filter+0x30b/0x520 [ 21.691786] ksys_read+0x6c/0xf0 [ 21.695607] do_syscall_64+0x82/0x170 [ 21.699909] ? arch_exit_to_user_mode_prepare.isra.0+0x1e/0xd0 [ 21.706637] ? syscall_exit_to_user_mode+0x37/0x1a0 [ 21.712295] ? __memcg_slab_free_hook+0xf7/0x160 [ 21.717660] ? __x64_sys_close+0x3c/0x80 [ 21.722248] ? kmem_cache_free+0x400/0x460 [ 21.727028] ? syscall_exit_to_user_mode_prepare+0x174/0x1b0 [ 21.733553] ? arch_exit_to_user_mode_prepare.isra.0+0x1e/0xd0 [ 21.740270] ? syscall_exit_to_user_mode+0x37/0x1a0 [ 21.745913] ? do_syscall_64+0x8e/0x170 [ 21.750388] ? do_syscall_64+0x8e/0x170 [ 21.754857] ? clear_bhb_loop+0x45/0xa0 [ 21.759318] ? clear_bhb_loop+0x45/0xa0 [ 21.763772] ? clear_bhb_loop+0x45/0xa0 [ 21.768218] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 21.774014] RIP: 0033:0x7f619f862585 [ 21.778170] Code: fe ff ff 50 48 8d 3d 52 a8 06 00 e8 e5 08 02 00 0f 1f 44 00 00 f3 0f 1e fa 48 8d 05 d5 71 2a 00 8b 00 85 c0 75 0f 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 53 c3 66 90 41 54 49 89 d4 55 48 89 f5 53 89 [ 21.799471] RSP: 002b:00007ffe50c2d3c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [ 21.808099] RAX: ffffffffffffffda RBX: 000056503c2802a0 RCX: 00007f619f862585 [ 21.816240] RDX: 0000000000000400 RSI: 000056503c28d000 RDI: 0000000000000004 [ 21.824382] RBP: 0000000000000d68 R08: 0000000000000008 R09: 0000000000000001 [ 21.832518] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f619fb00860 [ 21.840654] R13: 00007f619fb013a0 R14: 000056503c280a50 R15: 000056503c281480 [ 21.848789] </TASK> [ 21.851389] Modules linked in: raid1 mgag200 drm_client_lib drm_shmem_helper drm_kms_helper sd_mod sg raid0 mlx5_core(+) ahci libahci drm crct10dif_pclmul ghash_clmulni_intel mlxfw sha512_ssse3 igb nvme sha256_ssse3 libata tls sha1_ssse3 megaraid_sas nvme_core pci_hyperv_intf psample dca nvme_auth i2c_algo_bit nfit(+) libnvdimm aesni_intel gf128mul crypto_simd cryptd [ 21.888253] ---[ end trace 0000000000000000 ]--- [ 22.452319] RIP: 0010:bitmap_get_stats+0x2b/0xa0 [ 22.457699] Code: 0f 1e fa 0f 1f 44 00 00 48 89 f2 48 85 ff 74 7d 48 8b 4f 50 48 2b 0d dc 9f e5 00 48 8b 35 e5 9f e5 00 48 c1 f9 06 48 c1 e1 0c <48> 8b 4c 31 28 48 89 4a 20 48 8b 4f 18 48 89 4a 10 48 8b 4f 10 48 [ 22.479037] RSP: 0018:ff3e5f658fc3fb18 EFLAGS: 00010206 [ 22.485067] RAX: ffffffff8d17d660 RBX: ff27d0600af69690 RCX: 094b3d0000000000 [ 22.493217] RDX: ff3e5f658fc3fb28 RSI: ff27d03f80000000 RDI: ff27d06008cd9c00 [ 22.501372] RBP: ff27d0604a737418 R08: 0000000000000000 R09: 0000000000000000 [ 22.509527] R10: 0000000000000000 R11: 0000000000000000 R12: 00000000012c2000 [ 22.517686] R13: ff27d0604a737018 R14: ff27d0604a737000 R15: ff27d0604a737018 [ 22.525845] FS: 00007f61a01c98c0(0000) GS:ff27d07f7f600000(0000) knlGS:0000000000000000 [ 22.535089] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 22.541701] CR2: 000056503c28f458 CR3: 00000020c000c004 CR4: 0000000000771ef0 [ 22.549866] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 22.558040] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 22.566202] PKRU: 55555554 [ 22.569425] Kernel panic - not syncing: Fatal exception [ 22.576477] Kernel Offset: 0xb600000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) [ 22.654941] Rebooting in 60 seconds.. I would be happy to try any patches. Thanks, Harshit

2 months, 3 weeks

2
5
0 0

[PATCH] audit: Initialize lsmctx to avoid memory allocation error

by Huacai Chen

Initialize the local variable lsmctx in audit_receive_msg(), so as to avoid memory allocation errors like: [ 258.074914] WARNING: CPU: 2 PID: 443 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x4c8/0x1040 [ 258.074994] Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 10/21/2022 [ 258.074997] pc 900000000304d588 ra 9000000003059644 tp 9000000107774000 sp 9000000107777890 [ 258.075000] a0 0000000000040cc0 a1 0000000000000012 a2 0000000000000000 a3 0000000000000000 [ 258.075003] a4 9000000107777bd0 a5 0000000000000280 a6 0000000000000010 a7 0000000000000000 [ 258.075006] t0 9000000004b4c000 t1 0000000000000001 t2 1f3f37829c264c80 t3 000000000000002e [ 258.075009] t4 0000000000000000 t5 00000000000003f6 t6 90000001066b6310 t7 000000000000002f [ 258.075011] t8 000000000000003c u0 00000000000000b4 s9 900000010006f880 s0 9000000004a4b000 [ 258.075014] s1 0000000000000000 s2 9000000004a4b000 s3 9000000106673400 s4 9000000107777af0 [ 258.075017] s5 90000001066b6300 s6 0000000000000012 s7 fffffffffffff000 s8 0000000000000004 [ 258.075019] ra: 9000000003059644 ___kmalloc_large_node+0x84/0x1e0 [ 258.075026] ERA: 900000000304d588 __alloc_pages_noprof+0x4c8/0x1040 [ 258.075030] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) [ 258.075040] PRMD: 00000004 (PPLV0 +PIE -PWE) [ 258.075045] EUEN: 00000007 (+FPE +SXE +ASXE -BTE) [ 258.075051] ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) [ 258.075056] ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0) [ 258.075061] PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) [ 258.075064] CPU: 2 UID: 0 PID: 443 Comm: auditd Not tainted 6.13.0-rc1+ #1899 [ 258.075068] Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 10/21/2022 [ 258.075070] Stack : ffffffffffffffff 0000000000000000 9000000002debf5c 9000000107774000 [ 258.075077] 90000001077774f0 0000000000000000 90000001077774f8 900000000489e480 [ 258.075083] 9000000004b380e8 9000000004b380e0 9000000107777380 0000000000000001 [ 258.075089] 0000000000000001 9000000004a4b000 1f3f37829c264c80 90000001001a9b40 [ 258.075094] 9000000107774000 9000000004b080e8 00000000000003d4 9000000004b080e8 [ 258.075100] 9000000004a580e8 000000000000002d 0000000006ebc000 900000010006f880 [ 258.075106] 00000000000000b4 0000000000000000 0000000000000004 0000000000001277 [ 258.075112] 900000000489e480 90000001066b6300 0000000000000012 fffffffffffff000 [ 258.075118] 0000000000000004 900000000489e480 9000000002def6a8 00007ffff2ba4065 [ 258.075124] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d [ 258.075129] ... [ 258.075132] Call Trace: [ 258.075135] [<9000000002def6a8>] show_stack+0x30/0x148 [ 258.075146] [<9000000002debf58>] dump_stack_lvl+0x68/0xa0 [ 258.075152] [<9000000002e0fe18>] __warn+0x80/0x108 [ 258.075158] [<900000000407486c>] report_bug+0x154/0x268 [ 258.075163] [<90000000040ad468>] do_bp+0x2a8/0x320 [ 258.075172] [<9000000002dedda0>] handle_bp+0x120/0x1c0 [ 258.075178] [<900000000304d588>] __alloc_pages_noprof+0x4c8/0x1040 [ 258.075183] [<9000000003059640>] ___kmalloc_large_node+0x80/0x1e0 [ 258.075187] [<9000000003061504>] __kmalloc_noprof+0x2c4/0x380 [ 258.075192] [<9000000002f0f7ac>] audit_receive_msg+0x764/0x1530 [ 258.075199] [<9000000002f1065c>] audit_receive+0xe4/0x1c0 [ 258.075204] [<9000000003e5abe8>] netlink_unicast+0x340/0x450 [ 258.075211] [<9000000003e5ae9c>] netlink_sendmsg+0x1a4/0x4a0 [ 258.075216] [<9000000003d9ffd0>] __sock_sendmsg+0x48/0x58 [ 258.075222] [<9000000003da32f0>] __sys_sendto+0x100/0x170 [ 258.075226] [<9000000003da3374>] sys_sendto+0x14/0x28 [ 258.075229] [<90000000040ad574>] do_syscall+0x94/0x138 [ 258.075233] [<9000000002ded318>] handle_syscall+0xb8/0x158 [ 258.075239] [ 258.075241] ---[ end trace 0000000000000000 ]--- Cc: stable(a)vger.kernel.org Fixes: 6fba89813ccf333d ("lsm: ensure the correct LSM context releaser") Signed-off-by: Huacai Chen <chenhuacai(a)loongson.cn> --- kernel/audit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/audit.c b/kernel/audit.c index 13d0144efaa3..5f5bf85bcc90 100644 --- a/kernel/audit.c +++ b/kernel/audit.c @@ -1221,7 +1221,7 @@ static int audit_receive_msg(struct sk_buff *skb, struct nlmsghdr *nlh, struct audit_buffer *ab; u16 msg_type = nlh->nlmsg_type; struct audit_sig_info *sig_data; - struct lsm_context lsmctx; + struct lsm_context lsmctx = { NULL, 0, 0 }; err = audit_netlink_ok(skb, msg_type); if (err) -- 2.47.1

2 months, 3 weeks

1
0
0 0

[PATCH v3] scsi: ufs: fix use-after free in init error and remove paths

by André Draszik

devm_blk_crypto_profile_init() registers a cleanup handler to run when the associated (platform-) device is being released. For UFS, the crypto private data and pointers are stored as part of the ufs_hba's data structure 'struct ufs_hba::crypto_profile'. This structure is allocated as part of the underlying ufshd allocation. During driver release or during error handling in ufshcd_pltfrm_init(), this structure is released as part of ufshcd_dealloc_host() before the (platform-) device associated with the crypto call above is released. Once this device is released, the crypto cleanup code will run, using the just-released 'struct ufs_hba::crypto_profile'. This causes a use-after-free situation: exynos-ufshc 14700000.ufs: ufshcd_pltfrm_init() failed -11 exynos-ufshc 14700000.ufs: probe with driver exynos-ufshc failed with error -11 Unable to handle kernel paging request at virtual address 01adafad6dadad88 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [01adafad6dadad88] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.13.0-rc5-next-20250106+ #70 Tainted: [W]=WARN Hardware name: Oriole (DT) pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : kfree+0x60/0x2d8 lr : kvfree+0x44/0x60 sp : ffff80008009ba80 x29: ffff80008009ba90 x28: 0000000000000000 x27: ffffbcc6591e0130 x26: ffffbcc659309960 x25: ffffbcc658f89c50 x24: ffffbcc659539d80 x23: ffff22e000940040 x22: ffff22e001539010 x21: ffffbcc65714b22c x20: 6b6b6b6b6b6b6b6b x19: 01adafad6dadad80 x18: 0000000000000000 x17: ffffbcc6579fbac8 x16: ffffbcc657a04300 x15: ffffbcc657a027f4 x14: ffffbcc656f969cc x13: ffffbcc6579fdc80 x12: ffffbcc6579fb194 x11: ffffbcc6579fbc34 x10: 0000000000000000 x9 : ffffbcc65714b22c x8 : ffff80008009b880 x7 : 0000000000000000 x6 : ffff80008009b940 x5 : ffff80008009b8c0 x4 : ffff22e000940518 x3 : ffff22e006f54f40 x2 : ffffbcc657a02268 x1 : ffff80007fffffff x0 : ffffc1ffc0000000 Call trace: kfree+0x60/0x2d8 (P) kvfree+0x44/0x60 blk_crypto_profile_destroy_callback+0x28/0x70 devm_action_release+0x1c/0x30 release_nodes+0x6c/0x108 devres_release_all+0x98/0x100 device_unbind_cleanup+0x20/0x70 really_probe+0x218/0x2d0 In other words, the initialisation code flow is: platform-device probe ufshcd_pltfrm_init() ufshcd_alloc_host() scsi_host_alloc() allocation of struct ufs_hba creation of scsi-host devices devm_blk_crypto_profile_init() devm registration of cleanup handler using platform-device and during error handling of ufshcd_pltfrm_init() or during driver removal: ufshcd_dealloc_host() scsi_host_put() put_device(scsi-host) release of struct ufs_hba put_device(platform-device) crypto cleanup handler To fix this use-after free, change ufshcd_alloc_host() to register a devres action to automatically cleanup the underlying SCSI device on ufshcd destruction, without requiring explicit calls to ufshcd_dealloc_host(). This way: * the crypto profile and all other ufs_hba-owned resources are destroyed before SCSI (as they've been registered after) * a memleak is plugged in tc-dwc-g210-pci.c remove() as a side-effect * EXPORT_SYMBOL_GPL(ufshcd_dealloc_host) can be removed fully as it's not needed anymore * no future drivers using ufshcd_alloc_host() could ever forget adding the cleanup Fixes: cb77cb5abe1f ("blk-crypto: rename blk_keyslot_manager to blk_crypto_profile") Fixes: d76d9d7d1009 ("scsi: ufs: use devm_blk_ksm_init()") Cc: stable(a)vger.kernel.org Signed-off-by: André Draszik <andre.draszik(a)linaro.org> --- Changes in v3: - rename devres action handler to ufshcd_devres_release() (Bart) - Link to v2: https://lore.kernel.org/r/20250114-ufshcd-fix-v2-1-2dc627590a4a@linaro.org Changes in v2: - completely new approach using devres action for Scsi_host cleanup, to ensure ordering - add Fixes: and CC: stable tags (Eric) - Link to v1: https://lore.kernel.org/r/20250113-ufshcd-fix-v1-1-ca63d1d4bd55@linaro.org --- In my case, as per above trace I initially encountered an error in ufshcd_verify_dev_init(), which made me notice this problem both during error handling and release. For reproducing, it'd be possible to change that function to just return an error, or rmmod the platform glue driver. Other approaches for solving this issue I see are the following, but I believe this one here is the cleanest: * turn 'struct ufs_hba::crypto_profile' into a dynamically allocated pointer, in which case it doesn't matter if cleanup runs after scsi_host_put() * add an explicit devm_blk_crypto_profile_deinit() to be called by API users when necessary, e.g. before ufshcd_dealloc_host() in this case * register the crypto cleanup handler against the scsi-host device instead, like in v1 of this patch --- drivers/ufs/core/ufshcd.c | 27 +++++++++++++++++---------- drivers/ufs/host/ufshcd-pci.c | 2 -- drivers/ufs/host/ufshcd-pltfrm.c | 11 ++++------- include/ufs/ufshcd.h | 1 - 4 files changed, 21 insertions(+), 20 deletions(-) diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c index 43ddae7318cb..8351795296bb 100644 --- a/drivers/ufs/core/ufshcd.c +++ b/drivers/ufs/core/ufshcd.c @@ -10279,16 +10279,6 @@ int ufshcd_system_thaw(struct device *dev) EXPORT_SYMBOL_GPL(ufshcd_system_thaw); #endif /* CONFIG_PM_SLEEP */ -/** - * ufshcd_dealloc_host - deallocate Host Bus Adapter (HBA) - * @hba: pointer to Host Bus Adapter (HBA) - */ -void ufshcd_dealloc_host(struct ufs_hba *hba) -{ - scsi_host_put(hba->host); -} -EXPORT_SYMBOL_GPL(ufshcd_dealloc_host); - /** * ufshcd_set_dma_mask - Set dma mask based on the controller * addressing capability @@ -10307,6 +10297,16 @@ static int ufshcd_set_dma_mask(struct ufs_hba *hba) return dma_set_mask_and_coherent(hba->dev, DMA_BIT_MASK(32)); } +/** + * ufshcd_devres_release - devres cleanup handler, invoked during release of + * hba->dev + * @host: pointer to SCSI host + */ +static void ufshcd_devres_release(void *host) +{ + scsi_host_put(host); +} + /** * ufshcd_alloc_host - allocate Host Bus Adapter (HBA) * @dev: pointer to device handle @@ -10334,6 +10334,13 @@ int ufshcd_alloc_host(struct device *dev, struct ufs_hba **hba_handle) err = -ENOMEM; goto out_error; } + + err = devm_add_action_or_reset(dev, ufshcd_devres_release, + host); + if (err) + return dev_err_probe(dev, err, + "failed to add ufshcd dealloc action\n"); + host->nr_maps = HCTX_TYPE_POLL + 1; hba = shost_priv(host); hba->host = host; diff --git a/drivers/ufs/host/ufshcd-pci.c b/drivers/ufs/host/ufshcd-pci.c index ea39c5d5b8cf..9cfcaad23cf9 100644 --- a/drivers/ufs/host/ufshcd-pci.c +++ b/drivers/ufs/host/ufshcd-pci.c @@ -562,7 +562,6 @@ static void ufshcd_pci_remove(struct pci_dev *pdev) pm_runtime_forbid(&pdev->dev); pm_runtime_get_noresume(&pdev->dev); ufshcd_remove(hba); - ufshcd_dealloc_host(hba); } /** @@ -605,7 +604,6 @@ ufshcd_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id) err = ufshcd_init(hba, mmio_base, pdev->irq); if (err) { dev_err(&pdev->dev, "Initialization failed\n"); - ufshcd_dealloc_host(hba); return err; } diff --git a/drivers/ufs/host/ufshcd-pltfrm.c b/drivers/ufs/host/ufshcd-pltfrm.c index 505572d4fa87..adb0a65d9df5 100644 --- a/drivers/ufs/host/ufshcd-pltfrm.c +++ b/drivers/ufs/host/ufshcd-pltfrm.c @@ -488,13 +488,13 @@ int ufshcd_pltfrm_init(struct platform_device *pdev, if (err) { dev_err(dev, "%s: clock parse failed %d\n", __func__, err); - goto dealloc_host; + goto out; } err = ufshcd_parse_regulator_info(hba); if (err) { dev_err(dev, "%s: regulator init failed %d\n", __func__, err); - goto dealloc_host; + goto out; } ufshcd_init_lanes_per_dir(hba); @@ -502,14 +502,14 @@ int ufshcd_pltfrm_init(struct platform_device *pdev, err = ufshcd_parse_operating_points(hba); if (err) { dev_err(dev, "%s: OPP parse failed %d\n", __func__, err); - goto dealloc_host; + goto out; } err = ufshcd_init(hba, mmio_base, irq); if (err) { dev_err_probe(dev, err, "Initialization failed with error %d\n", err); - goto dealloc_host; + goto out; } pm_runtime_set_active(dev); @@ -517,8 +517,6 @@ int ufshcd_pltfrm_init(struct platform_device *pdev, return 0; -dealloc_host: - ufshcd_dealloc_host(hba); out: return err; } @@ -534,7 +532,6 @@ void ufshcd_pltfrm_remove(struct platform_device *pdev) pm_runtime_get_sync(&pdev->dev); ufshcd_remove(hba); - ufshcd_dealloc_host(hba); pm_runtime_disable(&pdev->dev); pm_runtime_put_noidle(&pdev->dev); } diff --git a/include/ufs/ufshcd.h b/include/ufs/ufshcd.h index da0fa5c65081..58eb6e897827 100644 --- a/include/ufs/ufshcd.h +++ b/include/ufs/ufshcd.h @@ -1311,7 +1311,6 @@ static inline void ufshcd_rmwl(struct ufs_hba *hba, u32 mask, u32 val, u32 reg) void ufshcd_enable_irq(struct ufs_hba *hba); void ufshcd_disable_irq(struct ufs_hba *hba); int ufshcd_alloc_host(struct device *, struct ufs_hba **); -void ufshcd_dealloc_host(struct ufs_hba *); int ufshcd_hba_enable(struct ufs_hba *hba); int ufshcd_init(struct ufs_hba *, void __iomem *, unsigned int); int ufshcd_link_recovery(struct ufs_hba *hba); --- base-commit: 4e16367cfe0ce395f29d0482b78970cce8e1db73 change-id: 20250113-ufshcd-fix-52409f2d32ff Best regards, -- André Draszik <andre.draszik(a)linaro.org>

2 months, 3 weeks

2
2
0 0

+ mm-compaction-fix-ubsan-shift-out-of-bounds-warning.patch added to mm-unstable branch

by Andrew Morton

The patch titled Subject: mm/compaction: fix UBSAN shift-out-of-bounds warning has been added to the -mm mm-unstable branch. Its filename is mm-compaction-fix-ubsan-shift-out-of-bounds-warning.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-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: Liu Shixin <liushixin2(a)huawei.com> Subject: mm/compaction: fix UBSAN shift-out-of-bounds warning Date: Thu, 23 Jan 2025 10:10:29 +0800 syzkaller reported a UBSAN shift-out-of-bounds warning of (1UL << order) in isolate_freepages_block(). The bogus compound_order can be any value because it is union with flags. Add back the MAX_PAGE_ORDER check to fix the warning. Link: https://lkml.kernel.org/r/20250123021029.2826736-1-liushixin2@huawei.com Fixes: 3da0272a4c7d ("mm/compaction: correctly return failure with bogus compound_order in strict mode") Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> Cc: Baolin Wang <baolin.wang(a)linux.alibaba.com> Cc: David Hildenbrand <david(a)redhat.com> Cc: Kefeng Wang <wangkefeng.wang(a)huawei.com> Cc: Kemeng Shi <shikemeng(a)huaweicloud.com> Cc: Mattew Wilcox <willy(a)infradead.org> [English fixes] Cc: Mel Gorman <mgorman(a)techsingularity.net> Cc: Nanyong Sun <sunnanyong(a)huawei.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/compaction.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/mm/compaction.c~mm-compaction-fix-ubsan-shift-out-of-bounds-warning +++ a/mm/compaction.c @@ -631,7 +631,8 @@ static unsigned long isolate_freepages_b if (PageCompound(page)) { const unsigned int order = compound_order(page); - if (blockpfn + (1UL << order) <= end_pfn) { + if ((order <= MAX_PAGE_ORDER) && + (blockpfn + (1UL << order) <= end_pfn)) { blockpfn += (1UL << order) - 1; page += (1UL << order) - 1; nr_scanned += (1UL << order) - 1; _ Patches currently in -mm which might be from liushixin2(a)huawei.com are mm-page_isolation-avoid-call-folio_hstate-without-hugetlb_lock.patch mm-compaction-fix-ubsan-shift-out-of-bounds-warning.patch

2 months, 3 weeks

1
0
0 0

[PATCH v5.10-v5.15] Bluetooth: RFCOMM: Fix not validating setsockopt user input

by Keerthana K

From: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> [ Upstream commit a97de7bff13b1cc825c1b1344eaed8d6c2d3e695 ] syzbot reported rfcomm_sock_setsockopt_old() is copying data without checking user input length. BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_old net/bluetooth/rfcomm/sock.c:632 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70 net/bluetooth/rfcomm/sock.c:673 Read of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064 Fixes: 9f2c8a03fbb3 ("Bluetooth: Replace RFCOMM link mode with security level") Fixes: bb23c0ab8246 ("Bluetooth: Add support for deferring RFCOMM connection setup") Reported-by: syzbot <syzkaller(a)googlegroups.com> Signed-off-by: Eric Dumazet <edumazet(a)google.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Keerthana K <keerthana.kalyanasundaram(a)broadcom.com> --- net/bluetooth/rfcomm/sock.c | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c index 1db441db4..2dcb70f49 100644 --- a/net/bluetooth/rfcomm/sock.c +++ b/net/bluetooth/rfcomm/sock.c @@ -631,7 +631,7 @@ static int rfcomm_sock_setsockopt_old(struct socket *sock, int optname, switch (optname) { case RFCOMM_LM: - if (copy_from_sockptr(&opt, optval, sizeof(u32))) { + if (bt_copy_from_sockptr(&opt, sizeof(opt), optval, optlen)) { err = -EFAULT; break; } @@ -666,7 +666,6 @@ static int rfcomm_sock_setsockopt(struct socket *sock, int level, int optname, struct sock *sk = sock->sk; struct bt_security sec; int err = 0; - size_t len; u32 opt; BT_DBG("sk %p", sk); @@ -688,11 +687,9 @@ static int rfcomm_sock_setsockopt(struct socket *sock, int level, int optname, sec.level = BT_SECURITY_LOW; - len = min_t(unsigned int, sizeof(sec), optlen); - if (copy_from_sockptr(&sec, optval, len)) { - err = -EFAULT; + err = bt_copy_from_sockptr(&sec, sizeof(sec), optval, optlen); + if (err) break; - } if (sec.level > BT_SECURITY_HIGH) { err = -EINVAL; @@ -708,10 +705,9 @@ static int rfcomm_sock_setsockopt(struct socket *sock, int level, int optname, break; } - if (copy_from_sockptr(&opt, optval, sizeof(u32))) { - err = -EFAULT; + err = bt_copy_from_sockptr(&opt, sizeof(opt), optval, optlen); + if (err) break; - } if (opt) set_bit(BT_SK_DEFER_SETUP, &bt_sk(sk)->flags); -- 2.39.4

2 months, 3 weeks

4
4
0 0

[PATCH V2] cpufreq: s3c64xx: Fix compilation warning

by Viresh Kumar

The driver generates following warning when regulator support isn't enabled in the kernel. Fix it. drivers/cpufreq/s3c64xx-cpufreq.c: In function 's3c64xx_cpufreq_set_target': >> drivers/cpufreq/s3c64xx-cpufreq.c:55:22: warning: variable 'old_freq' set but not used [-Wunused-but-set-variable] 55 | unsigned int old_freq, new_freq; | ^~~~~~~~ >> drivers/cpufreq/s3c64xx-cpufreq.c:54:30: warning: variable 'dvfs' set but not used [-Wunused-but-set-variable] 54 | struct s3c64xx_dvfs *dvfs; | ^~~~ Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202501191803.CtfT7b2o-lkp@intel.com/ Cc: <stable(a)vger.kernel.org> # v5.4+ Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> --- V2: Move s3c64xx_dvfs_table too inside ifdef. drivers/cpufreq/s3c64xx-cpufreq.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/cpufreq/s3c64xx-cpufreq.c b/drivers/cpufreq/s3c64xx-cpufreq.c index c6bdfc308e99..9cef71528076 100644 --- a/drivers/cpufreq/s3c64xx-cpufreq.c +++ b/drivers/cpufreq/s3c64xx-cpufreq.c @@ -24,6 +24,7 @@ struct s3c64xx_dvfs { unsigned int vddarm_max; }; +#ifdef CONFIG_REGULATOR static struct s3c64xx_dvfs s3c64xx_dvfs_table[] = { [0] = { 1000000, 1150000 }, [1] = { 1050000, 1150000 }, @@ -31,6 +32,7 @@ static struct s3c64xx_dvfs s3c64xx_dvfs_table[] = { [3] = { 1200000, 1350000 }, [4] = { 1300000, 1350000 }, }; +#endif static struct cpufreq_frequency_table s3c64xx_freq_table[] = { { 0, 0, 66000 }, @@ -51,15 +53,16 @@ static struct cpufreq_frequency_table s3c64xx_freq_table[] = { static int s3c64xx_cpufreq_set_target(struct cpufreq_policy *policy, unsigned int index) { - struct s3c64xx_dvfs *dvfs; - unsigned int old_freq, new_freq; + unsigned int new_freq = s3c64xx_freq_table[index].frequency; int ret; +#ifdef CONFIG_REGULATOR + struct s3c64xx_dvfs *dvfs; + unsigned int old_freq; + old_freq = clk_get_rate(policy->clk) / 1000; - new_freq = s3c64xx_freq_table[index].frequency; dvfs = &s3c64xx_dvfs_table[s3c64xx_freq_table[index].driver_data]; -#ifdef CONFIG_REGULATOR if (vddarm && new_freq > old_freq) { ret = regulator_set_voltage(vddarm, dvfs->vddarm_min, -- 2.31.1.272.g89b43f80a514

2 months, 3 weeks

2
2
0 0

[PATCH 6.1.y] ext4: filesystems without casefold feature cannot be mounted with siphash

by Rajani kantha

From: Lizhi Xu <lizhi.xu(a)windriver.com> [ upstream commit 985b67cd86392310d9e9326de941c22fc9340eec ] When mounting the ext4 filesystem, if the default hash version is set to DX_HASH_SIPHASH but the casefold feature is not set, exit the mounting. Reported-by: syzbot+340581ba9dceb7e06fb3(a)syzkaller.appspotmail.com Signed-off-by: Lizhi Xu <lizhi.xu(a)windriver.com> Link: https://patch.msgid.link/20240605012335.44086-1-lizhi.xu@windriver.com Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Signed-off-by: Rajani Kantha <rajanikantha(a)engineer.com> --- fs/ext4/super.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/fs/ext4/super.c b/fs/ext4/super.c index 0b2591c07166..2e9c14e2370f 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -3546,6 +3546,13 @@ int ext4_feature_set_ok(struct super_block *sb, int readonly) return 0; } #endif + if (EXT4_SB(sb)->s_es->s_def_hash_version == DX_HASH_SIPHASH && + !ext4_has_feature_casefold(sb)) { + ext4_msg(sb, KERN_ERR, + "Filesystem without casefold feature cannot be " + "mounted with siphash"); + return 0; + } if (readonly) return 1; -- 2.35.3

2 months, 3 weeks

1
0
0 0

[PATCH v2] atm/fore200e: Fix possible data race in fore200e_open()

by Gui-Dong Han

Protect access to fore200e->available_cell_rate with rate_mtx lock to prevent potential data race. In this case, since the update depends on a prior read, a data race could lead to a wrong fore200e.available_cell_rate value. The field fore200e.available_cell_rate is generally protected by the lock fore200e.rate_mtx when accessed. In all other read and write cases, this field is consistently protected by the lock, except for this case and during initialization. This potential bug was detected by our experimental static analysis tool, which analyzes locking APIs and paired functions to identify data races and atomicity violations. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable(a)vger.kernel.org Signed-off-by: Gui-Dong Han <2045gemini(a)gmail.com> --- v2: * Added a description of the data race hazard in fore200e_open(), as suggested by Jakub Kicinski and Simon Horman. --- drivers/atm/fore200e.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c index 4fea1149e003..f62e38571440 100644 --- a/drivers/atm/fore200e.c +++ b/drivers/atm/fore200e.c @@ -1374,7 +1374,9 @@ fore200e_open(struct atm_vcc *vcc) vcc->dev_data = NULL; + mutex_lock(&fore200e->rate_mtx); fore200e->available_cell_rate += vcc->qos.txtp.max_pcr; + mutex_unlock(&fore200e->rate_mtx); kfree(fore200e_vcc); return -EINVAL; -- 2.25.1

2 months, 3 weeks

3
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror January 2025