All of lore.kernel.org
 help / color / mirror / Atom feed
From: SeongJae Park <sj@kernel.org>
To: "Kumar, Kaushlendra" <kaushlendra.kumar@intel.com>
Cc: SeongJae Park <sj@kernel.org>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: RE: [PATCH] tools/mm/slabinfo: fix buffer overflows in fread operations
Date: Mon, 22 Sep 2025 02:45:17 -0700	[thread overview]
Message-ID: <20250922094517.58153-1-sj@kernel.org> (raw)
In-Reply-To: <LV3PR11MB8768BC4A1DF99E07DE49FAD8F512A@LV3PR11MB8768.namprd11.prod.outlook.com>

On Mon, 22 Sep 2025 02:40:11 +0000 "Kumar, Kaushlendra" <kaushlendra.kumar@intel.com> wrote:

> On Fri, 29 Aug 2025, SeongJae Park wrote:
> > On Fri, 29 Aug 2025 15:29:47 +0530 Kaushlendra Kumar <kaushlendra.kumar@intel.com> wrote:
> > 
> > > The fread() calls in read_slab_obj() and read_debug_slab_obj() can 
> > > read up to sizeof(buffer) bytes, but then unconditionally write a null 
> > > terminator at buffer[l]. If fread() returns sizeof(buffer), this 
> > > writes beyond the allocated buffer boundaries.
> > > 
> > > Fix by limiting reads to sizeof(buffer) - 1 bytes in both functions, 
> > > ensuring space is always reserved for null termination. This prevents 
> > > buffer overflows while maintaining proper string handling.
> > > 
> > > Signed-off-by: Kaushlendra Kumar <kaushlendra.kumar@intel.com>
> > 
> > Acked-by: SeongJae Park <sj@kernel.org>
> > 
> > 
> > Thanks,
> > SJ
> 
> Hi SeongJae,
> 
> Thank you for the Acked-by! 
> 
> Since this patch has received your acknowledgment, are we going to merge this 
> patch? Should I expect it to be picked up for the next kernel release, or 
> are there any additional steps needed from my side?

I'm not a maintainer or a reviewr of slabinfo, so my Acked-by: doesn't mean
many things.  I think the next steps and decisions are up to Andrew.

And I think Andrew should be busy for the preparation of the next merge window.
I'd suggest pinging Andrew again, after the next MM pull requests for 6.18-rc1
are done.


Thanks,
SJ

[...]


      reply	other threads:[~2025-09-22  9:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-29  9:59 [PATCH] tools/mm/slabinfo: fix buffer overflows in fread operations Kaushlendra Kumar
2025-08-29 11:51 ` Harry Yoo
2025-08-29 13:12   ` Kumar, Kaushlendra
2025-08-29 15:30   ` Kumar, Kaushlendra
2025-08-29 18:52 ` SeongJae Park
2025-09-22  2:40   ` Kumar, Kaushlendra
2025-09-22  9:45     ` SeongJae Park [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=20250922094517.58153-1-sj@kernel.org \
    --to=sj@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=kaushlendra.kumar@intel.com \
    --cc=linux-mm@kvack.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 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.