net.unix.max_dgram_qlen is documented as the maximum length of an AF_UNIX
datagram socket receive queue. Its sysctl entry accepts a signed integer.
The configured value is copied to sock::sk_max_ack_backlog, which is u32,
when a UNIX socket is created.

As a result, writing -1 is accepted and reads back as -1, but newly created
sockets receive UINT_MAX as their datagram queue limit. A nonblocking
sender can therefore enqueue past the configured finite limit instead of
receiving EAGAIN.

Use proc_dointvec_minmax with a zero lower bound, rejecting negative input
while preserving the existing nonnegative range and the zero-value
behavior.

The issue was reproduced on 6.12.80 and 6.12.105. With
max_dgram_qlen=10, an unprivileged local workload sent 11 of 16 datagrams
before EAGAIN. With max_dgram_qlen=-1, all 16 sends succeeded. After this
change, writing -1 fails with EINVAL, while the 10 and zero-value controls
retain their prior behavior.

Signed-off-by: Yingjie Wang <1075151112@qq.com>
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Assisted-by: Codex:gpt-5
---
 net/unix/sysctl_net_unix.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/unix/sysctl_net_unix.c b/net/unix/sysctl_net_unix.c
index 47660d5..2782095 100644
--- a/net/unix/sysctl_net_unix.c
+++ b/net/unix/sysctl_net_unix.c
@@ -19,7 +19,8 @@ static const struct ctl_table unix_table[] = {
 		.data		= &init_net.unx.sysctl_max_dgram_qlen,
 		.maxlen		= sizeof(int),
 		.mode		= 0644,
-		.proc_handler	= proc_dointvec
+		.proc_handler	= proc_dointvec_minmax,
+		.extra1		= SYSCTL_ZERO,
 	},
 };
 
-- 
2.43.0

On Tue, Aug 25, 2026 at 11:10 PM Yingjie Wang <1075151112@qq.com> wrote:
>
> net.unix.max_dgram_qlen is documented as the maximum length of an AF_UNIX
> datagram socket receive queue. Its sysctl entry accepts a signed integer.
> The configured value is copied to sock::sk_max_ack_backlog, which is u32,
> when a UNIX socket is created.
>
> As a result, writing -1 is accepted and reads back as -1, but newly created
> sockets receive UINT_MAX as their datagram queue limit.

I'm not sure if this was intended, but passing -1 for sk_max_ack_backlog
is known hacky config to get max, see __sys_listen_socket().


> A nonblocking
> sender can therefore enqueue past the configured finite limit instead of
> receiving EAGAIN.
>
> Use proc_dointvec_minmax

At least, this effectively limits the upper bound to half,
sk_buff_head.qlen is also u32.


> with a zero lower bound, rejecting negative input
> while preserving the existing nonnegative range and the zero-value
> behavior.
>
> The issue was reproduced on 6.12.80 and 6.12.105. With
> max_dgram_qlen=10, an unprivileged local workload sent 11 of 16 datagrams
> before EAGAIN. With max_dgram_qlen=-1, all 16 sends succeeded. After this
> change, writing -1 fails with EINVAL, while the 10 and zero-value controls
> retain their prior behavior.
>
> Signed-off-by: Yingjie Wang <1075151112@qq.com>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: stable@vger.kernel.org
> Assisted-by: Codex:gpt-5
> ---
>  net/unix/sysctl_net_unix.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/unix/sysctl_net_unix.c b/net/unix/sysctl_net_unix.c
> index 47660d5..2782095 100644
> --- a/net/unix/sysctl_net_unix.c
> +++ b/net/unix/sysctl_net_unix.c
> @@ -19,7 +19,8 @@ static const struct ctl_table unix_table[] = {
>                 .data           = &init_net.unx.sysctl_max_dgram_qlen,
>                 .maxlen         = sizeof(int),
>                 .mode           = 0644,
> -               .proc_handler   = proc_dointvec
> +               .proc_handler   = proc_dointvec_minmax,
> +               .extra1         = SYSCTL_ZERO,
>         },
>  };
>
> --
> 2.43.0
>

On Fri, Aug 28, 2026 at 10:49 AM Kuniyuki Iwashima <kuniyu@google.com> wrote:
> I'm not sure if this was intended, but passing -1 for sk_max_ack_backlog
> is known hacky config to get max, see __sys_listen_socket().

I checked this.  In __sys_listen_socket(), a negative backlog is cast to
unsigned and capped to somaxconn; there are also in-tree tests using
listen(..., -1).

I could not find the same convention for max_dgram_qlen.  It is not
documented or special-cased, and I found no in-tree user or test relying
on -1.  The sysctl value is copied directly to the u32 sk_max_ack_backlog,
so -1 becomes UINT_MAX without the somaxconn cap.

> At least, this effectively limits the upper bound to half,
> sk_buff_head.qlen is also u32.

Good point.  I'll change sysctl_max_dgram_qlen to unsigned int and use
proc_douintvec_minmax in v2, so negative writes are rejected while keeping
the full u32 range.

Thanks,
Yingjie