fix: add buffer-length check in tracereplay.c#219
Open
orbisai0security wants to merge 65 commits into
Open
Conversation
This should prevent infinite looping and error message spam when an nDAG (TCP or UDP) receives some bogus data. It should also make it easier for libtrace code to determine when an nDAG input has hit a fatal error, simply by checking with trace_is_err().
We were not properly handling cases where the configuration string ended in a ']'.
* make sure the singlemsg iovector is properly initialised in situations where recvmmsg is available but TCP is being used (so only one iovector is required). Not doing this was causing a subsequent call to recvmsg to return 0 -- normally this suggests that the other end had reset the connection, but actually the problem was that the io vector had zero space available and thus was only able to read 0 bytes into the buffer provided.
* remove DPDK test builds for any version of DPDK older than 2020. * add Ubuntu 24.04 to standard libtrace tests * add DPDK 24.11 to DPDK tests * fix missing dependency on libsystemd that was causing DPDK tests to fail on 24.04
meson in 20.04 is too old for the build files included in that version of DPDK
* fix bad name for libsystemd0 package * force install of libbz2-dev and lzma-dev for libtrace tests, as these are no longer pulled in by default by some other dependency
Fedora is a pain for us to deal with -- it's always a moving target and the build will randomly break between versions for stupid reasons (e.g. renaming packages we depend on). I don't feel like we have enough fedora users to justify this amount of effort in maintaining it, but if someone else wants to take over that side of things then I'm happy to assist with the handover.
60ms was proving a little too long for certain real-time applications when the packet rate was relatively low -- e.g. RTP streams at 100 pps. This causes the packets to be delivered by libtrace to a reading process in clumps rather than at the rate they appear on the wire. 10ms seems to be a reasonable middle ground between losing the benefits of tpacket v3's batching and not introducing noticeable latency for real time processing.
This bug occurred in the (rare) situation where the main ndag packet send fails due to EAGAIN. In that case, the "canary" data was being incorrectly re-sent as well, even though the client would have already received it. The resulting desynchronization would cause subsequent NDAG messages to be incorrectly offset in the client buffer, causing parsing errors on the client side.
* if we walk all of the encap buffers and fail to get a complete packet then we are probably dealing with a bogus "length" field, so the packet read attempt will now abort instead of looping forever. * when doing a parallel read, if no more packets are available in the buffer but we have managed to successfully read at least one then return what we've read rather than waiting for more data to come in.
This will hopefully finally fix the automated Mac OS test failures.
Also tidy up some other potential memory issues found while fixing the original crash bug report. * Use array indexes to keep track of which ndag_monitor_t belongs to a given streamsock, so that if the array is moved (e.g. due to expanding) then the streamsock won't be stuck with an invalid pointer. * Allocate port map on the heap rather than the stack in the ndag controller thread, which should help avoid stack overflow problems. * Better handling of situations where an ndag input is restarted with an increased number of threads than before. * Consistently use receiver_cnt rather than perpkt_thread_count for calculating nextthreadid -- while these values should be the same, our array is sized according to receiver_cnt so we should use that.
This is a best effort attempt to try and get useful stats out of the DPDK format on a per-thread basis. The difficulty is that there is no consistency between vendors as to the naming of the counters that stored the stats we need. Also: fixed a couple of compile errors that occur if the DEBUG flag is set for DPDK builds.
* fix source counting bug that meant many sources were not actively read at all * fix bug where sources handled by the same receive thread would share the same mmapped receive buffer, rather than having a dedicated buffer for each source. * simple_circular_buffer data struct now properly reports recv() failures in situations where there is unprocessed data in the buffer. * harden packet reading code to avoid reading bogus memory if we do not have enough packet content to safely determine the record length. * don't try to send keepalive responses to sockets that we have closed * fix memory leak in libpacketdump when decoding TRI records
* fix bad trace type in etsifile format definition * fix memory leak when demoting a packet during pcapfile format conversion * fix bad setting of packet->error when reading a packet using etsifile format
* apply demotion logic to pcapng format to try and wrangle packets into a suitable DLT for writing to pcapng
Previously, libtrace was trying to interpret these as raw IP but gretap actually delivers bridged Ethernet frames so the initial header is Ethernet, not IP.
* add ubuntu 26.04 to build test workflow * disable dag test workflow * bump libtool version revision for libpacketdump
Automated security fix generated by OrbisAI Security
In tracereplay
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fix critical severity security issue in
tools/tracereplay/tracereplay.c.Vulnerability
V-002tools/tracereplay/tracereplay.c:127Description: In tracereplay.c at lines 127-128, packet data is copied into a newly allocated buffer. The 'remaining' value is derived from the input packet's metadata. If 'remaining' exceeds the allocated size of newbuf minus sizeof(libtrace_ether_t), a heap buffer overflow occurs. Since tracereplay processes untrusted pcap files, an attacker can craft a file with manipulated packet lengths to achieve code execution.
Evidence
Exploitation scenario: An attacker crafts a malicious pcap trace file where a packet's capture length or wire length fields are manipulated to produce a large 'remaining' value.
Scanner confirmation: multi_agent_ai rule
V-002flagged this pattern.Production code: This file is in the production codebase, not test-only code.
Changes
tools/tracereplay/tracereplay.cVerification
Security Invariant
Regression test
This test guards against regressions — it's useful independent of the code change above.
Automated security fix by OrbisAI Security