Package:
iptables-netflow-dkms,linux-headers-4.19.0-17-amd64,linux-headers-4.19.0-17-i686-pae
Severity: serious
Version: iptables-netflow/2.3-5
Version: iptables-netflow/2.5.1-2
Version: linux/4.19.194-1
Tags: buster
Forwarded: https://github.com/aabc/ipt-netflow/issues/177
Since kernel packages linux-{image,headers}-4.19.0-17-*, at least with
-amd64 and -i686-pae, iptables-netflow-dkms no more compiles its kernel
module upon kernel installation:
In file included from /var/lib/dkms/ipt-netflow/2.3/build/ipt_NETFLOW.c:75:
/var/lib/dkms/ipt-netflow/2.3/build/ipt_NETFLOW.c: In function
‘register_ct_events’:
/var/lib/dkms/ipt-netflow/2.3/build/compat.h:173:21: error: implicit
declaration of function ‘ref_module’; did you mean ‘use_module’?
[-Werror=implicit-function-declaration]
# define use_module ref_module
^~~~~~~~~~
/var/lib/dkms/ipt-netflow/2.3/build/ipt_NETFLOW.c:5399:3: note: in expansion of
macro ‘use_module’
use_module(THIS_MODULE, netlink_m);
^~~~~~~~~~
Reading the kernel changelog, there are a few very suspicious entries
listed under upstream version 4.19.191:
- modules: mark ref_module static
- modules: mark find_symbol static
- modules: mark each_symbol_section static
One of the commits above (8745aa4e resp. 7ef5264d) states:
ref_module isn't used anywhere outside of module.c.
Which is only seems true if you ignore any third-party kernel modules
out there.
So why is the kernel API suddenly removing API-code used by third-party
modules inmidst a stable update? This looks like a regression to me. I
thought that stable updates only change the ABI, but not the API. (Well,
at least upstream and in Debian. :-)
I also tried the iptables-netflow-dkms 2.5.1-2 from Bullseye on Buster,
but it fails to build the kernel module for 4.19.0-17-* when as well.
2.5.1-2 though still works fine on Sid/Bullseye, hence marked as found
in the version in Sid, but tagged buster. In case this causes issues in
the BTS or the release team scripts, please rather remove 2.5.1-2 from
the "found" versions instead of removing the buster tag — unless the
same regression gets introduced into Sid and Bullseye as well.
Debian kernel maintainers: If this 3rd-party-module-breaking regression
was really intended and won't be fixed, please reassign the bug to
iptables-netflow-dkms only.
I also reported this issue to iptables-netflow upstream at
https://github.com/aabc/ipt-netflow/issues/177 as I think it at least
should update the version based ifdef checks in something which looks
like a similar issue in kernel 5.13, see
https://github.com/aabc/ipt-netflow/commit/5aae3791922bd3df878605b15e83ea48a4bd096c
which is part of iptables-netflow upstream's 2.6 release, not yet
packaged due to the freeze for bullseye.
I'll try and see if I can get that fix backported to the package in
buster (and if needed, later to the one in bullseye as well) and will
see if it actually helps in this case, too.
JFTR: dkms from buster-backports (as reported below) is only installed
as I needed it for the iptables-netflow-dkms package from bullseye. It
happened with dkms from buster before as well.
-- System Information:
Debian Release: 10.10
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable'),
(400, 'proposed-updates-debug'), (400, 'proposed-updates')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-12-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled
Versions of packages iptables-netflow-dkms depends on:
ii dkms 2.8.4-3~bpo10+1
ii libc6 2.28-10
ii libc6-dev 2.28-10
ii libxtables-dev 1.8.2-4
ii pkg-config 0.29-6
Versions of packages iptables-netflow-dkms recommends:
ii iptables 1.8.2-4
Versions of packages iptables-netflow-dkms suggests:
ii irqtop 2.3-5
ii nfdump 1.6.17-1
-- no debconf information
