-
Notifications
You must be signed in to change notification settings - Fork 105
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
use-after-free in tcp_rearm_rto #693
Comments
Other relevant traces:
https://github.com/tempesta-tech/linux-4.8.15-tfw/blob/5b3aa7fe30ce46bb8f112a9544548da926cb3714/net/ipv4/tcp_input.c#L3129
This shows that not just
|
In attempt to close in on the cause of this bug, the previous version of Linux kernel for Tempesta was tested. The changes included:
These versions of Tempesta and the kernel were tested in the original setup for this issue. The tests did not produce a single warning from KASAN. The whole system worked stable for many hours. This results of this research may be considered as a proof that the real issue is NOT in the latest massive changes to Tempesta code base, but rather it's in the patch to Tempesta kernel 4.8.15. It appears that there's something wrong with memory management in the patch. The traces above lead to believe that kernel memory may be taken away at any random time right from under Tempesta or the kernel itself. This issue is related to #691. |
After the latest kernel patch https://github.com/tempesta-tech/linux-4.8.15-tfw/commit/0bf3cf888a6bc61da0919c5c989bec938bda6e4b this bug still occurs. By observations of overall behaviour, there are a few small differences in my VM:
This issue and the issue mentioned in #692 (comment) appear to be duplicates. |
The setup:
The configuration means that Tempesta bypasses cache on all requests. All requests are forwarded to the back-end server without exceptions.
The test is a simple
wrk -t 8 -c 1024 -d 60s http://192.168.10.230
from the host machine to the VM with Tempesta and Nginx. The bug may not present itself immediately. I may require several test runs to get it.The current master at c40924b is the result of the merge of #660. It's likely that this is a bug introduced with that merge. The traces lead to believe that
sk
pointer to a socket is used after the socket was freed. Please see the traces and the preliminary analysis below.The kernel (KASAN) reports the following:
Then, the kernel crashes on NULL pointer dereference:
The address reported in the initial use-after-free message from KASAN leads to this line of code: https://github.com/tempesta-tech/linux-4.8.15-tfw/blob/5b3aa7fe30ce46bb8f112a9544548da926cb3714/net/ipv4/tcp_input.c#L3026
The text was updated successfully, but these errors were encountered: