-
Bug
-
Resolution: Unresolved
-
Undefined
-
None
-
None
-
False
-
-
False
-
Important
-
Very Likely
-
0
Current Behavior
Many Redhat CSAF files are invalid, as the list a fix to be applied to an already fixed version.
The problem is:
On files with category: `csaf_security_advisory` that give a fixed version:
The remediations.product_ids for "category": "vendor_fix" or "workaround"
must only contain ids for products that are not yet fixed.
In your CSAF files they have the fixed product ids, which is not correct
according to the CSAF standard. Technical details below.
Expected Behavior
All CSAF files should be valid according the standard.
Steps to reproduce
- Download a CSAF file that states a fix.
Example:
Looking at
https://access.redhat.com/hydra/rest/securitydata/csaf/RHSA-2024:0340.json
for example there is
BaseOS-9.3.0.Z.MAIN:kpatch-patch-5_14_0-362_13_1-0:1-1.el9_3.ppc64le
listed in "product_status.fixed", but also in
"remediations.product_ids" for the "vendor_fix" where it should not be.
The standard says
https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html#32312-vulnerabilities-property---remediations
> At least one of the optional elements Group IDs (group_ids) and Product IDs
(product_ids) MUST be present to state for which products or product groups
this remediation is applicable.
> Product IDs (product_ids) [..] contain a list of Products the current
remediation item applies to.
The upcoming draft 2.1 has an explicit test about this:
https://docs.oasis-open.org/csaf/csaf/v2.1/csd01/csaf-v2.1-csd01.html#contradicting-product-status-remediation-combination
see the negative "Example 1".
Impact Statement
Security automation depending on correct CSAF files and using this fix information may missbehave and in the worst case try to apply a fix to a fixed version and not an effected version. Another problem could be that the CSAF information are not acted upon because the file is rejected as invalid.
Attachments & Links
I've tested a sample of advisories from 2025 from Redhat, and the ones having
a remediations section show the same pattern, making them invalid.
Here is the sample and method of testing for extra details:
cat sample
/tmp/redhat/white/2025/rhsa-2025_15348.json
/tmp/redhat/white/2025/rhsa-2025_10672.json
/tmp/redhat/white/2025/rhsa-2025_18695.json
/tmp/redhat/white/2025/rhsa-2025_3397.json
/tmp/redhat/white/2025/rhsa-2025_4063.json
/tmp/redhat/white/2025/rhsa-2025_18703.json
/tmp/redhat/white/2025/rhsa-2025_8532.json
/tmp/redhat/white/2025/rhsa-2025_16008.json
/tmp/redhat/white/2025/rhsa-2025_8600.json
/tmp/redhat/white/2025/rhsa-2025_15662.json
Using https://github.com/secvisogram/csaf-validator-lib/releases/tag/v2.0.12
running the new CSAF 2.1 explicitly:
for f in `cat sample` ; do echo
$f ; ./csaf-validator-lib/scripts/runTest.js -t mandatoryTest_6_1_36 -c
2.1 -f $f ; done >validation-run.txt
8 are invalid, the other two rhsa-2025_18695.json and rhsa-2025_18703.json
have no remediations. Error messages start with
> "message": "contradicting combination of product status fixed
> and remediation category workaround
or "category vendor_fix".
Another "bad" example is
https://security.access.redhat.com/data/csaf/v2/advisories/2024/rhsa-2024_0217.json
Looks like SECDATA-1128 is related (but a bit different, as it is a VEX.)