ASTERISK-28800: Still open?

Yesterday I hit a highly reproducible segfault in Asterisk 20.6.0 and Asterisk 18. After some careful googling I came upon ASTERISK-28800: core: SIGSEGV on DTMF when some modules not loaded which fit my issue. As this is an archive site, I was wondering if this bug was fixed, or if it has migrated and I failed to find it.

The issue is basically that, without res_timing modules loaded, Asterisk will segfault when it receives DTMF on a call, such as in a dialplan menu. The segfault happens with no error and no log, just call the system, press a button, and boom you’re back at the OS command prompt. There appears to be a missing error handler to cause the missing module to be detected and the system config to be gracefully rejected.

The reason I was running without the timing modules at all is because I’m rebuilding a Asterisk server that is very basic, it just does SIP, a simple dialplan, and voicemail. Asterisk 20 comes with ~300 modules out of the box, of which I currently know I need ~100. As some of these modules look like things I know I won’t need but could be useful to an attacker, I want to disable modules unless I’m confident I need them. Given the number of modules and the overall good missing module reporting I took the approach of disabling everything and enabling what I needed as I tested. I missed the timing modules in reading over the list for obvious needs.

So, from a user perspective, I don’t expect Asterisk to work without the timing modules, and I know I’m playing with live wires by mucking with the module loading, but I do expect Asterisk to not segfault silently when a module is missing. Please let me know if ASTERISK-28800 is still open or not. Thanks.

Issues were not recreated on GitHub, if noone has opened a new one then it’s not present. Any closed issues would also be present on GitHub since our starting to use it.

Okay, I’ll I didn’t see it on Github and that explains it. I’ll reopen it as, while ultimately it was user error, the process to identify the error could be improved. Thanks.