Summary: | net-wireless/iwlwifi < 1.1.21-r1 NULL dereference vulnerability (CVE-2007-5938) | ||||||
---|---|---|---|---|---|---|---|
Product: | Gentoo Security | Reporter: | airsupply <airsupply> | ||||
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | trivial | CC: | compnerd, ischram | ||||
Priority: | High | ||||||
Version: | unspecified | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | ~3 [noglsa] | ||||||
Package list: | Runtime testing required: | --- | |||||
Attachments: |
|
Description
airsupply
2007-11-15 08:25:41 UTC
Saleem, please advise. (saleem submitted patches upstream, they are in iwlwifi git, and submitted to kernel mailinglists) I am going to take a risk here, and deny that what they claim that this is a non issue. The function will never return NULL in any real life circumstances. (this inconsistency in the code was already reported to the iwlwifi mailinglist at the end of september http://article.gmane.org/gmane.linux.drivers.ipw3945.devel/1618 ) I concluded that back in September, and i looked through the 3945 code again today more thoroughly right now. And it is my preliminary conviction that the level foo needed to return 0 is pretty high. there are 4 call sites for this function (.._set_rates() ) the only one which isn't safe from this (becuase it isn't obviously preceded by an get_channel_info is in reset_tsf callback.) In any case, it would only be exploitable when the module is loading/initialisation. because once it is set to a valid value, it will not be changed to something invalid anymore. I would be interested to know how it can be exploited. Feel free to mail/contact me with an exploitation scenario. but anyway it's better that the check is in place. The old versions are no longer in the tree. Created attachment 136472 [details, diff]
CVE-2007-5938.patch
Adding compnerd's patch for reference.
Patch is in 1.1.21-r1, closing. |