netdev - Re: [PATCH] sock: Fix sk_sleep return invalid pointer

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: <20230823001910.1943703-1-eadavis@sina.com>
Date: Wed, 23 Aug 2023 08:19:10 +0800
From: eadavis@...a.com
To: pabeni@...hat.com
Cc: davem@...emloft.net,
	edumazet@...gle.com,
	hdanton@...a.com,
	kuba@...nel.org,
	linux-hams@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org,
	ralf@...ux-mips.org,
	syzbot+666c97e4686410e79649@...kaller.appspotmail.com,
	syzkaller-bugs@...glegroups.com,
	Edward AD <eadavis@...a.com>
Subject: Re: [PATCH] sock: Fix sk_sleep return invalid pointer

From: Edward AD <eadavis@...a.com>

On Tue, 22 Aug 2023 17:31:00 +0200, pabeni@...hat.com wrote:
> > From: Edward AD <eadavis@...a.com>
> > 
> > The parameter sk_sleep(sk) passed in when calling prepare_to_wait may 
> > return an invalid pointer due to nr-release reclaiming the sock.
> > Here, schedule_timeout_interruptible is used to replace the combination 
> > of 'prepare_to_wait, schedule, finish_wait' to solve the problem.
> > 
> > Reported-and-tested-by: syzbot+666c97e4686410e79649@...kaller.appspotmail.com
> > Signed-off-by: Edward AD <eadavis@...a.com>
> 
> This looks wrong. No syscall should race with sock_release(). It looks
> like you are papering over the real issue.
> 
> As the reproducer shows a disconnect on an connected socket, I'm wild
> guessing something alike 4faeee0cf8a5d88d63cdbc3bab124fb0e6aed08c
> should be more appropriate.
There is insufficient evidence to prove where the current report provided by 
syz caused 'sk_sleep()' to return an invalid pointer.
So, the above statement is my guess.