linux-kernel - Re: [PATCH] NULL struct irq_desc's member 'name' in dynamic_irq

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] [day] [month] [year] [list]

Date:	Fri, 17 Oct 2008 13:30:48 -0500
From:	Dean Nelson <dcn@....com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	mingo@...e.hu, linux-kernel@...r.kernel.org, stable@...nel.org
Subject: Re: [PATCH] NULL struct irq_desc's member 'name' in dynamic_irq_cleanup()

On Thu, Oct 16, 2008 at 04:11:45PM -0700, Andrew Morton wrote:
> On Thu, 16 Oct 2008 07:58:08 -0500
> Dean Nelson <dcn@....com> wrote:
> 
> > If the member 'name' of the irq_desc structure happens to point to a character
> > string that is resident within a kernel module, problems insue if that module
> > is rmmod'd (at which time dynamic_irq_cleanup() is called) and then later
> > show_interrupts() is called by someone.
> 
> It would be nice to spell out what the "problems" are.

I'm working on a drivers/misc/sgi-xp patchset for SGI's UV system that will
call uv_setup_irq() and uv_teardown_irq(), both of which were submitted as a
patch (Subject: [PATCH] x86, UV: add uv_setup_irq() and uv_teardown_irq()
functions v.3) which has been applied to Ingo's tip/x86/uv.

The first argument to uv_setup_irq() is a pointer to the irq_name to be
stored in irq_desc.name. For XPC, it points to a string resident in the
kernel module.

When I rmmod xpc, uv_teardown_irq() calls destroy_irq() which in turn
calls dynamic_irq_cleanup().

In arch/x86/kernel/irq_64.c, show_interrupts() references the 'name' member
in the following manner:

	seq_printf(p, "-%-8s", irq_desc[i].name);

In my case, show_interrupts was called by the irq balancer and the end result
was an Oops. Note that this can occur later than the rmmod such that the
two events do not appear related.

> 
> Because we should work out whether this should be backported into
> -stable.  And if so, how far back it should go.

I don't have an answer for this.

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