I found a reproducible out-of-bounds read in XBPS's bundled portableproplib XML plist parser. In lib/portableproplib/prop_object.c, MATCH(str) calls memcmp(&xml[1], str, sizeof(str) - 1) before confirming that the input contains that many bytes. A one-byte input consisting only of < reaches this comparison.
Affected code tested: XBPS 0.60.7 and a frozen master revision at c5f41d5. With AddressSanitizer-enabled dictionary internalization builds, the one-byte input reports a five-byte heap-buffer-overflow read in _prop_object_internalize_context_alloc() at prop_object.c:722. I reproduced it again on both revisions on 23 September 2026; earlier testing also reached the same parser defect through the array internalization API. The test adapter allocates input_size + 1 bytes, copies the input, and appends a NUL terminator before invoking the upstream API. The invalid read therefore occurs despite the terminator.
Minimal input (hex): 3c (ASCII <). The relevant sanitizer trace begins:
ERROR: AddressSanitizer: heap-buffer-overflow
READ of size 5
#2 _prop_object_internalize_context_alloc .../lib/portableproplib/prop_object.c:722
#3 _prop_generic_internalize .../lib/portableproplib/prop_object.c:639
XBPS also passes repository index and metadata plist buffers to xbps_dictionary_internalize() in lib/repo.c, and archive dictionaries through lib/archive.c. This establishes product paths to the parser. I have not established a specific remote attacker model, native process termination, or information disclosure; the observed failure is the sanitizer-detected read while rejecting malformed input.
Please check the remaining input length before each fixed-length comparison and assess the affected release range. I can provide the full sanitizer log and adapter source if helpful.
I submitted a CVE ID request to MITRE CNA-LR under tracking number CAN-2026-2052927. This is a request tracking number, not an assigned CVE ID. Please coordinate on this existing request rather than filing a duplicate for the same root cause. For public credit, please identify He Huang as the finder and NexusSan as the discovery tool.
I found a reproducible out-of-bounds read in XBPS's bundled portableproplib XML plist parser. In
lib/portableproplib/prop_object.c,MATCH(str)callsmemcmp(&xml[1], str, sizeof(str) - 1)before confirming that the input contains that many bytes. A one-byte input consisting only of<reaches this comparison.Affected code tested: XBPS 0.60.7 and a frozen master revision at
c5f41d5. With AddressSanitizer-enabled dictionary internalization builds, the one-byte input reports a five-byte heap-buffer-overflow read in_prop_object_internalize_context_alloc()atprop_object.c:722. I reproduced it again on both revisions on 23 September 2026; earlier testing also reached the same parser defect through the array internalization API. The test adapter allocatesinput_size + 1bytes, copies the input, and appends a NUL terminator before invoking the upstream API. The invalid read therefore occurs despite the terminator.Minimal input (hex):
3c(ASCII<). The relevant sanitizer trace begins:XBPS also passes repository index and metadata plist buffers to
xbps_dictionary_internalize()inlib/repo.c, and archive dictionaries throughlib/archive.c. This establishes product paths to the parser. I have not established a specific remote attacker model, native process termination, or information disclosure; the observed failure is the sanitizer-detected read while rejecting malformed input.Please check the remaining input length before each fixed-length comparison and assess the affected release range. I can provide the full sanitizer log and adapter source if helpful.
I submitted a CVE ID request to MITRE CNA-LR under tracking number
CAN-2026-2052927. This is a request tracking number, not an assigned CVE ID. Please coordinate on this existing request rather than filing a duplicate for the same root cause. For public credit, please identify He Huang as the finder and NexusSan as the discovery tool.