July 2025 - Linux-stable-mirror

Host panic in bpf verifier when loading bpf prog in 5.10 stable kernel

by Aaron Lu

Hello, Wei reported when loading his bpf prog in 5.10.200 kernel, host would panic, this didn't happen in 5.10.135 kernel. Test on latest v5.10.238 still has this panic. [ 26.531718] BUG: kernel NULL pointer dereference, address: 0000000000000168 [ 26.538093] #PF: supervisor read access in kernel mode [ 26.542727] #PF: error_code(0x0000) - not-present page [ 26.548093] PGD 10f3e9067 P4D 10f332067 PUD 10f0c5067 PMD 0 [ 26.553211] Oops: 0000 [#1] SMP NOPTI [ 26.556531] CPU: 2 PID: 541 Comm: main Not tainted 5.10.238-00267-g01e7e36b8606 #63 [ 26.563816] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 [ 26.572357] RIP: 0010:__mark_chain_precision+0x24b/0x4d0 [ 26.576572] Code: 51 01 be 20 00 00 00 4c 89 ef 48 63 d2 e8 bd df 31 00 89 c1 83 f8 1f 7f 29 48 63 d1 48 89 d0 48 c1 e0 04 48 29 d0 48 8d 04 c3 <83> 38 01 75 c3 0f b6 74 24 06 80 78 74 00 c6 40 74 01 44 0f 44 f6 [ 26.589100] RSP: 0018:ffa0000000ff7b60 EFLAGS: 00010216 [ 26.592612] RAX: 0000000000000168 RBX: 0000000000000000 RCX: 0000000000000003 [ 26.597416] RDX: 0000000000000003 RSI: 0000000000000020 RDI: ffa0000000ff7b78 [ 26.601362] RBP: 0000000000000003 R08: ffa0000000ff7b70 R09: 0000000000000004 [ 26.604261] R10: 0000000000000007 R11: ffa0000000425000 R12: ff11000102ee2000 [ 26.607202] R13: ffa0000000ff7b78 R14: 0000000000000000 R15: ff1100010ee37140 [ 26.610327] FS: 00000000007a0630(0000) GS:ff1100081c400000(0000) knlGS:0000000000000000 [ 26.613678] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 26.616105] CR2: 0000000000000168 CR3: 0000000115e72002 CR4: 0000000000371ee0 [ 26.619059] Call Trace: [ 26.620118] adjust_reg_min_max_vals+0x133/0x340 [ 26.622048] ? krealloc+0x63/0xe0 [ 26.623435] do_check+0x38c/0xa80 [ 26.624859] do_check_common+0x15b/0x280 [ 26.626496] bpf_check+0xbe1/0xd30 [ 26.627939] ? srso_alias_return_thunk+0x5/0x7f [ 26.629796] ? trace_hardirqs_on+0x1a/0xd0 [ 26.631503] ? srso_alias_return_thunk+0x5/0x7f [ 26.633402] bpf_prog_load+0x422/0x8a0 [ 26.634987] ? srso_alias_return_thunk+0x5/0x7f [ 26.636864] ? __handle_mm_fault+0x3cb/0x6d0 [ 26.638658] ? srso_alias_return_thunk+0x5/0x7f [ 26.640543] ? lock_release+0xe3/0x110 [ 26.642114] __do_sys_bpf+0x485/0xdf0 [ 26.643624] do_syscall_64+0x33/0x40 [ 26.645110] entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ 26.647190] RIP: 0033:0x409a6e [ 26.648470] Code: 24 28 44 8b 44 24 2c e9 70 ff ff ff cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 49 89 f2 48 89 fa 48 89 ce 48 89 df 0f 05 <48> 3d 01 f0 ff ff 76 15 48 f7 d8 48 89 c1 48 c7 c0 ff ff ff ff 48 [ 26.656154] RSP: 002b:000000c00199edc0 EFLAGS: 00000212 ORIG_RAX: 0000000000000141 [ 26.659451] RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 0000000000409a6e [ 26.662375] RDX: 0000000000000098 RSI: 000000c00199f290 RDI: 0000000000000005 [ 26.665267] RBP: 000000c00199ee00 R08: 0000000000000000 R09: 0000000000000000 [ 26.668204] R10: 0000000000000000 R11: 0000000000000212 R12: 0000000000000000 [ 26.671125] R13: 0000000000000080 R14: 000000c000002380 R15: 8080808080808080 [ 26.674085] Modules linked in: [ 26.675363] CR2: 0000000000000168 [ 26.676772] ---[ end trace 3fc192ee4dabbf12 ]--- [ 26.678667] RIP: 0010:__mark_chain_precision+0x24b/0x4d0 [ 26.680926] Code: 51 01 be 20 00 00 00 4c 89 ef 48 63 d2 e8 bd df 31 00 89 c1 83 f8 1f 7f 29 48 63 d1 48 89 d0 48 c1 e0 04 48 29 d0 48 8d 04 c3 <83> 38 01 75 c3 0f b6 74 24 06 80 78 74 00 c6 40 74 01 44 0f 44 f6 [ 26.688665] RSP: 0018:ffa0000000ff7b60 EFLAGS: 00010216 [ 26.690828] RAX: 0000000000000168 RBX: 0000000000000000 RCX: 0000000000000003 [ 26.693777] RDX: 0000000000000003 RSI: 0000000000000020 RDI: ffa0000000ff7b78 [ 26.696680] RBP: 0000000000000003 R08: ffa0000000ff7b70 R09: 0000000000000004 [ 26.699651] R10: 0000000000000007 R11: ffa0000000425000 R12: ff11000102ee2000 [ 26.702561] R13: ffa0000000ff7b78 R14: 0000000000000000 R15: ff1100010ee37140 [ 26.705522] FS: 00000000007a0630(0000) GS:ff1100081c400000(0000) knlGS:0000000000000000 [ 26.708806] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 26.711179] CR2: 0000000000000168 CR3: 0000000115e72002 CR4: 0000000000371ee0 [ 26.714143] Kernel panic - not syncing: Fatal exception [ 26.716893] Kernel Offset: disabled [ 26.718911] Rebooting in 5 seconds.. I did a bisect in linux-5.10.y branch and found the fbc is commit 2474ec58b96d("bpf: allow precision tracking for programs with subprogs"). I noticed there is a commit in Linus master branch that has a fix tag for this bisected commit: commit 81335f90e8a8("bpf: unconditionally reset backtrack_state masks on global func exit"), I tried to apply it in this 5.10.y branch but since the bases are quite different, clean apply is not possible, I end up with the following diff: diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index 40ac67a04ab75..71da33fb96552 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -2118,11 +2118,9 @@ static int __mark_chain_precision(struct bpf_verifier_env *env, int frame, int r bitmap_from_u64(mask, reg_mask); for_each_set_bit(i, mask, 32) { reg = &st->frame[0]->regs[i]; - if (reg->type != SCALAR_VALUE) { - reg_mask &= ~(1u << i); - continue; - } - reg->precise = true; + reg_mask &= ~(1u << i); + if (reg->type == SCALAR_VALUE) + reg->precise = true; } return 0; } But it didn't make any difference. Here are the reproduce steps: 1 clone this repo https://github.com/bytedance/vArmor-ebpf and switch to panic-analysis branch; 2 make build A binary named main should be built. I used golang compiler downloaded here: https://go.dev/dl/go1.24.3.linux-amd64.tar.gz but other golang compiler may also work. Run main as root and it will panic the host(kernel needs CONFIG_BPF_LSM). Full dmesg and config are attached, feel free to let me know if you need any additional info, thanks. P.S. linux-5.15.y has the same situation.

3 months, 3 weeks

3
11
0 0

[PATCH 1/1] iommu/sva: Invalidate KVA range on kernel TLB flush

by Lu Baolu

The vmalloc() and vfree() functions manage virtually contiguous, but not necessarily physically contiguous, kernel memory regions. When vfree() unmaps such a region, it tears down the associated kernel page table entries and frees the physical pages. In the IOMMU Shared Virtual Addressing (SVA) context, the IOMMU hardware shares and walks the CPU's page tables. Architectures like x86 share static kernel address mappings across all user page tables, allowing the IOMMU to access the kernel portion of these tables. Modern IOMMUs often cache page table entries to optimize walk performance, even for intermediate page table levels. If kernel page table mappings are changed (e.g., by vfree()), but the IOMMU's internal caches retain stale entries, Use-After-Free (UAF) vulnerability condition arises. If these freed page table pages are reallocated for a different purpose, potentially by an attacker, the IOMMU could misinterpret the new data as valid page table entries. This allows the IOMMU to walk into attacker-controlled memory, leading to arbitrary physical memory DMA access or privilege escalation. To mitigate this, introduce a new iommu interface to flush IOMMU caches and fence pending page table walks when kernel page mappings are updated. This interface should be invoked from architecture-specific code that manages combined user and kernel page tables. Fixes: 26b25a2b98e4 ("iommu: Bind process address spaces to devices") Cc: stable(a)vger.kernel.org Co-developed-by: Jason Gunthorpe <jgg(a)nvidia.com> Signed-off-by: Jason Gunthorpe <jgg(a)nvidia.com> Signed-off-by: Lu Baolu <baolu.lu(a)linux.intel.com> --- arch/x86/mm/tlb.c | 2 ++ drivers/iommu/iommu-sva.c | 32 +++++++++++++++++++++++++++++++- include/linux/iommu.h | 4 ++++ 3 files changed, 37 insertions(+), 1 deletion(-) diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c index 39f80111e6f1..a41499dfdc3f 100644 --- a/arch/x86/mm/tlb.c +++ b/arch/x86/mm/tlb.c @@ -12,6 +12,7 @@ #include <linux/task_work.h> #include <linux/mmu_notifier.h> #include <linux/mmu_context.h> +#include <linux/iommu.h> #include <asm/tlbflush.h> #include <asm/mmu_context.h> @@ -1540,6 +1541,7 @@ void flush_tlb_kernel_range(unsigned long start, unsigned long end) kernel_tlb_flush_range(info); put_flush_tlb_info(); + iommu_sva_invalidate_kva_range(start, end); } /* diff --git a/drivers/iommu/iommu-sva.c b/drivers/iommu/iommu-sva.c index 1a51cfd82808..154384eab8a3 100644 --- a/drivers/iommu/iommu-sva.c +++ b/drivers/iommu/iommu-sva.c @@ -10,6 +10,8 @@ #include "iommu-priv.h" static DEFINE_MUTEX(iommu_sva_lock); +static DEFINE_STATIC_KEY_FALSE(iommu_sva_present); +static LIST_HEAD(iommu_sva_mms); static struct iommu_domain *iommu_sva_domain_alloc(struct device *dev, struct mm_struct *mm); @@ -42,6 +44,7 @@ static struct iommu_mm_data *iommu_alloc_mm_data(struct mm_struct *mm, struct de return ERR_PTR(-ENOSPC); } iommu_mm->pasid = pasid; + iommu_mm->mm = mm; INIT_LIST_HEAD(&iommu_mm->sva_domains); /* * Make sure the write to mm->iommu_mm is not reordered in front of @@ -132,8 +135,13 @@ struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct *mm if (ret) goto out_free_domain; domain->users = 1; - list_add(&domain->next, &mm->iommu_mm->sva_domains); + if (list_empty(&iommu_mm->sva_domains)) { + if (list_empty(&iommu_sva_mms)) + static_branch_enable(&iommu_sva_present); + list_add(&iommu_mm->mm_list_elm, &iommu_sva_mms); + } + list_add(&domain->next, &iommu_mm->sva_domains); out: refcount_set(&handle->users, 1); mutex_unlock(&iommu_sva_lock); @@ -175,6 +183,13 @@ void iommu_sva_unbind_device(struct iommu_sva *handle) list_del(&domain->next); iommu_domain_free(domain); } + + if (list_empty(&iommu_mm->sva_domains)) { + list_del(&iommu_mm->mm_list_elm); + if (list_empty(&iommu_sva_mms)) + static_branch_disable(&iommu_sva_present); + } + mutex_unlock(&iommu_sva_lock); kfree(handle); } @@ -312,3 +327,18 @@ static struct iommu_domain *iommu_sva_domain_alloc(struct device *dev, return domain; } + +void iommu_sva_invalidate_kva_range(unsigned long start, unsigned long end) +{ + struct iommu_mm_data *iommu_mm; + + might_sleep(); + + if (!static_branch_unlikely(&iommu_sva_present)) + return; + + guard(mutex)(&iommu_sva_lock); + list_for_each_entry(iommu_mm, &iommu_sva_mms, mm_list_elm) + mmu_notifier_arch_invalidate_secondary_tlbs(iommu_mm->mm, start, end); +} +EXPORT_SYMBOL_GPL(iommu_sva_invalidate_kva_range); diff --git a/include/linux/iommu.h b/include/linux/iommu.h index 156732807994..31330c12b8ee 100644 --- a/include/linux/iommu.h +++ b/include/linux/iommu.h @@ -1090,7 +1090,9 @@ struct iommu_sva { struct iommu_mm_data { u32 pasid; + struct mm_struct *mm; struct list_head sva_domains; + struct list_head mm_list_elm; }; int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode); @@ -1571,6 +1573,7 @@ struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct *mm); void iommu_sva_unbind_device(struct iommu_sva *handle); u32 iommu_sva_get_pasid(struct iommu_sva *handle); +void iommu_sva_invalidate_kva_range(unsigned long start, unsigned long end); #else static inline struct iommu_sva * iommu_sva_bind_device(struct device *dev, struct mm_struct *mm) @@ -1595,6 +1598,7 @@ static inline u32 mm_get_enqcmd_pasid(struct mm_struct *mm) } static inline void mm_pasid_drop(struct mm_struct *mm) {} +static inline void iommu_sva_invalidate_kva_range(unsigned long start, unsigned long end) {} #endif /* CONFIG_IOMMU_SVA */ #ifdef CONFIG_IOMMU_IOPF -- 2.43.0

3 months, 3 weeks

11
22
0 0

[PATCH net-next v2 1/2] net: ipv4: fix incorrect MTU in broadcast routes

by Oscar Maes

Currently, __mkroute_output overrules the MTU value configured for broadcast routes. This buggy behaviour can be reproduced with: ip link set dev eth1 mtu 9000 ip route del broadcast 192.168.0.255 dev eth1 proto kernel scope link src 192.168.0.2 ip route add broadcast 192.168.0.255 dev eth1 proto kernel scope link src 192.168.0.2 mtu 1500 The maximum packet size should be 1500, but it is actually 8000: ping -b 192.168.0.255 -s 8000 Fix __mkroute_output to allow MTU values to be configured for for broadcast routes (to support a mixed-MTU local-area-network). Signed-off-by: Oscar Maes <oscmaes92(a)gmail.com> --- net/ipv4/route.c | 1 - 1 file changed, 1 deletion(-) diff --git a/net/ipv4/route.c b/net/ipv4/route.c index 64ba377cd..f639a2ae8 100644 --- a/net/ipv4/route.c +++ b/net/ipv4/route.c @@ -2588,7 +2588,6 @@ static struct rtable *__mkroute_output(const struct fib_result *res, do_cache = true; if (type == RTN_BROADCAST) { flags |= RTCF_BROADCAST | RTCF_LOCAL; - fi = NULL; } else if (type == RTN_MULTICAST) { flags |= RTCF_MULTICAST | RTCF_LOCAL; if (!ip_check_mc_rcu(in_dev, fl4->daddr, fl4->saddr, -- 2.39.5

3 months, 3 weeks

3
3
0 0

[PATCH AUTOSEL 5.4] rxrpc: Fix oops due to non-existence of prealloc backlog struct

by Sasha Levin

From: David Howells <dhowells(a)redhat.com> [ Upstream commit 880a88f318cf1d2a0f4c0a7ff7b07e2062b434a4 ] If an AF_RXRPC service socket is opened and bound, but calls are preallocated, then rxrpc_alloc_incoming_call() will oops because the rxrpc_backlog struct doesn't get allocated until the first preallocation is made. Fix this by returning NULL from rxrpc_alloc_incoming_call() if there is no backlog struct. This will cause the incoming call to be aborted. Reported-by: Junvyyang, Tencent Zhuque Lab <zhuque(a)tencent.com> Suggested-by: Junvyyang, Tencent Zhuque Lab <zhuque(a)tencent.com> Signed-off-by: David Howells <dhowells(a)redhat.com> cc: LePremierHomme <kwqcheii(a)proton.me> cc: Marc Dionne <marc.dionne(a)auristor.com> cc: Willy Tarreau <w(a)1wt.eu> cc: Simon Horman <horms(a)kernel.org> cc: linux-afs(a)lists.infradead.org Link: https://patch.msgid.link/20250708211506.2699012-3-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: **YES** This commit should be backported to stable kernel trees for the following reasons: 1. **Fixes a Critical Kernel Oops**: The commit addresses a NULL pointer dereference that causes a kernel crash when `rx->backlog` is NULL. At line 257 of the original code, `smp_load_acquire(&b->call_backlog_head)` would dereference a NULL pointer if no preallocation was done. 2. **Minimal and Safe Fix**: The fix is a simple defensive check: ```c + if (!b) + return NULL; ``` This is placed immediately after obtaining the backlog pointer and before any usage. The fix has zero risk of regression - if `b` is NULL, the code would have crashed anyway. 3. **Clear Reproducible Scenario**: The bug occurs in a specific but realistic scenario - when an AF_RXRPC service socket is opened and bound but no calls are preallocated (meaning `rxrpc_service_prealloc()` was never called to allocate the backlog structure). 4. **Follows Stable Kernel Rules**: This fix meets all criteria for stable backporting: - Fixes a real bug that users can hit - Small and contained change (2 lines) - Obviously correct with no side effects - Already tested and merged upstream 5. **Similar to Previously Backported Fixes**: Looking at Similar Commit #2 which was marked YES, it also fixed an oops in the rxrpc preallocation/backlog system with minimal changes. The commit prevents a kernel crash with a trivial NULL check, making it an ideal candidate for stable backporting. net/rxrpc/call_accept.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/rxrpc/call_accept.c b/net/rxrpc/call_accept.c index 55fb3744552de..99f05057e4c90 100644 --- a/net/rxrpc/call_accept.c +++ b/net/rxrpc/call_accept.c @@ -281,6 +281,9 @@ static struct rxrpc_call *rxrpc_alloc_incoming_call(struct rxrpc_sock *rx, unsigned short call_tail, conn_tail, peer_tail; unsigned short call_count, conn_count; + if (!b) + return NULL; + /* #calls >= #conns >= #peers must hold true. */ call_head = smp_load_acquire(&b->call_backlog_head); call_tail = b->call_backlog_tail; -- 2.39.5

3 months, 3 weeks

1
0
0 0

[PATCH AUTOSEL 5.10] rxrpc: Fix oops due to non-existence of prealloc backlog struct

by Sasha Levin

From: David Howells <dhowells(a)redhat.com> [ Upstream commit 880a88f318cf1d2a0f4c0a7ff7b07e2062b434a4 ] If an AF_RXRPC service socket is opened and bound, but calls are preallocated, then rxrpc_alloc_incoming_call() will oops because the rxrpc_backlog struct doesn't get allocated until the first preallocation is made. Fix this by returning NULL from rxrpc_alloc_incoming_call() if there is no backlog struct. This will cause the incoming call to be aborted. Reported-by: Junvyyang, Tencent Zhuque Lab <zhuque(a)tencent.com> Suggested-by: Junvyyang, Tencent Zhuque Lab <zhuque(a)tencent.com> Signed-off-by: David Howells <dhowells(a)redhat.com> cc: LePremierHomme <kwqcheii(a)proton.me> cc: Marc Dionne <marc.dionne(a)auristor.com> cc: Willy Tarreau <w(a)1wt.eu> cc: Simon Horman <horms(a)kernel.org> cc: linux-afs(a)lists.infradead.org Link: https://patch.msgid.link/20250708211506.2699012-3-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: **YES** This commit should be backported to stable kernel trees for the following reasons: 1. **Fixes a Critical Kernel Oops**: The commit addresses a NULL pointer dereference that causes a kernel crash when `rx->backlog` is NULL. At line 257 of the original code, `smp_load_acquire(&b->call_backlog_head)` would dereference a NULL pointer if no preallocation was done. 2. **Minimal and Safe Fix**: The fix is a simple defensive check: ```c + if (!b) + return NULL; ``` This is placed immediately after obtaining the backlog pointer and before any usage. The fix has zero risk of regression - if `b` is NULL, the code would have crashed anyway. 3. **Clear Reproducible Scenario**: The bug occurs in a specific but realistic scenario - when an AF_RXRPC service socket is opened and bound but no calls are preallocated (meaning `rxrpc_service_prealloc()` was never called to allocate the backlog structure). 4. **Follows Stable Kernel Rules**: This fix meets all criteria for stable backporting: - Fixes a real bug that users can hit - Small and contained change (2 lines) - Obviously correct with no side effects - Already tested and merged upstream 5. **Similar to Previously Backported Fixes**: Looking at Similar Commit #2 which was marked YES, it also fixed an oops in the rxrpc preallocation/backlog system with minimal changes. The commit prevents a kernel crash with a trivial NULL check, making it an ideal candidate for stable backporting. net/rxrpc/call_accept.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/rxrpc/call_accept.c b/net/rxrpc/call_accept.c index 2a14d69b171f3..b96af42a1b041 100644 --- a/net/rxrpc/call_accept.c +++ b/net/rxrpc/call_accept.c @@ -271,6 +271,9 @@ static struct rxrpc_call *rxrpc_alloc_incoming_call(struct rxrpc_sock *rx, unsigned short call_tail, conn_tail, peer_tail; unsigned short call_count, conn_count; + if (!b) + return NULL; + /* #calls >= #conns >= #peers must hold true. */ call_head = smp_load_acquire(&b->call_backlog_head); call_tail = b->call_backlog_tail; -- 2.39.5

3 months, 3 weeks

1
0
0 0

[PATCH AUTOSEL 5.15 1/3] rxrpc: Fix oops due to non-existence of prealloc backlog struct

by Sasha Levin

From: David Howells <dhowells(a)redhat.com> [ Upstream commit 880a88f318cf1d2a0f4c0a7ff7b07e2062b434a4 ] If an AF_RXRPC service socket is opened and bound, but calls are preallocated, then rxrpc_alloc_incoming_call() will oops because the rxrpc_backlog struct doesn't get allocated until the first preallocation is made. Fix this by returning NULL from rxrpc_alloc_incoming_call() if there is no backlog struct. This will cause the incoming call to be aborted. Reported-by: Junvyyang, Tencent Zhuque Lab <zhuque(a)tencent.com> Suggested-by: Junvyyang, Tencent Zhuque Lab <zhuque(a)tencent.com> Signed-off-by: David Howells <dhowells(a)redhat.com> cc: LePremierHomme <kwqcheii(a)proton.me> cc: Marc Dionne <marc.dionne(a)auristor.com> cc: Willy Tarreau <w(a)1wt.eu> cc: Simon Horman <horms(a)kernel.org> cc: linux-afs(a)lists.infradead.org Link: https://patch.msgid.link/20250708211506.2699012-3-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: **YES** This commit should be backported to stable kernel trees for the following reasons: 1. **Fixes a Critical Kernel Oops**: The commit addresses a NULL pointer dereference that causes a kernel crash when `rx->backlog` is NULL. At line 257 of the original code, `smp_load_acquire(&b->call_backlog_head)` would dereference a NULL pointer if no preallocation was done. 2. **Minimal and Safe Fix**: The fix is a simple defensive check: ```c + if (!b) + return NULL; ``` This is placed immediately after obtaining the backlog pointer and before any usage. The fix has zero risk of regression - if `b` is NULL, the code would have crashed anyway. 3. **Clear Reproducible Scenario**: The bug occurs in a specific but realistic scenario - when an AF_RXRPC service socket is opened and bound but no calls are preallocated (meaning `rxrpc_service_prealloc()` was never called to allocate the backlog structure). 4. **Follows Stable Kernel Rules**: This fix meets all criteria for stable backporting: - Fixes a real bug that users can hit - Small and contained change (2 lines) - Obviously correct with no side effects - Already tested and merged upstream 5. **Similar to Previously Backported Fixes**: Looking at Similar Commit #2 which was marked YES, it also fixed an oops in the rxrpc preallocation/backlog system with minimal changes. The commit prevents a kernel crash with a trivial NULL check, making it an ideal candidate for stable backporting. net/rxrpc/call_accept.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/rxrpc/call_accept.c b/net/rxrpc/call_accept.c index 99e10eea37321..658b592e58e05 100644 --- a/net/rxrpc/call_accept.c +++ b/net/rxrpc/call_accept.c @@ -270,6 +270,9 @@ static struct rxrpc_call *rxrpc_alloc_incoming_call(struct rxrpc_sock *rx, unsigned short call_tail, conn_tail, peer_tail; unsigned short call_count, conn_count; + if (!b) + return NULL; + /* #calls >= #conns >= #peers must hold true. */ call_head = smp_load_acquire(&b->call_backlog_head); call_tail = b->call_backlog_tail; -- 2.39.5

3 months, 3 weeks

1
2
0 0

[PATCH AUTOSEL 6.1 1/4] net/sched: sch_qfq: Fix null-deref in agg_dequeue

by Sasha Levin

From: Xiang Mei <xmei5(a)asu.edu> [ Upstream commit dd831ac8221e691e9e918585b1003c7071df0379 ] To prevent a potential crash in agg_dequeue (net/sched/sch_qfq.c) when cl->qdisc->ops->peek(cl->qdisc) returns NULL, we check the return value before using it, similar to the existing approach in sch_hfsc.c. To avoid code duplication, the following changes are made: 1. Changed qdisc_warn_nonwc(include/net/pkt_sched.h) into a static inline function. 2. Moved qdisc_peek_len from net/sched/sch_hfsc.c to include/net/pkt_sched.h so that sch_qfq can reuse it. 3. Applied qdisc_peek_len in agg_dequeue to avoid crashing. Signed-off-by: Xiang Mei <xmei5(a)asu.edu> Reviewed-by: Cong Wang <xiyou.wangcong(a)gmail.com> Link: https://patch.msgid.link/20250705212143.3982664-1-xmei5@asu.edu Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: Based on my analysis of the commit and related code, here is my assessment: **YES** - This commit should be backported to stable kernel trees. Here's my extensive explanation: ## Reason for Backporting 1. **Real Bug Fix**: This commit fixes a NULL pointer dereference bug in `agg_dequeue()` function in `net/sched/sch_qfq.c`. The bug occurs when `cl->qdisc->ops->peek(cl->qdisc)` returns NULL, but the code at line 992 (before the fix) directly uses this potentially NULL value in `qdisc_pkt_len()` without checking: ```c else if (cl->deficit < qdisc_pkt_len(cl->qdisc->ops->peek(cl->qdisc))) ``` 2. **Crash Prevention**: This is not a theoretical issue - it causes an actual kernel crash (NULL pointer dereference) that can affect system stability. This meets the stable kernel criteria of fixing "a real bug that bothers people" including "an oops, a hang, data corruption." 3. **Similar Patterns in Other Schedulers**: The commit shows that this pattern of NULL checking after peek operations is already implemented in other packet schedulers: - `sch_hfsc.c` already has the `qdisc_peek_len()` function with NULL checking - `sch_drr.c` checks for NULL after peek operations (lines 385-387) - The similar commit #1 shows DRR had a similar issue fixed 4. **Minimal and Contained Fix**: The fix is: - Small in size (well under 100 lines) - Obviously correct - it adds proper NULL checking - Moves existing code to be reusable - Makes the code more consistent across schedulers 5. **Precedent from Similar Commits**: Looking at the historical commits: - Similar commit #2 (sch_codel NULL check) was backported (Status: YES) - Similar commit #3 (multiple schedulers NULL handling) was backported (Status: YES) - Both dealt with NULL pointer handling in packet scheduler dequeue paths 6. **Code Consolidation**: The fix properly consolidates the NULL checking logic: - Converts `qdisc_warn_nonwc` from a regular function to static inline (reducing overhead) - Moves `qdisc_peek_len` from sch_hfsc.c to the common header so it can be reused - Uses the same pattern across multiple schedulers for consistency 7. **Tested Pattern**: The `qdisc_peek_len()` function being moved has been in use in sch_hfsc.c, proving it's a tested and working solution. 8. **Security Consideration**: While not explicitly a security vulnerability, NULL pointer dereferences can potentially be exploited for denial of service attacks, making this fix important for system stability. The commit follows all the stable kernel rules: it fixes a real bug (NULL pointer dereference), is obviously correct (adds NULL check), is small and contained, and improves consistency across the codebase. The pattern of backporting similar NULL check fixes in packet schedulers (as seen in similar commits #2 and #3) supports backporting this fix as well. include/net/pkt_sched.h | 25 ++++++++++++++++++++++++- net/sched/sch_api.c | 10 ---------- net/sched/sch_hfsc.c | 16 ---------------- net/sched/sch_qfq.c | 2 +- 4 files changed, 25 insertions(+), 28 deletions(-) diff --git a/include/net/pkt_sched.h b/include/net/pkt_sched.h index f99a513b40a92..76f9fb651faff 100644 --- a/include/net/pkt_sched.h +++ b/include/net/pkt_sched.h @@ -113,7 +113,6 @@ struct qdisc_rate_table *qdisc_get_rtab(struct tc_ratespec *r, struct netlink_ext_ack *extack); void qdisc_put_rtab(struct qdisc_rate_table *tab); void qdisc_put_stab(struct qdisc_size_table *tab); -void qdisc_warn_nonwc(const char *txt, struct Qdisc *qdisc); bool sch_direct_xmit(struct sk_buff *skb, struct Qdisc *q, struct net_device *dev, struct netdev_queue *txq, spinlock_t *root_lock, bool validate); @@ -247,4 +246,28 @@ static inline bool tc_qdisc_stats_dump(struct Qdisc *sch, return true; } +static inline void qdisc_warn_nonwc(const char *txt, struct Qdisc *qdisc) +{ + if (!(qdisc->flags & TCQ_F_WARN_NONWC)) { + pr_warn("%s: %s qdisc %X: is non-work-conserving?\n", + txt, qdisc->ops->id, qdisc->handle >> 16); + qdisc->flags |= TCQ_F_WARN_NONWC; + } +} + +static inline unsigned int qdisc_peek_len(struct Qdisc *sch) +{ + struct sk_buff *skb; + unsigned int len; + + skb = sch->ops->peek(sch); + if (unlikely(skb == NULL)) { + qdisc_warn_nonwc("qdisc_peek_len", sch); + return 0; + } + len = qdisc_pkt_len(skb); + + return len; +} + #endif diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c index 7c5df62421bbd..6a2d258b01daa 100644 --- a/net/sched/sch_api.c +++ b/net/sched/sch_api.c @@ -593,16 +593,6 @@ void __qdisc_calculate_pkt_len(struct sk_buff *skb, qdisc_skb_cb(skb)->pkt_len = pkt_len; } -void qdisc_warn_nonwc(const char *txt, struct Qdisc *qdisc) -{ - if (!(qdisc->flags & TCQ_F_WARN_NONWC)) { - pr_warn("%s: %s qdisc %X: is non-work-conserving?\n", - txt, qdisc->ops->id, qdisc->handle >> 16); - qdisc->flags |= TCQ_F_WARN_NONWC; - } -} -EXPORT_SYMBOL(qdisc_warn_nonwc); - static enum hrtimer_restart qdisc_watchdog(struct hrtimer *timer) { struct qdisc_watchdog *wd = container_of(timer, struct qdisc_watchdog, diff --git a/net/sched/sch_hfsc.c b/net/sched/sch_hfsc.c index 61b91de8065f0..302413e0aceff 100644 --- a/net/sched/sch_hfsc.c +++ b/net/sched/sch_hfsc.c @@ -836,22 +836,6 @@ update_vf(struct hfsc_class *cl, unsigned int len, u64 cur_time) } } -static unsigned int -qdisc_peek_len(struct Qdisc *sch) -{ - struct sk_buff *skb; - unsigned int len; - - skb = sch->ops->peek(sch); - if (unlikely(skb == NULL)) { - qdisc_warn_nonwc("qdisc_peek_len", sch); - return 0; - } - len = qdisc_pkt_len(skb); - - return len; -} - static void hfsc_adjust_levels(struct hfsc_class *cl) { diff --git a/net/sched/sch_qfq.c b/net/sched/sch_qfq.c index 6462468bf77c7..cde6c7026ab1d 100644 --- a/net/sched/sch_qfq.c +++ b/net/sched/sch_qfq.c @@ -991,7 +991,7 @@ static struct sk_buff *agg_dequeue(struct qfq_aggregate *agg, if (cl->qdisc->q.qlen == 0) /* no more packets, remove from list */ list_del_init(&cl->alist); - else if (cl->deficit < qdisc_pkt_len(cl->qdisc->ops->peek(cl->qdisc))) { + else if (cl->deficit < qdisc_peek_len(cl->qdisc)) { cl->deficit += agg->lmax; list_move_tail(&cl->alist, &agg->active); } -- 2.39.5

3 months, 3 weeks

1
3
0 0

[PATCH AUTOSEL 6.6 1/6] net/sched: sch_qfq: Fix null-deref in agg_dequeue

by Sasha Levin

From: Xiang Mei <xmei5(a)asu.edu> [ Upstream commit dd831ac8221e691e9e918585b1003c7071df0379 ] To prevent a potential crash in agg_dequeue (net/sched/sch_qfq.c) when cl->qdisc->ops->peek(cl->qdisc) returns NULL, we check the return value before using it, similar to the existing approach in sch_hfsc.c. To avoid code duplication, the following changes are made: 1. Changed qdisc_warn_nonwc(include/net/pkt_sched.h) into a static inline function. 2. Moved qdisc_peek_len from net/sched/sch_hfsc.c to include/net/pkt_sched.h so that sch_qfq can reuse it. 3. Applied qdisc_peek_len in agg_dequeue to avoid crashing. Signed-off-by: Xiang Mei <xmei5(a)asu.edu> Reviewed-by: Cong Wang <xiyou.wangcong(a)gmail.com> Link: https://patch.msgid.link/20250705212143.3982664-1-xmei5@asu.edu Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: Based on my analysis of the commit and related code, here is my assessment: **YES** - This commit should be backported to stable kernel trees. Here's my extensive explanation: ## Reason for Backporting 1. **Real Bug Fix**: This commit fixes a NULL pointer dereference bug in `agg_dequeue()` function in `net/sched/sch_qfq.c`. The bug occurs when `cl->qdisc->ops->peek(cl->qdisc)` returns NULL, but the code at line 992 (before the fix) directly uses this potentially NULL value in `qdisc_pkt_len()` without checking: ```c else if (cl->deficit < qdisc_pkt_len(cl->qdisc->ops->peek(cl->qdisc))) ``` 2. **Crash Prevention**: This is not a theoretical issue - it causes an actual kernel crash (NULL pointer dereference) that can affect system stability. This meets the stable kernel criteria of fixing "a real bug that bothers people" including "an oops, a hang, data corruption." 3. **Similar Patterns in Other Schedulers**: The commit shows that this pattern of NULL checking after peek operations is already implemented in other packet schedulers: - `sch_hfsc.c` already has the `qdisc_peek_len()` function with NULL checking - `sch_drr.c` checks for NULL after peek operations (lines 385-387) - The similar commit #1 shows DRR had a similar issue fixed 4. **Minimal and Contained Fix**: The fix is: - Small in size (well under 100 lines) - Obviously correct - it adds proper NULL checking - Moves existing code to be reusable - Makes the code more consistent across schedulers 5. **Precedent from Similar Commits**: Looking at the historical commits: - Similar commit #2 (sch_codel NULL check) was backported (Status: YES) - Similar commit #3 (multiple schedulers NULL handling) was backported (Status: YES) - Both dealt with NULL pointer handling in packet scheduler dequeue paths 6. **Code Consolidation**: The fix properly consolidates the NULL checking logic: - Converts `qdisc_warn_nonwc` from a regular function to static inline (reducing overhead) - Moves `qdisc_peek_len` from sch_hfsc.c to the common header so it can be reused - Uses the same pattern across multiple schedulers for consistency 7. **Tested Pattern**: The `qdisc_peek_len()` function being moved has been in use in sch_hfsc.c, proving it's a tested and working solution. 8. **Security Consideration**: While not explicitly a security vulnerability, NULL pointer dereferences can potentially be exploited for denial of service attacks, making this fix important for system stability. The commit follows all the stable kernel rules: it fixes a real bug (NULL pointer dereference), is obviously correct (adds NULL check), is small and contained, and improves consistency across the codebase. The pattern of backporting similar NULL check fixes in packet schedulers (as seen in similar commits #2 and #3) supports backporting this fix as well. include/net/pkt_sched.h | 25 ++++++++++++++++++++++++- net/sched/sch_api.c | 10 ---------- net/sched/sch_hfsc.c | 16 ---------------- net/sched/sch_qfq.c | 2 +- 4 files changed, 25 insertions(+), 28 deletions(-) diff --git a/include/net/pkt_sched.h b/include/net/pkt_sched.h index 15960564e0c36..4d72d24b1f33e 100644 --- a/include/net/pkt_sched.h +++ b/include/net/pkt_sched.h @@ -112,7 +112,6 @@ struct qdisc_rate_table *qdisc_get_rtab(struct tc_ratespec *r, struct netlink_ext_ack *extack); void qdisc_put_rtab(struct qdisc_rate_table *tab); void qdisc_put_stab(struct qdisc_size_table *tab); -void qdisc_warn_nonwc(const char *txt, struct Qdisc *qdisc); bool sch_direct_xmit(struct sk_buff *skb, struct Qdisc *q, struct net_device *dev, struct netdev_queue *txq, spinlock_t *root_lock, bool validate); @@ -306,4 +305,28 @@ static inline bool tc_qdisc_stats_dump(struct Qdisc *sch, return true; } +static inline void qdisc_warn_nonwc(const char *txt, struct Qdisc *qdisc) +{ + if (!(qdisc->flags & TCQ_F_WARN_NONWC)) { + pr_warn("%s: %s qdisc %X: is non-work-conserving?\n", + txt, qdisc->ops->id, qdisc->handle >> 16); + qdisc->flags |= TCQ_F_WARN_NONWC; + } +} + +static inline unsigned int qdisc_peek_len(struct Qdisc *sch) +{ + struct sk_buff *skb; + unsigned int len; + + skb = sch->ops->peek(sch); + if (unlikely(skb == NULL)) { + qdisc_warn_nonwc("qdisc_peek_len", sch); + return 0; + } + len = qdisc_pkt_len(skb); + + return len; +} + #endif diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c index 282423106f15d..ae63b3199b1d1 100644 --- a/net/sched/sch_api.c +++ b/net/sched/sch_api.c @@ -594,16 +594,6 @@ void __qdisc_calculate_pkt_len(struct sk_buff *skb, qdisc_skb_cb(skb)->pkt_len = pkt_len; } -void qdisc_warn_nonwc(const char *txt, struct Qdisc *qdisc) -{ - if (!(qdisc->flags & TCQ_F_WARN_NONWC)) { - pr_warn("%s: %s qdisc %X: is non-work-conserving?\n", - txt, qdisc->ops->id, qdisc->handle >> 16); - qdisc->flags |= TCQ_F_WARN_NONWC; - } -} -EXPORT_SYMBOL(qdisc_warn_nonwc); - static enum hrtimer_restart qdisc_watchdog(struct hrtimer *timer) { struct qdisc_watchdog *wd = container_of(timer, struct qdisc_watchdog, diff --git a/net/sched/sch_hfsc.c b/net/sched/sch_hfsc.c index afcb83d469ff6..751b1e2c35b3f 100644 --- a/net/sched/sch_hfsc.c +++ b/net/sched/sch_hfsc.c @@ -835,22 +835,6 @@ update_vf(struct hfsc_class *cl, unsigned int len, u64 cur_time) } } -static unsigned int -qdisc_peek_len(struct Qdisc *sch) -{ - struct sk_buff *skb; - unsigned int len; - - skb = sch->ops->peek(sch); - if (unlikely(skb == NULL)) { - qdisc_warn_nonwc("qdisc_peek_len", sch); - return 0; - } - len = qdisc_pkt_len(skb); - - return len; -} - static void hfsc_adjust_levels(struct hfsc_class *cl) { diff --git a/net/sched/sch_qfq.c b/net/sched/sch_qfq.c index 5e557b960bde3..e0cefa21ce21c 100644 --- a/net/sched/sch_qfq.c +++ b/net/sched/sch_qfq.c @@ -992,7 +992,7 @@ static struct sk_buff *agg_dequeue(struct qfq_aggregate *agg, if (cl->qdisc->q.qlen == 0) /* no more packets, remove from list */ list_del_init(&cl->alist); - else if (cl->deficit < qdisc_pkt_len(cl->qdisc->ops->peek(cl->qdisc))) { + else if (cl->deficit < qdisc_peek_len(cl->qdisc)) { cl->deficit += agg->lmax; list_move_tail(&cl->alist, &agg->active); } -- 2.39.5

3 months, 3 weeks

1
5
0 0

[PATCH AUTOSEL 6.12 01/12] wifi: mac80211: always initialize sdata::key_list

by Sasha Levin

From: Miri Korenblit <miriam.rachel.korenblit(a)intel.com> [ Upstream commit d7a54d02db41f72f0581a3c77c75b0993ed3f6e2 ] This is currently not initialized for a virtual monitor, leading to a NULL pointer dereference when - for example - iterating over all the keys of all the vifs. Reviewed-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit(a)intel.com> Link: https://patch.msgid.link/20250709233400.8dcefe578497.I4c90a00ae3256520e0631… Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: Based on my analysis of the commit and the code changes, here is my assessment: **YES** This commit should be backported to stable kernel trees for the following reasons: 1. **Critical NULL Pointer Dereference Fix**: The commit fixes a NULL pointer dereference that occurs when iterating over the key_list of virtual monitor interfaces. This is a crash-inducing bug that affects system stability. 2. **Clear Bug with Simple Fix**: The issue is straightforward - the `key_list` was not initialized for virtual monitor interfaces created via `ieee80211_add_virtual_monitor()`. The fix is minimal and contained - it simply moves the `INIT_LIST_HEAD(&sdata->key_list)` initialization from `ieee80211_if_add()` into `ieee80211_sdata_init()`, ensuring all sdata structures have their key_list properly initialized. 3. **Real-World Impact**: The bug can be triggered when any code iterates over all interfaces and their keys. Looking at the code, functions like `ieee80211_iter_keys()` and `ieee80211_iter_keys_rcu()` iterate through all interfaces when called without a specific vif parameter: ```c list_for_each_entry(sdata, &local->interfaces, list) list_for_each_entry_safe(key, tmp, &sdata->key_list, list) ``` This would cause a NULL pointer dereference when it encounters a virtual monitor interface. 4. **Minimal Risk**: The change is extremely low risk - it only adds initialization of a list head that should have been initialized all along. There are no architectural changes or feature additions. 5. **Follows Stable Rules**: This perfectly fits the stable kernel criteria: - Fixes a real bug (NULL pointer dereference/crash) - Small and contained change (2 lines moved) - Obviously correct fix - No new features or behaviors introduced The commit is similar in nature to commit #5 in the reference list which was marked as suitable for backporting - both fix NULL pointer dereferences in the wifi/mac80211 subsystem with minimal, targeted changes. net/mac80211/iface.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c index 209d6ffa8e426..adfdc14bd91ac 100644 --- a/net/mac80211/iface.c +++ b/net/mac80211/iface.c @@ -1121,6 +1121,8 @@ static void ieee80211_sdata_init(struct ieee80211_local *local, { sdata->local = local; + INIT_LIST_HEAD(&sdata->key_list); + /* * Initialize the default link, so we can use link_id 0 for non-MLD, * and that continues to work for non-MLD-aware drivers that use just @@ -2162,8 +2164,6 @@ int ieee80211_if_add(struct ieee80211_local *local, const char *name, ieee80211_init_frag_cache(&sdata->frags); - INIT_LIST_HEAD(&sdata->key_list); - wiphy_delayed_work_init(&sdata->dec_tailroom_needed_wk, ieee80211_delayed_tailroom_dec); -- 2.39.5

3 months, 3 weeks

1
11
0 0

[PATCH AUTOSEL 6.15 01/15] wifi: mac80211: always initialize sdata::key_list

by Sasha Levin

From: Miri Korenblit <miriam.rachel.korenblit(a)intel.com> [ Upstream commit d7a54d02db41f72f0581a3c77c75b0993ed3f6e2 ] This is currently not initialized for a virtual monitor, leading to a NULL pointer dereference when - for example - iterating over all the keys of all the vifs. Reviewed-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit(a)intel.com> Link: https://patch.msgid.link/20250709233400.8dcefe578497.I4c90a00ae3256520e0631… Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: Based on my analysis of the commit and the code changes, here is my assessment: **YES** This commit should be backported to stable kernel trees for the following reasons: 1. **Critical NULL Pointer Dereference Fix**: The commit fixes a NULL pointer dereference that occurs when iterating over the key_list of virtual monitor interfaces. This is a crash-inducing bug that affects system stability. 2. **Clear Bug with Simple Fix**: The issue is straightforward - the `key_list` was not initialized for virtual monitor interfaces created via `ieee80211_add_virtual_monitor()`. The fix is minimal and contained - it simply moves the `INIT_LIST_HEAD(&sdata->key_list)` initialization from `ieee80211_if_add()` into `ieee80211_sdata_init()`, ensuring all sdata structures have their key_list properly initialized. 3. **Real-World Impact**: The bug can be triggered when any code iterates over all interfaces and their keys. Looking at the code, functions like `ieee80211_iter_keys()` and `ieee80211_iter_keys_rcu()` iterate through all interfaces when called without a specific vif parameter: ```c list_for_each_entry(sdata, &local->interfaces, list) list_for_each_entry_safe(key, tmp, &sdata->key_list, list) ``` This would cause a NULL pointer dereference when it encounters a virtual monitor interface. 4. **Minimal Risk**: The change is extremely low risk - it only adds initialization of a list head that should have been initialized all along. There are no architectural changes or feature additions. 5. **Follows Stable Rules**: This perfectly fits the stable kernel criteria: - Fixes a real bug (NULL pointer dereference/crash) - Small and contained change (2 lines moved) - Obviously correct fix - No new features or behaviors introduced The commit is similar in nature to commit #5 in the reference list which was marked as suitable for backporting - both fix NULL pointer dereferences in the wifi/mac80211 subsystem with minimal, targeted changes. net/mac80211/iface.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c index 7d93e5aa595b2..0485a78eda366 100644 --- a/net/mac80211/iface.c +++ b/net/mac80211/iface.c @@ -1117,6 +1117,8 @@ static void ieee80211_sdata_init(struct ieee80211_local *local, { sdata->local = local; + INIT_LIST_HEAD(&sdata->key_list); + /* * Initialize the default link, so we can use link_id 0 for non-MLD, * and that continues to work for non-MLD-aware drivers that use just @@ -2177,8 +2179,6 @@ int ieee80211_if_add(struct ieee80211_local *local, const char *name, ieee80211_init_frag_cache(&sdata->frags); - INIT_LIST_HEAD(&sdata->key_list); - wiphy_delayed_work_init(&sdata->dec_tailroom_needed_wk, ieee80211_delayed_tailroom_dec); -- 2.39.5

3 months, 3 weeks

1
14
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror July 2025