Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp207457ybg; Sun, 26 Jul 2020 01:57:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwf0CEF+TuqDSdzYJuimZpSZGmOo1EusGo7e+9WPU2boLAjxHx0W9Ay0EqE523LVkHWol2K X-Received: by 2002:a17:906:9147:: with SMTP id y7mr15380957ejw.399.1595753878758; Sun, 26 Jul 2020 01:57:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595753878; cv=none; d=google.com; s=arc-20160816; b=o6jsXjdxItAKl08D3pw6psGFxf2WM7CK1Ii8Pv8mK4d1bFTL7HgQ1wkmEH6VGl2I7x ZCkemeuYR07RN+te+c+k4cPPbWeqnuxAPb7uO9Uuvh5TlGLYh5wjEsRTO6wBbO+O97iY QkkQ/1xOJgmOK90/pv/81sGhTFlliT6E3vyoDwr47TN0CStk5tsbQrkxI+I5mN4hcoUk lgt4HknvyCOd7w68C3QsiZdIINLdpcTt8dWkLBRDf0fu61x4pgXZBykwGljNXDhetoTB l513AzyNnAIfJzB2hoWthN44Km3m7khjDomvIAwHicwNds3RYI9qiHmcAZ9ceUI3xEDU nQUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=BiHp5LUc9PuHCot82qcRCOL9br0dFdzgknx8tkEtCyo=; b=sBOEtuXRoDk6SIw3jEkYnpWL5BSGdDyjE1Ipwi7bOH+2fG5UaGw6qnkF0lQIXtKckt dboOfhvwF7fqZb6IJb14yX677v0vER2ujCb1YY5SIXQj5zkexr3Q7Rj9cZN+D+SM2EeE E7GQdzo3kjRAqsPmg4OULarzf544PPsy+YznSivS5vnB43IyJyzZJN0dRq03Nn0a7n2r H32zWxTBuxGQfCxRHGaI9SZQtUE8/9jF0+kUOlWrF4lY459QHTYGbEimlHtxSEduBFth br98DMW/fAGFTo2fbMIIS5orjNQfdrHZIaFedYW2XRpuHyRfcB542pNjx5+dpOhQ+U/2 GtJQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=AzC6Rkjl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g13si3613302ejr.215.2020.07.26.01.57.19; Sun, 26 Jul 2020 01:57:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=AzC6Rkjl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725960AbgGZI4H (ORCPT + 99 others); Sun, 26 Jul 2020 04:56:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47238 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725794AbgGZI4G (ORCPT ); Sun, 26 Jul 2020 04:56:06 -0400 Received: from mail-pf1-x444.google.com (mail-pf1-x444.google.com [IPv6:2607:f8b0:4864:20::444]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 85D1EC0619D2 for ; Sun, 26 Jul 2020 01:56:05 -0700 (PDT) Received: by mail-pf1-x444.google.com with SMTP id 1so7488863pfn.9 for ; Sun, 26 Jul 2020 01:56:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BiHp5LUc9PuHCot82qcRCOL9br0dFdzgknx8tkEtCyo=; b=AzC6RkjlolNsWZXQ1jzEnFUYelHlzN9vaw4Mo7YjLgPC7C4QvAkSMSvgUsyqrFC5xV cx6O9RKDTsKrQusl0BYJm841lANFn8nUizwXv5tLilClZTJdfmxsqm1eYVx4hsKcZhD8 mVf5iPIjvaN5Ml95jYWPGMff0z9LaohLAolIAJZ3jDJhkL6WQIxTLV/lwaGCOvi30BKT ArBZ70amdW4zSqa9mFp5rAqePmoQSqL7yHQoDb9EBJIkVWgGBB3ttB+ixNrQglmtngCz i3/mDjTRyBmEMqiPDquucRPL86ZpNncPo58YnGKdnYMU5T1z/pCkrvsScdOIed7LIwmp B27Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BiHp5LUc9PuHCot82qcRCOL9br0dFdzgknx8tkEtCyo=; b=fuwudOjTMNxRQ4+S6/Ubjs7M7vszqlFU2y1g7I2KHpiqD8IrLd5MuaztCJYCF5s8Xw x4zypcNDALpy4fORJuwnUR4dmc5nNW60QA3eBUoY2UGfFv1io1ilzBflkecxZr2Js93I R0c8IkKiryxTL1C26SdG9lttSGMA5JelxE85oaurhugHFVlkmI+rdmn+ZvIOfUH0SxHF DYCU55/IrjKt7dDrqCHOi9rtVXYkhqnFu+02xbK8kaGTTXfsYMxzzN3rtNColjO6wwJ8 A6ZZjFeVoLhF/YkKbnjp1D19kyvNyXi+3aRoMll3xTvjwqU2dx64nLH5mABwCIsHmZeb EhLg== X-Gm-Message-State: AOAM532BxrWO9EAzh/mjrzQSFLpJjG4Yac8moN3DKixJTMy3bPz7YDbk 4I1DDjo51ObJgAJ/fIrgapxzaaQ/fBOmyU8ZH6Q= X-Received: by 2002:a63:a05f:: with SMTP id u31mr14817755pgn.4.1595753764903; Sun, 26 Jul 2020 01:56:04 -0700 (PDT) MIME-Version: 1.0 References: <20200726052804.GA51199@xin-virtual-machine> In-Reply-To: <20200726052804.GA51199@xin-virtual-machine> From: Andy Shevchenko Date: Sun, 26 Jul 2020 11:55:48 +0300 Message-ID: Subject: Re: [PATCH] tty: fix pid refcount leak in tty_signal_session_leader To: Xin Xiong Cc: Greg Kroah-Hartman , Jiri Slaby , Linux Kernel Mailing List , Xiyu Yang , Xin Tan , yuanxzhang@fudan.edu.cn Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jul 26, 2020 at 8:30 AM Xin Xiong wrote: > > In the loop, every time when p->signal->leader is true, the function > tty_signal_session_leader() will invoke get_pid() and return a > reference of tty->pgrp with increased refcount to the local variable > tty_pgrp or return NULL if it fails. After finishing the loop, the > function invokes put_pid() for only once, decreasing the refcount that > tty_pgrp keeps. > > Refcount leaks may occur when the scenario that p->signal->leader is > true happens more than once. In this assumption, if the above scenario > happens n times in the loop, the function forgets to decrease the > refcount for n-1 times, which causes refcount leaks. > > Fix the issue by decreasing the current refcount of the local variable > tty_pgrp before assigning new objects to it. > > Signed-off-by: Xiyu Yang > Signed-off-by: Xin Tan > Signed-off-by: Xin Xiong This SoB chain is out of order. If you are the author, your SoB should go first, if you are a commiter, the From line should correspond to the first SoB (not yours), if it's a group of authors (funny for one-/twoliner) then you consider to use Co-developed-by. Please, read Submitting Patches document. ... > put_pid(p->signal->tty_old_pgrp); /* A noop */ > spin_lock(&tty->ctrl_lock); > + if (tty_pgrp) > + put_pid(tty_pgrp); > tty_pgrp = get_pid(tty->pgrp); > if (tty->pgrp) > p->signal->tty_old_pgrp = get_pid(tty->pgrp); I guess this patch wasn't thought thru. You see the get_pid for it happens twice in a row. Perhaps you have to get the logic behind all these first? P.S. ...on top of what Greg said. -- With Best Regards, Andy Shevchenko