[GH-ISSUE #259] Incompatibility with Ubuntu 26.04 7.0.0-38 kernel #142

Open
opened 2026-10-13 21:06:58 +00:00 by bsakaguchi · 10 comments
Owner

Originally created by @LDVSOFT on GitHub (Oct 3, 2026).
Original GitHub issue: https://github.com/amnezia-vpn/amneziawg-linux-kernel-module/issues/259

Compilation fails when updating linux kernel on Ubuntu 26.04 to most recent 7.0.0-38 with:

In file included from <command-line>:
socket.c: In function ‘wg_socket_init’:
./././compat/compat.h:1449:79: error: passing argument 2 of ‘setup_udp_tunnel_sock’ from incompatible pointer type [-Werror=incompatible-pointer-types]
 1449 | #define setup_udp_tunnel_sock(net, sk, sock_cfg) setup_udp_tunnel_sock(net, sk->sk_socket, sock_cfg)
socket.c:434:9: note: in expansion of macro ‘setup_udp_tunnel_sock’
  434 |         setup_udp_tunnel_sock(net, new4->sk, &cfg);
      |         ^~~~~~~~~~~~~~~~~~~~~
In file included from ./././compat/compat.h:1448:
/usr/src/linux-headers-7.0.0-38-generic/include/net/udp_tunnel.h:98:58: note: expected ‘struct sock *’ but argument is of type ‘struct socket *’
   98 | void setup_udp_tunnel_sock(struct net *net, struct sock *sk,
      |                                             ~~~~~~~~~~~~~^~

In checking the Linux headers: 7.0.0-34 had

// include/net/udp_tunnel.h

/* Setup the given (UDP) sock to receive UDP encapsulated packets */
void setup_udp_tunnel_sock(struct net *net, struct socket *sock,
                           struct udp_tunnel_sock_cfg *sock_cfg);

and 7.0.0-38 has

// include/net/udp_tunnel.h

/* Setup the given (UDP) sock to receive UDP encapsulated packets */
void setup_udp_tunnel_sock(struct net *net, struct sock *sk,
                           struct udp_tunnel_sock_cfg *sock_cfg);

Looks like OpenVPN had a similar fate: https://github.com/OpenVPN/ovpn-dco/issues/103.

Originally created by @LDVSOFT on GitHub (Oct 3, 2026). Original GitHub issue: https://github.com/amnezia-vpn/amneziawg-linux-kernel-module/issues/259 Compilation fails when updating linux kernel on Ubuntu 26.04 to most recent 7.0.0-38 with: ``` In file included from <command-line>: socket.c: In function ‘wg_socket_init’: ./././compat/compat.h:1449:79: error: passing argument 2 of ‘setup_udp_tunnel_sock’ from incompatible pointer type [-Werror=incompatible-pointer-types] 1449 | #define setup_udp_tunnel_sock(net, sk, sock_cfg) setup_udp_tunnel_sock(net, sk->sk_socket, sock_cfg) socket.c:434:9: note: in expansion of macro ‘setup_udp_tunnel_sock’ 434 | setup_udp_tunnel_sock(net, new4->sk, &cfg); | ^~~~~~~~~~~~~~~~~~~~~ In file included from ./././compat/compat.h:1448: /usr/src/linux-headers-7.0.0-38-generic/include/net/udp_tunnel.h:98:58: note: expected ‘struct sock *’ but argument is of type ‘struct socket *’ 98 | void setup_udp_tunnel_sock(struct net *net, struct sock *sk, | ~~~~~~~~~~~~~^~ ``` In checking the Linux headers: 7.0.0-34 had ```c // include/net/udp_tunnel.h /* Setup the given (UDP) sock to receive UDP encapsulated packets */ void setup_udp_tunnel_sock(struct net *net, struct socket *sock, struct udp_tunnel_sock_cfg *sock_cfg); ``` and 7.0.0-38 has ```c // include/net/udp_tunnel.h /* Setup the given (UDP) sock to receive UDP encapsulated packets */ void setup_udp_tunnel_sock(struct net *net, struct sock *sk, struct udp_tunnel_sock_cfg *sock_cfg); ``` Looks like OpenVPN had a similar fate: https://github.com/OpenVPN/ovpn-dco/issues/103.
Author
Owner

@LDVSOFT commented on GitHub (Oct 3, 2026):

It seems that the fix that changed function signature in 7.1.5 was back-ported into previous branch? We might need to update compat.h version check.

<!-- gh-comment-id:5968888740 --> @LDVSOFT commented on GitHub (Oct 3, 2026): It seems that the fix that changed function signature in 7.1.5 was back-ported into previous branch? We might need to update compat.h version check.
Author
Owner

@LDVSOFT commented on GitHub (Oct 3, 2026):

Unfortunately I don't see how one can probe vanilla Linux header for a check if the fix was backported. All version headers contain the same stuff, so either the check shall go autotools-style with probing, or at the very least with grep-ping the headers.

One might argue that Ubuntu here changed Linux API without changing a version. I'll look for a Launchpad ticket.

<!-- gh-comment-id:5972146687 --> @LDVSOFT commented on GitHub (Oct 3, 2026): Unfortunately I don't see how one can probe vanilla Linux header for a check if the fix was backported. All version headers contain the same stuff, so either the check shall go autotools-style with probing, or at the very least with grep-ping the headers. One might argue that Ubuntu here changed Linux API without changing a version. I'll look for a Launchpad ticket.
Author
Owner

@SignFinder commented on GitHub (Oct 3, 2026):

That is a workaround to boot previous kernel - 6.8.0-146-generic. It is still in grub.

sudo cp /etc/default/grub /etc/default/grub.bak
grep -n '^GRUB_DEFAULT\|^GRUB_SAVEDEFAULT' /etc/default/grub
sudo sed -i 's|^GRUB_DEFAULT=.*|GRUB_DEFAULT="Advanced options for Ubuntu>Ubuntu, with Linux 6.8.0-146-generic"|' /etc/default/grub
grep -n '^GRUB_DEFAULT' /etc/default/grub
sudo update-grub

And block from autoremove

sudo apt-mark manual linux-image-6.8.0-146-generic linux-modules-6.8.0-146-generic linux-headers-6.8.0-146-generic linux-headers-6.8.0-146
<!-- gh-comment-id:5972757226 --> @SignFinder commented on GitHub (Oct 3, 2026): That is a workaround to boot previous kernel - 6.8.0-146-generic. It is still in grub. ``` sudo cp /etc/default/grub /etc/default/grub.bak grep -n '^GRUB_DEFAULT\|^GRUB_SAVEDEFAULT' /etc/default/grub sudo sed -i 's|^GRUB_DEFAULT=.*|GRUB_DEFAULT="Advanced options for Ubuntu>Ubuntu, with Linux 6.8.0-146-generic"|' /etc/default/grub grep -n '^GRUB_DEFAULT' /etc/default/grub sudo update-grub ``` And block from autoremove ``` sudo apt-mark manual linux-image-6.8.0-146-generic linux-modules-6.8.0-146-generic linux-headers-6.8.0-146-generic linux-headers-6.8.0-146 ```
Author
Owner

@LDVSOFT commented on GitHub (Oct 3, 2026):

Wrong, we can look at UTS_UBUNTU_RELEASE_ABI in utsrelease.h. HOWEVER they only changed setup_udp_tunnel_sock.

Changing compat.h to have:

1447 #if LINUX_VERSION_CODE < KERNEL_VERSION(7, 1, 5)
1448 #include <net/udp_tunnel.h>
1449 
1450 // Workaround for Ubuntu 26.04 having API change in 7.0.0-38 that aligned back with upstream
1451 #if !(defined(UTS_UBUNTU_RELEASE_ABI) && (LINUX_VERSION_CODE == KERNEL_VERSION(7, 0, 14)) && (UTS_UBUNTU_RELEASE_ABI >= 38))
1452 #define setup_udp_tunnel_sock(net, sk, sock_cfg) setup_udp_tunnel_sock(net, sk->sk_socket, sock_cfg)
1453 #endif
1454 
1455 #define udp_tunnel_sock_release(sk) udp_tunnel_sock_release(sk->sk_socket)
1456 #endif

seemed to help! I don't know how helpful it is for the general support.

<!-- gh-comment-id:5972797457 --> @LDVSOFT commented on GitHub (Oct 3, 2026): Wrong, we can look at `UTS_UBUNTU_RELEASE_ABI` in `utsrelease.h`. HOWEVER they only changed `setup_udp_tunnel_sock`. Changing compat.h to have: ```c 1447 #if LINUX_VERSION_CODE < KERNEL_VERSION(7, 1, 5) 1448 #include <net/udp_tunnel.h> 1449 1450 // Workaround for Ubuntu 26.04 having API change in 7.0.0-38 that aligned back with upstream 1451 #if !(defined(UTS_UBUNTU_RELEASE_ABI) && (LINUX_VERSION_CODE == KERNEL_VERSION(7, 0, 14)) && (UTS_UBUNTU_RELEASE_ABI >= 38)) 1452 #define setup_udp_tunnel_sock(net, sk, sock_cfg) setup_udp_tunnel_sock(net, sk->sk_socket, sock_cfg) 1453 #endif 1454 1455 #define udp_tunnel_sock_release(sk) udp_tunnel_sock_release(sk->sk_socket) 1456 #endif ``` seemed to help! I don't know how helpful it is for the general support.
Author
Owner

@LDVSOFT commented on GitHub (Oct 3, 2026):

I've filled an issue on Launchpad to confirm the change https://bugs.launchpad.net/ubuntu/+source/linux-hwe-7.0/+bug/2169429

<!-- gh-comment-id:5972847690 --> @LDVSOFT commented on GitHub (Oct 3, 2026): I've filled an issue on Launchpad to confirm the change https://bugs.launchpad.net/ubuntu/+source/linux-hwe-7.0/+bug/2169429
Author
Owner

@Kyoto-sh commented on GitHub (Oct 4, 2026):

I've also run into this problem. As far as I understand, shouldn't the AWG developers fix this somehow and add support for this kernel?

<!-- gh-comment-id:5985744418 --> @Kyoto-sh commented on GitHub (Oct 4, 2026): I've also run into this problem. As far as I understand, shouldn't the AWG developers fix this somehow and add support for this kernel?
Author
Owner

@bivlked commented on GitHub (Oct 5, 2026):

@LDVSOFT's guess about a backport is right: the changelog of Ubuntu's linux 7.0.0-38.38 has "udp_tunnel: Pass struct sock to setup_udp_tunnel_sock()", the upstream 7.1.5 change. The same backport is in the 24.04 HWE kernel 7.0.0-38~24.04.4, and 7.0.0-39 (still in -proposed) keeps the new signature.

Because of that, a check by version or ABI number has to track every such kernel. The approach in #218 avoids it: it looks at the setup_udp_tunnel_sock signature in the kernel headers. We built the module with that change on Debian 12 and 13, Ubuntu 24.04 (6.8 and HWE 7.0.0-38), 25.10 and 26.04 (7.0.0-34, -38 and -39), and it compiled on all of them.

If you use amneziawg-installer, v5.37.1 applies that change to the module source before DKMS builds it (only to the PPA source it was tested with), so a kernel update to 7.0.0-38 goes through without manual steps. A server installed with an older version needs one run of --repair-module; the commands, with the signature check, are in ADVANCED. For a manual install, booting the previous kernel (as @SignFinder showed) or applying #218 by hand works until a fixed source comes from the PPA.

<!-- gh-comment-id:6003760766 --> @bivlked commented on GitHub (Oct 5, 2026): @LDVSOFT's guess about a backport is right: the changelog of Ubuntu's `linux 7.0.0-38.38` has "udp_tunnel: Pass struct sock to setup_udp_tunnel_sock()", the upstream 7.1.5 change. The same backport is in the 24.04 HWE kernel `7.0.0-38~24.04.4`, and `7.0.0-39` (still in -proposed) keeps the new signature. Because of that, a check by version or ABI number has to track every such kernel. The approach in #218 avoids it: it looks at the `setup_udp_tunnel_sock` signature in the kernel headers. We built the module with that change on Debian 12 and 13, Ubuntu 24.04 (6.8 and HWE 7.0.0-38), 25.10 and 26.04 (7.0.0-34, -38 and -39), and it compiled on all of them. If you use [amneziawg-installer](https://github.com/bivlked/amneziawg-installer), v5.37.1 applies that change to the module source before DKMS builds it (only to the PPA source it was tested with), so a kernel update to 7.0.0-38 goes through without manual steps. A server installed with an older version needs one run of `--repair-module`; the commands, with the signature check, are in [ADVANCED](https://github.com/bivlked/amneziawg-installer/blob/main/ADVANCED.en.md#kernel-70-backport-adv). For a manual install, booting the previous kernel (as @SignFinder showed) or applying #218 by hand works until a fixed source comes from the PPA.
Author
Owner

@CptTZ commented on GitHub (Oct 5, 2026):

fyi I tried #262 and it worked, however i think that PR is too rough.

Raised my own PR #265 which avoids hardcoded implementation.

<!-- gh-comment-id:6003781489 --> @CptTZ commented on GitHub (Oct 5, 2026): fyi I tried #262 and it worked, ~~however i think that PR is too rough~~. Raised my own PR #265 which avoids hardcoded implementation.
Author
Owner

@LDVSOFT commented on GitHub (Oct 6, 2026):

@bivlked OH THAT'S WHAT I WANTED TO DO but I'm not that profficent in C compatability macros. I tried looking up _Generic tricks but they don't work for function parameter type.

<!-- gh-comment-id:6021398445 --> @LDVSOFT commented on GitHub (Oct 6, 2026): @bivlked OH THAT'S WHAT I WANTED TO DO but I'm not _that_ profficent in C compatability macros. I tried looking up `_Generic` tricks but they don't work for function parameter type.
Author
Owner

@shvchk commented on GitHub (Oct 12, 2026):

Until proper fix is released, here's how to patch manually with the code from #218 (maybe #265 is better, though, idk):

(
  patch_file="/tmp/awg-pr-218.patch"
  wget -O "$patch_file" https://github.com/VaisVaisov/amneziawg-linux-kernel-module/commit/02789db.patch

  echo "Please review that $patch_file is what you expect"
  echo "Press Enter to continue, Ctrl+C to abort"
  read -r _

  sudo patch -p2 -d /usr/src/amneziawg-1.0.0 < "$patch_file"
)

I'm feeling lucky mode:

wget -O- https://github.com/VaisVaisov/amneziawg-linux-kernel-module/commit/02789db.patch | sudo patch /usr/src/amneziawg-1.0.0/compat/compat.h

Expected sha256sum /usr/src/amneziawg-1.0.0/compat/compat.h:

  • original: b14346040ce0188c47e2db2baad1a4f21aa784510f6c95bbb4aa58d5bbe691c9
  • patched: 8d47a358b4df0b2187788ce6f88ad63128218de1be22c78b263ef3e5d770c26b

After patching do sudo dpkg --configure -a

<!-- gh-comment-id:6131018975 --> @shvchk commented on GitHub (Oct 12, 2026): Until proper fix is released, here's how to patch manually with the code from #218 (maybe #265 is better, though, idk): ```sh ( patch_file="/tmp/awg-pr-218.patch" wget -O "$patch_file" https://github.com/VaisVaisov/amneziawg-linux-kernel-module/commit/02789db.patch echo "Please review that $patch_file is what you expect" echo "Press Enter to continue, Ctrl+C to abort" read -r _ sudo patch -p2 -d /usr/src/amneziawg-1.0.0 < "$patch_file" ) ``` I'm feeling lucky mode: ```sh wget -O- https://github.com/VaisVaisov/amneziawg-linux-kernel-module/commit/02789db.patch | sudo patch /usr/src/amneziawg-1.0.0/compat/compat.h ``` Expected `sha256sum /usr/src/amneziawg-1.0.0/compat/compat.h`: - original: `b14346040ce0188c47e2db2baad1a4f21aa784510f6c95bbb4aa58d5bbe691c9` - patched: `8d47a358b4df0b2187788ce6f88ad63128218de1be22c78b263ef3e5d770c26b` After patching do `sudo dpkg --configure -a`
Sign in to join this conversation.
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
amnezia-vpn/amneziawg-linux-kernel-module#142
No description provided.