Skip to content

Conversation

@victorjulien
Copy link
Member

When in a `base64_decode`-`base64_data` pair the decode was depending
on another match through the relative option, the `buffer_offset` would
be updated to the relative position of the previous match. During the
`base64_data` phase, a relative match would use that offset even though
the match happened in a new buffer.

Example::

        http.request_body; content:"|27|";                              \
                base64_decode:relative;                                 \
                base64_data; content:"|ff ff ff ff|"; within:16;

This use of the `buffer_offset` is incorrect as that value is relative
to a buffer and the `base64_data` points to a new buffer.

This patch addresses this by resetting DetectEngineThreadCtx::buffer_offset
before inspecting `base64_data`.

Bug: OISF#7842.
(cherry picked from commit 5f92a6c)
@suricata-qa
Copy link

WARNING:

field baseline test %
SURI_TLPR1_stats_chk
.uptime 650 625 96.15%

Pipeline = 29237

@OISF OISF deleted a comment from suricata-qa Jan 22, 2026
@OISF OISF deleted a comment from suricata-qa Jan 22, 2026
@victorjulien victorjulien merged commit 96f7549 into OISF:main-7.0.x Jan 22, 2026
136 of 137 checks passed
@victorjulien victorjulien mentioned this pull request Jan 22, 2026
@victorjulien victorjulien deleted the next/1186/70x/20260120/v1 branch January 22, 2026 08:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants