From: Kuniyuki Iwashima <kuniyu@amazon.com>
To: <devnull+0x7f454c46.gmail.com@kernel.org>
Cc: <0x7f454c46@gmail.com>, <borisp@nvidia.com>, <colona@arista.com>,
<davem@davemloft.net>, <dsahern@kernel.org>,
<edumazet@google.com>, <geliang@kernel.org>, <horms@kernel.org>,
<john.fastabend@gmail.com>, <kuba@kernel.org>,
<linux-kernel@vger.kernel.org>, <martineau@kernel.org>,
<matttbe@kernel.org>, <mptcp@lists.linux.dev>,
<netdev@vger.kernel.org>, <pabeni@redhat.com>
Subject: Re: [PATCH net 5/6] net/diag: Limit TCP-MD5-diag array by max attribute length
Date: Wed, 6 Nov 2024 16:25:55 -0800 [thread overview]
Message-ID: <20241107002555.57247-1-kuniyu@amazon.com> (raw)
In-Reply-To: <20241106-tcp-md5-diag-prep-v1-5-d62debf3dded@gmail.com>
From: Dmitry Safonov via B4 Relay <devnull+0x7f454c46.gmail.com@kernel.org>
Date: Wed, 06 Nov 2024 18:10:18 +0000
> From: Dmitry Safonov <0x7f454c46@gmail.com>
>
> Currently TCP-MD5 keys are dumped as an array of
> (struct tcp_diag_md5sig). All the keys from a socket go
> into the same netlink attribute. The maximum amount of TCP-MD5 keys on
> any socket is limited by /proc/sys/net/core/optmem_max, which post
> commit 4944566706b2 ("net: increase optmem_max default value") is now by
> default 128 KB. With the help of selftest I've figured out that equals
> to 963 keys, without user having to increase optmem_max:
> > test_set_md5() [963/1024]: Cannot allocate memory
>
> The maximum length of nlattr is limited by typeof(nlattr::nla_len),
> which is (U16_MAX - 1). When there are too many keys the array written
> overflows the netlink attribute. Here is what one can see on a test,
> with no adjustments to optmem_max defaults:
>
> > recv() = 65180
> > socket: 10.0.254.1:7013->0.0.0.0:0 (intf 3)
> > family: 2 state: 10 timer: 0 retrans: 0
> > expires: 0 rqueu: 0 wqueue: 1 uid: 0 inode: 456
> > attr type: 8 (5)
> > attr type: 15 (8)
> > attr type: 21 (12)
> > attr type: 22 (6)
> > attr type: 2 (252)
> > attr type: 18 (64804)
> > recv() = 130680
> > socket: 10.0.254.1:7013->0.0.0.0:0 (intf 3)
> > family: 2 state: 10 timer: 0 retrans: 0
> > expires: 0 rqueu: 0 wqueue: 1 uid: 0 inode: 456
> > attr type: 8 (5)
> > attr type: 15 (8)
> > attr type: 21 (12)
> > attr type: 22 (6)
> > attr type: 2 (252)
> > attr type: 18 (64768)
> > attr type: 29555 (25966)
> > recv() = 130680
> > socket: 10.0.254.1:7013->0.0.0.0:0 (intf 3)
> > family: 2 state: 10 timer: 0 retrans: 0
> > expires: 0 rqueu: 0 wqueue: 1 uid: 0 inode: 456
> > attr type: 8 (5)
> > attr type: 15 (8)
> > attr type: 21 (12)
> > attr type: 22 (6)
> > attr type: 2 (252)
> > attr type: 18 (64768)
> > attr type: 29555 (25966)
> > attr type: 8265 (8236)
>
> Here attribute type 18 is INET_DIAG_MD5SIG, the following nlattr types
> are junk made of tcp_diag_md5sig's content.
>
> Here is the overflow of the nlattr size:
> >>> hex(64768)
> '0xfd00'
> >>> hex(130300)
> '0x1fcfc'
>
> Limit the size of (struct tcp_diag_md5sig) array in the netlink reply by
> maximum attribute length. Not perfect as NLM_F_DUMP_INTR will be set on
> the netlink header flags, but the userspace can differ if it's due to
> inconsistency or due to maximum size of the netlink attribute.
>
> In a following patch set, I'm planning to address this and re-introduce
> TCP-MD5-diag that actually works.
Given the issue has not been reported so far (I think), we can wait for
the series rather than backporting this.
next prev parent reply other threads:[~2024-11-07 0:26 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-06 18:10 [PATCH net 0/6] Make TCP-MD5-diag slightly less broken Dmitry Safonov via B4 Relay
2024-11-06 18:10 ` [PATCH net 1/6] net/diag: Do not race on dumping MD5 keys with adding new MD5 keys Dmitry Safonov via B4 Relay
2024-11-07 4:21 ` kernel test robot
2024-11-06 18:10 ` [PATCH net 2/6] net/diag: Warn only once on EMSGSIZE Dmitry Safonov via B4 Relay
2024-11-06 18:10 ` [PATCH net 3/6] net/diag: Pre-allocate optional info only if requested Dmitry Safonov via B4 Relay
2024-11-06 18:10 ` [PATCH net 4/6] net/diag: Always pre-allocate tcp_ulp info Dmitry Safonov via B4 Relay
2024-11-07 0:21 ` Kuniyuki Iwashima
2024-11-07 17:35 ` Dmitry Safonov
2024-11-06 18:10 ` [PATCH net 5/6] net/diag: Limit TCP-MD5-diag array by max attribute length Dmitry Safonov via B4 Relay
2024-11-07 0:25 ` Kuniyuki Iwashima [this message]
2024-11-07 17:46 ` Dmitry Safonov
2024-11-06 18:10 ` [PATCH net 6/6] net/netlink: Correct the comment on netlink message max cap Dmitry Safonov via B4 Relay
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=20241107002555.57247-1-kuniyu@amazon.com \
--to=kuniyu@amazon.com \
--cc=0x7f454c46@gmail.com \
--cc=borisp@nvidia.com \
--cc=colona@arista.com \
--cc=davem@davemloft.net \
--cc=devnull+0x7f454c46.gmail.com@kernel.org \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=geliang@kernel.org \
--cc=horms@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martineau@kernel.org \
--cc=matttbe@kernel.org \
--cc=mptcp@lists.linux.dev \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/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
all inboxes | Powered by JetHome®