linux-kernel - Re: 2.6.30-rc6: Reported regressions from 2.6.29

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]

Date:	Sat, 16 May 2009 17:01:26 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Adrian Bunk <bunk@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Natalie Protasevich <protasnb@...il.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Kay Sievers <kay.sievers@...y.org>
Subject: Re: 2.6.30-rc6: Reported regressions from 2.6.29

On Sat, 16 May 2009, Rafael J. Wysocki wrote:
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13326
> Subject		: Null pointer dereference in rtc-cmos driver
> Submitter	: Ozan Çağlayan <ozan@...dus.org.tr>
> Date		: 2009-05-14 16:16 (3 days old)
> References	: http://marc.info/?l=linux-kernel&m=124231783704696&w=4

Ok, I'm of two minds on this one.

The thing that triggers it is a module that is both a module _and_ 
compiled in (ie the same kernel compiled twice, and the stale module kept 
around). I can see how it happens, and we should react more gracefully to 
it, but at the same time I can't really bring myself to care deeply.

What is going on is that the cmos-rtc.c driver does this:

	#ifdef  CONFIG_PNP
	        pnp_register_driver(&cmos_pnp_driver);
	#endif

	        if (!cmos_rtc.dev)
	                retval = platform_driver_probe(&cmos_platform_driver,
                                               cmos_platform_probe);

	        if (retval == 0)
	                return 0;

	#ifdef  CONFIG_PNP
	        pnp_unregister_driver(&cmos_pnp_driver);
	#endif
	        return retval;

and what happens is that the pnp_register_driver fails when the module 
calls it (because the built-in driver already exists under the same name):

	[   10.428691] Error: Driver 'rtc_cmos' is already registered, aborting...

but the driver doesn't really care whether that succeeded or not, but then 
the platform_driver_probe fails (because the thing is already in use), so 
then it ends up unregistering something that never got registered in the 
first place.

I think this is strictly speaking a bug in driver_unregister(), which is 
too fragile. If you unregister a drivert that wasn't registered, we 
shouldn't oops. 

But we could certainly do it at the rtc-cmos.c level too, and just not 
unregister it if the registration failed. My gut feel is that we should 
aim for the core driver helpers to be less fragile, though - we'll always 
have driver bugs.

Greg?

			Linus
--
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/