From: Stephen Hemminger <stephen@networkplumber.org>
To: netdev@vger.kernel.org
Subject: Fw: [Bug 212515] New: DoS Attack on Fragment Cache
Date: Thu, 1 Apr 2021 11:08:34 -0700 [thread overview]
Message-ID: <20210401110834.3ca4676b@hermes.local> (raw)
Initial discussion is that this bug is not easily addressable.
Any fragmentation handler is subject to getting poisoned.
Begin forwarded message:
Date: Wed, 31 Mar 2021 22:39:12 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 212515] New: DoS Attack on Fragment Cache
https://bugzilla.kernel.org/show_bug.cgi?id=212515
Bug ID: 212515
Summary: DoS Attack on Fragment Cache
Product: Networking
Version: 2.5
Kernel Version: 5.12.0-rc5
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV4
Assignee: stephen@networkplumber.org
Reporter: kman001@ucr.edu
Regression: No
Hi,
After the kernel receives an IPv4 fragment, it will try to fit it into a
queue by calling function
struct inet_frag_queue *inet_frag_find(struct fqdir *fqdir, void *key)
in
net/ipv4/inet_fragment.c.
However, this function will first check if the existing fragment memory
exceeds the fqdir->high_thresh. If it exceeds, then drop the fragment
regradless it belongs to a new queue or an existing queue.
Chances are that an attacker can fill the cache with fragments that will
never be assembled (i.e., only sends the first fragment with new IPIDs every
time) to exceed the threshold so that all future incoming fragmented IPv4
traffic would be blocked and dropped. Since there is GC machanism, the victim
host has to wait for 30s when the fragments are expired to continue receive
incoming fragments normally.
In pratice, given the 4MB fragment cache, the attacker only needs to send
1766 fragments to exhaust the cache and DoS the victim for 30s, whose cost is
pretty low. Besides, IPv6 would also be affected since the issue resides in
inet part.
This issue is introduced in commit
648700f76b03b7e8149d13cc2bdb3355035258a9 (inet: frags: use rhashtables for
reassembly units) which removes fqdir->low_thresh, which is used by GC worker.
I would recommand to bring GC worker back to prevent the DoS attacks.
Thanks,
Keyu Man
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
next reply other threads:[~2021-04-01 19:19 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-01 18:08 Stephen Hemminger [this message]
2021-04-01 19:43 ` Fw: [Bug 212515] New: DoS Attack on Fragment Cache Eric Dumazet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210401110834.3ca4676b@hermes.local \
--to=stephen@networkplumber.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).