zebra: Fix for heap-use-after-free in EVPN #13062
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Issue: When a netns is deleted, since zebra doesn’t receive interface down/delete notifications from kernel, it manually deletes the interface without removing the association between zebra_l3vni and the interface that is being deleted (i.e it deletes the interface without setting “zl3vni->vxlan_if” to NULL). Later, during the deletion of netns, when zl3vni_rmac_uninstall() is called to uninstall the remote RMAC from the kernel, zebra ends up accessing stale “zl3vni->vxlan_if” pointer, which now points to freed memory. This was causing heap use-after-free. Fix: Before zebra starts deleting the interfaces when it receives netns delete notification, appropriate functions() are being called to remove the association between evpn structs and interface and set “zl3vni->vxlan_if” to NULL. This ensures that when zl3vni_rmac_uninstall() is called during netns deletion, it will bail because “zl3vni->vxlan_if” is NULL. Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
|
@Mergifyio backport stable/8.4 stable/8.5 |
✅ Backports have been created
|
Continuous Integration Result: SUCCESSFULCongratulations, this patch passed basic tests Tested-by: NetDEF / OpenSourceRouting.org CI System CI System Testrun URL: https://ci1.netdef.org/browse/FRR-PULLREQ2-10274/ This is a comment from an automated CI system. |
|
verified that this is fixed |
This was referenced Mar 21, 2023
ton31337
added a commit
that referenced
this pull request
Mar 21, 2023
zebra: Fix for heap-use-after-free in EVPN (backport #13062)
ton31337
added a commit
that referenced
this pull request
Mar 21, 2023
zebra: Fix for heap-use-after-free in EVPN (backport #13062)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issue:
When a netns is deleted, since zebra doesn’t receive interface down/delete notifications from kernel, it manually deletes the interface without removing the association between zebra_l3vni and the interface that is being deleted (i.e it deletes the interface without setting “zl3vni->vxlan_if” to NULL).
Later, during the deletion of netns, when zl3vni_rmac_uninstall() is called to uninstall the remote RMAC from the kernel, zebra ends up accessing stale “zl3vni->vxlan_if” pointer, which now points to freed memory. This was causing heap use-after-free.
Fix:
Before zebra starts deleting the interfaces when it receives netns delete notification, appropriate functions() are being called to remove the association between evpn structs and interface and set “zl3vni->vxlan_if” to NULL. This ensures that when zl3vni_rmac_uninstall() is called during netns deletion, it will bail because “zl3vni->vxlan_if” is NULL.
In netlink_link_change() during interface deletion, it calls the appropriate functions to do the clean up before calling if_delete_update() to delete the interface. Similar changes have been made in zebra_ns_delete() to handle the interface deletion.
Address-sanitizer output before fix on R1:
With Fix:
Zebra logs on r1 for topotests/bgp_evpn_rt5/test_bgp_evpn.py: