Re: [PATCH v2] netlink, audit: prevent false ENOBUFS on timeout expiry

[Jakub Kicinski <kuba@kernel.org>]

On Wed, 27 May 2026 16:29:37 -0300 Ricardo Robaina wrote:
> On Mon, May 18, 2026 at 9:35 PM Jakub Kicinski <kuba@kernel.org> wrote:
> >
> > On Wed, 13 May 2026 14:24:43 -0300 Ricardo Robaina wrote:  
> > > When auditd is bottlenecked (e.g., by slow disk I/O), kauditd blocks on
> > > the netlink socket.  
> >
> > Holding socket lock during slow IO sounds very wrong. One could say -
> > that's abuse of the socket lock?
> >  
> > > If the wait timeout fully expires (timeo == 0),
> > > netlink mistakenly interprets the zeroed timeout as a non-blocking
> > > request. It then triggers netlink_overrun that drops the event,
> > > completely bypassing the audit subsystem's internal retry queue, and
> > > falsely returns ENOBUFS to user-space, resulting in the following error:
> > >
> > >  auditd[]: Error receiving audit netlink packet (No buffer space available)
> > >
> > > Fix this by detecting when a blocking sender's timeout has expired
> > > (timeo == 0 && !nonblock) in netlink_unicast(). In this case, instead
> > > of retrying with timeo=0 (which would incorrectly trigger netlink_overrun
> > > on the next iteration), safely free the skb and return -EAGAIN, allowing
> > > the audit subsystem to gracefully enqueue the pending event into its
> > > internal backlog.  
> >
> > The socket _is_ the queue, normally.
> >
> > Please explore fixing this in audit?
> > --
> > pw-bot: cr
> >  
> 
> Hi Jakub,
> 
> Thanks for reviewing this patch as well.
> 
> First, regarding the lock: kauditd does not hold the socket lock during
> slow I/O. The sleep in netlink_attachskb() uses schedule_timeout() on
> nlk->wait (a wait queue). No socket lock or mutex is held during the sleep.

So you're saying the queue _is_ actually congested?
netlink_attachskb() sleeps because there's no space left in the socket's 
rcvbuf? So the skbs are moved to audit_retry_queue "temporarily" until
user space drains its socket and kernel can succeed sending?

Could you confirm this understanding is correct?

> Second, regarding an audit-only fix: the symptom manifests as sk->sk_err =
> ENOBUFS set inside netlink_overrun() (called from netlink_attachskb when
> timeo == 0). Audit has no mechanism to prevent or clear this socket state
> from the outside. Potential workarounds all fail:
> 
> (1) Clearing sk_err after the fact is racy and affects other socket ops

Why would you clear the sk_err, it's the reader's responsibility to
clear the congestion and the reader is AFAIU a user space process.

> (2) Avoiding timeouts entirely defeats the anti-deadlock mechanism

What's the anti-deadlock mechanism?

> (3) A new NETLINK_F_RECV_NO_ENOBUFS socket flag doesn't exist in stable
> kernels where this bug is actively impacting users

Which commit are you referring to? Isn't that flag itself ancient?

> I've submitted v3 [1] with NETLINK_UNICAST_TIMED as an explicit opt-in
> constant. 

It's really not great to fall silent for 10+ days, then respond and
immediately posts equally pointless next version of the patch :/