linux-kernel - Re: [PATCH net-next v2] mptcp: correct MPTCP_SUBFLOW_ATTR_SSN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <df52ac23-5eee-4d17-9e74-237cf49fe4d7@kernel.org>
Date: Mon, 12 Aug 2024 09:43:29 +0200
From: Matthieu Baerts <matttbe@...nel.org>
To: Eugene Syromiatnikov <esyr@...hat.com>, mptcp@...ts.linux.dev
Cc: Mat Martineau <martineau@...nel.org>, Geliang Tang <geliang@...nel.org>,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Davide Caratti <dcaratti@...hat.com>, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v2] mptcp: correct MPTCP_SUBFLOW_ATTR_SSN_OFFSET
 reserved size

Hi Eugene, Network maintainers,

On 12/08/2024 08:51, Eugene Syromiatnikov wrote:
> ssn_offset field is u32 and is placed into the netlink response with
> nla_put_u32(), but only 2 bytes are reserved for the attribute payload
> in subflow_get_info_size() (even though it makes no difference
> in the end, as it is aligned up to 4 bytes).  Supply the correct
> argument to the relevant nla_total_size() call to make it less
> confusing.
> 
> Fixes: 5147dfb50832 ("mptcp: allow dumping subflow context to userspace")
> Signed-off-by: Eugene Syromiatnikov <esyr@...hat.com>
> ---
> v2:
>   - Added prefix to the patch subject
>   - Fixed commit message formatting (line width, "Fixes:" commit hash
>     prefix size)

Thank you for the v2!

The patch looks good to me:

Reviewed-by: Matthieu Baerts (NGI0) <matttbe@...nel.org>

Because it is a fix, I think it is a candidate for -net, not net-next.

@Network maintainers: is it OK for you to apply this v2 in "net", not
"net-next"? Or is it easier for you to have a v3 with a different prefix?

(No conflicts to apply this patch on -net, the code didn't change for 4
years.)

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.