Segmentation fault while triggering webhook


Server consistently shut down with SIGSEGV when triggering a specific webook.

Steps to reproduce

Mattermost 5.4.0

Expected behavior

Successful webhook post, or error in log

Observed behavior

Several attempts to post messages via the webhook failed because the destination hostname could not be resolved. Those errors were visible in the log.
After that, there was nothing else in the log immediately prior to the event. Presumably another trigger word was encountered, and then we saw:

Dec 14 03:23:57 <server>[114318]: panic: runtime error: invalid memory address or nil pointer dereference
Dec 14 03:23:57 <server>[114318]: [signal SIGSEGV: segmentation violation code=0x1 addr=0x38 pc=0xeb8acd]
Dec 14 03:23:57 <server>[114318]: goroutine 50655814 [running]:
Dec 14 03:23:57 <server>[114318]:*App).TriggerWebhook.func1.1()
Dec 14 03:23:57 <server>[114318]: /home/ubuntu/jenkins/workspace/msr/mattermost-platform-release/src/ +0xfd
Dec 14 03:23:57 <server>[114318]:*App).Go.func1(0xc00f3e18b0, 0xc000100580)
Dec 14 03:23:57 <server>[114318]: /home/ubuntu/jenkins/workspace/msr/mattermost-platform-release/src/ +0x27
Dec 14 03:23:57 <server>[114318]: created by*App).Go
Dec 14 03:23:57 <server>[114318]: /home/ubuntu/jenkins/workspace/msr/mattermost-platform-release/src/ +0x52

This crash was repeated a further two times.

Hi @gubbins,

Would you be open to sharing more details on your config settings?

Yes, what do you need?

Hi @gubbins,

Thank you - could you share your config.json file as well as your installation environment?

Installation is on CentOS 7.

Sharing the entire config file is not very practical - is there a relevant section or setting?

From the code (webhook.go:108) it looks like maybe http.NewRequest returned null, which is interesting given that we were having difficulty resolving the destination hostname. I hoped it might be reproducible just from that.

I tested an incoming webhook, a slash command and the outgoing webhook in the 5.4 version and I was not able to reproduce the issue.
is it possible you share with me the configuration you did (like if a slash command or other) and the message that you are trying to post


1 Like

@cpanato It was an outgoing webhook, posting JSON to a URL like http://nn.nn.nn.nn:5000/status.

I do not believe the webhook settings themselves are the problem. I believe the problem is that in some circumstances http.NewRequest may return null if the destination URL is not resolvable. in TriggerWebhook:

				req, _ := http.NewRequest("POST", url, body)
				req.Header.Set("Content-Type", contentType)
				req.Header.Set("Accept", "application/json")

Clearly we are not expecting req to ever be nil here, but I believe the stack trace I posted at the top shows that it was indeed nil. in NewRequest it looks like nil is returned if the URL cannot be parsed.

I tried an experiment on our dev server - I set up an outgoing webhook with URL http://arealhostname:5000/whoops#this%&breaks;=no (with a valid hostname) and reproduced the crash.

I think the server should just be checking for the nil response here. Sorry for the lack of a PR - I would submit one if I had more time and was actually a golang developer!

@cpanato Do you know if this seems to be a bug and I should create a Jira ticket?

@amy.blais yes please create a jira ticket

thanks for reporting this, we will check that internally now :slight_smile:

Opened a ticket here: