pimd: clean stale upstream NHT tracking on RP delete (backport #22505)#22605
Merged
Conversation
Issue: Faced a crash in below sequence. pim_upstream_mroute_iif_update+0x16 -> pimd/pim_mroute.c:1256 pimd(+0x78a94) -> pimd/pim_nht.c pim_nexthop_update+0x587 -> pimd/pim_nht.c Rootcause: pim_rpf_update() tracks upstreams in pnc->upstream_hash keyed by up->upstream_addr. Some RP delete/BSM cleanup paths clear RPF state and then mutate up->upstream_addr to PIMADDR_ANY without first removing the upstream from the old RP nexthop cache bucket. If the upstream was previously tracked under the old RP address, a later Zebra NHT update for that address can still walk the stale upstream entry. Fix: Add pim_nht_delete_tracked_upstream() and call it from RP delete and BSM cleanup paths to remove the upstream from the old NHT bucket before up->upstream_addr is changed to PIMADDR_ANY. This prevents the old pnc->upstream_hash from retaining a stale upstream pointer. Signed-off-by: harini <hnattamaisub@nvidia.com> (cherry picked from commit 04f04ca)
pim_upstream_mroute_iif_update() dereferences c_oil via oil_incoming_vif() and pim_upstream_get_mroute_iif() with no NULL check. Some upstream cleanup paths can reach these callers after channel_oil has been freed, producing a NULL dereference. Add a defensive NULL check at the top of pim_upstream_mroute_iif_update(), and skip the call in pim_upstream_rpf_clear() and the PIM_RPF_CHANGED branch of pim_update_upstream_nh_helper() when up->channel_oil is NULL. Signed-off-by: harini <hnattamaisub@nvidia.com> (cherry picked from commit 18aba5c)
|
Target branch is not in the allowed branches list. |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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:
Faced a crash in below sequence.
pim_upstream_mroute_iif_update+0x16 -> pimd/pim_mroute.c:1256
pimd(+0x78a94) -> pimd/pim_nht.c
pim_nexthop_update+0x587 -> pimd/pim_nht.c
Rootcause:
pim_rpf_update() tracks upstreams in pnc->upstream_hash keyed by up->upstream_addr.
Some RP delete/BSM cleanup paths clear RPF state and then mutate up->upstream_addr to PIMADDR_ANY without first removing the upstream from the old RP nexthop cache bucket. If the upstream was previously tracked under the old RP address, a later Zebra NHT update for that address can still walk the stale upstream entry.
Fix:
1)Guard channel_oil at appropriate places.
2)Wrote an api for cleanup.
RP delete and BSM cleanup now remove the upstream from the old NHT bucket before up->upstream_addr is changed to PIMADDR_ANY. This prevents the old pnc->upstream_hash from retaining a stale upstream pointer.
This is an automatic backport of pull request #22505 done by Mergify.