CVE-2010-1187: Null Pointer Dereference
Description of problem: tipc: Fix oops on send prior to entering networked mode (v3)
Fix TIPC to disallow sending to remote addresses prior to entering NETMODE
user programs can oops the kernel by sending datagrams via AFTIPC prior to entering networked mode. The following backtrace has been observed:
ID: 13459 TASK: ffff810014640040 CPU: 0 COMMAND: "tipc-client" [exception RIP: tipcnodeselectnexthop+90] RIP: ffffffff8869d3c3 RSP: ffff81002d9a5ab8 RFLAGS: 00010202 RAX: 0000000000000001 RBX: 0000000000000001 RCX: 0000000000000001 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000001001001 RBP: 0000000001001001 R8: 0074736575716552 R9: 0000000000000000 R10: ffff81003fbd0680 R11: 00000000000000c8 R12: 0000000000000008 R13: 0000000000000001 R14: 0000000000000001 R15: ffff810015c6ca00 ORIGRAX: ffffffffffffffff CS: 0010 SS: 0018 RIP: 0000003cbd8d49a3 RSP: 00007fffc84e0be8 RFLAGS: 00010206 RAX: 000000000000002c RBX: ffffffff8005d116 RCX: 0000000000000000 RDX: 0000000000000008 RSI: 00007fffc84e0c00 RDI: 0000000000000003 RBP: 0000000000000000 R8: 00007fffc84e0c10 R9: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fffc84e0d10 R14: 0000000000000000 R15: 00007fffc84e0c30 ORIGRAX: 000000000000002c CS: 0033 SS: 002b
What happens is that, when the tipc module in inserted it enters a standalone node mode in which communication to its own address is allowed <0.0.0> but not to other addresses, since the appropriate data structures have not been allocated yet (specifically the tipcnet pointer). There is nothing stopping a client from trying to send such a message however, and if that happens, we attempt to dereference tipcnet.zones while the pointer is still NULL, and explode. The fix is pretty straightforward. Since these oopses all arise from the dereference of global pointers prior to their assignment to allocated values, and since these allocations are small (about 2k total), lets convert these pointers to static arrays of the appropriate size. All the accesses to these bits consider 0/NULL to be a non match when searching, so all the lookups still work properly, and there is no longer a chance of a bad dererence anywhere. As a bonus, this lets us eliminate the setup/teardown routines for those pointers, and elimnates the need to preform any locking around them to prevent access while their being allocated/freed.
http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commit;h=d0021b252eaf65ca07ed14f0d66425dd9ccab9a6
Other sources
The Transparent Inter-Process Communication (TIPC) functionality in Linux kernel 2.6.16-rc1 through 2.6.33, and possibly other versions, allows local users to cause a denial of service (kernel OOPS) by sending datagrams through AFTIPC before entering network mode, which triggers a NULL pointer dereference.
— MITRE
Affected Software
Remediation
Event History
Frequently Asked Questions
What is the severity of CVE-2010-1187?
CVE-2010-1187 has a severity rating that indicates it can cause a kernel oops when sending datagrams before entering networked mode.
How do I fix CVE-2010-1187?
Fix CVE-2010-1187 by ensuring that applications do not attempt to send datagrams via AF_TIPC until the kernel has entered networked mode.
Which versions of Linux are affected by CVE-2010-1187?
CVE-2010-1187 affects Linux kernel versions ranging from 2.6.16 up to, but not including, 2.6.33.
What are the potential consequences of CVE-2010-1187?
The potential consequence of CVE-2010-1187 is a kernel crash caused by an oops if datagrams are sent prematurely.
Is there a workaround for CVE-2010-1187?
The only effective workaround for CVE-2010-1187 is to modify user programs to avoid sending datagrams until the system is in networked mode.