Fixed out-of-bounds read in module protocol when a '%' line has no '='#6178
Open
aizu-m wants to merge 2 commits into
Open
Fixed out-of-bounds read in module protocol when a '%' line has no '='#6178aizu-m wants to merge 2 commits into
aizu-m wants to merge 2 commits into
Conversation
AddressSanitizer, parsing a "%" module-protocol line with no "=":
ERROR: AddressSanitizer: SEGV on a READ
#0 strlen
cfengine#1 BufferNewFrom buffer.c:68
cfengine#2 ModuleProtocol evalfunction.c:10252
Came across this whilst reading the module protocol parser. The "%" case
builds the JSON payload with
BufferNewFrom(line + strlen(name) + 1 + 1,
length - strlen(name) - 1 - 1);
which assumes a well-formed "%name=<json>" line. But sscanf("%256[^=]=",
name) also returns with name set when the line carries no "=": it leaves
the whole tail in name. So strlen(name) == length - 1, the length argument
underflows to SIZE_MAX, and the data pointer steps one past the terminating
NUL. BufferAppend() then scans from there and walks off the heap line
buffer.
read_module_protocol() hands arbitrary file lines straight to
ModuleProtocol(), so a single line "%x" is enough to reproduce it.
The other directives ("=", "@", ...) already guard their input; the "%"
case did not. Only do the arithmetic once the "=" delimiter is present.
Changelog: Title
Signed-off-by: aizu-m <aizumusheer2@gmail.com>
|
Thanks for submitting a PR! Maybe @larsewi can review this? |
larsewi
requested review from
SimonThalvorsen,
craigcomstock,
larsewi and
victormlg
larsewi
requested changes
Jun 19, 2026
Comment on lines
-10249
to
+10252
| if (CheckID(name)) | ||
| /* A well-formed line is "%name=<json>". Without the '=' delimiter | ||
| * sscanf() leaves the whole tail in name, so strlen(name) == length-1 | ||
| * and the "length - strlen(name) - 1 - 1" below underflows. */ | ||
| if (CheckID(name) && line[strlen(name) + 1] == '=') |
Contributor
There was a problem hiding this comment.
Your test passes without this change
Contributor
Author
There was a problem hiding this comment.
Good catch, you are right. The OOB read only trips under ASan. In a plain build the scan past the line just reads adjacent heap, JsonParse() rejects the garbage, and the variable ends up undefined either way, so the behavioural check could not tell the patched and unpatched paths apart.
Reworked the test to be deterministic instead of leaning on ASan. The "%bad" line now sits with its terminating NUL on the last readable byte before a PROT_NONE guard page, so the underflowed scan walks straight into it. Confirmed both ways locally:
without the fix: Bus error -> test_module_protocol_percent_no_delimiter: Test failed -> 1 out of 4 tests failed
with the fix: All 4 tests passed
Pushed in 5f94cc1.
The behavioural test only tripped under ASan: in a plain build the scan past the line buffer reads adjacent heap, JsonParse() rejects the garbage, and the variable is left undefined either way, so it passed without the fix. Place the malformed '%bad' line so its terminating NUL is the last readable byte before a PROT_NONE guard page. The unpatched arithmetic steps one past the NUL and BufferAppend() scans into the guard page, so the test now crashes (caught as a failure) without the fix and passes with it. Changelog: none Signed-off-by: aizu-m <aizumusheer2@gmail.com>
Contributor
|
@cf-bottom Jenkins please :) |
|
Alright, I triggered a build: Jenkins: https://ci.cfengine.com/job/pr-pipeline/13979/ Packages: http://buildcache.cfengine.com/packages/testing-pr/jenkins-pr-pipeline-13979/ |
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
3 participants
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.
AddressSanitizer, parsing a "%" module-protocol line with no "=":
Came across this whilst reading the module protocol parser. The "%" case
builds the JSON payload with
which assumes a well-formed "%name=" line. But sscanf("%256[^=]=",
name) also returns with name set when the line carries no "=": it leaves
the whole tail in name. So strlen(name) == length - 1, the length argument
underflows to SIZE_MAX, and the data pointer steps one past the terminating
NUL. BufferAppend() then scans from there and walks off the heap line
buffer.
read_module_protocol() hands arbitrary file lines straight to
ModuleProtocol(), so a single line "%x" is enough to reproduce it.
The other directives ("=", "@", ...) already guard their input; the "%"
case did not. Only do the arithmetic once the "=" delimiter is present.