A few inlineQoS parameters lead to segmentation fault during SPDP about opendds HOT 7 CLOSED

Please add test cases.

Does the same stack trace apply to all scenarios?

from opendds.

In the PID_PROPERTY_LIST example, does the packet end after offset 0x4f or is there more that's not shown here?

from opendds.

Please check if the patch in #4010 fixes this

from opendds.

I appreciate your quick response and fix!

Does the same stack trace apply to all scenarios?

Their entries differ (due to different parameter ids) but from handle_input the traces overlap.

In the PID_PROPERTY_LIST example is there more that's not shown here?

My bad. I copy-pasted a wrong dump. It should have been the following:

00000000: 1503 3c00 0000 1400 0000 0000 0000 0000  ..<.............
00000010: 0000 0000 0000 0000 2f34 2000 0000 0000  ......../4 .....
00000020: 4400 0000 0000 0000 5600 0000 6100 0000  D.......V...a...
00000030: 0000 0000 0000 0000 3500 0400 0100 0000  ........5.......

Please check if the patch in #4010 fixes this

Yes, the added null check does preclude this issue. Thank you.

Could you request a CVE ID for this issue through Github?

from opendds.

I'm still unclear on this since the the new hexdump doesn't seem to match up with the first 32 submessage bytes of the PID_PROPERTY_LIST example.

If you confirm that the linked PR fixes all cases you're testing, we'll close this issue.

from opendds.

Ah, after a closer look, the culprit turned out to be PID_CONTENT_FILTER_PROPERTY, not PID_PROPERTY_LIST. It happens during parsing \x35\x00\x04\x00 (bytes 0x38-0x3b) of the submessage.

Backtrace:

#0  0x00007ffff53a261c in ACE_Message_Block::total_length (this=<optimized out>) at Message_Block.inl:419
#1  0x00007ffff6bd73e0 in OpenDDS::DCPS::Serializer::read_string (this=0x7ffff02fbe20, dest=@0x7ffff02fb600: 0x0, str_alloc=<optimized out>, str_free=0x0) at DCPS/Serializer.cpp:557
#2  OpenDDS::DCPS::operator>> (s=..., x=...) at DCPS/Serializer.inl:1395
#3  0x00007ffff68c8a83 in OpenDDS::DCPS::operator>> (strm=..., stru=...) at DdsDcpsInfoUtilsTypeSupportImpl.cpp:5215
#4  0x00007ffff787187c in OpenDDS::DCPS::operator>> (strm=..., uni=...) at RtpsCoreTypeSupportImpl.cpp:12590
#5  0x00007ffff786fa9c in OpenDDS::DCPS::operator>> (strm=..., seq=...) at RtpsCoreTypeSupportImpl.cpp:9756
#6  0x00007ffff78d0b7e in OpenDDS::DCPS::operator>> (strm=..., stru=...) at RtpsCoreTypeSupportImpl.cpp:19523
#7  0x00007ffff7b72441 in OpenDDS::RTPS::Spdp::SpdpTransport::handle_input (this=<optimized out>, h=<optimized out>) at Spdp.cpp:3130

RtpsCoreTypeSupportImpl.cpp:12588-12590

12588   case 53u: {
12589      ::OpenDDS::DCPS::ContentFilterProperty_t tmp;
12590     if (strm >> tmp) { // <- here

from opendds.

I've rerun all my test cases against the patched version and confirmed that the bug is gone.
And before closing, it would be nice if you could request a CVE ID for this. Thank you.

from opendds.