From: "Adam J. Richter" <adam@yggdrasil.com>
To: mm@ns.caldera.de
Cc: linux-kernel@vger.kernel.org
Subject: Re: PATCH: linux-2.4.10-pre14/drivers/sound/maestro.c ignored pci_module_init results
Date: Sun, 23 Sep 2001 14:21:59 -0700 [thread overview]
Message-ID: <200109232121.OAA03841@adam.yggdrasil.com> (raw)
>> = Adam Richter
> = Marcus Meissner
>> The initialization routine in
>> linux-2.4.10-pre14/drivers/sound/maestro.c ignores the return value
>> from pci_module_init, and allows module initialization to succeed
>> even if pci_module_init failed. pci_module_init fails and unloads
>> the driver if the caller is a module and there is no matching hardware.
>> Because maestro.c ignored this failure, loading maestro.o on a system
>> where the corresponding alsa driver was already loaded or on a system
>> without matchin hardware would result in a kernel null pointer dereference
>> in pci_unregister_driver when the module is unloaded or when one
>> attempts to reboot the system (i.e., when the module attempt to
>> unregister a PCI driver that is not registered).
>Why and where does it Oops?
On a machine that has no maestro hardware or that already has
the alsa drivers bound to the maestro PCI hardware, either of the
following will cause a null pointer dereference when
pci_unregister_driver tries to unregister a driver that is not registered:
modprobe maestro
rmmod maestro
(as cleanup_maestro incorrectly calls pci_unregister_driver
on a PCI driver that is not loaded.)
...or...
modprobe meastro
reboot
(as maestro_notifier incorrectly calls pci_unregister_driver
on a PCI driver that is not loaded.)
I experimentally verified both of these on a machine that already
had the maestro ALSA drivers loaded. I assume the null pointer dereference
would be from the list_del(&drv->node) in pci_unregister_driver, since
list_del calls __list_del, which assumes that drv->node->{prev,next} are
not NULL, but they would have been set to NULL by the first
pci_remove_module, which pci_module_init called when the driver failed
to bind to anything, but which the maestro driver incorrectly ignored.
>The code for pci_unregister_driver in
>drivers/pci/pci.c looks correct and should not Oops.
>
>The reboot notifier might be problematic, but I have not checked it.
There is nothing wrong with pci_unregister_driver. The bug
is where init_maestro in maestro.c ignored the results of
pci_module_init, which is what my patch fixes.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
next reply other threads:[~2001-09-23 21:21 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-23 21:21 Adam J. Richter [this message]
-- strict thread matches above, loose matches on Subject: below --
2001-09-23 6:02 Adam J. Richter
2001-09-23 16:24 ` Marcus Meissner
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=200109232121.OAA03841@adam.yggdrasil.com \
--to=adam@yggdrasil.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mm@ns.caldera.de \
/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
all inboxes | Powered by JetHome®