[asterisk-bugs] [JIRA] (ASTERISK-30156) sip_rtp_read: crash for video rtp session variable (vrtp) not inizialized

Joshua C. Colp (JIRA) noreply at issues.asterisk.org
Tue Jul 26 05:09:09 CDT 2022


    [ https://issues.asterisk.org/jira/browse/ASTERISK-30156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=259796#comment-259796 ] 

Joshua C. Colp commented on ASTERISK-30156:
-------------------------------------------

The chan_sip module is community supported, so you are free to put such a change up for review after signing the license agreement. Note that such a change will not go into any current certified version. If you are a support customer, then you should go through Sangoma Support.

That doesn't answer this question though: why does chan_sip think it has to read video, when there is no video.

> sip_rtp_read: crash for video rtp session variable (vrtp) not inizialized
> -------------------------------------------------------------------------
>
>                 Key: ASTERISK-30156
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-30156
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/SRTP
>    Affects Versions: 16.8.0
>         Environment: Centos 7.8 64 bit
>            Reporter: Diego Busacca
>            Severity: Major
>
> Hello,
> in a new installation we're experiencing some random crash. Analyzing the core dump with gdb we traced back the issue to a null pointer exception in sip_rtp_read of chan_sip
> We're using asterisk 16.8-cert5 but the affected function is the same in main.
> Using {{gdb}} and {{bt}} we got:
> {noformat}
> #0  ast_rtp_instance_read (instance=0x0, rtcp=rtcp at entry=1) at rtp_engine.c:583
> #1  0x00007f06fca3f421 in sip_rtp_read (faxdetect=<synthetic pointer>, p=0x7f05943f8b50, ast=0x7f0568a88e90) at chan_sip.c:8625
> #2  sip_read (ast=0x7f0568a88e90) at chan_sip.c:8722
> #3  0x00000000004b1852 in __ast_read (chan=0x7f0568a88e90, dropaudio=dropaudio at entry=0, dropnondefault=dropnondefault at entry=1) at channel.c:3757
> #4  0x00000000004b258c in ast_read (chan=<optimized out>) at channel.c:4285
> #5  0x00007f06f7b00c8b in run_agi (argv=0x7f05268e3978, argc=<optimized out>, dead=0, status=0x7f05268e3830, pid=<optimized out>, agi=0x7f05268e38a0, request=<optimized out>, chan=0x7f0568a88e90) at res_agi.c:4180
> #6  agi_exec_full (chan=<optimized out>, data=<optimized out>, enhanced=<optimized out>, dead=<optimized out>) at res_agi.c:4530
> #7  0x0000000000535b29 in pbx_exec (c=c at entry=0x7f0568a88e90, app=app at entry=0x35e4fb0, data=data at entry=0x7f05268e5b30 "agi://127.0.0.1:9130/cc_service.agi?TELENIA=2_0_3_2_HOLIDAYBASIC_0_0_0") at pbx_app.c:492
> #8  0x0000000000529190 in pbx_extension_helper (c=c at entry=0x7f0568a88e90, context=0x7f0568a89850 "telenia_services_op", exten=exten at entry=0x7f0568a898a0 "2_0_3_2_HOLIDAYBASIC_0_0_0", priority=priority at entry=1,
>     label=label at entry=0x0, callerid=callerid at entry=0x7f058c0431c0 "3059", action=action at entry=E_SPAWN, found=found at entry=0x7f05268e7bc0, combined_find_spawn=combined_find_spawn at entry=1, con=0x0) at pbx.c:2947
> #9  0x000000000052b28a in ast_spawn_extension (combined_find_spawn=1, found=0x7f05268e7bc0, callerid=0x7f058c0431c0 "3059", priority=1, exten=0x7f0568a898a0 "2_0_3_2_HOLIDAYBASIC_0_0_0", context=<optimized out>,
>     c=0x7f0568a88e90) at pbx.c:4197
> #10 __ast_pbx_run (c=c at entry=0x7f0568a88e90, args=args at entry=0x0) at pbx.c:4371
> #11 0x000000000052c7cb in pbx_thread (data=data at entry=0x7f0568a88e90) at pbx.c:4695
> #12 0x00000000005acecd in dummy_start (data=<optimized out>) at utils.c:1249
> #13 0x00007f0763ac4ea5 in start_thread (arg=0x7f05268e8700) at pthread_create.c:307
> #14 0x00007f0762e658dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
> {noformat}
> Analizing the {{frame 1}} we got:
> {noformat}
> 8625                    f = ast_rtp_instance_read(p->vrtp, 1);  /* RTCP Control Channel for video */
> {noformat}
> In sip_rtp_read there is a NULL guard for p->rtp but not for p->vrtp.
> {noformat}
> /*! \brief Read RTP from network */
> static struct ast_frame *sip_rtp_read(struct ast_channel *ast, struct sip_pvt *p, int *faxdetect)
> {
> 	/* Retrieve audio/etc from channel.  Assumes p->lock is already held. */
> 	struct ast_frame *f;
> 	if (!p->rtp) {
> 		/* We have no RTP allocated for this channel */
> 		return &ast_null_frame;
> 	}
> 	switch(ast_channel_fdno(ast)) {
> 	case 0:
> 		f = ast_rtp_instance_read(p->rtp, 0);	/* RTP Audio */
> 		break;
> 	case 1:
> 		f = ast_rtp_instance_read(p->rtp, 1);	/* RTCP Control Channel */
> 		break;
> 	case 2:
> 		f = ast_rtp_instance_read(p->vrtp, 0);	/* RTP Video */
> 		break;
> 	case 3:
> 		f = ast_rtp_instance_read(p->vrtp, 1);	/* RTCP Control Channel for video */
> 		break;
> {noformat}
> We're thinking to add a NULL safety guard in the vrtp swicth casese:
> {noformat}
> 	case 2:
>                 if (!p->vrtp) {
> 		     /* We have no VRTP allocated for this channel */
>                      return &ast_null_frame;
> 	        }
> 		f = ast_rtp_instance_read(p->vrtp, 0);	/* RTP Video */
> 		break;
> 	case 3:
>                 if (!p->vrtp) {
> 		     /* We have no VRTP allocated for this channel */
>                      return &ast_null_frame;
> 	        }
> 		f = ast_rtp_instance_read(p->vrtp, 1);	/* RTCP Control Channel for video */
>                 break;
> {noformat}
> There can be unexpected behaviors?



--
This message was sent by Atlassian JIRA
(v6.2#6252)



More information about the asterisk-bugs mailing list