-
Notifications
You must be signed in to change notification settings - Fork 2.1k
sys/net/gnrc_sixlowpan: fix a possible NULL ptr dereference #22066
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
sys/net/gnrc_sixlowpan: fix a possible NULL ptr dereference #22066
Conversation
Due to a typo in a logical operation, a specifically crafted packet could cause a NULL ptr dereference. However, the affected code is only active when 6LoWPAN without IPv6 support is used, which is not expected to ever happen in any real world deployment.
|
Shunting in favor of the release note PR |
kfessel
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you might want to remove the second condition part
| #ifndef MODULE_GNRC_IPV6 | ||
| type = GNRC_NETTYPE_UNDEF; | ||
| for (gnrc_pktsnip_t *ptr = pkt; (ptr || (type == GNRC_NETTYPE_UNDEF)); | ||
| for (gnrc_pktsnip_t *ptr = pkt; (ptr && (type == GNRC_NETTYPE_UNDEF)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is that && (type == GNRC_NETTYPE_UNDEF) needed?
the type is set only only if the ptr->next->type is GNRC_NETTYPE_NETIF and then then loop is broken anyway (the for condition is not checked again and no code (e.g.: deref) is run.
| for (gnrc_pktsnip_t *ptr = pkt; (ptr && (type == GNRC_NETTYPE_UNDEF)); | |
| for (gnrc_pktsnip_t *ptr = pkt; ptr; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It leads to an early exit (yes that's only one more pkt->next if the list is correct, but does not hurt).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should go for a clean for loop (only one running variable and only that is checked) otherwise we will have a linter complain next.
it will also increase the readability ( and the for will probalbly fit in one line ;
but you can dismiss this (thats what the ? is for).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It leads to an early exit (yes that's only one more
pkt->nextif the list is correct, but does not hurt).
there is no extra one more pkt->next as the for loop is broken (no for loop next ) when the interface is next
| for (gnrc_pktsnip_t *ptr = pkt; (ptr && (type == GNRC_NETTYPE_UNDEF)); | ||
| ptr = ptr->next) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| for (gnrc_pktsnip_t *ptr = pkt; (ptr && (type == GNRC_NETTYPE_UNDEF)); | |
| ptr = ptr->next) { | |
| for (gnrc_pktsnip_t *ptr = pkt; ptr; ptr = ptr->next) { |
Contribution description
Due to a typo in a logical operation, a specifically crafted packet could cause a NULL ptr dereference. However, the affected code is only active when 6LoWPAN without IPv6 support is used, which is not expected to ever happen in any real world deployment.
Testing procedure
type == GNRC_NETTYPE_UNDEFafter the 6LoWPAN header, no NULL pointer dereference should occurIssues/PRs references
None