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

Message-ID: <a06093f1-22b3-7d72-bc6c-f99f4e0d0de9@linuxfoundation.org>
Date:   Fri, 29 Jan 2021 14:18:09 -0700
From:   Shuah Khan <skhan@...uxfoundation.org>
To:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        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,
        Shuah Khan <skhan@...uxfoundation.org>
Subject: Re: general protection fault in tomoyo_socket_sendmsg_permission

On 1/29/21 10:08 AM, Tetsuo Handa wrote:
> 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...
> 

In this console log:

06:57:50 executing program 1:
socketpair$tipc(0x1e, 0x2, 0x0, &(0x7f00000000c0)={<r0=>0xffffffffffffffff})
sendmsg$BATADV_CMD_GET_TRANSTABLE_LOCAL(r0, 
&(0x7f00000002c0)={&(0x7f00000001c0), 0xc, &(0x7f0000000280)={0x0, 
0xd001010000000000}}, 0x0)

[ 1151.090883][T23361] vhci_hcd vhci_hcd.0: pdev(4) rhport(0) sockfd(4)
[ 1151.097445][T23361] vhci_hcd vhci_hcd.0: devid(0) speed(1) 
speed_str(low-speed)
06:57:50 executing program 0:
r0 = syz_open_dev$binderN(&(0x7f0000000680)='/dev/binder#\x00', 0x0, 0x0)
ioctl$BINDER_WRITE_READ(r0, 0xc0306201, &(0x7f0000000cc0)={0x88, 0x0, 
&(0x7f0000000b80)=[@transaction={0x40406300, {0x2, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}, @transaction={0x40406300, {0x0, 0x0, 
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}], 0x0, 0x0, 0x0})

[ 1151.164402][T23363] vhci_hcd: connection closed
[ 1151.167346][  T240] vhci_hcd: stop threads


[ 1151.178329][T26761] usb 17-1: new low-speed USB device number 2 using 
vhci_hcd


SK: Looking at the console log, it looks like while connection is being
     torn down,


[ 1151.181245][  T240] vhci_hcd: release socket


Can you share your your test code for this program:
"executing program 1"

Also your setup? Do you run usbip_host and vhci_hcd both?

thanks,
-- Shuah