bryancall opened a new pull request, #13689: URL: https://github.com/apache/trafficserver/pull/13689
These are the Coverity test-code findings that turned out to be real defects rather than analyzer artifacts. Part of #13682. Unlike the other test-code PRs in this series, there is no single shared idea here — each commit is its own argument, which is why they are separated out. ### Memory safety | CID | Defect | |---|---| | 1497313 | `SDK_API_TSUrlParse` destroys the MBuffer inside the `TSUrlCreate` error branch, then falls through to shared cleanup that releases an MLoc against it and destroys it a second time — using a stale `url_loc` from the previous loop iteration. Open since 2022-09-01. | | 1497445 | `SDK_API_TSMimeHdrParse` destroys `bufp1` when `TSMimeHdrCreate` fails and then keeps using it for the remaining thirteen test cases, ending in a second `TSMBufferDestroy`. The header location is never assigned on that path either. | | 1644274 | `test_RemapPlugin.cc` held a `PluginDebugObject *` that points into a `dlopen`'d image, declared one scope *outside* the `unique_ptr` whose destructor `dlclose`s it. Harmless today only because Catch2 re-enters the body per section and reassigns it; the fix makes the ordering structural. | | 1544438 | `nexthop_test_stubs.cc build_request()` copied a client address with `sizeof(struct sockaddr)` out of an object that is a `struct sockaddr_in`. Now both sides of the copy are the same type. | | 1660031 | `test_LogAccess.cc` copied the client address as `&x.sa`, handing `ats_ip_copy` an undersized pointee type. Switched to the `IpEndpoint` overload that production code uses everywhere (`HttpSM.cc`, `HttpTransact.cc`, `PluginVC.cc`); behaviour-identical. | ### Unbounded lengths and buffers | CID | Defect | |---|---| | 1660644 | `test_Huffmancode.cc decoder_roundtrip_fuzz` passed `huffman_encode`'s `int64_t` return straight into `huffman_decode`'s `uint32_t src_len`. An error return would have been read as a ~4 GB source length, and the existing `REQUIRE` never bounded it *above* the encode buffer at all. This commit adds a real new assertion. | | 1523657 | `test_HPACK.cc prepare()` built paths with an unbounded `strcat` into a `PATH_MAX + 1` buffer, plus an unchecked index write. Safe only because of a 511-byte cap enforced in `ink_args.cc` — an invariant expressed nowhere locally, and the adjacent line already used the bounded `ink_strlcat`. Fixed at the root: no fixed buffer. | | 1644201 | `test_HpackIndexingTable.cc`: verify the value suffix fits before `memcpy` into the block buffer. | | 1644260 | Same file: the decoder's `buf_end` was derived from an unchecked signed length. | | 1644235 | `test_Http2Frame.cc`: bound the PUSH_PROMISE frame length against the readback buffer before reading it back. | | 1660641 | `test_Huffmancode.cc`: assert the decode produced a byte before reading the output buffer. | ### Error handling | CID | Defect | |---|---| | 1523644 | `test_HPACK.cc prepare()` classified directory entries from a `struct stat` it never checked `stat()` had filled in. | | 1591523 | `test_AIO.cc dump_summary()` divides operation counts by measured seconds without checking them, reporting `inf` and `nan` rates when a run records no elapsed time. | | 1022107 | `SDK_API_TSMimeHdrParse` passed a possibly-null MLoc to `compare_field_names`, aborting inside `TSMimeHdrFieldNameGet`'s `sdk_assert`; it now reports `TC_FAIL` instead. The pass/fail outcome is unchanged. | | 1664287 | `test_OCSPStapling.cc` released a cert from its `unique_ptr` before knowing `SSL_CTX_add_extra_chain_cert()` had adopted it, leaking on the allocation-failure path. | ### Verification `test_records`, `test_tsutil`, `test_proxy_hdrs`, `test_proxy_hdrs_xpack`, `test_cache`, `test_hostdb`, `test_tscore`, `test_tsconfig` — 321 tests, all passing. Every touched file compiles independently on this branch. No test assertion was changed, weakened or removed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
