All of lore.kernel.org
 help / color / mirror / Atom feed
From: asmadeus@codewreck.org
To: Christian Schoenebeck <linux_oss@crudebyte.com>
Cc: Leon Romanovsky <leon@kernel.org>,
	syzbot <syzbot+67d13108d855f451cafc@syzkaller.appspotmail.com>,
	davem@davemloft.net, edumazet@google.com, ericvh@gmail.com,
	kuba@kernel.org, linux-kernel@vger.kernel.org, lucho@ionkov.net,
	netdev@vger.kernel.org, pabeni@redhat.com,
	syzkaller-bugs@googlegroups.com,
	v9fs-developer@lists.sourceforge.net
Subject: Re: [syzbot] KASAN: use-after-free Read in rdma_close
Date: Thu, 29 Sep 2022 06:52:56 +0900	[thread overview]
Message-ID: <YzTCOGCo5mIxwf9S@codewreck.org> (raw)
In-Reply-To: <1783490.kFEjeSjHVE@silver>

Christian Schoenebeck wrote on Wed, Sep 28, 2022 at 02:57:07PM +0200:
> OK, maybe it's just me, but ask yourself Leon, if you were the only guy left 
> (i.e. Dominique) still actively taking care for 9p, would those exactly be 
> motivating phrases for your efforts? Just saying.

I didn't plan on replying (happy to disagree), but I'm actually grateful
for Leon to have taken the time to look here: Thank you!
While I probably would also have spotted the error (the change is
fresh), it saved me time even if you account for some bikeshedding.

(Not particularly happy with the amount of time I can allocate to 9p nor
the maintainance work I'm doing by the way, but I guess it's better than
leaving it completely unmaintained)

> From technical perspective, yes, destruction in reverse order is usually the 
> better way to go. Whether I would carve that in stone, without any exception, 
> probably not.

I think it's a tradeoff really.
Unrolling in place is great, don't get me wrong, but it's also easy to
miss things when adding code later on -- we actually just did that and
got another kasan report which made me factor things in to future-proof
the code.

Having a single place of truth that knows how to "untangle" and properly
free a struct, making sure it is noop for parts of the struct that
haven't been initialized yet, is less of a burden for me to think about.


... Just happened to be wrong about the "making sure it's noop" part
because I didn't check properly and my mental model had close functions
noop on NULL clnt->priv, like free functions...
(Uh, actually it is for RDMA, so the "problem" was that it left
clnt->trans set after later errors -- but conversely virtio's close
doesn't check so also had the problem and we really must ensure we don't
close something not open)

Anyway, I've sent a couple of patch (even fixing up the order to match
in create/destroy), I'll consider this closed.

-- 
Dominique

  reply	other threads:[~2022-09-28 21:54 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-25 11:29 [syzbot] KASAN: use-after-free Read in rdma_close syzbot
2022-09-28 10:07 ` Leon Romanovsky
2022-09-28 10:43   ` asmadeus
2022-09-28 10:49     ` Leon Romanovsky
2022-09-28 11:23       ` asmadeus
2022-09-28 11:54         ` Leon Romanovsky
2022-09-28 12:57           ` Christian Schoenebeck
2022-09-28 21:52             ` asmadeus [this message]
2022-09-29  6:10               ` Leon Romanovsky
2022-09-28 21:44   ` [PATCH 1/2] 9p: client_create/destroy: only call trans_mod->close after create Dominique Martinet
2022-09-28 21:44     ` [PATCH 2/2] 9p: client_create: init fcall_cache earlier Dominique Martinet
2022-09-29  5:57       ` Leon Romanovsky
2022-09-29  7:03         ` Dominique Martinet
2022-09-28 21:58     ` [PATCH 1/2 v2] 9p: client_create/destroy: only call trans_mod->close after create Dominique Martinet
2022-09-28 22:19       ` [PATCH v3] " Dominique Martinet
2022-09-29  5:54         ` Leon Romanovsky
2022-09-29  7:24           ` Dominique Martinet
2022-12-30 10:34 ` [syzbot] KASAN: use-after-free Read in rdma_close syzbot
2023-01-13 10:35 ` syzbot
2023-01-27 10:36 ` syzbot
2023-02-10 10:36 ` syzbot
2023-02-24 10:37 ` syzbot
2023-03-10 10:38 ` syzbot
2023-03-24 10:38 ` syzbot
2023-04-07 10:38 ` syzbot
2023-04-21 10:39 ` syzbot
2023-05-05 10:40 ` syzbot
2023-05-19 10:40 ` syzbot
2023-06-02 10:42 ` syzbot
2023-06-02 10:57   ` Aleksandr Nogikh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YzTCOGCo5mIxwf9S@codewreck.org \
    --to=asmadeus@codewreck.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=ericvh@gmail.com \
    --cc=kuba@kernel.org \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux_oss@crudebyte.com \
    --cc=lucho@ionkov.net \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=syzbot+67d13108d855f451cafc@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=v9fs-developer@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.