lkml.org 
[lkml]   [2021]   [Jan]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: general protection fault in tomoyo_socket_sendmsg_permission
From
Date
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...

\
 
 \ /
  Last update: 2021-01-29 18:13    [W:0.058 / U:2.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site