Opened 8 months ago
Closed 4 months ago
#18585 closed bug (fixed)
Memory leak when sending SYN ACK flood and ping of death to Haiku
| Reported by: | Coldfirex | Owned by: | axeld |
|---|---|---|---|
| Priority: | normal | Milestone: | R1/beta5 |
| Component: | Network & Internet/IPv4 | Version: | R1/beta4 |
| Keywords: | Cc: | ||
| Blocked By: | #17208 | Blocking: | |
| Platform: | All |
Description (last modified by )
hrev57247 I was messing around with Kali targeting Haiku and had the following two commands running against it.
ping -f 192.168.250.10 (IP of Haiku) hping3 -c 15000 -d 120 -S -w 64 -p 80 --flood --rand-source 192.168.250.10
These perform a ping of death and a sync ack flood.
I watched Haiku as its memory usage increased until it filled up and spilled over into virtual memory. After a while I attempted to close Poorman, which was up, and got the following KDL.
Attachments (4)
Change History (15)
by , 8 months ago
| Attachment: | syslog.txt added |
|---|
by , 8 months ago
by , 8 months ago
by , 8 months ago
| Attachment: | boot-kdl.png added |
|---|
comment:1 by , 8 months ago
comment:2 by , 8 months ago
| Component: | - General → Network & Internet/IPv4 |
|---|---|
| Description: | modified (diff) |
| Owner: | changed from to |
comment:3 by , 8 months ago
| Blocked By: | 17208 added |
|---|---|
| Summary: | KDL when sending SYN ACK flood and ping of death to Haiku → Memory leak when sending SYN ACK flood and ping of death to Haiku |
I fixed the KDL in hrev57279, however the memory leak remains. "#if 0'ing" out that whole block does not fix it.
According to the "slabs" KDL command, the memory leaked is in the net_buffer/data_node heaps, which is what I'd expect. This sounds like the same symptoms as #17208, and possibly it's the same problem.
Hopefully korli or another networking expert will have some time to take a look at this, since it's easily reproduced in a VM setup. "hping3" alone triggers the problem, the first command isn't necessary.
comment:4 by , 8 months ago
| Milestone: | Unscheduled → R1/beta5 |
|---|
comment:6 by , 4 months ago
Interestingly enough the memory leak seems to only be replicatable intermittently. I have gotten it to occur a few times, but not reliably so at this point. I can run the command for a while and Haiku can go over a minute without used memory increasing at all, and then suddenly it will start increasing the way it did before for some time, before levelling off for a while.
ifconfig stats show a lot of packets dropped, though, which probably means that a large part of the leak was in the device_receiver thread, which didn't properly free packets on drop until recently.
comment:7 by , 4 months ago
(I mean, only now intermittently replicatable. Previously it always replicated.)
comment:8 by , 4 months ago
Remaining problem looks like an mbuf leak: net_buffer and data_node usage is around 37MB and 20MB total respectively, but "mbuf jumbo page size" is at 1.5GB used.
comment:10 by , 4 months ago
I ran the commands for over an hour and I did not see any leaks, so I think this one is good. I did see some packet drops (7000ish), but I think they came in at the same time so it wasnt incrementing or anything. Appreciate you fixing!
comment:11 by , 4 months ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Thanks for reporting and testing!
Also, I tried having the Kali commands pre-running against Haiku before booting it up. During Haiku's boot process it KDLs reliably which I thought was interesting (before it loads the desktop). KDL looks almost exactly the same.