Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 281391 (CVE-2009-2692) - Kernel: NULL pointer dereference due to incorrect proto_ops initializations (CVE-2009-2692)
Summary: Kernel: NULL pointer dereference due to incorrect proto_ops initializations (...
Alias: CVE-2009-2692
Product: Gentoo Security
Classification: Unclassified
Component: Kernel (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: Gentoo Security
Whiteboard: [ linux >= 2.4.4 < 2.6 ] [ linux >= 2...
: 281903 (view as bug list)
Depends on:
Reported: 2009-08-13 22:14 UTC by Alex Legler (RETIRED)
Modified: 2013-09-12 05:01 UTC (History)
8 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Alex Legler (RETIRED) archtester gentoo-dev Security 2009-08-13 22:14:36 UTC
From taviso:

In the Linux kernel, each socket has an associated struct of operations
called proto_ops which contain pointers to functions implementing various
features, such as accept, bind, shutdown, and so on.

If an operation on a particular socket is unimplemented, they are expected
to point the associated function pointer to predefined stubs, for example if
the "accept" operation is undefined it would point to sock_no_accept(). However,
we have found that this is not always the case and some of these pointers are
left uninitialized.

This is not always a security issue, as the kernel validates the pointers at
the call site, such as this example from sock_splice_read:


But we have found an example where this is not the case; the sock_sendpage()
routine does not validate the function pointer is valid before dereferencing
it, and therefore relies on the correct initialization of the proto_ops

We have identified several examples where the initialization is incomplete:

- The SOCKOPS_WRAP macro defined in include/linux/net.h, which appears correct
  at first glance, was actually affected. This includes PF_APPLETALK, PF_IPX,
  PF_IRDA, PF_X25 and PF_AX25 families.

- Initializations were missing in other protocols, including PF_BLUETOOTH,


All Linux 2.4/2.6 versions since May 2001 are believed to be affected:

- Linux 2.4, from 2.4.4 up to and including
- Linux 2.6, from 2.6.0 up to and including
Comment 1 Christian Hoffmann (RETIRED) gentoo-dev 2009-08-14 10:56:15 UTC
Just for reference:

This allows for local privilege escalation to root in many common setups (either SELinux or pulseaudio available...).
Exploit code in the wild.
Comment 2 Alex Legler (RETIRED) archtester gentoo-dev Security 2009-08-14 22:19:44 UTC
CVE-2009-2692 (
  The Linux kernel 2.6.0 through, and 2.4.4 through,
  does not initialize all function pointers for socket operations in
  proto_ops structures, which allows local users to trigger a NULL
  pointer dereference and gain privileges by using mmap to map page
  zero, placing arbitrary code on this page, and then invoking an
  unavailable operation, as demonstrated by the sendpage operation on a
  PF_PPPOX socket.

Comment 3 Alex Legler (RETIRED) archtester gentoo-dev Security 2009-08-18 12:22:40 UTC
*** Bug 281903 has been marked as a duplicate of this bug. ***
Comment 4 Bernd Marienfeldt 2009-08-19 09:21:56 UTC
Any updates on this ?
Comment 5 Alex Legler (RETIRED) archtester gentoo-dev Security 2009-08-19 09:31:24 UTC
(In reply to comment #4)
> Any updates on this ?

gentoo-sources 2.6.30-r5 and vanilla-sources have the fix, hardened-sources are believed to be not affected.

Upstream has the fix in as well.
Comment 6 Jappie 2009-08-19 14:02:38 UTC
(In reply to comment #5)
> hardened-sources are believed to be not affected.

Can someone confirm that the hardened-sources really aren't affected?
Comment 7 Robert Buchholz (RETIRED) gentoo-dev 2009-08-20 14:00:59 UTC
(In reply to comment #6)
> Can someone confirm that the hardened-sources really aren't affected?
Comment 8 Benedikt Böhm (RETIRED) gentoo-dev 2009-08-25 07:18:49 UTC
fixed in vserver-sources-{,}
Comment 9 Anton Bolshakov 2009-09-11 22:56:56 UTC
Nice. Shouldn't it get stabilized sometime soon now?
We need to force use of gcc 4.1.2 for compiling btw.