[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20200418.131830.1251168077969815139.davem@davemloft.net>
Date: Sat, 18 Apr 2020 13:18:30 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: xiyuyang19@...an.edu.cn
Cc: jmaloy@...hat.com, ying.xue@...driver.com, kuba@...nel.org,
netdev@...r.kernel.org, tipc-discussion@...ts.sourceforge.net,
linux-kernel@...r.kernel.org, yuanxzhang@...an.edu.cn,
kjlu@....edu, tanxin.ctf@...il.com
Subject: Re: [PATCH] tipc: Fix potential tipc_aead refcnt leak in
tipc_crypto_rcv
From: Xiyu Yang <xiyuyang19@...an.edu.cn>
Date: Wed, 15 Apr 2020 16:39:56 +0800
> tipc_crypto_rcv() invokes tipc_aead_get(), which returns a reference of
> the tipc_aead object to "aead" with increased refcnt.
>
> When tipc_crypto_rcv() returns, the original local reference of "aead"
> becomes invalid, so the refcount should be decreased to keep refcount
> balanced.
>
> The issue happens in one error path of tipc_crypto_rcv(). When TIPC
> message decryption status is EINPROGRESS or EBUSY, the function forgets
> to decrease the refcnt increased by tipc_aead_get() and causes a refcnt
> leak.
>
> Fix this issue by calling tipc_aead_put() on the error path when TIPC
> message decryption status is EINPROGRESS or EBUSY.
>
> Signed-off-by: Xiyu Yang <xiyuyang19@...an.edu.cn>
> Signed-off-by: Xin Tan <tanxin.ctf@...il.com>
Applied and queued up for -stable.
This code is harder to audit than it needs to be due to the special
casing of things like -ENOKEY etc. It should rather explicitly handle
the NULL test on aead in this top-level piece of code, which would
make the validation of aead reference counting much more explicit and
clear.
Powered by blists - more mailing lists