Hi,
On Sun, 2011-01-09 at 15:22 +0300, Sergei Shtylyov wrote:
> > return &NULL->request;
>
> I can only repeat what I've said: there is no actual dereference here as
> we're not following the NULL pointer. Mind the & operator -- we're only
ok ok, I have to agree with this. You're right.
> adding offset of the field (0) to NULL which doesn't change it, so we still
> return NULL.
this isn't correct. I just ran a test with this simple code:
#include <linux/kernel.h>
#include <linux/module.h>
struct field {
int a;
int b;
int c;
};
struct my_mod {
int a;
int b;
int c;
struct field f;
};
static struct field *get_field(void)
{
struct my_mod *mod = NULL;
return &mod->f;
}
static int __init mod_init(void)
{
struct field *f = get_field();
if (f == NULL)
pr_info("===> f (%p) is NULL\n", f);
else
pr_info("===> f (%p) is not NULL\n", f);
return 0;
}
module_init(mod_init);
static void __exit mod_exit(void)
{ }
module_exit(mod_exit);
if you compile and insmod this simple module you'll see on dmesg:
$ dmesg
[1385224.347740] ===> f (0000000c) is not NULL
Which means that gadget drivers testing for valid struct usb_request *
pointers against NULL will be fooled thinking it got a valid struct
usb_request *, which is a mistake.
Now, if change the check:
--- t.c.orig 2011-01-09 19:06:31.581642000 +0200
+++ t.c 2011-01-09 19:05:41.733642000 +0200
@@ -26,7 +26,7 @@ static int __init mod_init(void)
{
struct field *f = get_field();
- if (f == NULL)
+ if (f)
pr_info("===> f (%p) is NULL\n", f);
else
pr_info("===> f (%p) is not NULL\n", f);
Everything the pointer is considered NULL:
$ dmesg
[1385484.405684] ===> f (0000000c) is NULL
So the potential for kernel oops is valid, my commit log might not have
been the brightest though :-p
--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
