-
-
Notifications
You must be signed in to change notification settings - Fork 358
Malformed PDU Length leads to Segmentantion fault #705
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Hello Making this modification in the core utils library would not be a good practise. And may lead to some side effects as the relevant OctetView class might be used in many different places. We should determine the specific location and fix the issue there. Thanks |
Hello @aligungr and sorry for the late reply. I made a change on my PR. Instead of checking the length based on a constant, arbitrary number, it checks if index + length is larger than the size of the data that is held in the OctetView object, which could prevent any other issues arising in the future since it does the length check more dynamically. I tested UERANSIM with this modification and the program behaves as expected with no other issues. However, if you do not want to make any changes in the OctectView class, we could still tackle this issue from the DecodeRlsMessage function which is located on src/lib/rls/rls_pdu.cpp UERANSIM/src/lib/rls/rls_pdu.cpp Lines 55 to 105 in 85a0fbf
The problem is on line 91, which, in case the message type is PDU Transmission, it calls the readOctetString function, with stream.read4I() being the length of the PDU Message. We could do the if statement check there, but that could cause other issues, for example, in case a legitimate user wants to send a packet that is larger than the arbitrary number we may put. I suggest we do the length check in the readOctetString function, since it has access to both the length and the actual size of the data. If you have any other concerns with this change, let me know. |
@f4rs1ght Thanks for this modification. The second approach seems solid. And also we can add an index and range checking to readOctetString function for other potential bugs. Returning an empty OctetString might hide an underlying issue. Therefore we should throw an exception instead. Please replace (With #include stdexcept) Going back to original issue, yes, we should add a length check for line 91, as you suggested. If the length is greater than the remaining size (or greater than maximum RLS packet size, let's say 2^14=16384), we should drop and ignore that packet. |
Hello @aligungr, I made the necessary changes, feel free to test it yourself or make any other changes. |
Thanks @f4rs1ght |
Affected versions
3.2.6 >=
Steps to reproduce
i) Build and setup UERANSIM v3.2.6 gNodeB following the installation guide from the wiki (https://github.com/aligungr/UERANSIM/wiki/Installation).
ii) Adjust the appropriate values and run the following python script
Core flaw
UERANSIM/src/utils/octet_view.cpp
Lines 20 to 28 in 85a0fbf
The flaw arises in
src/utils/octet_view.cpp
on line 25, where a vector is initialized. The end of the range for this initialization is influenced by the variable length, which is determined by the user sending the packet. Consequently, setting length to a very large value, specifically 20871 or higher, can lead to exceeding the maximum size of the vector or attempting to access data beyond its bounds.Fix
A possible fix is to control the value of the variable length, by limiting its size to a maximum number of 20870.