Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965083AbbLSUuS (ORCPT ); Sat, 19 Dec 2015 15:50:18 -0500 Received: from mail-yk0-f180.google.com ([209.85.160.180]:35169 "EHLO mail-yk0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753491AbbLSUuP (ORCPT ); Sat, 19 Dec 2015 15:50:15 -0500 MIME-Version: 1.0 In-Reply-To: <5674AF3B.6030903@oracle.com> References: <5674AF3B.6030903@oracle.com> Date: Sat, 19 Dec 2015 12:50:14 -0800 Message-ID: Subject: Re: net, ipv6: out of bounds access in secret_stable From: Cong Wang To: Sasha Levin Cc: Hannes Frederic Sowa , "David S. Miller" , LKML , "netdev@vger.kernel.org" Content-Type: multipart/mixed; boundary=001a1149298c21c57405274667d5 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3328 Lines: 63 --001a1149298c21c57405274667d5 Content-Type: text/plain; charset=UTF-8 On Fri, Dec 18, 2015 at 5:13 PM, Sasha Levin wrote: > Hi Hannes, > > I've hit the following out of bounds access while fuzzing on the latest -next kernel. > > This code was added in 3d1bec9932 ("ipv6: introduce secret_stable to ipv6_devconf"). > > [ 459.553655] BUG: KASAN: stack-out-of-bounds in strlen+0x58/0x90 at addr ffff8802ab0efb0e > [ 459.554953] Read of size 1 by task trinity-c91/22576 > [ 459.555805] page:ffffea000aac3bc0 count:0 mapcount:0 mapping: (null) index:0x0 > [ 459.556899] flags: 0x26fffff80000000() > [ 459.557521] page dumped because: kasan: bad access detected > [ 459.558320] CPU: 7 PID: 22576 Comm: trinity-c91 Not tainted 4.4.0-rc5-next-20151218-sasha-00021-gaba8d84-dirty #2750 > [ 459.559809] 0000000000000000 00000000549d0aa3 ffff8802ab0ef860 ffffffffa1042384 > [ 459.561036] 0000000041b58ab3 ffffffffac667cdb ffffffffa10422d9 ffff8802ab0ef848 > [ 459.562245] ffffffff9f6a417e 00000000549d0aa3 ffff8802ab0efb0e ffff8802ab0efb0e > [ 459.563429] Call Trace: > [ 459.563831] dump_stack (lib/dump_stack.c:52) > [ 459.564623] ? _atomic_dec_and_lock (lib/dump_stack.c:27) > [ 459.565628] ? __dump_page (mm/debug.c:126) > [ 459.566538] kasan_report_error (include/linux/kasan.h:28 mm/kasan/report.c:170 mm/kasan/report.c:237) > [ 459.570997] __asan_report_load1_noabort (mm/kasan/report.c:277) > [ 459.572119] ? check_preemption_disabled (lib/smp_processor_id.c:39) > [ 459.573731] ? strlen (lib/string.c:481 (discriminator 1)) > [ 459.574646] strlen (lib/string.c:481 (discriminator 1)) > [ 459.575485] proc_dostring (kernel/sysctl.c:1825 kernel/sysctl.c:1906) > [ 459.576445] ? alloc_debug_processing (mm/slub.c:1054) > [ 459.577523] addrconf_sysctl_stable_secret (net/ipv6/addrconf.c:5395) Looks like we don't initialize the array on stack for write case. At least other callers always initialize the data for both read and write. Please try the attached patch. Thanks! --001a1149298c21c57405274667d5 Content-Type: text/plain; charset=US-ASCII; name="tmp.diff" Content-Disposition: attachment; filename="tmp.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_iidkwnrf0 ZGlmZiAtLWdpdCBhL25ldC9pcHY2L2FkZHJjb25mLmMgYi9uZXQvaXB2Ni9hZGRyY29uZi5jCmlu ZGV4IDE3ZjhlN2UuLjhkNGZhN2MgMTAwNjQ0Ci0tLSBhL25ldC9pcHY2L2FkZHJjb25mLmMKKysr IGIvbmV0L2lwdjYvYWRkcmNvbmYuYwpAQCAtNTM2OSwxMyArNTM2OSwxMSBAQCBzdGF0aWMgaW50 IGFkZHJjb25mX3N5c2N0bF9zdGFibGVfc2VjcmV0KHN0cnVjdCBjdGxfdGFibGUgKmN0bCwgaW50 IHdyaXRlLAogCQlnb3RvIG91dDsKIAl9CiAKLQlpZiAoIXdyaXRlKSB7Ci0JCWVyciA9IHNucHJp bnRmKHN0ciwgc2l6ZW9mKHN0ciksICIlcEk2IiwKLQkJCSAgICAgICAmc2VjcmV0LT5zZWNyZXQp OwotCQlpZiAoZXJyID49IHNpemVvZihzdHIpKSB7Ci0JCQllcnIgPSAtRUlPOwotCQkJZ290byBv dXQ7Ci0JCX0KKwllcnIgPSBzbnByaW50ZihzdHIsIHNpemVvZihzdHIpLCAiJXBJNiIsCisJCSAg ICAgICAmc2VjcmV0LT5zZWNyZXQpOworCWlmIChlcnIgPj0gc2l6ZW9mKHN0cikpIHsKKwkJZXJy ID0gLUVJTzsKKwkJZ290byBvdXQ7CiAJfQogCiAJZXJyID0gcHJvY19kb3N0cmluZygmbGN0bCwg d3JpdGUsIGJ1ZmZlciwgbGVucCwgcHBvcyk7Cg== --001a1149298c21c57405274667d5-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/