On Sat, 12 Sept 2026 at 06:23, Salvatore Bonaccorso <[email protected]> wrote:
> There is [1], but it is not immediately clear if it has been > reporterdd upstream. > > [1] > https://gist.github.com/thesmartshadow/001cea595e75fed6aaea7389666dc9eb I've not seen anything in the upstream issue tracker. Fortunately, Debian as shipped *and configured* is not immediately vulnerable. The analysis focused on the build-time configuration, not the run-time configuration. I was trying to reproduce it and nothing was listening on TCP port 199 The systemd service (and init script) have a run-time enabling of modules[2] ExecStart=/usr/sbin/snmpd -LOw -u Debian-snmp -g Debian-snmp -I -smux,mteTrigger,mteTriggerConf -f The -I option specifies which modules are initialized unless the list is preceded by - which makes it modules we won't initialise. So, the smux (and the two mteTrigger) modules are not started by a default Debian setup. If smux is enabled, does snmpd hang? Yes, it does so definitely worthwhile doing the fix. I tried running an snmpwalk on the impacted agent and it didn't respond. The reporter checked it on 5.9.3+dfsg-2+deb12u1 but I found the issue in both 5.9.4+dfsg-2+deb13u1 and 5.9.5.2+dfsg-2.1+b2 - Craig [2] https://salsa.debian.org/debian/net-snmp/-/blob/master/debian/snmpd.service?ref_type=heads#L9
