So, by reading git bisect final output:

b29ddccf36946a90323486221f39e9f88cc01b8e is the first bad commit
commit b29ddccf36946a90323486221f39e9f88cc01b8e
Author: Fernando Fernandez Mancera <[email protected]>
Date:   Fri Nov 21 01:14:32 2025 +0100

    netfilter: nft_connlimit: update the count if add was skipped
    
    [ Upstream commit 69894e5b4c5e28cda5f32af33d4a92b7a4b93b0e ]
    
    Connlimit expression can be used for all kind of packets and not
only
    for packets with connection state new. See this ruleset as example:
    
    table ip filter {
            chain input {
                    type filter hook input priority filter; policy
accept;
                    tcp dport 22 ct count over 4 counter
            }
    }
    
    Currently, if the connection count goes over the limit the counter
will
    count the packets. When a connection is closed, the connection
count
    won't decrement as it should because it is only updated for new
    connections due to an optimization on __nf_conncount_add() that
prevents
    updating the list if the connection is duplicated.
    
    To solve this problem, check whether the connection was skipped and
if
    so, update the list. Adjust count_tree() too so the same fix is
applied
    for xt_connlimit.
    
    Fixes: 976afca1ceba ("netfilter: nf_conncount: Early exit in
nf_conncount_lookup() and cleanup")
    Closes:
https://lore.kernel.org/netfilter/trinity-85c72a88-d762-46c3-be97-36f10e5d9796-1761173693813@3c-app-mailcom-bs12/
    Signed-off-by: Fernando Fernandez Mancera <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 net/netfilter/nf_conncount.c  | 12 ++++++++----
 net/netfilter/nft_connlimit.c | 13 +++++++++++--
 2 files changed, 19 insertions(+), 6 deletions(-)


I got the clue that the issue seems related to netfilter connection
count/track limit.
Effectively, I do use in my iptables scripts de connection limit
feature to deal with some DoS activity.


I can assert that by just commenting the following iptables line on my
scripts:

     iptables -A INPUT -p tcp -m connlimit --connlimit-above 111 -j
REJECT --reject-with tcp-reset

And reloading the rules, networking resumes working normally with
latest 6.12.73 kernel (and presumably with all of them in between).
Still, this iptables rule has worked nicely for me for years.
Not sure whether I should dismiss it from now on, since this is the
intended way for the kernel to work, or there is, indeed, something
wrong on the kernel

Cheers.

On Wed, 2026-03-11 at 11:15 +0100, Salvatore Bonaccorso wrote:
> Control: tags -1 + moreinfo upstream
> 
> Hi
> 
> On Wed, Mar 11, 2026 at 11:02:42AM +0100, Alejandro Olivan Alvarez
> wrote:
> > Package: linux-image-6.12.73+deb13-amd64
> > Version: 6.12.73-1
> > Severity: normal
> > X-Debbugs-Cc: [email protected]
> > 
> > Dear Maintainer,
> > 
> >    * What led up to the situation?
> >         apt-get dist-upgrade
> > 
> >    * What exactly did you do (or not do) that was effective (or
> >      ineffective)?
> >         reboot to previous linux-image-6.12.41+deb13-amd64 makes
> > networking
> > work again.
> > 
> >    * What was the outcome of this action?
> > 
> >         Seems like TCP connections do not work beyond the first
> > connection.
> >         For example, two apt-get update commands fail on the second
> > one:
> > 
> > root@marcamalaga:~# uname -r
> > 6.12.73+deb13-amd64
> > root@marcamalaga:~# date
> > Wed Mar 11 10:22:19 AM CET 2026
> > root@marcamalaga:~# apt-get update
> > Get:1 http://security.debian.org/debian-security trixie-security
> > InRelease
> > [43.4 kB]
> > Hit:2 http://ftp.es.debian.org/debian trixie InRelease
> > Get:3 http://ftp.es.debian.org/debian trixie-updates InRelease
> > [47.3 kB]
> > Hit:4 https://www.deb-multimedia.org trixie InRelease
> > Fetched 90.7 kB in 1s (152 kB/s)
> > Reading package lists... Done
> > root@marcamalaga:~#
> > root@marcamalaga:~# date
> > Wed Mar 11 10:22:28 AM CET 2026
> > root@marcamalaga:~#
> > root@marcamalaga:~# apt-get update
> > Hit:1 http://security.debian.org/debian-security trixie-security
> > InRelease
> > Hit:2 http://ftp.es.debian.org/debian trixie InRelease
> > Hit:3 http://ftp.es.debian.org/debian trixie-updates InRelease
> > Ign:4 https://www.deb-multimedia.org trixie InRelease
> > Ign:4 https://www.deb-multimedia.org trixie InRelease
> > Ign:4 https://www.deb-multimedia.org trixie InRelease
> > Err:4 https://www.deb-multimedia.org trixie InRelease
> >   Cannot initiate the connection to www.deb-multimedia.org:443
> > (2607:5300:120:e71::1). - connect (101: Network is unreachable)
> > Could not
> > connect to www.deb-multimedia.org:443 (158.69.254.113), connection
> > timed out
> >   Cannot initiate the connection to www.deb-multimedia.org:443
> > (2607:5300:120:e71::1). - connect (101: Network is unreachable)
> > Reading package lists... Done
> > W: Failed to fetch
> > https://www.deb-multimedia.org/dists/trixie/InRelease
> > Cannot initiate the connection to www.deb-multimedia.org:443
> > (2607:5300:120:e71::1). - connect (101: Network is unreachable)
> > W: Some index files failed to download. They have been ignored, or
> > old ones
> > used instead.
> > root@marcamalaga:~#
> > 
> >         Similarly, for illustration, here two probes of an HTTP
> > stream, works
> > only once:
> > 
> > administrator@marcamalaga:~$ uname -r
> > 6.12.73+deb13-amd64
> > administrator@marcamalaga:~$ date
> > Wed Mar 11 10:19:23 AM CET 2026
> > administrator@marcamalaga:~$ ffprobe
> > http://10.20.10.80:8130/malagafmmobile
> > ffprobe version 7.1.3 Copyright (c) 2007-2025 the FFmpeg developers
> >   built with gcc 14 (Debian 14.2.0-19)
> >   configuration: --disable-decoder=amrnb --disable-gnutls --
> > disable-liblensfun
> > --disable-libopencv --disable-podpages --disable-sndio --disable-
> > stripping
> > --disable-omx --enable-avfilter --enable-chromaprint --enable-
> > frei0r --enable-
> > gcrypt --enable-gpl --enable-ladspa --enable-libaom --enable-
> > libaribb24
> > --enable-libass --enable-libbluray --enable-libbs2b --enable-
> > libcaca --enable-
> > libcdio --enable-libcodec2 --enable-libdav1d --enable-libdavs2 --
> > enable-
> > libdc1394 --enable-libdrm --enable-libdvdnav --enable-libdvdread --
> > enable-
> > libfdk-aac --enable-libflite --enable-libfontconfig --enable-
> > libfreetype
> > --enable-libfribidi --enable-libgme --enable-libgsm --enable-
> > libharfbuzz
> > --enable-libiec61883 --enable-libilbc --enable-libjack --enable-
> > libjxl
> > --enable-libklvanc --enable-libkvazaar --enable-libmp3lame --
> > enable-libmysofa
> > --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-
> > libopenh264
> > --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-
> > libplacebo
> > --enable-libpulse --enable-librabbitmq --enable-librist --enable-
> > librsvg
> > --enable-librubberband --enable-libshine --enable-libsmbclient --
> > enable-
> > libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --
> > enable-libsvtav1
> > --enable-libtesseract --enable-libtheora --enable-libtwolame --
> > enable-
> > libvidstab --enable-libvmaf --enable-libvo-amrwbenc --enable-
> > libvorbis
> > --enable-libvpx --enable-libwebp --enable-libwebp --enable-libx264
> > --enable-
> > libx265 --enable-libxavs2 --enable-libxml2 --enable-libxvid --
> > enable-libzimg
> > --enable-libzmq --enable-libzvbi --enable-lv2 --enable-nonfree --
> > enable-openal
> > --enable-opencl --enable-opengl --enable-openssl --enable-postproc
> > --enable-
> > pthreads --enable-shared --enable-version3 --
> > incdir=/usr/include/x86_64-linux-
> > gnu --libdir=/usr/lib/x86_64-linux-gnu --prefix=/usr --
> > toolchain=hardened
> > --enable-vaapi --enable-libvpl --cc=x86_64-linux-gnu-gcc --
> > cxx=x86_64-linux-
> > gnu-g++ --disable-altivec --shlibdir=/usr/lib/x86_64-linux-gnu
> >   libavutil      59. 39.100 / 59. 39.100
> >   libavcodec     61. 19.101 / 61. 19.101
> >   libavformat    61.  7.100 / 61.  7.100
> >   libavdevice    61.  3.100 / 61.  3.100
> >   libavfilter    10.  4.100 / 10.  4.100
> >   libswscale      8.  3.100 /  8.  3.100
> >   libswresample   5.  3.100 /  5.  3.100
> >   libpostproc    58.  3.100 / 58.  3.100
> > Input #0, mp3, from 'http://10.20.10.80:8130/malagafmmobile':
> >   Metadata:
> >     icy-br          : 170
> >     icy-description : : Radio MARCA MA :
> >     icy-genre       : Sport Radio
> >     icy-name        : : Radio MARCA MA :
> >     icy-pub         : 1
> >     icy-url         : www.radiomarca.com
> >     StreamTitle     :
> >   Duration: N/A, start: 0.000000, bitrate: 191 kb/s
> >   Stream #0:0: Audio: mp3 (mp3float), 44100 Hz, stereo, fltp, 191
> > kb/s
> > administrator@marcamalaga:~$
> > administrator@marcamalaga:~$
> > administrator@marcamalaga:~$ date
> > Wed Mar 11 10:19:44 AM CET 2026
> > administrator@marcamalaga:~$ ffprobe
> > http://10.20.10.80:8130/malagafmmobile
> > ffprobe version 7.1.3 Copyright (c) 2007-2025 the FFmpeg developers
> >   built with gcc 14 (Debian 14.2.0-19)
> >   configuration: --disable-decoder=amrnb --disable-gnutls --
> > disable-liblensfun
> > --disable-libopencv --disable-podpages --disable-sndio --disable-
> > stripping
> > --disable-omx --enable-avfilter --enable-chromaprint --enable-
> > frei0r --enable-
> > gcrypt --enable-gpl --enable-ladspa --enable-libaom --enable-
> > libaribb24
> > --enable-libass --enable-libbluray --enable-libbs2b --enable-
> > libcaca --enable-
> > libcdio --enable-libcodec2 --enable-libdav1d --enable-libdavs2 --
> > enable-
> > libdc1394 --enable-libdrm --enable-libdvdnav --enable-libdvdread --
> > enable-
> > libfdk-aac --enable-libflite --enable-libfontconfig --enable-
> > libfreetype
> > --enable-libfribidi --enable-libgme --enable-libgsm --enable-
> > libharfbuzz
> > --enable-libiec61883 --enable-libilbc --enable-libjack --enable-
> > libjxl
> > --enable-libklvanc --enable-libkvazaar --enable-libmp3lame --
> > enable-libmysofa
> > --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-
> > libopenh264
> > --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-
> > libplacebo
> > --enable-libpulse --enable-librabbitmq --enable-librist --enable-
> > librsvg
> > --enable-librubberband --enable-libshine --enable-libsmbclient --
> > enable-
> > libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --
> > enable-libsvtav1
> > --enable-libtesseract --enable-libtheora --enable-libtwolame --
> > enable-
> > libvidstab --enable-libvmaf --enable-libvo-amrwbenc --enable-
> > libvorbis
> > --enable-libvpx --enable-libwebp --enable-libwebp --enable-libx264
> > --enable-
> > libx265 --enable-libxavs2 --enable-libxml2 --enable-libxvid --
> > enable-libzimg
> > --enable-libzmq --enable-libzvbi --enable-lv2 --enable-nonfree --
> > enable-openal
> > --enable-opencl --enable-opengl --enable-openssl --enable-postproc
> > --enable-
> > pthreads --enable-shared --enable-version3 --
> > incdir=/usr/include/x86_64-linux-
> > gnu --libdir=/usr/lib/x86_64-linux-gnu --prefix=/usr --
> > toolchain=hardened
> > --enable-vaapi --enable-libvpl --cc=x86_64-linux-gnu-gcc --
> > cxx=x86_64-linux-
> > gnu-g++ --disable-altivec --shlibdir=/usr/lib/x86_64-linux-gnu
> >   libavutil      59. 39.100 / 59. 39.100
> >   libavcodec     61. 19.101 / 61. 19.101
> >   libavformat    61.  7.100 / 61.  7.100
> >   libavdevice    61.  3.100 / 61.  3.100
> >   libavfilter    10.  4.100 / 10.  4.100
> >   libswscale      8.  3.100 /  8.  3.100
> >   libswresample   5.  3.100 /  5.  3.100
> >   libpostproc    58.  3.100 / 58.  3.100
> > [tcp @ 0x561036562fc0] Connection to tcp://10.20.10.80:8130 failed:
> > Connection
> > timed out
> > http://10.20.10.80:8130/malagafmmobile: Connection timed out
> > 
> >         The problem happens on VIRTUAL MACHINES (PROXMOX 9 guests)
> > using virtio
> > drivers.
> >         I have experienced same behaviour on dist-upgraded Bookworm
> > VMs with
> > latest kernel.
> >         All VMs worked as expected and are inproduction without any
> > issues
> > before dist-upgrading them.
> >         Machines still not dist-upgraded work flawless.
> >         The problem is fully consistent with kernel upgrade... just
> > reboot to
> > previous kernel to resume work.
> > 
> >    * What outcome did you expect instead?
> >         Regular operation of the networking stack
> 
> I suspect this then depends on the underlaying virtualisation,
> otherwise we would have I think more such reports. As you have a
> fairly straightforward reproducer, can you please bisect the changes
> between 6.12.41 and 6.12.73? (Ideally you test first the kernels
> inbetween up to 6.12.69-1 so we have a closer range, you can get
> other
> images earlier in the archive from the snapshots service. This should
> be done as first step, because there were a a couple of releases in
> Debian between 6.12.41-1 and 6.12.73-1). So assume you have 6.12.69-1
> which is good, and 6.12.73-1 which is not anymore, bisecting would
> involve:
> 
>     git clone --single-branch -b linux-6.12.y
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
>     cd linux-stable
>     git checkout v6.12.69
>     cp /boot/config-$(uname -r) .config
>     yes '' | make localmodconfig
>     make savedefconfig
>     mv defconfig arch/x86/configs/my_defconfig
> 
>     # test 6.12.69 to ensure this is "good"
>     make my_defconfig
>     make -j $(nproc) bindeb-pkg
>     ... install the resulting .deb package and confirm problem does
> not exist
> 
>     # test 6.12.73 to ensure this is "bad"
>     git checkout v6.12.73
>     make my_defconfig
>     make -j $(nproc) bindeb-pkg
>     ... install the resulting .deb package and confirm the problem
> exists.
> 
> With that confirmed, the bisection can start:
> 
>     git bisect start
>     git bisect good v6.12.69
>     git bisect bad v6.12.73
> 
> In each bisection step git checks out a state between the oldest
> known-bad and the newest known-good commit. In each step test using:
> 
>     make my_defconfig
>     make -j $(nproc) bindeb-pkg
>     ... install, verify if problem exists
> 
> and if the problem is hit run:
> 
>     git bisect bad
> 
> and if the problem doesn't trigger run:
> 
>     git bisect good
> 
> . Please pay attention to always select the just built kernel for
> booting, it won't always be the default kernel picked up by grub.
> 
> Iterate until git announces to have identified the first bad commit.
> 
> Then provide the output of
> 
>     git bisect log
> 
> In the course of the bisection you might have to uninstall previous
> kernels again to not exhaust the disk space in /boot. Also in the end
> uninstall all self-built kernels again.
> 
> Regards,
> Salvatore

Reply via email to