Skip to content
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

[v1.14] Bluetooth: controller: Fix uninit conn context after invalid channel map #27510

Closed
erbr-ot opened this issue Aug 12, 2020 · 6 comments
Closed
Assignees
Labels
area: Bluetooth bug The issue is a bug, or the PR is fixing a bug priority: high High impact/importance bug Stale
Milestone

Comments

@erbr-ot
Copy link
Collaborator

erbr-ot commented Aug 12, 2020

When a connect indication contains a channel map of all zeros, the adv->conn is left NULL'ed after connect establishment is abborted and next connect attempt leads to a crash.

This was identified via the Sweyntooth test suite - executing the script re. issue 6.14 towards an Oticon target.
https://asset-group.github.io/disclosures/sweyntooth/
Zephyr v1.14 needs to be analysed.

See #27507

@erbr-ot erbr-ot added bug The issue is a bug, or the PR is fixing a bug area: Bluetooth labels Aug 12, 2020
@erbr-ot erbr-ot added this to the v1.14.2 milestone Aug 12, 2020
@erbr-ot erbr-ot changed the title Bluetooth: controller: v1.14.x - conn-ind with an all zero chmap crash Bluetooth: controller: Fix uninit conn context after invalid channel map Aug 12, 2020
@MaureenHelm MaureenHelm added the priority: high High impact/importance bug label Aug 18, 2020
@nashif nashif modified the milestones: v1.14.2, v1.14.3 Sep 15, 2020
@carlescufi carlescufi changed the title Bluetooth: controller: Fix uninit conn context after invalid channel map [v1.14] Bluetooth: controller: Fix uninit conn context after invalid channel map Sep 15, 2020
@carlescufi
Copy link
Member

@erbr-ot will you create a backport PR for this, targetting the v1.14-branch?

@erbr-ot
Copy link
Collaborator Author

erbr-ot commented Sep 16, 2020

@carlescufi I will, in the next few days.

@erbr-ot
Copy link
Collaborator Author

erbr-ot commented Oct 13, 2020

Hi @carlescufi - sorry this got back-seated during our race to finish-line. Looking into this now, and have a question: I see that the guard re. lll->data_chan_hop is not present in v1.14.2, should I introduce this also in the same PR?

@carlescufi
Copy link
Member

Hi @carlescufi - sorry this got back-seated during our race to finish-line. Looking into this now, and have a question: I see that the guard re. lll->data_chan_hop is not present in v1.14.2, should I introduce this also in the same PR?

I think this is a question for @cvinayak

@github-actions
Copy link

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

@cvinayak
Copy link
Contributor

This slipped through me. Now addressed here #33760

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Bluetooth bug The issue is a bug, or the PR is fixing a bug priority: high High impact/importance bug Stale
Projects
None yet
Development

No branches or pull requests

5 participants