(gdb) bt
#0 0x00007efd8d9f15b0 in MEM_ROOT::Alloc (length=56, this=this@entry=0x0) at ./include/my_alloc.h:157
#1 init_default_directories (alloc=alloc@entry=0x0) at ./mysys/my_default.cc:1632
#2 0x00007efd8d9f817a in my_load_defaults (conf_file=0x7efd8e751f64 "my", groups=0x7efd8e7550c8, argc=0x7ffd8941b674, argv=0x7ffd8941b678, alloc=0x0, default_directories=0x555a8abccc00) at ./mysys/my_default.cc:692
#3 0x00007efd8e74fe1b in netsnmp_mysql_init () from /lib/x86_64-linux-gnu/libnetsnmptrapd.so.35
#4 0x0000555a8a9e3873 in main (argc=<optimized out>, argv=<optimized out>) at snmptrapd.c:1196
What happens is that we are calling my_load_defaults() even though we have mysql_options(), and the arguments we pass into my_load_defaults() are NULL, which eventually get de-referenced.
The fix is to change the configure script to only call my_load_defaults() if we don't have mysql_options().
There is a test package available in the following ppa:
When running this test package, you will instead see:
$ sudo /usr/sbin/snmptrapd -LOw -f
[Where problems can occur]
We are changing how snmptrapd initialises and begins connections to a mysql server, and if a regression were to occur, it would be limited to users of snmptrapd with the mysql backend. Other database backends would not be affected.
Other binaries produced would also not be affected.
[Other Info]
The issue was fixed upstream by the following commit:
[Impact]
When starting snmptrapd configured to connect to a mysql server, we segmentation fault when calling my_load_defaults():
$ sudo /usr/sbin/snmptrapd -LOw -f
Segmentation fault (core dumped)
(gdb) bt entry=0x0) at ./include/ my_alloc. h:157 directories (alloc= alloc@entry= 0x0) at ./mysys/ my_default. cc:1632 0x7efd8e751f64 "my", groups= 0x7efd8e7550c8, argc=0x7ffd8941 b674, argv=0x7ffd8941 b678, alloc=0x0, default_ directories= 0x555a8abccc00) at ./mysys/ my_default. cc:692 64-linux- gnu/libnetsnmpt rapd.so. 35
#0 0x00007efd8d9f15b0 in MEM_ROOT::Alloc (length=56, this=this@
#1 init_default_
#2 0x00007efd8d9f817a in my_load_defaults (conf_file=
#3 0x00007efd8e74fe1b in netsnmp_mysql_init () from /lib/x86_
#4 0x0000555a8a9e3873 in main (argc=<optimized out>, argv=<optimized out>) at snmptrapd.c:1196
What happens is that we are calling my_load_defaults() even though we have mysql_options(), and the arguments we pass into my_load_defaults() are NULL, which eventually get de-referenced.
The fix is to change the configure script to only call my_load_defaults() if we don't have mysql_options().
[Testcase]
$ sudo apt update downloader
$ sudo apt install snmp snmpd snmptrapd snmp-mibs-
Edit /etc/snmp/ snmptrapd. conf and add the following entries:
disableAuthoriz ation yes
traphandle default /usr/bin/logger
sqlMaxQueue 1
sqlSaveInterval 9
Save and exit.
It is easier to reproduce if you stop and disable all services:
$ sudo systemctl stop snmptrapd.service
$ sudo systemctl stop snmp.service
Then try running:
$ sudo /usr/sbin/snmptrapd -LOw -f
Segmentation fault (core dumped)
There is a test package available in the following ppa:
When running this test package, you will instead see:
$ sudo /usr/sbin/snmptrapd -LOw -f
[Where problems can occur]
We are changing how snmptrapd initialises and begins connections to a mysql server, and if a regression were to occur, it would be limited to users of snmptrapd with the mysql backend. Other database backends would not be affected.
Other binaries produced would also not be affected.
[Other Info]
The issue was fixed upstream by the following commit:
commit 011342d8e453b9e 0585bf77f659d80 c648df8c9f /github. com/net- snmp/net- snmp/commit/ 011342d8e453b9e 0585bf77f659d80 c648df8c9f
Author: Bart Van Assche <email address hidden>
Date: Sat Aug 18 09:28:14 2018 -0700
Subject: snmptrapd: Let configure check for mysql_options()
Link: https:/