mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Viacheslav Dubeyko <slava@dubeyko.com>
To: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Cc: Aldo Ariel Panzardo <qwe.aldo@gmail.com>,
	linux-nilfs@vger.kernel.org,  linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH v2] nilfs2: validate segment number in nilfs_sufile_get_suinfo()
Date: Thu, 17 Sep 2026 12:35:53 -0700	[thread overview]
Message-ID: <ee4a4f8cb0cad602a520161f4c9cbb1beac81d58.camel@dubeyko.com> (raw)
In-Reply-To: <CAKFNMo=Lsaci5bY+G8A-C_FdD3Rhais4eANUdz8rHL7e-auHvw@mail.gmail.com>

On Fri, 2026-09-18 at 01:05 +0900, Ryusuke Konishi wrote:
> On Fri, Sep 18, 2026 at 12:46 AM Ryusuke Konishi  wrote:
> > 
> > On Thu, Sep 17, 2026 at 4:06 AM Viacheslav Dubeyko wrote:
> > > 
> > > On Tue, 2026-09-15 at 16:52 -0300, Aldo Ariel Panzardo wrote:
> > > > nilfs_sufile_get_suinfo() subtracts the caller-provided segment
> > > > number
> > > > from the total number of segments without first checking its
> > > > range.
> > > > If
> > > > the requested number is greater than the total, the unsigned
> > > > subtraction
> > > > wraps and the function may process segment numbers outside the
> > > > filesystem.
> > > > 
> > > > Cache the total while holding the metadata semaphore and return
> > > > no
> > > > entries
> > > > when the starting segment number is at or beyond the end.
> > > > 
> > > > Fixes: 6c98cd4ecb0a ("nilfs2: segment usage file")
> > > > Cc: stable@vger.kernel.org
> > > > Signed-off-by: Aldo Ariel Panzardo <qwe.aldo@gmail.com>
> > > > ---
> > > >  fs/nilfs2/sufile.c | 10 +++++++---
> > > >  1 file changed, 7 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/fs/nilfs2/sufile.c b/fs/nilfs2/sufile.c
> > > > index eceedca026..573646c5f7 100644
> > > > --- a/fs/nilfs2/sufile.c
> > > > +++ b/fs/nilfs2/sufile.c
> > > > @@ -870,10 +870,14 @@ ssize_t nilfs_sufile_get_suinfo(struct
> > > > inode
> > > > *sufile, __u64 segnum, void *buf,
> > > > 
> > > >       down_read(&NILFS_MDT(sufile)->mi_sem);
> > > > 
> > > > +     nsegs = nilfs_sufile_get_nsegments(sufile);
> > > > +     if (segnum >= nsegs) {
> > > > +             ret = 0;
> > > > +             goto out;
> > > > +     }
> > > > +
> > > >       segusages_per_block =
> > > > nilfs_sufile_segment_usages_per_block(sufile);
> > > > -     nsegs = min_t(unsigned long,
> > > > -                   nilfs_sufile_get_nsegments(sufile) -
> > > > segnum,
> > > > -                   nsi);
> > > > +     nsegs = min_t(unsigned long, nsegs - segnum, nsi);
> > > >       for (i = 0; i < nsegs; i += n, segnum += n) {
> > > >               n = min_t(unsigned long,
> > > >                         segusages_per_block -
> > > 
> > > Looks good to me.
> > > 
> > > Reviewed-by: Viacheslav Dubeyko <slava@dubeyko.com>
> > > 
> > > Thanks,
> > > Slava.
> > 
> > Acked-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
> > 
> > Hi Viacheslav,
> > 
> > Please take this directly.
> > 
> > I also agree that this change makes sense, and my local test
> > results
> > are as expected.
> > 
> > However, please drop the 'Cc: stable' tag since it does not cause
> > any
> > fatal issues at the moment.
> > If a real-world problem is found or reported, I think it would be
> > fine
> > to request a manual backport then.
> > 
> > While acquiring information on out-of-range segments due to
> > wrap-around is indeed possible, sufile is also a metadata
> > management
> > file.
> > When accessing out-of-range areas, it simply hits as a hole block
> > and
> > returns empty data.
> > 
> > Neither memory overrun in user space or kernel space, nor
> > out-of-bounds block device access or information leaks will occur.
> > 
> > Well-behaved userland tools read segment information based on the
> > statistics obtained via nilfs_get_sustat(), so no problem will
> > occur
> > (the difference in behavior was visually indistinguishable).
> > 
> > Therefore, I modified the nilfs-utils to perform ill-behaved calls
> > and
> > tested it.
> > Although out-of-range non-existent segments were displayed as empty
> > data, no critical issue that compromises kernel stability occurred.
> > 
> > At present, it does not appear to meet the basic criteria for
> > stable
> > backporting, so when backporting, we need to be able to organize
> > and
> > demonstrate the reasoning why it is necessary.
> > 
> > Thanks,
> > Ryusuke Konishi
> 
> Hi Viacheslav,
> 
> To follow up on my previous email regarding the stable tag: since the
> patch includes a Fixes tag, simply dropping 'Cc: stable' will not
> prevent automatic pickup by AUTOSEL.
> 
> To strictly prevent automatic backporting while keeping it tracked,
> please replace the tag with the following instead of dropping it
> entirely:
> 
> Cc: stable+noautosel@kernel.org # Non-fatal bug fix; defer backport
> until a real issue is reported
> 

Applied with exchanged CC.

Thanks,
Slava.

      reply	other threads:[~2026-09-17 19:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <MSG-ID-sufile-v1>
2026-09-15 19:51 ` [PATCH] " Aldo Ariel Panzardo
2026-09-15 19:52 ` [PATCH v2] " Aldo Ariel Panzardo
2026-09-16 19:06   ` Viacheslav Dubeyko
2026-09-17 15:46     ` Ryusuke Konishi
2026-09-17 16:05       ` Ryusuke Konishi
2026-09-17 19:35         ` Viacheslav Dubeyko [this message]

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=ee4a4f8cb0cad602a520161f4c9cbb1beac81d58.camel@dubeyko.com \
    --to=slava@dubeyko.com \
    --cc=konishi.ryusuke@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nilfs@vger.kernel.org \
    --cc=qwe.aldo@gmail.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

all inboxes | Powered by JetHome®