Last Modified: Dec 18, 2024
Affected Product(s):
BIG-IP TMOS
Known Affected Versions:
14.1.0, 14.1.0.1, 14.1.0.2, 14.1.0.3, 14.1.0.5, 14.1.0.6, 14.1.2, 14.1.2.1, 14.1.2.2, 14.1.2.3, 14.1.2.4, 14.1.2.5, 14.1.2.6, 14.1.2.7, 14.1.2.8, 14.1.3, 14.1.3.1, 14.1.4, 14.1.4.1, 14.1.4.2, 14.1.4.3, 14.1.4.4, 14.1.4.5, 14.1.4.6, 14.1.5, 14.1.5.1, 14.1.5.2, 14.1.5.3, 14.1.5.4, 14.1.5.6, 15.1.0, 15.1.0.1, 15.1.0.2, 15.1.0.3, 15.1.0.4, 15.1.0.5, 15.1.1, 15.1.2, 15.1.2.1, 15.1.3, 15.1.3.1, 15.1.4, 15.1.4.1, 15.1.5, 15.1.5.1, 15.1.6, 15.1.6.1, 15.1.7, 15.1.8, 15.1.8.1, 15.1.8.2, 15.1.9, 15.1.9.1, 15.1.10, 15.1.10.2, 15.1.10.3, 15.1.10.4, 15.1.10.5, 15.1.10.6, 16.0.0, 16.0.0.1, 16.0.1, 16.0.1.1, 16.0.1.2
Opened: Jun 17, 2021 Severity: 3-Major
When a dynamic or static route is instantiated for application traffic processing, protection exists at configuration-validation time to ensure that the new route does not overwrite how the management port's subnet is accessed. To do so, the destination of the new route is compared to the management port's subnet. If the two match, the new route is only instantiated in TMM, but not in the Linux host's routing table. The issue is this logic fails when the new route is a subset of the management port's subnet. For example, if the new route is to destination 10.215.50.0/25, and the management port's subnet is 10.215.50.0/24, the new route will be added to both TMM and the Linux host, bypassing the aforementioned protection. Instead, the logic should check for overlapping subnets, not just strict equality.
A new and more specific route for part of the management port's subnet is added to the Linux host's routing table. Part of the management port traffic can fail or be misrouted via a TMM interface. If multiple routes of this kind are instantiated (e.g. 10.215.50.0/25 + 10.215.50.128/25), the whole management port's subnet can be overtaken.
- A dynamic or static route whose destination partially overlaps with the management port's subnet is added to or learnt by the system.
Redesign your network and then reconfigure the BIG-IP system so that TMM does not need access to the management port's subnet or part of it (thus negating the need to create a route to that destination in the first place). If this is not possible, you can temporarily resolve the issue by using the `route` or `ip` utility on the Linux host subsystem to manually fix the routing table. However, the issue will occur again the next time the problematic route is loaded or learnt by the system.
None