netlink_attachskb() checks for the socket's read memory allocation constraints. Firstly, it has:
rmem < READ_ONCE(sk->sk_rcvbuf)
to check if the just increased rmem value fits into the socket's receive buffer. If not, it proceeds and tries to wait for the memory under:
rmem + skb->truesize > READ_ONCE(sk->sk_rcvbuf)
The checks don't cover the case when skb->truesize + sk->sk_rmem_alloc is equal to sk->sk_rcvbuf. Thus the function neither successfully accepts these conditions, nor manages to reschedule the task - and is called in retry loop for indefinite time which is caught as:
rcu: INFO: rcu_sched self-detected stall on CPU rcu: 0-....: (25999 ticks this GP) idle=ef2/1/0x4000000000000000 softirq=262269/262269 fqs=6212 (t=26000 jiffies g=230833 q=259957) NMI backtrace for cpu 0 CPU: 0 PID: 22 Comm: kauditd Not tainted 5.10.240 #68 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc42 04/01/2014 Call Trace: <IRQ> dump_stack lib/dump_stack.c:120 nmi_cpu_backtrace.cold lib/nmi_backtrace.c:105 nmi_trigger_cpumask_backtrace lib/nmi_backtrace.c:62 rcu_dump_cpu_stacks kernel/rcu/tree_stall.h:335 rcu_sched_clock_irq.cold kernel/rcu/tree.c:2590 update_process_times kernel/time/timer.c:1953 tick_sched_handle kernel/time/tick-sched.c:227 tick_sched_timer kernel/time/tick-sched.c:1399 __hrtimer_run_queues kernel/time/hrtimer.c:1652 hrtimer_interrupt kernel/time/hrtimer.c:1717 __sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1113 asm_call_irq_on_stack arch/x86/entry/entry_64.S:808 </IRQ>
netlink_attachskb net/netlink/af_netlink.c:1234 netlink_unicast net/netlink/af_netlink.c:1349 kauditd_send_queue kernel/audit.c:776 kauditd_thread kernel/audit.c:897 kthread kernel/kthread.c:328 ret_from_fork arch/x86/entry/entry_64.S:304
Restore the original behavior of the check which commit in Fixes accidentally missed when restructuring the code.
Found by Linux Verification Center (linuxtesting.org).
Fixes: ae8f160e7eb2 ("netlink: Fix wraparounds of sk->sk_rmem_alloc.") Cc: stable@vger.kernel.org Signed-off-by: Fedor Pchelkin pchelkin@ispras.ru ---
Similar rmem and sk->sk_rcvbuf comparing pattern in netlink_broadcast_deliver() accepts these values being equal, while the netlink_dump() case does not - but it goes all the way down to f9c2288837ba ("netlink: implement memory mapped recvmsg()") and looks like an irrelevant issue without any real consequences. Though might be cleaned up if needed.
Updated sk->sk_rmem_alloc vs sk->sk_rcvbuf checks throughout the kernel diverse in treating the corner case of them being equal.
net/netlink/af_netlink.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c index 6332a0e06596..0fc3f045fb65 100644 --- a/net/netlink/af_netlink.c +++ b/net/netlink/af_netlink.c @@ -1218,7 +1218,7 @@ int netlink_attachskb(struct sock *sk, struct sk_buff *skb, nlk = nlk_sk(sk); rmem = atomic_add_return(skb->truesize, &sk->sk_rmem_alloc);
- if ((rmem == skb->truesize || rmem < READ_ONCE(sk->sk_rcvbuf)) && + if ((rmem == skb->truesize || rmem <= READ_ONCE(sk->sk_rcvbuf)) && !test_bit(NETLINK_S_CONGESTED, &nlk->state)) { netlink_skb_set_owner_r(skb, sk); return 0;
On Mon, Jul 28, 2025 at 1:07 AM Fedor Pchelkin pchelkin@ispras.ru wrote:
netlink_attachskb() checks for the socket's read memory allocation constraints. Firstly, it has:
rmem < READ_ONCE(sk->sk_rcvbuf)
to check if the just increased rmem value fits into the socket's receive buffer. If not, it proceeds and tries to wait for the memory under:
rmem + skb->truesize > READ_ONCE(sk->sk_rcvbuf)
The checks don't cover the case when skb->truesize + sk->sk_rmem_alloc is equal to sk->sk_rcvbuf. Thus the function neither successfully accepts these conditions, nor manages to reschedule the task - and is called in retry loop for indefinite time which is caught as:
rcu: INFO: rcu_sched self-detected stall on CPU rcu: 0-....: (25999 ticks this GP) idle=ef2/1/0x4000000000000000 softirq=262269/262269 fqs=6212 (t=26000 jiffies g=230833 q=259957) NMI backtrace for cpu 0 CPU: 0 PID: 22 Comm: kauditd Not tainted 5.10.240 #68 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc42 04/01/2014 Call Trace:
<IRQ> dump_stack lib/dump_stack.c:120 nmi_cpu_backtrace.cold lib/nmi_backtrace.c:105 nmi_trigger_cpumask_backtrace lib/nmi_backtrace.c:62 rcu_dump_cpu_stacks kernel/rcu/tree_stall.h:335 rcu_sched_clock_irq.cold kernel/rcu/tree.c:2590 update_process_times kernel/time/timer.c:1953 tick_sched_handle kernel/time/tick-sched.c:227 tick_sched_timer kernel/time/tick-sched.c:1399 __hrtimer_run_queues kernel/time/hrtimer.c:1652 hrtimer_interrupt kernel/time/hrtimer.c:1717 __sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1113 asm_call_irq_on_stack arch/x86/entry/entry_64.S:808 </IRQ>
netlink_attachskb net/netlink/af_netlink.c:1234 netlink_unicast net/netlink/af_netlink.c:1349 kauditd_send_queue kernel/audit.c:776 kauditd_thread kernel/audit.c:897 kthread kernel/kthread.c:328 ret_from_fork arch/x86/entry/entry_64.S:304
Restore the original behavior of the check which commit in Fixes accidentally missed when restructuring the code.
Found by Linux Verification Center (linuxtesting.org).
Fixes: ae8f160e7eb2 ("netlink: Fix wraparounds of sk->sk_rmem_alloc.") Cc: stable@vger.kernel.org Signed-off-by: Fedor Pchelkin pchelkin@ispras.ru
Similar rmem and sk->sk_rcvbuf comparing pattern in netlink_broadcast_deliver() accepts these values being equal, while the netlink_dump() case does not - but it goes all the way down to f9c2288837ba ("netlink: implement memory mapped recvmsg()") and looks like an irrelevant issue without any real consequences. Though might be cleaned up if needed.
This should be fixed in a separate patch. It's weird that one path accepts a value == SO_RCVBUF but the other path doesn't.
Reviewed-by: Kuniyuki Iwashima kuniyu@google.com
Thanks!
Updated sk->sk_rmem_alloc vs sk->sk_rcvbuf checks throughout the kernel diverse in treating the corner case of them being equal.
net/netlink/af_netlink.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c index 6332a0e06596..0fc3f045fb65 100644 --- a/net/netlink/af_netlink.c +++ b/net/netlink/af_netlink.c @@ -1218,7 +1218,7 @@ int netlink_attachskb(struct sock *sk, struct sk_buff *skb, nlk = nlk_sk(sk); rmem = atomic_add_return(skb->truesize, &sk->sk_rmem_alloc);
if ((rmem == skb->truesize || rmem < READ_ONCE(sk->sk_rcvbuf)) &&
if ((rmem == skb->truesize || rmem <= READ_ONCE(sk->sk_rcvbuf)) && !test_bit(NETLINK_S_CONGESTED, &nlk->state)) { netlink_skb_set_owner_r(skb, sk); return 0;-- 2.50.1
Hello:
This patch was applied to netdev/net.git (main) by Jakub Kicinski kuba@kernel.org:
On Mon, 28 Jul 2025 11:06:47 +0300 you wrote:
netlink_attachskb() checks for the socket's read memory allocation constraints. Firstly, it has:
rmem < READ_ONCE(sk->sk_rcvbuf)
to check if the just increased rmem value fits into the socket's receive buffer. If not, it proceeds and tries to wait for the memory under:
[...]
Here is the summary with links: - [net] netlink: avoid infinite retry looping in netlink_unicast() https://git.kernel.org/netdev/net/c/759dfc7d04ba
You are awesome, thank you!
On 31.07.25 04:30, patchwork-bot+netdevbpf@kernel.org wrote:
Hello:
This patch was applied to netdev/net.git (main) by Jakub Kicinski kuba@kernel.org:
On Mon, 28 Jul 2025 11:06:47 +0300 you wrote:
netlink_attachskb() checks for the socket's read memory allocation constraints. Firstly, it has:
rmem < READ_ONCE(sk->sk_rcvbuf)
to check if the just increased rmem value fits into the socket's receive buffer. If not, it proceeds and tries to wait for the memory under:
[...]
Here is the summary with links:
- [net] netlink: avoid infinite retry looping in netlink_unicast() https://git.kernel.org/netdev/net/c/759dfc7d04ba
You are awesome, thank you!
hello, as far as I can tell this patch has not made it to the 6.1 stable tree yet in the 6.1.148 review yet: https://www.spinics.net/lists/stable/msg866199.html
As this seems to be causing issues in distributions releasing 6.1.147 can this still be added to the next possible stable release? See following issues in relation to loading audit rules which seems to trigger the fixed bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1111017 https://github.com/amazonlinux/amazon-linux-2023/issues/988
I have tested this patch solves the problem in the Debian bookworm using 6.1.x
cheers, Julian Taylor
On Thu, Aug 14, 2025 at 02:51:27PM +0200, Julian Taylor wrote:
On 31.07.25 04:30, patchwork-bot+netdevbpf@kernel.org wrote:
Hello:
This patch was applied to netdev/net.git (main) by Jakub Kicinski kuba@kernel.org:
On Mon, 28 Jul 2025 11:06:47 +0300 you wrote:
netlink_attachskb() checks for the socket's read memory allocation constraints. Firstly, it has:
rmem < READ_ONCE(sk->sk_rcvbuf)
to check if the just increased rmem value fits into the socket's receive buffer. If not, it proceeds and tries to wait for the memory under:
[...]
Here is the summary with links:
- [net] netlink: avoid infinite retry looping in netlink_unicast() https://git.kernel.org/netdev/net/c/759dfc7d04ba
You are awesome, thank you!
hello, as far as I can tell this patch has not made it to the 6.1 stable tree yet in the 6.1.148 review yet: https://www.spinics.net/lists/stable/msg866199.html
Please use lore.kernel.org links.
As this seems to be causing issues in distributions releasing 6.1.147 can this still be added to the next possible stable release? See following issues in relation to loading audit rules which seems to trigger the fixed bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1111017 https://github.com/amazonlinux/amazon-linux-2023/issues/988
I have tested this patch solves the problem in the Debian bookworm using 6.1.x
What is the git commit id of this patch in Linus's tree?
thanks,
greg k-h
On 14.08.25 15:57, Greg KH wrote:
On Thu, Aug 14, 2025 at 02:51:27PM +0200, Julian Taylor wrote:
On 31.07.25 04:30, patchwork-bot+netdevbpf@kernel.org wrote:
Hello:
This patch was applied to netdev/net.git (main) by Jakub Kicinski kuba@kernel.org:
On Mon, 28 Jul 2025 11:06:47 +0300 you wrote:
netlink_attachskb() checks for the socket's read memory allocation constraints. Firstly, it has:
rmem < READ_ONCE(sk->sk_rcvbuf)to check if the just increased rmem value fits into the socket's receive buffer. If not, it proceeds and tries to wait for the memory under:
[...]
Here is the summary with links: - [net] netlink: avoid infinite retry looping in netlink_unicast() https://git.kernel.org/netdev/net/c/759dfc7d04ba
You are awesome, thank you!
hello, as far as I can tell this patch has not made it to the 6.1 stable tree yet in the 6.1.148 review yet: https://www.spinics.net/lists/stable/msg866199.html
Please use lore.kernel.org links.
As this seems to be causing issues in distributions releasing 6.1.147 can this still be added to the next possible stable release? See following issues in relation to loading audit rules which seems to trigger the fixed bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1111017 https://github.com/amazonlinux/amazon-linux-2023/issues/988
I have tested this patch solves the problem in the Debian bookworm using 6.1.x
What is the git commit id of this patch in Linus's tree?
The commit id is 759dfc7d04bab1b0b86113f1164dc1fec192b859 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
On Thu, Aug 14, 2025 at 04:14:39PM +0200, Julian Taylor wrote:
On 14.08.25 15:57, Greg KH wrote:
On Thu, Aug 14, 2025 at 02:51:27PM +0200, Julian Taylor wrote:
On 31.07.25 04:30, patchwork-bot+netdevbpf@kernel.org wrote:
Hello:
This patch was applied to netdev/net.git (main) by Jakub Kicinski kuba@kernel.org:
On Mon, 28 Jul 2025 11:06:47 +0300 you wrote:
netlink_attachskb() checks for the socket's read memory allocation constraints. Firstly, it has:
rmem < READ_ONCE(sk->sk_rcvbuf)to check if the just increased rmem value fits into the socket's receive buffer. If not, it proceeds and tries to wait for the memory under:
[...]
Here is the summary with links: - [net] netlink: avoid infinite retry looping in netlink_unicast() https://git.kernel.org/netdev/net/c/759dfc7d04ba
You are awesome, thank you!
hello, as far as I can tell this patch has not made it to the 6.1 stable tree yet in the 6.1.148 review yet: https://www.spinics.net/lists/stable/msg866199.html
Please use lore.kernel.org links.
As this seems to be causing issues in distributions releasing 6.1.147 can this still be added to the next possible stable release? See following issues in relation to loading audit rules which seems to trigger the fixed bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1111017 https://github.com/amazonlinux/amazon-linux-2023/issues/988
I have tested this patch solves the problem in the Debian bookworm using 6.1.x
What is the git commit id of this patch in Linus's tree?
The commit id is 759dfc7d04bab1b0b86113f1164dc1fec192b859 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
Thanks, I'll queue this up for the next round of kernels.
Right now we have a backlog of 500+ patches due to all of these being added during the -rc1 merge window. Please be patient while we dig through them.
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org
-
Fedor Pchelkin -
Greg KH -
Julian Taylor -
Kuniyuki Iwashima -
patchwork-bot+netdevbpf＠kernel.org