From: Dan Carpenter <dan.carpenter@oracle.com>
To: kernel-janitors@vger.kernel.org
Subject: Re: Doubt about some kernel definitions..
Date: Sat, 05 Nov 2011 20:21:16 +0000 [thread overview]
Message-ID: <20111105202116.GS4682@mwanda> (raw)
[-- Attachment #1: Type: text/plain, Size: 2117 bytes --]
Hi Marcos,
I've added the kernel-janitors and driver-devel to the CC list. Btw,
in particular for patches, you should always CC at least one email
list.
The stuff in ttypes.h is messed up in a couple ways.
typedef int BOOL;
BOOL should be bool, but int is 32 bits and bool is 1 bit so this is
not a white space change. You need to check every place that uses
BOOL to make sure changing it does not introduce a bug.
typedef unsigned char BYTE; // 8-bit
This one is simple. Change all these places to u8.
typedef unsigned short WORD; // 16-bit
This is weird because you'd normally think of a word as an int.
Changing all of these to u16 won't introduce any bugs, but you should
check all the places to make sure there isn't a bug already there.
typedef unsigned long DWORD; // 32-bit
unsigned long is 32bit on 32 bit systems and 64 bit on 64 bit systems
so you'd need to look at each place this is used and see what is
correct. It could be u32, int, unsigned long, etc.
typedef unsigned long ULONG_PTR; // 32-bit
I looked at how ULONG_PTR was used and it's normally something like
this:
unsigned int uLen = pRSNWPA->len + 2;
if (uLen <= (uIELength -
(unsigned int) (ULONG_PTR) ((PBYTE) pRSNWPA - pbyIEs))) {
pBSSList->wWPALen = uLen;
memcpy(pBSSList->byWPAIE, pRSNWPA, uLen);
WPA_ParseRSN(pBSSList, pRSNWPA);
}
This looks wrong to me.
1) It's doing pointer math and pointers are 64 bit on x86_64 systems.
Then it's truncating the upper bits away. Not a big deal in this
case, but it's ugly.
2) uIELength is unsigned so a negative value for the subtraction gets
turned into a large positive value and the test becomes meaningless.
Possibly leading to memory corruption. This particular code is
parsing data from over the network so it could be a remote security
problem.
Basically when you're doing this kind of work keep your eyes open for
any other bugs you can spot. It's not just a matter of running sed
over the driver.
regards,
dan carpenter
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
reply other threads:[~2011-11-05 20:21 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20111105202116.GS4682@mwanda \
--to=dan.carpenter@oracle.com \
--cc=kernel-janitors@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox