Issue metadata
Sign in to add a comment
|
CVE-2017-12193 CrOS: Vulnerability reported in Linux kernel |
||||||||||||||||||||||
Issue descriptionVOMIT (go/vomit) has received an external vulnerability report for the Linux kernel. Advisory: CVE-2017-12193 Details: http://vomit.googleplex.com/advisory?id=CVE/CVE-2017-12193 CVSS severity score: 4.9/10.0 Description: The assoc_array_insert_into_terminal_node function in lib/assoc_array.c in the Linux kernel before 4.13.11 mishandles node splitting, which allows local users to cause a denial of service (NULL pointer dereference and panic) via a crafted application, as demonstrated by the keyring key type, and key addition and link creation operations. This bug was filed by http://go/vomit Please contact us at vomit-team@google.com if you need any assistance.
,
Dec 13 2017
,
Dec 13 2017
Will fix in chromeos-3.18 and chromeos-3.14. WontFix in older kernels due to conflicts.
,
Dec 18 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/a2ad7a671e35299aeccb7b92119655c039574ee3 commit a2ad7a671e35299aeccb7b92119655c039574ee3 Author: David Howells <dhowells@redhat.com> Date: Mon Dec 18 23:01:42 2017 UPSTREAM: assoc_array: Fix a buggy node-splitting case This fixes CVE-2017-12193. Fix a case in the assoc_array implementation in which a new leaf is added that needs to go into a node that happens to be full, where the existing leaves in that node cluster together at that level to the exclusion of new leaf. What needs to happen is that the existing leaves get moved out to a new node, N1, at level + 1 and the existing node needs replacing with one, N0, that has pointers to the new leaf and to N1. The code that tries to do this gets this wrong in two ways: (1) The pointer that should've pointed from N0 to N1 is set to point recursively to N0 instead. (2) The backpointer from N0 needs to be set correctly in the case N0 is either the root node or reached through a shortcut. Fix this by removing this path and using the split_node path instead, which achieves the same end, but in a more general way (thanks to Eric Biggers for spotting the redundancy). The problem manifests itself as: BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 IP: assoc_array_apply_edit+0x59/0xe5 BUG= chromium:794491 TEST=Build and run Change-Id: Ia54b17b16e4532cfacd23b689fde5a5214d2fe83 Fixes: 3cb989501c26 ("Add a generic associative array implementation.") Reported-and-tested-by: WU Fan <u3536072@connect.hku.hk> Signed-off-by: David Howells <dhowells@redhat.com> Cc: stable@vger.kernel.org [v3.13-rc1+] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit ea6789980fda) Reviewed-on: https://chromium-review.googlesource.com/825771 [modify] https://crrev.com/a2ad7a671e35299aeccb7b92119655c039574ee3/lib/assoc_array.c
,
Dec 18 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/0b2c65ee8c7b7cd754b147d83292c4a65ee8a84b commit 0b2c65ee8c7b7cd754b147d83292c4a65ee8a84b Author: David Howells <dhowells@redhat.com> Date: Mon Dec 18 23:01:38 2017 UPSTREAM: assoc_array: Fix a buggy node-splitting case This fixes CVE-2017-12193. Fix a case in the assoc_array implementation in which a new leaf is added that needs to go into a node that happens to be full, where the existing leaves in that node cluster together at that level to the exclusion of new leaf. What needs to happen is that the existing leaves get moved out to a new node, N1, at level + 1 and the existing node needs replacing with one, N0, that has pointers to the new leaf and to N1. The code that tries to do this gets this wrong in two ways: (1) The pointer that should've pointed from N0 to N1 is set to point recursively to N0 instead. (2) The backpointer from N0 needs to be set correctly in the case N0 is either the root node or reached through a shortcut. Fix this by removing this path and using the split_node path instead, which achieves the same end, but in a more general way (thanks to Eric Biggers for spotting the redundancy). The problem manifests itself as: BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 IP: assoc_array_apply_edit+0x59/0xe5 BUG= chromium:794491 TEST=Build and run Change-Id: Ia54b17b16e4532cfacd23b689fde5a5214d2fe83 Fixes: 3cb989501c26 ("Add a generic associative array implementation.") Reported-and-tested-by: WU Fan <u3536072@connect.hku.hk> Signed-off-by: David Howells <dhowells@redhat.com> Cc: stable@vger.kernel.org [v3.13-rc1+] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit ea6789980fda) Reviewed-on: https://chromium-review.googlesource.com/825770 [modify] https://crrev.com/0b2c65ee8c7b7cd754b147d83292c4a65ee8a84b/lib/assoc_array.c
,
Dec 18 2017
,
Dec 18 2017
This bug requires manual review: M64 has already been promoted to the beta branch, so this requires manual review Please contact the milestone owner if you have questions. Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 20 2017
,
Dec 20 2017
Approving merge to M64 Chrome OS.
,
Dec 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/75508d1c3d906462a3070a46a5d82961e87e4412 commit 75508d1c3d906462a3070a46a5d82961e87e4412 Author: David Howells <dhowells@redhat.com> Date: Wed Dec 20 23:20:43 2017 UPSTREAM: assoc_array: Fix a buggy node-splitting case This fixes CVE-2017-12193. Fix a case in the assoc_array implementation in which a new leaf is added that needs to go into a node that happens to be full, where the existing leaves in that node cluster together at that level to the exclusion of new leaf. What needs to happen is that the existing leaves get moved out to a new node, N1, at level + 1 and the existing node needs replacing with one, N0, that has pointers to the new leaf and to N1. The code that tries to do this gets this wrong in two ways: (1) The pointer that should've pointed from N0 to N1 is set to point recursively to N0 instead. (2) The backpointer from N0 needs to be set correctly in the case N0 is either the root node or reached through a shortcut. Fix this by removing this path and using the split_node path instead, which achieves the same end, but in a more general way (thanks to Eric Biggers for spotting the redundancy). The problem manifests itself as: BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 IP: assoc_array_apply_edit+0x59/0xe5 BUG= chromium:794491 TEST=Build and run Change-Id: Ia54b17b16e4532cfacd23b689fde5a5214d2fe83 Fixes: 3cb989501c26 ("Add a generic associative array implementation.") Reported-and-tested-by: WU Fan <u3536072@connect.hku.hk> Signed-off-by: David Howells <dhowells@redhat.com> Cc: stable@vger.kernel.org [v3.13-rc1+] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit ea6789980fda) Reviewed-on: https://chromium-review.googlesource.com/825776 [modify] https://crrev.com/75508d1c3d906462a3070a46a5d82961e87e4412/lib/assoc_array.c
,
Dec 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/8b4f7c643ebc222d7b5cb7d023ea4d540c156135 commit 8b4f7c643ebc222d7b5cb7d023ea4d540c156135 Author: David Howells <dhowells@redhat.com> Date: Wed Dec 20 23:20:55 2017 UPSTREAM: assoc_array: Fix a buggy node-splitting case This fixes CVE-2017-12193. Fix a case in the assoc_array implementation in which a new leaf is added that needs to go into a node that happens to be full, where the existing leaves in that node cluster together at that level to the exclusion of new leaf. What needs to happen is that the existing leaves get moved out to a new node, N1, at level + 1 and the existing node needs replacing with one, N0, that has pointers to the new leaf and to N1. The code that tries to do this gets this wrong in two ways: (1) The pointer that should've pointed from N0 to N1 is set to point recursively to N0 instead. (2) The backpointer from N0 needs to be set correctly in the case N0 is either the root node or reached through a shortcut. Fix this by removing this path and using the split_node path instead, which achieves the same end, but in a more general way (thanks to Eric Biggers for spotting the redundancy). The problem manifests itself as: BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 IP: assoc_array_apply_edit+0x59/0xe5 BUG= chromium:794491 TEST=Build and run Change-Id: Ia54b17b16e4532cfacd23b689fde5a5214d2fe83 Fixes: 3cb989501c26 ("Add a generic associative array implementation.") Reported-and-tested-by: WU Fan <u3536072@connect.hku.hk> Signed-off-by: David Howells <dhowells@redhat.com> Cc: stable@vger.kernel.org [v3.13-rc1+] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit ea6789980fda) Reviewed-on: https://chromium-review.googlesource.com/825772 [modify] https://crrev.com/8b4f7c643ebc222d7b5cb7d023ea4d540c156135/lib/assoc_array.c
,
Dec 20 2017
,
Dec 21 2017
,
Mar 27 2018
,
Mar 29 2018
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by groeck@chromium.org
, Dec 13 2017Labels: M-64 Security_Severity-Medium Security_Impact-Stable Pri-1
Owner: groeck@chromium.org
Status: Assigned (was: Untriaged)
Upstream commit ea6789980fda ("assoc_array: Fix a buggy node-splitting case"). Fixed in chromeos-4.4 (R64+) and chromeos-4.14. Needed in older kernels.