daxbot / node-rtp Goto Github PK

Context

Node version: 16.13.1
node-rtp version: 0.4.1

Description

If the a user attempts to parse too many SDES packets of a certain type, this will induce a segmentation fault. However, it is only SDES packets containing certain kinds of sources. Here is a script which reliably detects the segmentation fault:

const SegfaultHandler = require('segfault-handler');
SegfaultHandler.registerHandler('crash.log');
const { SdesPacket, parse } = require('@daxbot/rtp');

let pkt1 = new SdesPacket();
pkt1.addSource({
    ssrc:2823272256,
    cname:"786b5a7e-6d6e-4e69-b3d4-72fe13a9d329",
    name:"Test"
})

let i=0;
while ( ++i ) {
    console.log(i);
    parse(pkt1.serialize());
}

Which evaluates to something like:

1
2
...
71
72
73
74
PID 227635 received SIGSEGV for address: 0x4
/path/.../to/nyota-client-node/node_modules/segfault-handler/build/Release/segfault-handler.node(+0x3351)[0x7f2ce22ba351]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x14420)[0x7f2ce1f36420]
/path/.../to/nyota-client-node/node_modules/@daxbot/rtp/build/Release/librtp.so(+0x25e0)[0x7f2ce22af5e0]
/path/.../to/nyota-client-node/node_modules/@daxbot/rtp/build/Release/node_rtp.node(_ZN10SdesPacketC2ERKN4Napi12CallbackInfoE+0x1ff)[0x7f2ce0501b7f]
/path/.../to/nyota-client-node/node_modules/@daxbot/rtp/build/Release/node_rtp.node(_ZN4Napi10ObjectWrapI10SdesPacketE26ConstructorCallbackWrapperEP10napi_env__P20napi_callback_info__+0x117)[0x7f2ce0507dd7]
node[0xaabfcd]
node[0xd4b20e]
node(_ZN2v88internal21Builtin_HandleApiCallEiPmPNS0_7IsolateE+0x107)[0xd4b7d7]
node[0x15e78f9]
Segmentation fault (core dumped)

Note, if rather than serializing the packet every time, you just serialize the packet once and then keep re-parsing the same buffer, the crash doesn't happen.

A Theory

After some more extensive testing, it seems like the necessary conditions for causing the segfault are:

1. The SDES source contains all three fields: ssrc, cname, and name
2. The number of bytes used by the cname and name values is divisible by 4.

For example, the follow cause crashes:

pkt1.addSource({
    ssrc:0,
    cname: "",
    name:  ""
})
pkt1.addSource({
    ssrc:0,
    cname: "1234",
    name:  ""
})
pkt1.addSource({
    ssrc:0,
    cname: "123",
    name:  "4"
})
pkt1.addSource({
    ssrc:0,
    cname: "12341234",
    name:  "1234"
})

But these do not:

pkt1.addSource({
    ssrc:0,
    cname: "123",
    name:  ""
})
pkt1.addSource({
    ssrc:0,
    cname: "1234"
})

My theory is that the SDES parsing might have a bug with handling the padding (similar to the 0.4.0 -> 0.4.1 issue with extra padding), so that if the packet is already an even division of octets, parser is try to read 4 bytes to far. In this case, it might be a librtp issue, not actually a node-rtp issue