From patchwork Mon Aug 28 02:45:01 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Xin Long X-Patchwork-Id: 806349 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="E6Pue9mg"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3xgblC3jSGz9sP1 for ; Mon, 28 Aug 2017 12:47:03 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751829AbdH1CpL (ORCPT ); Sun, 27 Aug 2017 22:45:11 -0400 Received: from mail-pf0-f193.google.com ([209.85.192.193]:37125 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751768AbdH1CpK (ORCPT ); Sun, 27 Aug 2017 22:45:10 -0400 Received: by mail-pf0-f193.google.com with SMTP id r187so3205505pfr.4 for ; Sun, 27 Aug 2017 19:45:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=15y1FAaKQcreyF3FyjLrMy22GyyWJYa/41UoyuJpOYk=; b=E6Pue9mgdcAU1SKfH+Tn/LQJV5D1yT+98psNI1GBglmUEtyFV9+qbk0E0dCmBzCtZ3 UfqoAguOZ+Zule8o9mMwAwKYMpYL91xHDURZb8LlQTsPDgXuJWoxIlPWjLz+WecD7wo2 48yZmam/ui6dSVzA18mf5BS8nVPuG2ZaUmN31gq2eEDhp2BDKQ9ph91EA8cFFiVpes49 QdZ4T4JBux4Iuwja4kaRj8ytgCvRKkrAa9V+oCGOFEGSEp8X/TkL38Mw0Pxu31bRSt7R YhXOaFA43qGi7p+bj4IKV/ktQ5yqGhv8h7tiq53GKzgU/K5eCMcYEquoEz6TR3Yox+g8 mgzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=15y1FAaKQcreyF3FyjLrMy22GyyWJYa/41UoyuJpOYk=; b=PS3GJmQ7RDROQuz4P4bb19sQ8XzqewVkflI5hEVA00UWu7kdOn6quA6FYf5MHkNg6p 4g4DdOB3uy7ZccEj7q+9o1tM8u78xpVMnA2aW4glY9wBZtC80pFNZ+8mM1br+BdbyVZ/ MACQS3Z0AIs/QQsrob1eF0a9g46bih0HOkRqyATYh4QMTxN8PPbOipapTBBQcWMjFYsN 1xzTk5jzTjdd0RHA+Rk8T0v4hDDDgxMWhz9TmrcICG8n9fPdKU6wNrs+qJ3L1Kcz8PJQ IwFXRnFRaZi4BQuwZmIp0VqUktxVluCSQ0I/cAyjFjpUV6MmBdU306BxGvUUYuM5cS6o 59aw== X-Gm-Message-State: AHYfb5har+fwxWFDEaAE2B+MJ5HDJnW5ERhPhPcRYQJisEH6gC3e3ugW nqd6HEh7Ta1G4llaZSc= X-Received: by 10.84.167.2 with SMTP id c2mr6836588plb.365.1503888309746; Sun, 27 Aug 2017 19:45:09 -0700 (PDT) Received: from localhost ([209.132.188.80]) by smtp.gmail.com with ESMTPSA id r2sm20300431pfk.180.2017.08.27.19.45.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 27 Aug 2017 19:45:09 -0700 (PDT) From: Xin Long To: network dev Cc: davem@davemloft.net, pabeni@redhat.com, chunwang@redhat.com, syzkaller@googlegroups.com Subject: [PATCH net] ipv6: do not set sk_destruct in IPV6_ADDRFORM sockopt Date: Mon, 28 Aug 2017 10:45:01 +0800 Message-Id: <4cfe77b4a829c0d6134b842fe2ea7c41b6b210ff.1503888301.git.lucien.xin@gmail.com> X-Mailer: git-send-email 2.1.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org ChunYu found a kernel warn_on during syzkaller fuzzing: [40226.038539] WARNING: CPU: 5 PID: 23720 at net/ipv4/af_inet.c:152 inet_sock_destruct+0x78d/0x9a0 [40226.144849] Call Trace: [40226.147590] [40226.149859] dump_stack+0xe2/0x186 [40226.176546] __warn+0x1a4/0x1e0 [40226.180066] warn_slowpath_null+0x31/0x40 [40226.184555] inet_sock_destruct+0x78d/0x9a0 [40226.246355] __sk_destruct+0xfa/0x8c0 [40226.290612] rcu_process_callbacks+0xaa0/0x18a0 [40226.336816] __do_softirq+0x241/0x75e [40226.367758] irq_exit+0x1f6/0x220 [40226.371458] smp_apic_timer_interrupt+0x7b/0xa0 [40226.376507] apic_timer_interrupt+0x93/0xa0 The warn_on happned when sk->sk_rmem_alloc wasn't 0 in inet_sock_destruct. As after commit f970bd9e3a06 ("udp: implement memory accounting helpers"), udp has changed to use udp_destruct_sock as sk_destruct where it would udp_rmem_release all rmem. But IPV6_ADDRFORM sockopt sets sk_destruct with inet_sock_destruct after changing family to PF_INET. If rmem is not 0 at that time, and there is no place to release rmem before calling inet_sock_destruct, the warn_on will be triggered. This patch is to fix it by not setting sk_destruct in IPV6_ADDRFORM sockopt any more. As IPV6_ADDRFORM sockopt only works for tcp and udp. TCP sock has already set it's sk_destruct with inet_sock_destruct and UDP has set with udp_destruct_sock since they're created. Fixes: f970bd9e3a06 ("udp: implement memory accounting helpers") Reported-by: ChunYu Wang Signed-off-by: Xin Long Acked-by: Paolo Abeni --- net/ipv6/ipv6_sockglue.c | 1 - 1 file changed, 1 deletion(-) diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c index 02d795f..a5e466d 100644 --- a/net/ipv6/ipv6_sockglue.c +++ b/net/ipv6/ipv6_sockglue.c @@ -242,7 +242,6 @@ static int do_ipv6_setsockopt(struct sock *sk, int level, int optname, pktopt = xchg(&np->pktoptions, NULL); kfree_skb(pktopt); - sk->sk_destruct = inet_sock_destruct; /* * ... and add it to the refcnt debug socks count * in the new family. -acme