Skip to content
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

One thread stuck at 100% usage due to connection flood? #20830

Closed
sfan5 opened this issue May 11, 2024 · 2 comments
Closed

One thread stuck at 100% usage due to connection flood? #20830

sfan5 opened this issue May 11, 2024 · 2 comments

Comments

@sfan5
Copy link

sfan5 commented May 11, 2024

qBittorrent & operating system versions

qBittorrent: v4.6.4
Operating system: Ubuntu 20.04
Qt: 6.7.0
libtorrent-rasterbar: 2.0.10.0

What is the problem?

This one's a bit peculiar and I'm not sure if it qualifies as a bug, so feel free to close. But I wanted to draw attention to it.

Today I noticed that one of the threads belonging to the qbittorrent-nox process was constantly at 100% cpu usage.
I first checked using strace and it seemed to be doing normal stuff, sending packets, receiving packets.
What caught my eye in the strace output was this:
grafik

IP addresses are usually distributed quite randomly, so qBt organically interacting with this many IPs in the same subnet is statistically unlikely.
I also checked all my active torrents and couldn't find a single of these IPs in the peer list.

Next I used tcpdump to capture all traffic to/from the relevant subnet (190.80.24.0/24).
In the ~20 seconds I captured Wireshark counted more than 800 unique conversations happening with the port qBt was listening on.
Almost all of the 256 IPs in that subnet were involved (that includes .0 and .255).

What I tried next was to block all traffic from 190.80.24.0/24 in the firewall. The CPU usage instantly returned to normal levels.

The last thing I tested was to remove the firewall rule. It didn't take long for some suspicious CPU peaks to appear and the 100% usage returned after about half an hour.

Unanswered questions:

  • what exactly is happening that uses so much CPU?
  • does qBt/libtorrent have any built-in protections against this?
  • could this be a bad actor? if so, what does he gain from this?
  • has anyone else seen this?

Steps to reproduce

  1. run active installation of qBt
  2. ???

Additional context

I can share the PCAPs if they're useful.

Log(s) & preferences file(s)

No response

@HanabishiRecca
Copy link
Contributor

HanabishiRecca commented May 12, 2024

what exactly is happening that uses so much CPU?

Probably a DDoS or another kind of attack.

does qBt/libtorrent have any built-in protections against this?

qB restricts a number of active connections (Settings > Connection > Global maximum number of connections) to 500 by default. This could not really help if the connections are fast pacing though and total count doesn't make it enough to hit the limit.

could this be a bad actor? if so, what does he gain from this?

Yes. Who knows.

has anyone else seen this?

Yep, different kind of attacks will happen, especially if you have a static IP. Torrent clients basically advertise their existance to the whole world via DHT.

So you have no other choice than utilizing firewalls. The client itself also supports IP filters, but I guess it will continue to drain CPU to reject connections (and also spams into the log), so OS-level firewall it the way to go I believe.
Changing your client port could help, at least temporarily, but chances are attackers will find the new port. Switching IP also could help, if possible.

@sfan5
Copy link
Author

sfan5 commented May 13, 2024

qB restricts a number of active connections (Settings > Connection > Global maximum number of connections) to 500 by default.

Indeed and I have it set to 500. It doesn't seem to have helped in this case.

@sfan5 sfan5 closed this as completed Jun 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants