linux-kernel - Re: [git pull] DVB + ieee1394: firedtv driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.0902260824470.3111@localhost.localdomain>
Date:	Thu, 26 Feb 2009 08:40:04 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
cc:	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	linux1394-devel@...ts.sourceforge.net, linux-media@...r.kernel.org,
	Mauro Carvalho Chehab <mchehab@...radead.org>,
	Ben Backx <ben@...ckx.com>, Henrik Kurelid <henrik@...elid.se>
Subject: Re: [git pull] DVB + ieee1394: firedtv driver



On Thu, 26 Feb 2009, Stefan Richter wrote:
> 
> Alas I have no Linux box at hand before Saturday.  I wonder, was
> ieee1394_bus_type not yet registered (i.e. ieee1394's ieee1394_init() not yet
> called) at the moment when fdtv_init is executed?
> 
> Or what else could have been the NULL pointer dereference in driver_find?

Afaik, the only way that NULL pointer dereference can happen is if

	struct kobject *k = kset_find_obj(bus->p->drivers_kset, name);

gets a NULL pointer exception either because of a NULL "bus" pointer as 
the argument, or if "bus->p" is NULL.

And in this case, it's the latter. The Code: decode shows the whole 
function in this case:

  1c:	55                   	push   %rbp
  1d:	89 e5                	mov    %esp,%ebp
  1f:	e8 34 5f c8 ff       	callq  0xffffffffffc85f58
  24:	89 c1                	mov    %eax,%ecx
  26:	8b 42 38             	mov    0x38(%rdx),%eax
  29:	89 ca                	mov    %ecx,%edx
  2b:*	8b 40 54             	mov    0x54(%rax),%eax     <-- trapping instruction
  2e:	e8 6c 48 f9 ff       	callq  0xfffffffffff9489f
  33:	31 d2                	xor    %edx,%edx
  35:	85 c0                	test   %eax,%eax
  37:	74 03                	je     0x3c
  39:	8b 50 6c             	mov    0x6c(%rax),%edx
  3c:	5d                   	pop    %rbp
  3d:	89 d0                	mov    %edx,%eax
  3f:	c3                   	retq   

and that first "callq" seems to be due to Ingo having function tracing on, 
while the second callq would have been that 'kset_find_obj()' thing.

So it does look like "&ieee1394_bus_type" has simply not been initialized 
yet. It looks like ieee1394_init() is called too late.

Two choices that I can see:

 - do the ieee1394_init() as a fs_initcall(), earlier

 - move drivers/ieee1394 linking up to before drivers/media

but I suspect that drivers/media wants to be early, in order to do the 
_media_ layer initialization early.

Does this work?

		Linus

---
 drivers/ieee1394/ieee1394_core.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/ieee1394/ieee1394_core.c b/drivers/ieee1394/ieee1394_core.c
index 1028e72..8723380 100644
--- a/drivers/ieee1394/ieee1394_core.c
+++ b/drivers/ieee1394/ieee1394_core.c
@@ -1275,7 +1275,7 @@ static void __exit ieee1394_cleanup(void)
 	unregister_chrdev_region(IEEE1394_CORE_DEV, 256);
 }
 
-module_init(ieee1394_init);
+fs_initcall(ieee1394_init);
 module_exit(ieee1394_cleanup);
 
 /* Exported symbols */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/