All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: shao.mingyin@zte.com.cn
Cc: surenb@google.com, akpm@linux-foundation.org, linux-mm@kvack.org,
	 hao.ge@linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: snapshot alloc tags in alloc_tag_top_users() to avoid UAF
Date: Sat, 14 Nov 2026 17:31:29 +0000	[thread overview]
Message-ID: <aviaKvQu1QqlMvNB@gremlin> (raw)
In-Reply-To: <20261115004711126EXlXUnHk7NZz7rkWhDkyP@zte.com.cn>

On Sun, Nov 15, 2026 at 12:47:11AM +0800, shao.mingyin@zte.com.cn wrote:
> From: Shao Mingyin <shao.mingyin@zte.com.cn>
>
> mm: snapshot alloc tags in alloc_tag_top_users() to avoid UAF
>
> alloc_tag_top_users() selects tags under the codetag module-list lock,
> then returns raw codetag pointers. __show_mem() dereferences the tags,
> their strings and per-CPU counters after that lock has been released.
> Concurrent module unloading can invalidate those objects before they
> are printed in the OOM or SysRq-m report.
>
> Copy the selected tags and counters while holding the module-list lock,
> and print only the copies. Reuse allocinfo_to_params(), which copies
> names into fixed-size buffers and retains at most their last 63
> characters. Preserve the signed comparison used to select the top tags.
>
> Keep the larger output array static under the existing show_mem lock
> to avoid increasing the stack frame. The counters remain approximate
> lockless per-CPU observations; the copy protects object lifetime.
>
> Fixes: 1438d349d16b ("lib: add memory allocations report in show_mem()")
> Signed-off-by: Shao Mingyin <shao.mingyin@zte.com.cn>

NAK.

this is generated by some AI slopper's script, spamming the kernel. The
patches I looked at were wrong/broken, so no to anything from this person.

They've sent 300 mails in under four weeks spanniing: ata, scsi, target,
ufs, nvme/nvmet, ubifs, ublk, zloop, dm, md, mmc, virtio-blk, mfd, gpio,
pwm, spi, PCI, ASoC, ACPI, net, vfs mount, block partitions, and now mm.

and 17 series across 7 subsystems over the past 23 hours.

We need a way to ban emails from people like this...

--
Cheers, Lorenzo


      reply	other threads:[~2026-11-14 17:31 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-14 16:47 [PATCH] mm: snapshot alloc tags in alloc_tag_top_users() to avoid UAF shao.mingyin
2026-11-14 17:31 ` Lorenzo Stoakes (ARM) [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=aviaKvQu1QqlMvNB@gremlin \
    --to=ljs@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=hao.ge@linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=shao.mingyin@zte.com.cn \
    --cc=surenb@google.com \
    /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.