public inbox for gfs2@lists.linux.dev
 help / color / mirror / Atom feed
From: Clayton Casciato <majortomtosourcecontrol@gmail.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: rpeterso@redhat.com, agruenba@redhat.com, stable@vger.kernel.org,
	gfs2@lists.linux.dev
Subject: Re: [PATCH 6.1.96] gfs2: Fix slab-use-after-free in gfs2_qd_dealloc
Date: Mon, 1 Jul 2024 15:30:54 -0600	[thread overview]
Message-ID: <1c68b9b2-24b9-4bbb-852f-cbc5c267443b@gmail.com> (raw)
In-Reply-To: <2024062953-problem-truth-ce3c@gregkh>

On 6/29/24 2:10 AM, Greg KH wrote:
> On Fri, Jun 28, 2024 at 12:07:52PM -0600, Clayton Casciato wrote:
>> [ Upstream commit bdcb8aa434c6d36b5c215d02a9ef07551be25a37 ]
>>
>> In gfs2_put_super(), whether withdrawn or not, the quota should
>> be cleaned up by gfs2_quota_cleanup().
>>
>> Otherwise, struct gfs2_sbd will be freed before gfs2_qd_dealloc (rcu
>> callback) has run for all gfs2_quota_data objects, resulting in
>> use-after-free.
>>
>> Also, gfs2_destroy_threads() and gfs2_quota_cleanup() is already called
>> by gfs2_make_fs_ro(), so in gfs2_put_super(), after calling
>> gfs2_make_fs_ro(), there is no need to call them again.
>>
>> The origin of a cherry-pick conflict is the (relevant) code block added in
>> commit f66af88e3321 ("gfs2: Stop using gfs2_make_fs_ro for withdraw")
>>
>> There are no references to gfs2_withdrawn() nor gfs2_destroy_threads() in
>> gfs2_put_super(), so we can simply call gfs2_quota_cleanup() in a new else
>> block as bdcb8aa434c6 achieves.
>>
>> Else braces were used for consistency with the if block.
>>
>> Sponsor: 21SoftWare LLC
> 
> That's not a valid tag for kernel commits, sorry.
> 

The documentation mentions "some people also put extra tags at the end.
They’ll just be ignored for now [...]"

I don't imagine this would be appropriate on a line *after* the sign-off?

>> Signed-off-by: Clayton Casciato <majortomtosourcecontrol@gmail.com>
> 
> What happened to the original authorship information, and all of the
> other signed-off-by that were on the original commit?  YOu can not just
> delete them, would you want someone doing that to a patch you
> contributed?
> 

I didn't understand this and was concerned along the lines of "it is very
impolite to change one submitter’s code and make him endorse your bugs"

> as-is, we can't take this, please fix up.

I've submitted v2

> 
> thanks,
> 
> greg k-h

Thank you for the feedback!

Clayton Casciato

           reply	other threads:[~2024-07-01 21:30 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <2024062953-problem-truth-ce3c@gregkh>]

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=1c68b9b2-24b9-4bbb-852f-cbc5c267443b@gmail.com \
    --to=majortomtosourcecontrol@gmail.com \
    --cc=agruenba@redhat.com \
    --cc=gfs2@lists.linux.dev \
    --cc=gregkh@linuxfoundation.org \
    --cc=rpeterso@redhat.com \
    --cc=stable@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox