CVE-2022-43681 (https://forescout.com): An out-of-bounds read exists in the BGP daemon of FRRouting FRR through 8.4. When sending a malformed BGP OPEN message that ends with the option length octet (or the option length word, in case of an extended OPEN message), the FRR code reads of out of the bounds of the packet, throwing a SIGABRT signal and exiting. This results in a bgpd daemon restart, causing a Denial-of-Service condition. CVE-2022-40302 (https://github.com/FRRouting/frr/releases): An issue was discovered in bgpd in FRRouting (FRR) through 8.4. By crafting a BGP OPEN message with an option of type 0xff (Extended Length from RFC 9072), attackers may cause a denial of service (assertion failure and daemon restart, or out-of-bounds read). This is possible because of inconsistent boundary checks that do not account for reading 3 bytes (instead of 2) in this 0xff case. CVE-2022-40318 (https://github.com/FRRouting/frr/releases): An issue was discovered in bgpd in FRRouting (FRR) through 8.4. By crafting a BGP OPEN message with an option of type 0xff (Extended Length from RFC 9072), attackers may cause a denial of service (assertion failure and daemon restart, or out-of-bounds read). This is possible because of inconsistent boundary checks that do not account for reading 3 bytes (instead of 2) in this 0xff case. NOTE: this behavior occurs in bgp_open_option_parse in the bgp_open.c file, a different location (with a different attack vector) relative to CVE-2022-40302. The first CVE's reference is obviously advertising, not clear based on the other references where the fixes are.
None of these versions are in-tree any more, and these are extremely old, no longer relevant I believe.
(In reply to Jaco Kroon from comment #1) > None of these versions are in-tree any more, and these are extremely old, no > longer relevant I believe. Please don't close bugs owned by the security team since the team has a process to follow. The CVE descriptions mention the versions that are vulnerable, but what indication do we have that the issues are fixed in later versions (specifically the first CVE)?
My apologies. CVE-2022-43681 it states specifically "through 8.4" so my opinion is that it should be fixed, but as you say, the process is the process.
Those CVEs has been fixed two years ago https://github.com/FRRouting/frr/commit/1117baca3c592877a4d8a13ed6a1d9bd83977487 https://github.com/FRRouting/frr/commit/3e46b43e3788f0f87bae56a86b54d412b4710286 https://github.com/FRRouting/frr/commit/766eec1b7accffe2c04a5c9ebb14e9f487bb9f78
