SNMPD hangs when a client browses a restricted OID

[Tom Smith]

Overview:
When snmpd is configured to show a limited view of oids using VACM, it is possible to cause snmpd to hang by performing an snmpwalk.

Tested on 5.7.2~dfsg-8.1ubuntu3.2 on Mint 17.1 (aka Ubuntu 14.04) and 5.7.3+dfsg-1ubuntu4 on Ubuntu 16.04.3

Steps to reproduce:
Use VACM to restrict the OIDs that a user has access to as follows: (I'll attach a full snmpd.conf below)
view limited_vw included .1.3.6.1.2.1.1
view limited_vw included .1.3.6.1.2.1.2
view limited_vw included .1.3.6.1.2.1.4.31

Perform an snmpwalk NOT using bulk walk

Expected result; A listing of the contents of those three OID trees

Actual result; snmpwalk will list all the OIDs up to iso.3.6.1.2.1.2.2.1.22 and then hang.

All subsequent attempts to query any SNMP will time out. SNMPD has to be restarted before it will respond again. There doesn't seem to be anything useful in the logs.

Mitigation:
If the user is also allowed to browse two more OIDs the problem goes away:
view limited_vw included .1.3.6.1.2.1.1
view limited_vw included .1.3.6.1.2.1.2
# Necessary OIDs
view limited_vw included .1.3.6.1.2.1.4.1
view limited_vw included .1.3.6.1.2.1.4.25
#
view limited_vw included .1.3.6.1.2.1.4.31

Or, only query the host using snmpbulkwalk.

[Christian Ehrhardt  (paelzer)]

Hi Tom,
thank you for your report.
First of all I can confirm your issue.

In a fresh container triggerable with:
$ apt install snmp snmpd
$ echo > /etc/snmp/snmpd.conf << EOF
agentAddress udp:161,udp6:[::1]:161
view limited_vw included .1.3.6.1.2.1.1
view limited_vw included .1.3.6.1.2.1.2
view limited_vw included .1.3.6.1.2.1.4.31
access limited_grp "" usm priv exact limited_vw none none
sysLocation dummylocation
sysContact dummycontact
createUser limited SHA "password" AES "password"

I tested 16.04 but also the most recent 18.04 - it triggers the issue everywhere.

rouser limited priv -V limited_vw
createUser unlimited SHA "password" AES "password"
rouser unlimited priv
EOF
$ systemctl restart snmpd

# Now the unlimited case is fine:
$ snmpwalk -v3 -u unlimited -l authPriv -a SHA -x AES -A password -X password localhost
# Also the bulkwalk with the limited user is good
$ snmpbulkwalk -v3 -u limited -l authPriv -a SHA -x AES -A password -X password localhost
# But as reported the following seems to hang the server (command hangs, further commands hang immediately)
$ snmpwalk -v3 -u limited -l authPriv -a SHA -x AES -A password -X password localhost

[Christian Ehrhardt  (paelzer)]

I must admit, I'm not a net-snmp expert and I wonder if <email address hidden> is dead htese days - otherwsie I'd recommend to report there as well to get support from developers focussed on it.

Also the limited_hw VAM rules seem rather uncommon (or at least underdocumented), I needed to read [1] to get a bit more info on them. And searching for "limited_vw snmp" lists this bug at the top and nonsense.

Since you have set this up, do you have better links on how it is supposed to work in detail on that configuration?

[1]: https://tools.ietf.org/html/rfc2575

[Christian Ehrhardt  (paelzer)]

While running the commands that triggers the server hang I see a bunch of connects, but the same is true for the working walks.

Once that is triggered snmpd falls into a busy loop (I'd assume some sort of spinning deadlock / infinite loop)

on Strace I see the following repeating:
     0.000085 openat(AT_FDCWD, "/proc/sys/net/ipv4/conf/all/forwarding", O_RDONLY) = 11 <0.000026>
     0.000057 fstat(11, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 <0.000014>
     0.000043 read(11, "1\n", 1024) = 2 <0.000014>
     0.000044 close(11) = 0 <0.000014>
     [...]

Also installing a bunch of dbg symbols to look at where it spins:
$ apt install snmp-dbgsym snmpd-dbgsym libsnmp30-dbg libsensors4-dbgsym libpci3-dbgsym zlib1g-dbg libudev1-dbgsym libpcre3-dbg

An example backtrace:
#0 0x00007fe4de8fad0e in __libc_open64 (file=0x7fe4defd29c0 <ipfw_name> "/proc/sys/net/ipv4/conf/all/forwarding", oflag=0)
    at ../sysdeps/unix/sysv/linux/open64.c:46
#1 0x00007fe4de87ad83 in __GI__IO_file_open (fp=fp@entry=0x558c3bd609a0, filename=<optimized out>, posix_mode=<optimized out>, prot=prot@entry=438,
    read_write=8, is32not64=is32not64@entry=1) at fileops.c:229
#2 0x00007fe4de87b055 in _IO_new_file_fopen (fp=fp@entry=0x558c3bd609a0,
    filename=filename@entry=0x7fe4defd29c0 <ipfw_name> "/proc/sys/net/ipv4/conf/all/forwarding", mode=<optimized out>, mode@entry=0x7fe4defaa952 "r",
    is32not64=is32not64@entry=1) at fileops.c:334
#3 0x00007fe4de86da24 in __fopen_internal (filename=0x7fe4defd29c0 <ipfw_name> "/proc/sys/net/ipv4/conf/all/forwarding", mode=0x7fe4defaa952 "r", is32=1)
    at iofopen.c:86
#4 0x00007fe4de86da6a in _IO_new_fopen (filename=<optimized out>, mode=<optimized out>) at iofopen.c:97
#5 0x00007fe4def7f593 in netsnmp_arch_ip_scalars_ipForwarding_get (value=value@entry=0x7ffe83c37990) at ip-mib/data_access/scalars_linux.c:29
#6 0x00007fe4def36460 in handle_ipForwarding (handler=<optimized out>, reginfo=<optimized out>, reqinfo=0x558c3bec8740, requests=0x558c3bee4b10)
    at ip-mib/ip_scalars.c:112
#7 0x00007fe4df35425d in netsnmp_call_handler (requests=0x558c3bee4b10, reqinfo=0x558c3bec8740, reginfo=0x558c3be69640, next_handler=0x558c3be695d0)
    at agent_handler.c:526
#8 netsnmp_call_next_handler (current=current@entry=0x558c3be69710, reginfo=reginfo@entry=0x558c3be69640, reqinfo=reqinfo@entry=0x558c3bec8740,
    requests=requests@entry=0x558c3bee4b10) at agent_handler.c:640
#9 0x00007fe4df343370 in netsnmp_instance_helper_handler (handler=0x558c3be69710, reginfo=0x558c3be69640, reqinfo=0x558c3bec8740, requests=0x558c3bee4b10)
    at helpers/instance.c:775
#10 0x00007fe4df35425d in netsnmp_call_handler (requests=0x558c3bee4b10, reqinfo=0x558c3bec8740, reginfo=0x558c3be69640, next_handler=0x558c3be69710)
    at agent_handler.c:526
#11 netsnmp_call_next_handler (current=current@entry=0x558c3be69780, reginfo=reginfo@entry=0x558c3be69640, reqinfo=reqinfo@entry=0x558c3bec8740,
    requests=requests@entry=0x558c3bee4b10) at agent_handler.c:640
#12 0x00007fe4df345e7d in netsnmp_scalar_helper_handler (handler=0x558c3be69780, reginfo=0x558c3be69640, reqinfo=0x558c3bec8740, requests=0x558c3bee4b10)
    at helpers/scala...

[Tom Smith (uom)]

Yes, this does seem to be the same issue as https://sourceforge.net/p/net-snmp/mailman/message/35379818/
Sorry for opening a duplicate.

As for explaining my config, "limited_vw" is purely my name, it just needs to match what is defined for the user and group, hence why this is the only search engine result. I suspect that almost nobody has ever used VACM which is why this bug has gone unnoticed for so long.