linux-kernel - Re: [PATCH] zram: fix NULL pointer dereference in zcomp_available

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]

Message-ID: <5ydfoytbfcvgkxxvc4s6e7rjqzldldjanq3jgwlonm3pczpysh@gtf3u6hibkri>
Date: Wed, 6 Aug 2025 12:04:35 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: Seyediman Seyedarab <imandevel@...il.com>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>, minchan@...nel.org, 
	axboe@...nel.dk, linux-kernel@...r.kernel.org, linux-block@...r.kernel.org, 
	syzbot+1a281a451fd8c0945d07@...kaller.appspotmail.com
Subject: Re: [PATCH] zram: fix NULL pointer dereference in
 zcomp_available_show()

On (25/08/05 10:43), Seyediman Seyedarab wrote:
> The NULL dereference (which syzbot reported) has a much tighter race 
> window: it requires catching the brief moment during zram_reset_device() 
> where comp_algs[prio] is NULL between zram_destroy_comps() and 
> comp_algorithm_set(). This 'can' be triggered by racing concurrent:
> - writes to /sys/block/zram0/reset 
> - reads from /sys/block/zram0/comp_algorithm
> The window is only a few instructions wide under write lock, so it is 
> significantly harder to reproduce than the use-after-free.

I honestly don't understand how this is possible.  comp_algorithm_set()
calls are done under writer ->init_lock, which is mutual exclusive:
neither concurrent writes no concurrent reads can occur in the meantime.