linux-kernel - Re: 2.6.25-git16 -- BUG: unable to handle kernel NULL pointer dereference at 00000000 -- IP: [<c02dd5d5>] fw_show_drv_device

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: <4819DC1F.1050904@s5r6.in-berlin.de>
Date:	Thu, 01 May 2008 17:05:03 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	dpn@...merica.net
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	krh@...hat.com, linux1394-devel@...ts.sourceforge.net
Subject: Re: 2.6.25-git16 -- BUG: unable to handle kernel NULL pointer dereference
 at 00000000 -- IP: [<c02dd5d5>] fw_show_drv_device_ids+0xd9/0xee

Dan Noé wrote:
> I like to be warned about things, even if there isn't anything I can 
> really do about it (fix my IEEE 1394 ROM CRC? :) But there doesn't seem 
> to be any point to repeating the message.
> 
> Do the repeats come because it prints each time the config ROM is accessed?

There are three reasons which cause repetition:

   - While we fetch and parse the config ROM, another bus resets happens.
     We then need to start over reading the config ROM.  This kind of
     repetition cannot easily be prevented, but hopefully happens less
     often.

   - A variation of the theme:  Device plugged out, plugged in again.
     Causes the config ROM to be at least partially fetched and parsed
     again.

   - If the firmware author did the CRC algorithm wrong, he got it wrong
     for the bus information block, the root directory, and each
     subdirectory or leaf (unit directories, instance directories,
     textual descriptor leaves, icon descriptors...).  Giving a log
     notice about each of these CRCs is surely redundant.

When I added the log notice, I didn't try to suppress at least the 
latter kind of repetition because I figured that this kind of mistake is 
rare nowadays.  (If I'm not mistaken, there have for example been 
clarifications in IEEE 1212-2001.)  Of course it isn't rare to those 
people who happen to work with affected devices all the time.  So I will 
try to reduce the log spam.

BTW, "fix my IEEE 1394 ROM CRC" can sometimes be done by firmware update.
-- 
Stefan Richter
-=====-==--- -=-= ----=
http://arcgraph.de/sr/
--
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/