forked from luck/tmp_suning_uos_patched
4184b2a79a
A very minimal and simple user space application allocating an SCTP
socket, setting SCTP_AUTH_KEY setsockopt(2) on it and then closing
the socket again will leak the memory containing the authentication
key from user space:
unreferenced object 0xffff8800837047c0 (size 16):
comm "a.out", pid 2789, jiffies 4296954322 (age 192.258s)
hex dump (first 16 bytes):
01 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff816d7e8e>] kmemleak_alloc+0x4e/0xb0
[<ffffffff811c88d8>] __kmalloc+0xe8/0x270
[<ffffffffa0870c23>] sctp_auth_create_key+0x23/0x50 [sctp]
[<ffffffffa08718b1>] sctp_auth_set_key+0xa1/0x140 [sctp]
[<ffffffffa086b383>] sctp_setsockopt+0xd03/0x1180 [sctp]
[<ffffffff815bfd94>] sock_common_setsockopt+0x14/0x20
[<ffffffff815beb61>] SyS_setsockopt+0x71/0xd0
[<ffffffff816e58a9>] system_call_fastpath+0x12/0x17
[<ffffffffffffffff>] 0xffffffffffffffff
This is bad because of two things, we can bring down a machine from
user space when auth_enable=1, but also we would leave security sensitive
keying material in memory without clearing it after use. The issue is
that sctp_auth_create_key() already sets the refcount to 1, but after
allocation sctp_auth_set_key() does an additional refcount on it, and
thus leaving it around when we free the socket.
Fixes:
|
||
|---|---|---|
| .. | ||
| associola.c | ||
| auth.c | ||
| bind_addr.c | ||
| chunk.c | ||
| debug.c | ||
| endpointola.c | ||
| input.c | ||
| inqueue.c | ||
| ipv6.c | ||
| Kconfig | ||
| Makefile | ||
| objcnt.c | ||
| output.c | ||
| outqueue.c | ||
| primitive.c | ||
| probe.c | ||
| proc.c | ||
| protocol.c | ||
| sm_make_chunk.c | ||
| sm_sideeffect.c | ||
| sm_statefuns.c | ||
| sm_statetable.c | ||
| socket.c | ||
| ssnmap.c | ||
| sysctl.c | ||
| transport.c | ||
| tsnmap.c | ||
| ulpevent.c | ||
| ulpqueue.c | ||