#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 diver)

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)

syslog.txt (356.1 KB ) - added by Coldfirex 14 months ago.
bt.png (36.8 KB ) - added by Coldfirex 14 months ago.
kdl.png (34.1 KB ) - added by Coldfirex 14 months ago.
boot-kdl.png (34.4 KB ) - added by Coldfirex 14 months ago.

Download all attachments as: .zip

Change History (15)

by Coldfirex, 14 months ago

Attachment: syslog.txt added

by Coldfirex, 14 months ago

Attachment: bt.png added

by Coldfirex, 14 months ago

Attachment: kdl.png added

by Coldfirex, 14 months ago

Attachment: boot-kdl.png added

comment:1 by Coldfirex, 14 months ago

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.

comment:2 by diver, 14 months ago

Component: - GeneralNetwork & Internet/IPv4
Description: modified (diff)
Owner: changed from nobody to axeld

comment:3 by waddlesplash, 14 months ago

Blocked By: 17208 added
Summary: KDL when sending SYN ACK flood and ping of death to HaikuMemory 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 waddlesplash, 14 months ago

Milestone: UnscheduledR1/beta5

comment:5 by Coldfirex, 14 months ago

Confirmed the boot KDL is fixed now. Thanks!

comment:6 by waddlesplash, 10 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 waddlesplash, 10 months ago

(I mean, only now intermittently replicatable. Previously it always replicated.)

comment:8 by waddlesplash, 10 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:9 by waddlesplash, 10 months ago

Please retest after hrev57528.

comment:10 by Coldfirex, 10 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 waddlesplash, 10 months ago

Resolution: fixed
Status: newclosed

Thanks for reporting and testing!

Note: See TracTickets for help on using tickets.