Argh, sorry, somehow bugzie ate my initial text. The listed GLSAs match against a version of vserver-sources that never existed according to the sys-kernel/vserver-sources/ChangeLog. The version numbering of vserver-sources is NOT coherent with the rest of our kernel version numbering, as it instead reflects upstream vserver numbering. # grep 2.4 /usr/portage/sys-kernel/vserver-sources/ChangeLog (nothing) # glsa-check -d 200407-02 |grep vserver-sources -A4 Affected package: sys-kernel/vserver-sources Affected archs: All Vulnerable: <2.4.26.1.3.9-r2 Unaffected: >=2.4.26.1.3.9-r2 (trimming the next bit for length) # glsa-check -t --verbose 200407-02 This system is affected by the following GLSAs: [A] means this GLSA was marked as applied (injected), [U] means the system is not affected and [N] indicates that the system might be affected. 200407-02 [N] [local ] Linux Kernel: Multiple vulnerabilities ( ... sys-kernel/vserver-sources-2.3.0.36.14 ... )
There actually were ebuilds in the 2.4.* range in CVS, just not in the changelog. I've changed the version ranges to basically make <2.0, >= 2.4 and <2.4.26.1.3.9-r2 vulnerable. That excludes the current 2.3 series. However once upstream hits 2.4 again, we need to revisit this. I have no idea though on how to canonically fixing this if the versions repeat themselves. I guess we need to put explicit versions into the advisory and then put specific revisions onto the ebuilds.
