Skip to content

Conversation

@maribu
Copy link
Member

@maribu maribu commented Feb 9, 2026

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

  • this makes static analysis happy
  • when not using IPv6 and receiving a packet with only header counting as type == GNRC_NETTYPE_UNDEF after the 6LoWPAN header, no NULL pointer dereference should occur

Issues/PRs references

None

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.
@maribu maribu requested a review from miri64 as a code owner February 9, 2026 09:34
@maribu maribu added Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors) CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Feb 9, 2026
@github-actions github-actions bot added Area: network Area: Networking Area: sys Area: System labels Feb 9, 2026
@riot-ci
Copy link

riot-ci commented Feb 9, 2026

Murdock results

✔️ PASSED

bc697dd sys/net/gnrc_sixlowpan: fix a possible NULL ptr dereference

Success Failures Total Runtime
11004 0 11005 09m:24s

Artifacts

@maribu maribu added this pull request to the merge queue Feb 9, 2026
@miri64
Copy link
Member

miri64 commented Feb 9, 2026

Shunting in favor of the release note PR

@miri64 miri64 removed this pull request from the merge queue due to a manual request Feb 9, 2026
@miri64 miri64 added this pull request to the merge queue Feb 9, 2026
Copy link
Contributor

@kfessel kfessel left a 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

@kfessel kfessel removed this pull request from the merge queue due to a manual request Feb 9, 2026
#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));
Copy link
Contributor

@kfessel kfessel Feb 9, 2026

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.

Suggested change
for (gnrc_pktsnip_t *ptr = pkt; (ptr && (type == GNRC_NETTYPE_UNDEF));
for (gnrc_pktsnip_t *ptr = pkt; ptr;

Copy link
Member

@miri64 miri64 Feb 9, 2026

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).

Copy link
Contributor

@kfessel kfessel Feb 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that code is not needed since you @miri64 worked around it in #10866 by adding the break

Copy link
Contributor

@kfessel kfessel Feb 9, 2026

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).

Copy link
Contributor

@kfessel kfessel Feb 9, 2026

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 is no extra one more pkt->next as the for loop is broken (no for loop next ) when the interface is next

Comment on lines +74 to 75
for (gnrc_pktsnip_t *ptr = pkt; (ptr && (type == GNRC_NETTYPE_UNDEF));
ptr = ptr->next) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
for (gnrc_pktsnip_t *ptr = pkt; (ptr && (type == GNRC_NETTYPE_UNDEF));
ptr = ptr->next) {
for (gnrc_pktsnip_t *ptr = pkt; ptr; ptr = ptr->next) {

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Area: network Area: Networking Area: sys Area: System CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants