linux-kernel - Re: general protection fault in tomoyo_socket_sendmsg

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-next>] [day] [month] [year] [list]

Message-ID: <5f9ec159-77d8-ffba-21d1-2810e059f998@i-love.sakura.ne.jp>
Date:   Sat, 30 Jan 2021 02:08:41 +0900
From:   Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To:     Shuah Khan <skhan@...uxfoundation.org>,
        Hillf Danton <hdanton@...a.com>,
        syzbot <syzbot+95ce4b142579611ef0a9@...kaller.appspotmail.com>
Cc:     linux-kernel@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        Andrey Konovalov <andreyknvl@...gle.com>,
        Valentina Manea <valentina.manea.m@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        syzkaller-bugs@...glegroups.com
Subject: Re: general protection fault in tomoyo_socket_sendmsg_permission

On 2021/01/30 1:05, Shuah Khan wrote:
>> Since "general protection fault in tomoyo_socket_sendmsg_permission" is caused by
>> unexpectedly resetting ud->tcp_socket to NULL without waiting for tx thread to
>> terminate, tracing the ordering of events is worth knowing. Even adding
>> schedule_timeout_uninterruptible() to before kernel_sendmsg() might help.
>>
> 
> What about the duplicate bug information that was in my email?
> Did you take a look at that?

I was not aware of the duplicate bugs. It is interesting that
"KASAN: null-ptr-deref Write in event_handler" says that vdev->ud.tcp_tx became NULL at

	if (vdev->ud.tcp_tx) {

		/* this location */

		kthread_stop_put(vdev->ud.tcp_tx);
		vdev->ud.tcp_tx = NULL;
	}

which means that somebody else is unexpectedly resetting vdev->ud.tcp_tx to NULL.

If memset() from vhci_device_init() from vhci_start() were unexpectedly called,
all of tcp_socket, tcp_rx, tcp_tx etc. becomes NULL which can explain these bugs ?
I'm inclined to report not only tcp_socket but also other fields when kernel_sendmsg()
detected that tcp_socket is NULL...