[Linux-ia64] null pointer dereference patch

[Linux-ia64] null pointer dereference patch

[Bjorn Helgaas]

Without the attached patch, unaligned references before
init_modules() is called result in null pointer dereferences.
This is against 2.4.17-ia64-011226.
-- 
Bjorn Helgaas - bjorn_helgaas@hp.com
Linux Systems Operation R&D
Hewlett-Packard


Index: arch/ia64/mm/extable.c
=================================RCS file: /var/cvs/linux/arch/ia64/mm/extable.c,v
retrieving revision 1.2
diff -u -p -r1.2 extable.c
--- arch/ia64/mm/extable.c	25 Jan 2002 20:14:42 -0000	1.2
+++ arch/ia64/mm/extable.c	12 Feb 2002 16:42:55 -0000
@@ -59,6 +59,8 @@ search_exception_table (unsigned long ad
 		if (!mp->ex_table_start)
 			continue;
 		archdata = (struct archdata *) mp->archdata_start;
+		if (!archdata)
+			continue;
 		entry = search_one_table(mp->ex_table_start, mp->ex_table_end - 1,
 					 addr, (unsigned long) archdata->gp);
 		if (entry) {

Re: [Linux-ia64] null pointer dereference patch

[David Mosberger]

>>>>> On Tue, 12 Feb 2002 14:51:22 -0700, Bjorn Helgaas <bjorn_helgaas@hp.com> said:

  Bjorn> Without the attached patch, unaligned references before
  Bjorn> init_modules() is called result in null pointer dereferences.
  Bjorn> This is against 2.4.17-ia64-011226.

I wonder whether module_list shouldn't be made to be NULL until
init_modules() has had a chance to initialize it.  Keith?

	--david

Re: [Linux-ia64] null pointer dereference patch

[Keith Owens]

On Tue, 12 Feb 2002 14:09:43 -0800, 
David Mosberger <davidm@hpl.hp.com> wrote:
>>>>>> On Tue, 12 Feb 2002 14:51:22 -0700, Bjorn Helgaas <bjorn_helgaas@hp.com> said:
>
>  Bjorn> Without the attached patch, unaligned references before
>  Bjorn> init_modules() is called result in null pointer dereferences.
>  Bjorn> This is against 2.4.17-ia64-011226.
>
>I wonder whether module_list shouldn't be made to be NULL until
>init_modules() has had a chance to initialize it.  Keith?

Some arch dependent init code relies on extable working right from the
start, to catch kernel operations that may or may not be valid,
depending on the precise hardware.  Changing module_list to NULL breaks
that code, the patch is correct.

Re: [Linux-ia64] null pointer dereference patch

[David Mosberger]

>>>>> On Wed, 20 Feb 2002 11:22:29 +1100, Keith Owens <kaos@ocs.com.au> said:

  Keith> On Tue, 12 Feb 2002 14:09:43 -0800, David Mosberger
  Keith> <davidm@hpl.hp.com> wrote:
  >>>>>>> On Tue, 12 Feb 2002 14:51:22 -0700, Bjorn Helgaas
  >>>>>>> <bjorn_helgaas@hp.com> said:
  >>
  Bjorn> Without the attached patch, unaligned references before
  Bjorn> init_modules() is called result in null pointer dereferences.
  Bjorn> This is against 2.4.17-ia64-011226.
  >>  I wonder whether module_list shouldn't be made to be NULL until
  >> init_modules() has had a chance to initialize it.  Keith?

  Keith> Some arch dependent init code relies on extable working right
  Keith> from the start, to catch kernel operations that may or may
  Keith> not be valid, depending on the precise hardware.  Changing
  Keith> module_list to NULL breaks that code, the patch is correct.

If you insist on the kernel module descriptor being initialized right
from the get go, then I'd argue there should be a way for statically
initializing this descriptor.  I really think it's a bad idea to have
partially initialized data laying around.

	--david

Re: [Linux-ia64] null pointer dereference patch

[Keith Owens]

On Wed, 20 Feb 2002 14:26:35 -0800, 
David Mosberger <davidm@hpl.hp.com> wrote:
>>>>>> On Wed, 20 Feb 2002 11:22:29 +1100, Keith Owens <kaos@ocs.com.au> said:
>  Keith> Some arch dependent init code relies on extable working right
>  Keith> from the start, to catch kernel operations that may or may
>  Keith> not be valid, depending on the precise hardware.  Changing
>  Keith> module_list to NULL breaks that code, the patch is correct.
>
>If you insist on the kernel module descriptor being initialized right
>from the get go, then I'd argue there should be a way for statically
>initializing this descriptor.  I really think it's a bad idea to have
>partially initialized data laying around.

The bulk of the kernel module descriptor is statically initialized,
all the common fields are filled in that way, including the extable
that init code relies on.  However archdata is a bit harder (arch
dependent initialization) and the kernel_data field cannot be
statically initialized at all.  Just have to check if those fields have
been filled in or not.  In any case it is possible (but unlikely) for a
module to be loaded that has no archdata so the field can be NULL for
modules as well.