netdev - Re: Question about timeout bug in recvmmsg

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAFfO_h6bLS5vc8YUBnFffk2hS4Oj9MK7EdEyCA__5KWMqyqAPg@mail.gmail.com>
Date: Wed, 14 Jan 2026 20:32:33 +0600
From: Dorjoy Chowdhury <dorjoychy111@...il.com>
To: netdev@...r.kernel.org
Cc: "edumazet@...gle.com" <edumazet@...gle.com>, kuniyu@...gle.com, pabeni@...hat.com, 
	willemb@...gle.com
Subject: Re: Question about timeout bug in recvmmsg

Hi,
Gentle ping regarding this request. I would really appreciate some
input on this. Thank you!

Regards,
Dorjoy

On Thu, Jan 8, 2026 at 12:39 AM Dorjoy Chowdhury <dorjoychy111@...il.com> wrote:
>
> Hi,
> Hope everyone is doing well. I came upon this timeout bug in the
> recvmmsg system call from this URL:
> https://bugzilla.kernel.org/show_bug.cgi?id=75371 . I am not familiar
> with the linux kernel code. I thought it would be a good idea to try
> to fix it and as a side effect I can get to know the code a bit
> better. As far as I can see, the system call eventually goes through
> the do_recvmmsg function in the net/socket.c file. There is a while
> loop that checks for timeout after the call to ___sys_recvmmsg(...).
> So this probably is still a bug where if the socket was not configured
> with any SO_RCVTIMEO (i.e., sk_rcvtimeo in struct sock), the call can
> block indefinitely. Is this considered something that should ideally
> be fixed?
>
> If this is something that should be fixed, I can try to take a look
> into it. I have tried to follow the codepath a bit and from what I
> understand, if we keep following the main function calls i.e.,
> do_recvmmsg, ___sys_recvmmsg ... we eventually reach
> tcp_recvmsg_locked function in net/ipv4/tcp.c (there are of course
> other ipv6, udp code paths as well). In this function, the timeo
> variable represents the timeout I think and it gets the timeout value
> from the sock_rcvtimeo function. I think this is where we need to use
> the smaller one between sk_rcvtimeo and the remaining timeout
> (converted to 'long' from struct timespec) from the recvmmsg call (we
> need to consider the case of timeout values 0 here of course). It
> probably would have been easier if we could add a new member in struct
> sock after sk_rcvtimeo, that way the change would only have to be in
> sock_rcvtimeo function implementation. But this new timeout  value
> from the recvmmsg call probably doesn't make sense to be part of
> struct sock. So we need to pass this remaining timeout from
> do_recvmmsg all the way to tcp_recvmsg_locked (and similar other
> places) and do the check for smaller between the passed parameter and
> return value from sock_rcvtimeo function. As we need to pass a new
> timeout parameter anyway, it probably then makes sense to move the
> sock_rcvtimeo call all the way up the call chain to do_recvmmsg and
> compare and send the finalized timeout value to the function calls
> upto tcp_recvmsg_locked, right?
>
> I would really appreciate any suggestion about this issue so that I
> can try to fix it. Thank you!
>
> Regards,
> Dorjoy