Messages in this thread | | | Subject | Re: general protection fault in tomoyo_socket_sendmsg_permission | From | Tetsuo Handa <> | Date | Sat, 30 Jan 2021 02:08:41 +0900 |
| |
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...
| |