From: Shuah Khan <skhan@linuxfoundation.org>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Hillf Danton <hdanton@sina.com>,
syzbot <syzbot+95ce4b142579611ef0a9@syzkaller.appspotmail.com>
Cc: linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
Andrey Konovalov <andreyknvl@google.com>,
Valentina Manea <valentina.manea.m@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
syzkaller-bugs@googlegroups.com,
Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: general protection fault in tomoyo_socket_sendmsg_permission
Date: Fri, 29 Jan 2021 14:18:09 -0700 [thread overview]
Message-ID: <a06093f1-22b3-7d72-bc6c-f99f4e0d0de9@linuxfoundation.org> (raw)
In-Reply-To: <5f9ec159-77d8-ffba-21d1-2810e059f998@i-love.sakura.ne.jp>
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
next prev parent reply other threads:[~2021-01-29 21:19 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-13 7:21 syzbot
[not found] ` <20201113120055.11748-1-hdanton@sina.com>
2020-11-13 17:14 ` Shuah Khan
2021-01-28 6:09 ` Tetsuo Handa
[not found] ` <2b70d360-a293-4acb-ea6c-2badda5e8b8b@linuxfoundation.org>
2021-01-29 5:48 ` Tetsuo Handa
[not found] ` <6b8da36f-a994-7604-77f4-52e29434605f@linuxfoundation.org>
2021-01-29 17:08 ` Tetsuo Handa
2021-01-29 21:18 ` Shuah Khan [this message]
2021-01-30 2:25 ` Tetsuo Handa
2021-02-10 18:17 ` Shuah Khan
2021-02-10 19:07 ` Tetsuo Handa
2021-02-10 19:29 ` Shuah Khan
2021-02-11 1:14 ` Tetsuo Handa
2021-02-12 1:34 ` Shuah Khan
2021-02-12 2:22 ` Tetsuo Handa
2021-02-12 4:58 ` Tetsuo Handa
2021-02-12 20:02 ` Shuah Khan
2021-02-13 10:02 ` Tetsuo Handa
2021-02-13 10:10 ` Greg Kroah-Hartman
2021-02-13 10:10 ` Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a06093f1-22b3-7d72-bc6c-f99f4e0d0de9@linuxfoundation.org \
--to=skhan@linuxfoundation.org \
--cc=andreyknvl@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=hdanton@sina.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=syzbot+95ce4b142579611ef0a9@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=valentina.manea.m@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®