[lvc-project] [PATCH net-next v8] l2tp: fix double dst_release() on sk_dst_cache race

Li Xiasong lixiasong1 at huawei.com
Fri Mar 6 10:44:35 MSK 2026


Hi Jakub,

On 12/17/2025 12:35 AM, Jakub Kicinski wrote:
> On Mon, 15 Dec 2025 17:55:33 +0300 Mikhail Lobanov wrote:
>> A reproducible rcuref - imbalanced put() warning is observed under
>> IPv6 L2TP (pppol2tp) traffic with blackhole routes, indicating an
>> imbalance in dst reference counting for routes cached in
>> sk->sk_dst_cache and pointing to a subtle lifetime/synchronization
>> issue between the helpers that validate and drop cached dst entries.
> 
> This seems to be causing a leak:
> 
> unreferenced object 0xffff888017774e40 (size 64):
>   comm "ip", pid 3486, jiffies 4298584595
>   hex dump (first 32 bytes):
>     10 00 00 00 e9 01 00 00 01 00 00 00 00 00 00 00  ................
>     ff ff ff ff 00 00 00 00 48 4e 77 17 80 88 ff ff  ........HNw.....
>   backtrace (crc b523287):
>     __kmalloc_node_noprof+0x579/0x8c0
>     crypto_alloc_tfmmem.isra.0+0x2e/0xf0
>     crypto_create_tfm_node+0x81/0x2e0
>     crypto_spawn_tfm2+0x4e/0x80
>     crypto_rfc4106_init_tfm+0x41/0x190
>     crypto_create_tfm_node+0x108/0x2e0
>     crypto_spawn_tfm2+0x4e/0x80
>     aead_init_geniv+0x14c/0x2a0
>     crypto_create_tfm_node+0x108/0x2e0
>     crypto_alloc_tfm_node+0xe0/0x1d0
>     esp_init_aead.constprop.0+0xe4/0x340
>     esp_init_state+0x83/0x4c0
>     __xfrm_init_state+0x6f2/0x13d0
>     xfrm_state_construct+0x1455/0x2480 [xfrm_user]
>     xfrm_add_sa+0x137/0x3c0 [xfrm_user]
>     xfrm_user_rcv_msg+0x502/0x920 [xfrm_user]

I'm writing to follow up on Mikhail's patch, which aims to fix a race
condition in sk_dst_cache.

I've encountered the exact same issue. Specifically, the problem occurs
when using L2TP with a UDP socket file descriptor specified via netlink.
Below is the call stack from our system where the issue manifested:

rcuref - imbalanced put()
WARNING: CPU: 13 PID: 1222 at lib/rcuref.c:266 rcuref_put_slowpath+0x10c/0x120
Modules linked in:
CPU: 13 PID: 1222 Comm: l2tp Not tainted 6.6.0+ #9
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
RIP: 0010:rcuref_put_slowpath+0x10c/0x120
Code: 83 e4 01 31 ff 44 89 e6 e8 21 bb 53 ff 45 84 e4 75 1a e8 f7 c4 53 ff
48 c7 c7 4e ee c8 86 c6 05 41 22 01 06 01 e8 a4 10 39 ff <0f> 0b e8 dd c4
53 ff c7 03 00 00 00 e0 e9 2d ff ff ff 66 90 90 90
RSP: 0018:ffffc90006b7b9d8 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff88811df01740 RCX: ffffffff8134b438
RDX: ffff8881223fd080 RSI: 0000000000000000 RDI: 0000000000000001
RBP: 00000000dfffffff R08: 0000000000000000 R09: 6e616c61626d6920
R10: 0000000000000000 R11: 2928747570206465 R12: 0000000000000000
R13: ffff88811df01740 R14: 00000000ffffffea R15: 0000000000000000
FS:  00007f5dd7d22500(0000) GS:ffff88813b480000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000ee11668 CR3: 000000012259e000 CR4: 00000000000006e0
Call Trace:
 <TASK>
 dst_release+0x141/0x160
 ip6_dst_lookup_tail.constprop.0+0xa0/0x9b0
 ? sysvec_apic_timer_interrupt+0xf/0x90
 ? asm_sysvec_apic_timer_interrupt+0x1a/0x20
 ? sk_dst_check+0x1c/0x160
 ip6_dst_lookup_flow+0x54/0xe0
 ip6_sk_dst_lookup_flow+0x1f6/0x2d0
 udpv6_sendmsg+0xc08/0x1760
 ? __pfx_ip_generic_getfrag+0x10/0x10
 ? sysvec_apic_timer_interrupt+0xf/0x90
 ? asm_sysvec_apic_timer_interrupt+0x1a/0x20
 ? update_curr+0x35/0x3e0
 ? __pfx_udpv6_sendmsg+0x10/0x10
 ? inet6_sendmsg+0xb2/0xd0
 inet6_sendmsg+0xb2/0xd0
 __sock_sendmsg+0x60/0x120
 __sys_sendto+0x17a/0x230
 ? timerqueue_add+0xe1/0x140
 ? sched_clock+0x37/0x60
 ? sched_clock_cpu+0x11/0x1b0
 ? irqtime_account_irq+0x53/0x100
 ? handle_softirqs+0x189/0x320
 __x64_sys_sendto+0x2d/0x40
 do_syscall_64+0x5b/0x110
 entry_SYSCALL_64_after_hwframe+0x78/0xe2
RIP: 0033:0x7f5dd7722c4d
Code: ff ff ff ff eb b6 0f 1f 80 00 00 00 00 48 8d 05 c1 dc 2c 00 41 89 ca
8b 00 85 c0 75 20 45 31 c9 45 31 c0 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff
ff 77 6b f3 c3 66 0f 1f 84 00 00 00 00 00 41 56 41
RSP: 002b:00007ffcbf9e36d8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5dd7722c4d
RDX: 0000000000000009 RSI: 000055cefbc01a57 RDI: 0000000000000003
RBP: 00007ffcbf9e4790 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 000055cefbc00bf0
R13: 00007ffcbf9e4870 R14: 0000000000000000 R15: 0000000000000000
 </TASK>

Our investigation led us to the same root cause that Mikhail identified. I
have applied his patch and can confirm that it resolves the issue perfectly.

Thank you for looking into this previously. We noted your concern about a
potential memory leak during your review. We have been running the patch
but haven't been able to reproduce the leak ourselves.

Could you perhaps share the specific conditions or steps required to
trigger the memory leak? Any details you can provide would be very helpful
for us to further validate the patch or identify the root cause of the leak.

Thanks for your time and effort on this.

Best regards,

Li Xiasong





More information about the lvc-project mailing list