Thanks Emi. I went ahead and merged this branch, after trying to ensure that the changes to active_edit were safe (but hit LP: #2058614 in the existing code).
One issue I hit with the non-interactive mode is, in testing in particular the some recenet kernel CVEs, the descriptions include code related things, including C pointers, which the interpreter tried to parse as a command and failed. To reproduce:
$ ./scripts/detect_priorities_mismatches.py --packages linux --published-since 2024-02-01
[... text elided ...]
=========== 12/18: CVE-2024-26589 ===========
In the Linux kernel, the following vulnerability has been resolved: bpf:
Reject variable offset alu on PTR_TO_FLOW_KEYS For PTR_TO_FLOW_KEYS,
check_flow_keys_access() only uses fixed off for validation. However,
variable offset ptr alu is not prohibited for this ptr kind. So the
variable offset is not checked. The following prog is accepted: func#0 @0
0: R1=ctx() R10=fp0 0: (bf) r6 = r1 ; R1=ctx() R6_w=ctx() 1: (79) r7 =
*(u64 *)(r6 +144) ; R6_w=ctx() R7_w=flow_keys() 2: (b7) r8 = 1024 ;
[... rest elided ...]
which results in:
============================ Summary =============================
18 CVEs needing priority reason
0 CVEs processed:
- 0 skipped CVE(s)
- 0 CVE(s) automatically updated with their corresponding reasons
- 0 CVE(s) opened in editor for manual edit
- 1 issue(s)
- #425: Invalid CVE ID format: *(u64 *)(r6 +144) ; R6_w=ctx() R7_w=flow_keys() 2: (b7) r8 = 1024 ;
So likely we need to indent the description and any other fields that might have lines that start with '*'.
(I think this is why the experimental triage interface prefixes all the information as comments / '#'; then the processor can ignore any such lines, rather than worrying about individual fields of info colliding with actions.)
Thanks Emi. I went ahead and merged this branch, after trying to ensure that the changes to active_edit were safe (but hit LP: #2058614 in the existing code).
One issue I hit with the non-interactive mode is, in testing in particular the some recenet kernel CVEs, the descriptions include code related things, including C pointers, which the interpreter tried to parse as a command and failed. To reproduce:
$ ./scripts/ detect_ priorities_ mismatches. py --packages linux --published-since 2024-02-01 keys_access( ) only uses fixed off for validation. However,
[... text elided ...]
=========== 12/18: CVE-2024-26589 ===========
In the Linux kernel, the following vulnerability has been resolved: bpf:
Reject variable offset alu on PTR_TO_FLOW_KEYS For PTR_TO_FLOW_KEYS,
check_flow_
variable offset ptr alu is not prohibited for this ptr kind. So the
variable offset is not checked. The following prog is accepted: func#0 @0
0: R1=ctx() R10=fp0 0: (bf) r6 = r1 ; R1=ctx() R6_w=ctx() 1: (79) r7 =
*(u64 *)(r6 +144) ; R6_w=ctx() R7_w=flow_keys() 2: (b7) r8 = 1024 ;
[... rest elided ...]
which results in:
======= ======= ======= ======= Summary ======= ======= ======= ======= =
18 CVEs needing priority reason
0 CVEs processed:
- 0 skipped CVE(s)
- 0 CVE(s) automatically updated with their corresponding reasons
- 0 CVE(s) opened in editor for manual edit
- 1 issue(s)
- #425: Invalid CVE ID format: *(u64 *)(r6 +144) ; R6_w=ctx() R7_w=flow_keys() 2: (b7) r8 = 1024 ;
So likely we need to indent the description and any other fields that might have lines that start with '*'.
(I think this is why the experimental triage interface prefixes all the information as comments / '#'; then the processor can ignore any such lines, rather than worrying about individual fields of info colliding with actions.)