linux-kernel - Re: 回复：general protection fault in refill_obj

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Sat, 13 Apr 2024 21:19:54 -0700
From: Shakeel Butt <shakeel.butt@...ux.dev>
To: Ubisectech Sirius <bugreport@...sectech.com>
Cc: Roman Gushchin <roman.gushchin@...ux.dev>, 
	linux-trace-kernel <linux-trace-kernel@...r.kernel.org>, linux-kernel <linux-kernel@...r.kernel.org>, 
	hannes <hannes@...xchg.org>, mhocko <mhocko@...nel.org>
Subject: Re: 回复：general protection fault
 in refill_obj_stock

On Tue, Apr 02, 2024 at 09:50:54AM +0800, Ubisectech Sirius wrote:
> > On Mon, Apr 01, 2024 at 03:04:46PM +0800, Ubisectech Sirius wrote:
> > Hello.
> > We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec. Recently, our team has discovered a issue in Linux kernel 6.7. Attached to the email were a PoC file of the issue.
> 
> > Thank you for the report!
> 
> > I tried to compile and run your test program for about half an hour
> > on a virtual machine running 6.7 with enabled KASAN, but wasn't able
> > to reproduce the problem.
> 
> > Can you, please, share a bit more information? How long does it take
> > to reproduce? Do you mind sharing your kernel config? Is there anything special
> > about your setup? What are exact steps to reproduce the problem?
> > Is this problem reproducible on 6.6?
> 
> Hi. 
>    The .config of linux kernel 6.7 has send to you as attachment. And The problem is reproducible on 6.6.

Can you please share the reproducer of this issue?

> 
> > It's interesting that the problem looks like use-after-free for the objcg pointer
> > but happens in the context of udev-systemd, which I believe should be fairly stable
> > and it's cgroup is not going anywhere.
> 
> > Thanks!
>