linux-kernel - RE: [PATCH v2] tipc: Don't using smp_processor

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AM6PR0502MB3925A724B302DE48876AED87E27E0@AM6PR0502MB3925.eurprd05.prod.outlook.com>
Date:   Wed, 15 Jul 2020 03:53:43 +0000
From:   Tuong Tong Lien <tuong.t.lien@...tech.com.au>
To:     "Zhang, Qiang" <Qiang.Zhang@...driver.com>,
        Eric Dumazet <eric.dumazet@...il.com>,
        "jmaloy@...hat.com" <jmaloy@...hat.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "Xue, Ying" <Ying.Xue@...driver.com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "tipc-discussion@...ts.sourceforge.net" 
        <tipc-discussion@...ts.sourceforge.net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2] tipc: Don't using smp_processor_id() in preemptible
 code



> -----Original Message-----
> From: Zhang, Qiang <Qiang.Zhang@...driver.com>
> Sent: Wednesday, July 15, 2020 9:13 AM
> To: Eric Dumazet <eric.dumazet@...il.com>; jmaloy@...hat.com; davem@...emloft.net; kuba@...nel.org; Tuong Tong Lien
> <tuong.t.lien@...tech.com.au>; Xue, Ying <Ying.Xue@...driver.com>
> Cc: netdev@...r.kernel.org; tipc-discussion@...ts.sourceforge.net; linux-kernel@...r.kernel.org
> Subject: 回复: [PATCH v2] tipc: Don't using smp_processor_id() in preemptible code
> 
> 
> 
> ________________________________________
> 发件人: Eric Dumazet <eric.dumazet@...il.com>
> 发送时间: 2020年7月14日 22:15
> 收件人: Zhang, Qiang; jmaloy@...hat.com; davem@...emloft.net; kuba@...nel.org; tuong.t.lien@...tech.com.au;
> eric.dumazet@...il.com; Xue, Ying
> 抄送: netdev@...r.kernel.org; tipc-discussion@...ts.sourceforge.net; linux-kernel@...r.kernel.org
> 主题: Re: [PATCH v2] tipc: Don't using smp_processor_id() in preemptible code
> 
> 
> 
> On 7/14/20 1:05 AM, qiang.zhang@...driver.com wrote:
> > From: Zhang Qiang <qiang.zhang@...driver.com>
> >
> > CPU: 0 PID: 6801 Comm: syz-executor201 Not tainted 5.8.0-rc4-syzkaller #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine,
> > BIOS Google 01/01/2011
> >
> > Fixes: fc1b6d6de2208 ("tipc: introduce TIPC encryption & authentication")
> > Reported-by: syzbot+263f8c0d007dc09b2dda@...kaller.appspotmail.com
> > Signed-off-by: Zhang Qiang <qiang.zhang@...driver.com>
> > ---
> >  v1->v2:
> >  add fixes tags.
> >
> >  net/tipc/crypto.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/tipc/crypto.c b/net/tipc/crypto.c
> > index 8c47ded2edb6..520af0afe1b3 100644
> > --- a/net/tipc/crypto.c
> > +++ b/net/tipc/crypto.c
> > @@ -399,9 +399,10 @@ static void tipc_aead_users_set(struct tipc_aead __rcu *aead, int val)
> >   */
> >  static struct crypto_aead *tipc_aead_tfm_next(struct tipc_aead *aead)
> >  {
> > -     struct tipc_tfm **tfm_entry = this_cpu_ptr(aead->tfm_entry);
> > +     struct tipc_tfm **tfm_entry = get_cpu_ptr(aead->tfm_entry);
> >
> >       *tfm_entry = list_next_entry(*tfm_entry, list);
> > +     put_cpu_ptr(tfm_entry);
> >       return (*tfm_entry)->tfm;
> >  }
> >
> >
> 
> > You have not explained why this was safe.
> >
> >  This seems to hide a real bug.
> >
> > Presumably callers of this function should have disable preemption, and maybe > interrupts as well.
> >
> >Right after put_cpu_ptr(tfm_entry), this thread could migrate to another cpu, >and still access
> >data owned by the old cpu.
> 
> Thanks for you suggest, I will check code again.
> 

Actually, last week I sent a similar patch to tipc-discussion which covers the
case as well (there is also another place causing the same issue...). If you
don't mind, you can take a look at below (just copied/pasted).

BR/Tuong

-----Original Message-----
From: Tuong Tong Lien <tuong.t.lien@...tech.com.au> 
Sent: Friday, July 10, 2020 5:11 PM
To: jmaloy@...hat.com; maloy@...jonn.com; ying.xue@...driver.com; tipc-discussion@...ts.sourceforge.net
Cc: tipc-dek <tipc-dek@...tech.com.au>
Subject: [PATCH RFC 1/5] tipc: fix using smp_processor_id() in preemptible

The 'this_cpu_ptr()' is used to obtain the AEAD key' TFM on the current
CPU for encryption, however the execution can be preemptible since it's
actually user-space context, so the 'using smp_processor_id() in
preemptible' has been observed.

We fix the issue by using the 'get/put_cpu_ptr()' API which consists of
a 'preempt_disable()' instead.

Signed-off-by: Tuong Lien <tuong.t.lien@...tech.com.au>
---
 net/tipc/crypto.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/net/tipc/crypto.c b/net/tipc/crypto.c
index c8c47fc72653..1827ce4fac5d 100644
--- a/net/tipc/crypto.c
+++ b/net/tipc/crypto.c
@@ -326,7 +326,8 @@ static void tipc_aead_free(struct rcu_head *rp)
 	if (aead->cloned) {
 		tipc_aead_put(aead->cloned);
 	} else {
-		head = *this_cpu_ptr(aead->tfm_entry);
+		head = *get_cpu_ptr(aead->tfm_entry);
+		put_cpu_ptr(aead->tfm_entry);
 		list_for_each_entry_safe(tfm_entry, tmp, &head->list, list) {
 			crypto_free_aead(tfm_entry->tfm);
 			list_del(&tfm_entry->list);
@@ -399,10 +400,15 @@ static void tipc_aead_users_set(struct tipc_aead __rcu *aead, int val)
  */
 static struct crypto_aead *tipc_aead_tfm_next(struct tipc_aead *aead)
 {
-	struct tipc_tfm **tfm_entry = this_cpu_ptr(aead->tfm_entry);
+	struct tipc_tfm **tfm_entry;
+	struct crypto_aead *tfm;
 
+	tfm_entry = get_cpu_ptr(aead->tfm_entry);
 	*tfm_entry = list_next_entry(*tfm_entry, list);
-	return (*tfm_entry)->tfm;
+	tfm = (*tfm_entry)->tfm;
+	put_cpu_ptr(tfm_entry);
+
+	return tfm;
 }
 
 /**
-- 
2.13.7