linux-kernel - Re: Patch 2.4 kernel / allow to read more than 2048 (1821) Symbols from /boot/System.map

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]

Message-Id: <20060921.155615.11378692.davem@davemloft.net>
Date:	Thu, 21 Sep 2006 15:56:15 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	w@....eu
Cc:	DJurzitza@...manbecker.com, linux-kernel@...r.kernel.org,
	sparclinux@...r.kernel.org
Subject: Re: Patch 2.4 kernel / allow to read more than 2048 (1821) Symbols
 from /boot/System.map

From: Willy Tarreau <w@....eu>
Date: Tue, 19 Sep 2006 20:26:38 +0200

> On Sun, Sep 17, 2006 at 10:35:12PM -0700, David Miller wrote:
> > From: "Jurzitza, Dieter" <DJurzitza@...manbecker.com>
> > Date: Mon, 18 Sep 2006 07:23:58 +0200
> > 
> > > The 2.4 kernel series uses sys32_get_kernel_syms(struct kernel_sym32
> > > *table) for reading the kernel symbols (on sparc64). The size of
> > > struct kernel_sym is 64 byte on "normal" arches, but 72 byte on
> > > sparc64.
> > 
> > Jurzita, you do not need to post this patch multiple times.
> > I was simply on vacation for 2 weeks right after your first
> > posting so I had no chance to review the patch.
> 
> BTW, did you finally review it (no emergency at all on my side) ?

There are two problems:

1) If this goes in, similar fixes for sys_ia32.c, mips64, et al.
   should go in at the same time.

2) I dislike this fix because it means that users can lock down
   a significant amount of non-swappable kernel memory.  There are
   no privilege checks in the get_kernel_syms() system call, so
   anyone can invoke it.  Imagine a fork bomb invoking this, and it
   could also potentially eat up nearly all of the vmalloc() space.

It may be, in the end, simply better to have a
"compat_sys_get_kernel_syms" written that can be called
so a temporary kernel copy is not needed.

I'm not offering to implement this :-)  But it does seem to be the
only reasonable solution.
-
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/