Received: by 10.192.165.148 with SMTP id m20csp211413imm; Fri, 20 Apr 2018 05:41:14 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/leXoDgR0N9ocuqtNLGlsHSV5Ihfgx09Z5es9jwRraKU5qQDhVAP+JMkd+dsz6aZsXKvXO X-Received: by 10.99.104.9 with SMTP id d9mr8484710pgc.304.1524228074845; Fri, 20 Apr 2018 05:41:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524228074; cv=none; d=google.com; s=arc-20160816; b=nzoKkn5/2G9LoZWsnEqfZqUfBqeAA1dRK71/Qb6CdkshjY5FE7LrC9oM7iLz98mSrG VQABblZcZcBO4bZnx6M1VduiuL7N1Jfu7QqoewgHK6rQrdQh24CkPs7ZgMkL/tVhslj7 tySOHJLjE4WWPmzuSI4Y0M3zowq66MfAttNct1fGFKcp3INc99CFjm/Qw7PmTnaep4iP Fbi/pD93BQvxwXkbQ5qql4N8pnOyEM2GTnBTWjTL8hbMs+VjB7LJ++TsPqsETo2NHaJT ostlnXINCYvoVgpMtNugoLzbVNW6lqcR7x60+yGOl4BfgUlCC/BGFE0nF6VLIo4v+UJM BAGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:date:cc:to:from:subject :message-id:arc-authentication-results; bh=JhNUrwBr8Rogit4+fe84DES3yDgjcOoeVBkESolM9WU=; b=cUH8dLODFrZ9LoMYIRfqftulZxtcz6/06YLFdorINAwc5ZzTe3gCRfZNbQf72vTEiY +CNTHTgV1+zg5KuKgKZFWAX/Z4nqnQbqO9h2tcEe87x9dHeQcourfzxNwRCL172muGCB WQTxYaAIgy8uqzSkuIPO3ng2lzYSD7+LWhD6XUyxJkkwVnTVz4Yi6aQotwanGAXMzIPK xlCNkLCSeoD8UTY022mTURudV/6dwW2/fMCe6wa5IVc3j3lUJw+URNZqeNdW3kEShMgb ra7PP0pkZVf2FVx8AoA4DMUkP8qXJiHVTsecPzjRNjdJaJg6x6i/WFjMOw0MT+uMG1Yu FdtQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id bh1-v6si5258227plb.246.2018.04.20.05.41.00; Fri, 20 Apr 2018 05:41:14 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754844AbeDTMjv (ORCPT + 99 others); Fri, 20 Apr 2018 08:39:51 -0400 Received: from mga06.intel.com ([134.134.136.31]:38882 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754591AbeDTMju (ORCPT ); Fri, 20 Apr 2018 08:39:50 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Apr 2018 05:39:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,301,1520924400"; d="scan'208";a="35130742" Received: from smile.fi.intel.com (HELO smile) ([10.237.72.86]) by orsmga008.jf.intel.com with ESMTP; 20 Apr 2018 05:39:46 -0700 Message-ID: <1524227986.21176.467.camel@linux.intel.com> Subject: Re: [RESEND][PATCH 2/4] NFC: st21nfca: Fix memory OOB and leak issues in connectivity events handler From: Andy Shevchenko To: Amit Pundir , lkml , linux-wireless@vger.kernel.org Cc: Samuel Ortiz , Christophe Ricard , Greg KH , John Stultz , Dmitry Shmidt , Todd Kjos , Android Kernel Team , Suren Baghdasaryan Date: Fri, 20 Apr 2018 15:39:46 +0300 In-Reply-To: <1524045904-7005-3-git-send-email-amit.pundir@linaro.org> References: <1524045904-7005-1-git-send-email-amit.pundir@linaro.org> <1524045904-7005-3-git-send-email-amit.pundir@linaro.org> Organization: Intel Finland Oy Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.5-1+b1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2018-04-18 at 15:35 +0530, Amit Pundir wrote: > if (skb->data[transaction->aid_len + 2] != > - NFC_EVT_TRANSACTION_PARAMS_TAG) > + NFC_EVT_TRANSACTION_PARAMS_TAG || > + skb->len < transaction->aid_len + transaction- > >params_len + 4) { > + devm_kfree(dev, transaction); Oh, no. This is not memory leak per se, this is bad choice of devm_ API where it should use plain kmalloc() / kfree(). > return -EPROTO; > + } -- Andy Shevchenko Intel Finland Oy