Build fails on Debian kernel 6.12: recvmsg signature mismatch (IP_TUNNEL_RECURSION_LIMIT guard issue)

[mr-brune]

Description

Building the module fails on Debian 13 (trixie) with kernel 6.12.90+deb13.1 due to a recvmsg function signature mismatch.

Error

/usr/src/quic-git/modules/net/quic/socket.c:2868:28: error: initialization of
'int (*)(struct sock *, struct msghdr *, size_t, int, int *)' from incompatible
pointer type 'int (*)(struct sock *, struct msghdr *, size_t, int)'
[-Wincompatible-pointer-types]
 2868 |         .recvmsg        =  quic_recvmsg,

Root Cause

In socket.c, the guard used to select the quic_recvmsg signature is:

#ifdef IP_TUNNEL_RECURSION_LIMIT
static int quic_recvmsg(struct sock *sk, struct msghdr *msg, size_t msg_len,
                        int flags)  // 4 params (old kernel)
#else
static int quic_recvmsg(struct sock *sk, struct msghdr *msg, size_t msg_len,
                        int flags, int *addr_len)  // 5 params (new kernel)
#endif

On Debian kernel 6.12, IP_TUNNEL_RECURSION_LIMIT is defined (value 5) in include/net/ip_tunnels.h, so the 4-parameter variant is compiled. However, struct proto.recvmsg on this kernel expects the 5-parameter signature (with int *addr_len), causing the type mismatch.

$ grep -r "IP_TUNNEL_RECURSION_LIMIT" /usr/src/linux-headers-6.12.90+deb13.1-common/include/
/usr/src/linux-headers-6.12.90+deb13.1-common/include/net/ip_tunnels.h:#define IP_TUNNEL_RECURSION_LIMIT 5

Suggested Fix

Replace the IP_TUNNEL_RECURSION_LIMIT guard with a proper kernel version check, which is the only reliable way to detect this signature change:

#if LINUX_VERSION_CODE < KERNEL_VERSION(6, 11, 0)
static int quic_recvmsg(struct sock *sk, struct msghdr *msg, size_t msg_len,
                        int flags)
#else
static int quic_recvmsg(struct sock *sk, struct msghdr *msg, size_t msg_len,
                        int flags, int *addr_len)
#endif

Environment

• OS: Debian 13 (trixie)
• Kernel: 6.12.90+deb13.1-amd64
• Headers: linux-headers-6.12.90+deb13.1-amd64 / linux-headers-6.12.90+deb13.1-common

[lxin]

This change actually landed upstream in v7.1:

commit 8341c989ac77d712c7d6e2bce29e8a4bcb2eeae4
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Feb 27 15:11:20 2026 +0000

    net: remove addr_len argument of recvmsg() handlers

I think what’s happening is that Debian’s 6.12.x kernel backported this commit. That’s something we can’t really control across different distro kernels.

I already tried avoiding plain KERNEL_VERSION() checks by using a macro introduced around the same change, but it still breaks depending on how each distro picks and mixes backports.

At this point I don’t really have a clean generic solution. If I add a Debian-specific check, it’ll likely just shift the problem and still break somewhere else on other kernels.

Let me know if you have a better way to handle this. Otherwise we may just need to wait until Linux QUIC is merged upstream (The patchset is already at v13: https://lore.kernel.org/netdev/cover.1780855296.git.lucien.xin@gmail.com/)

Thanks.

[dreibh]

I noticed the same issue under Ubuntu 26.04 (kernel 7.0.14). IP_TUNNEL_RECURSION_LIMIT is set, but the call signature of quic_recvmsg() is still the old one. The fix for Ubuntu was a version check for 7.1.0 (-> #76).

I could also make some tests under OpenSUSE Tumbleweed and Alpine, if this is useful.

[dreibh]

The build issue also occurs under OpenSUSE Tumbleweed (VERSION_ID="20260628"). #if LINUX_VERSION_CODE >= KERNEL_VERSION(7, 1, 0) (#76) works here as well.

$ uname -a
Linux opensuse 7.0.12-1-default #1 SMP PREEMPT_DYNAMIC Wed Jun 10 05:12:39 UTC 2026 (8beab0b) x86_64 x86_64 x86_64 GNU/Linux

The same for Alpine Linux 3.24, i.e. #76 works here as well.

$ uname -a
Linux alpine 6.18.37-0-lts #1-Alpine SMP PREEMPT_DYNAMIC 2026-06-29 10:52:25 x86_64 GNU/Linux