-
Notifications
You must be signed in to change notification settings - Fork 6.8k
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
eswifi: Fix possible buffer overflows #63074
Merged
+12
−4
Merged
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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.
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.
This is almost certainly not what we want to do, as the result will not ever have a nul termination on it.
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.
Not sure, I saw several places assuming that the string may be not nul terminate and allocating
WIFI_SSID_MAX_LEN + 1
to accommodate the \0 e.g:shell_fprintf(sh, SHELL_NORMAL, "SSID: %-32s\n", status.ssid)
if (params->ssid_length > WIFI_SSID_MAX_LEN) {
other drivers too (e.g drivers/wifi/esp32/src/esp_wifi_drv.c)
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.
In theory SSID can have \0 in it so using strncpy() will probably not work as expected. On the other hand I doubt anybody would use \0 in the SSID as it would make connecting quite difficult. So it would make sense to allocate one extra \0 byte at the end of SSID array to make sure the value is null terminated even if the SSID is max length (32 bytes).
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.
the point is that upper layer is whether or not assuming that ssid is nul terminate ? I didn't dig too much, but my impression is that places manipulating
struct wifi_iface_status.ssid
are assuming that this is not nul terminate.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.
Yes, that should be the case, we should not assume there is \0 at the end. I am just pondering here that it might make sense to add one at the end anyway (just in case).
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.
Without really now the context and reasons why they are not nul terminate, I'd say that generally speaking this can be a huge source of mistakes since most common APIs to deal with strings expects a nul terminator.
That's said, this is not particular to this driver, I think we should merge this fix (if it is correct)
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.
@loicpoulain , do you have any input about this?
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.
IEEE 802.11-2020: 9.4.22
TL;DR, Null termination of SSID isn't guaranteed, so, if the stored SSID is used as a string it should be
ssid[33]
to accomodate NULL character.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.
The WiFi controller reports NULL terminated strings and we convert that into what the WiFi susbsystem is expecting, so... it seems ok to merge.