diff options
author | Sona Sarmadi <sona.sarmadi@enea.com> | 2015-12-02 12:21:41 +0100 |
---|---|---|
committer | Huimin She <huimin.she@enea.com> | 2015-12-03 10:58:17 +0100 |
commit | fb6a465c392827d23c84aff644d7dd1856d59218 (patch) | |
tree | 96e5ae407a68a3521c193cbfbc59f76b972695fc | |
parent | 380a96f628fab2263cc12d72b15bf432a9528435 (diff) | |
download | meta-enea-fb6a465c392827d23c84aff644d7dd1856d59218.tar.gz |
net-sctp: CVE-2015-1421
Fix slab corruption from use after free on INIT collisions
Fix for linux-qoriq 3.12.
Reference:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-1421
Upstream fix:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/patch/
?id=43e39c2f63240f67a67b4060882f67dac1a6f339
Signed-off-by: Sona Sarmadi <sona.sarmadi@enea.com>
Signed-off-by: Huimin She <huimin.she@enea.com>
-rw-r--r-- | recipes-kernel/linux/files/net-sctp-CVE-2015-1421.patch | 136 | ||||
-rw-r--r-- | recipes-kernel/linux/linux-qoriq-common.inc | 1 |
2 files changed, 137 insertions, 0 deletions
diff --git a/recipes-kernel/linux/files/net-sctp-CVE-2015-1421.patch b/recipes-kernel/linux/files/net-sctp-CVE-2015-1421.patch new file mode 100644 index 0000000..9b40705 --- /dev/null +++ b/recipes-kernel/linux/files/net-sctp-CVE-2015-1421.patch | |||
@@ -0,0 +1,136 @@ | |||
1 | Date: Thu, 22 Jan 2015 18:26:54 +0100 | ||
2 | Subject: net: sctp: fix slab corruption from use after free on INIT collisions | ||
3 | |||
4 | [ Upstream commit 600ddd6825543962fb807884169e57b580dba208 ] | ||
5 | |||
6 | When hitting an INIT collision case during the 4WHS with AUTH enabled, as | ||
7 | already described in detail in commit 1be9a950c646 ("net: sctp: inherit | ||
8 | auth_capable on INIT collisions"), it can happen that we occasionally | ||
9 | still remotely trigger the following panic on server side which seems to | ||
10 | have been uncovered after the fix from commit 1be9a950c646 ... | ||
11 | |||
12 | [ 533.876389] BUG: unable to handle kernel paging request at 00000000ffffffff | ||
13 | [ 533.913657] IP: [<ffffffff811ac385>] __kmalloc+0x95/0x230 | ||
14 | [ 533.940559] PGD 5030f2067 PUD 0 | ||
15 | [ 533.957104] Oops: 0000 [#1] SMP | ||
16 | [ 533.974283] Modules linked in: sctp mlx4_en [...] | ||
17 | [ 534.939704] Call Trace: | ||
18 | [ 534.951833] [<ffffffff81294e30>] ? crypto_init_shash_ops+0x60/0xf0 | ||
19 | [ 534.984213] [<ffffffff81294e30>] crypto_init_shash_ops+0x60/0xf0 | ||
20 | [ 535.015025] [<ffffffff8128c8ed>] __crypto_alloc_tfm+0x6d/0x170 | ||
21 | [ 535.045661] [<ffffffff8128d12c>] crypto_alloc_base+0x4c/0xb0 | ||
22 | [ 535.074593] [<ffffffff8160bd42>] ? _raw_spin_lock_bh+0x12/0x50 | ||
23 | [ 535.105239] [<ffffffffa0418c11>] sctp_inet_listen+0x161/0x1e0 [sctp] | ||
24 | [ 535.138606] [<ffffffff814e43bd>] SyS_listen+0x9d/0xb0 | ||
25 | [ 535.166848] [<ffffffff816149a9>] system_call_fastpath+0x16/0x1b | ||
26 | |||
27 | ... or depending on the the application, for example this one: | ||
28 | |||
29 | [ 1370.026490] BUG: unable to handle kernel paging request at 00000000ffffffff | ||
30 | [ 1370.026506] IP: [<ffffffff811ab455>] kmem_cache_alloc+0x75/0x1d0 | ||
31 | [ 1370.054568] PGD 633c94067 PUD 0 | ||
32 | [ 1370.070446] Oops: 0000 [#1] SMP | ||
33 | [ 1370.085010] Modules linked in: sctp kvm_amd kvm [...] | ||
34 | [ 1370.963431] Call Trace: | ||
35 | [ 1370.974632] [<ffffffff8120f7cf>] ? SyS_epoll_ctl+0x53f/0x960 | ||
36 | [ 1371.000863] [<ffffffff8120f7cf>] SyS_epoll_ctl+0x53f/0x960 | ||
37 | [ 1371.027154] [<ffffffff812100d3>] ? anon_inode_getfile+0xd3/0x170 | ||
38 | [ 1371.054679] [<ffffffff811e3d67>] ? __alloc_fd+0xa7/0x130 | ||
39 | [ 1371.080183] [<ffffffff816149a9>] system_call_fastpath+0x16/0x1b | ||
40 | |||
41 | With slab debugging enabled, we can see that the poison has been overwritten: | ||
42 | |||
43 | [ 669.826368] BUG kmalloc-128 (Tainted: G W ): Poison overwritten | ||
44 | [ 669.826385] INFO: 0xffff880228b32e50-0xffff880228b32e50. First byte 0x6a instead of 0x6b | ||
45 | [ 669.826414] INFO: Allocated in sctp_auth_create_key+0x23/0x50 [sctp] age=3 cpu=0 pid=18494 | ||
46 | [ 669.826424] __slab_alloc+0x4bf/0x566 | ||
47 | [ 669.826433] __kmalloc+0x280/0x310 | ||
48 | [ 669.826453] sctp_auth_create_key+0x23/0x50 [sctp] | ||
49 | [ 669.826471] sctp_auth_asoc_create_secret+0xcb/0x1e0 [sctp] | ||
50 | [ 669.826488] sctp_auth_asoc_init_active_key+0x68/0xa0 [sctp] | ||
51 | [ 669.826505] sctp_do_sm+0x29d/0x17c0 [sctp] [...] | ||
52 | [ 669.826629] INFO: Freed in kzfree+0x31/0x40 age=1 cpu=0 pid=18494 | ||
53 | [ 669.826635] __slab_free+0x39/0x2a8 | ||
54 | [ 669.826643] kfree+0x1d6/0x230 | ||
55 | [ 669.826650] kzfree+0x31/0x40 | ||
56 | [ 669.826666] sctp_auth_key_put+0x19/0x20 [sctp] | ||
57 | [ 669.826681] sctp_assoc_update+0x1ee/0x2d0 [sctp] | ||
58 | [ 669.826695] sctp_do_sm+0x674/0x17c0 [sctp] | ||
59 | |||
60 | Since this only triggers in some collision-cases with AUTH, the problem at | ||
61 | heart is that sctp_auth_key_put() on asoc->asoc_shared_key is called twice | ||
62 | when having refcnt 1, once directly in sctp_assoc_update() and yet again | ||
63 | from within sctp_auth_asoc_init_active_key() via sctp_assoc_update() on | ||
64 | the already kzfree'd memory, which is also consistent with the observation | ||
65 | of the poison decrease from 0x6b to 0x6a (note: the overwrite is detected | ||
66 | at a later point in time when poison is checked on new allocation). | ||
67 | |||
68 | Reference counting of auth keys revisited: | ||
69 | |||
70 | Shared keys for AUTH chunks are being stored in endpoints and associations | ||
71 | in endpoint_shared_keys list. On endpoint creation, a null key is being | ||
72 | added; on association creation, all endpoint shared keys are being cached | ||
73 | and thus cloned over to the association. struct sctp_shared_key only holds | ||
74 | a pointer to the actual key bytes, that is, struct sctp_auth_bytes which | ||
75 | keeps track of users internally through refcounting. Naturally, on assoc | ||
76 | or enpoint destruction, sctp_shared_key are being destroyed directly and | ||
77 | the reference on sctp_auth_bytes dropped. | ||
78 | |||
79 | User space can add keys to either list via setsockopt(2) through struct | ||
80 | sctp_authkey and by passing that to sctp_auth_set_key() which replaces or | ||
81 | adds a new auth key. There, sctp_auth_create_key() creates a new sctp_auth_bytes | ||
82 | with refcount 1 and in case of replacement drops the reference on the old | ||
83 | sctp_auth_bytes. A key can be set active from user space through setsockopt() | ||
84 | on the id via sctp_auth_set_active_key(), which iterates through either | ||
85 | endpoint_shared_keys and in case of an assoc, invokes (one of various places) | ||
86 | sctp_auth_asoc_init_active_key(). | ||
87 | |||
88 | sctp_auth_asoc_init_active_key() computes the actual secret from local's | ||
89 | and peer's random, hmac and shared key parameters and returns a new key | ||
90 | directly as sctp_auth_bytes, that is asoc->asoc_shared_key, plus drops | ||
91 | the reference if there was a previous one. The secret, which where we | ||
92 | eventually double drop the ref comes from sctp_auth_asoc_set_secret() with | ||
93 | intitial refcount of 1, which also stays unchanged eventually in | ||
94 | sctp_assoc_update(). This key is later being used for crypto layer to | ||
95 | set the key for the hash in crypto_hash_setkey() from sctp_auth_calculate_hmac(). | ||
96 | |||
97 | To close the loop: asoc->asoc_shared_key is freshly allocated secret | ||
98 | material and independant of the sctp_shared_key management keeping track | ||
99 | of only shared keys in endpoints and assocs. Hence, also commit 4184b2a79a76 | ||
100 | ("net: sctp: fix memory leak in auth key management") is independant of | ||
101 | this bug here since it concerns a different layer (though same structures | ||
102 | being used eventually). asoc->asoc_shared_key is reference dropped correctly | ||
103 | on assoc destruction in sctp_association_free() and when active keys are | ||
104 | being replaced in sctp_auth_asoc_init_active_key(), it always has a refcount | ||
105 | of 1. Hence, it's freed prematurely in sctp_assoc_update(). Simple fix is | ||
106 | to remove that sctp_auth_key_put() from there which fixes these panics. | ||
107 | |||
108 | Fixes CVE-2015-1421 | ||
109 | Upstream-Status: Backport | ||
110 | |||
111 | Fixes: 730fc3d05cd4 ("[SCTP]: Implete SCTP-AUTH parameter processing") | ||
112 | Signed-off-by: Daniel Borkmann <dborkman@redhat.com> | ||
113 | Acked-by: Vlad Yasevich <vyasevich@gmail.com> | ||
114 | Acked-by: Neil Horman <nhorman@tuxdriver.com> | ||
115 | Signed-off-by: David S. Miller <davem@davemloft.net> | ||
116 | Signed-off-by: Jiri Slaby <jslaby@suse.cz> | ||
117 | Signed-off-by: Sona Sarmadi <sona.sarmadi@enea.com> | ||
118 | --- | ||
119 | net/sctp/associola.c | 1 - | ||
120 | 1 file changed, 1 deletion(-) | ||
121 | |||
122 | diff --git a/net/sctp/associola.c b/net/sctp/associola.c | ||
123 | index 737050f..88ca530 100644 | ||
124 | --- a/net/sctp/associola.c | ||
125 | +++ b/net/sctp/associola.c | ||
126 | @@ -1282,7 +1282,6 @@ void sctp_assoc_update(struct sctp_association *asoc, | ||
127 | asoc->peer.peer_hmacs = new->peer.peer_hmacs; | ||
128 | new->peer.peer_hmacs = NULL; | ||
129 | |||
130 | - sctp_auth_key_put(asoc->asoc_shared_key); | ||
131 | sctp_auth_asoc_init_active_key(asoc, GFP_ATOMIC); | ||
132 | } | ||
133 | |||
134 | -- | ||
135 | cgit v0.11.2 | ||
136 | |||
diff --git a/recipes-kernel/linux/linux-qoriq-common.inc b/recipes-kernel/linux/linux-qoriq-common.inc index 5a5d7e9..978d7d8 100644 --- a/recipes-kernel/linux/linux-qoriq-common.inc +++ b/recipes-kernel/linux/linux-qoriq-common.inc | |||
@@ -6,6 +6,7 @@ SRC_URI += "file://b4860-hard_irq_disable-bug.patch \ | |||
6 | file://mm-CVE-2014-3122.patch \ | 6 | file://mm-CVE-2014-3122.patch \ |
7 | file://IB-uverbs-CVE-2014-8159.patch \ | 7 | file://IB-uverbs-CVE-2014-8159.patch \ |
8 | file://media-ttusb-dec-CVE-2014-8884.patch \ | 8 | file://media-ttusb-dec-CVE-2014-8884.patch \ |
9 | file://net-sctp-CVE-2015-1421.patch \ | ||
9 | " | 10 | " |
10 | 11 | ||
11 | SRC_URI += "file://cfg/00013-localversion.cfg \ | 12 | SRC_URI += "file://cfg/00013-localversion.cfg \ |