Re: [PATCH] mctp: accept MSG_CMSG_COMPAT in recvmsg

[Davidlohr Bueso]

On Thu, 05 Nov 2026, Simon Horman wrote:

> On Sun, Nov 01, 2026 at 12:03:31PM -0800, Davidlohr Bueso wrote:
> > 32-bit userspace running on a 64-bit kernel is unable to receive MCTP
> > messages on an AF_MCTP socket, even though sending succeeds. There is
> > nothing for MCTP to do with it beyond not rejecting it, as af_packet,
> > af_key and can/isotp already do, for example.
>
> Hi Davidlohr,
>
> Thanks for your patch.
>
> As prompted elsewhere by a bot, it would be good if the patch description
> included some information about how this was found. And also to what
> extent the fix has been tested. I know you answered that already but
> I'm going to ask for a v2 for other reasons. And it would be good
> to include that detail there.

Thanks for taking a look.

So I don't think the changelog should be mentioning random userspace
programs for testing/verifying this - as the bot email suggested, just
replying there should be enough.

> > Fixes: 833ef3b91de6 ("mctp: Populate socket implementation")
> > Signed-off-by: Davidlohr Bueso <dave@xxxxxxxxxxxx>
>
> This seems to be a fix that effects users. Which I believe you have
> reproduced. As such I'd lean towards this being for net, CCed to stable.
>
> Subject: [PATCH net v2] ...
>
> Otherwise, it should be for net-next.
>
> Subject: [PATCH net-next v2] ...

Will do.

> > ---
> >  net/mctp/af_mctp.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/net/mctp/af_mctp.c b/net/mctp/af_mctp.c
> > index 8af5e2b3c8d1..aa22c0860712 100644
> > --- a/net/mctp/af_mctp.c
> > +++ b/net/mctp/af_mctp.c
> > @@ -292,8 +292,7 @@ static int mctp_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
>
> Strangely this patch has been mangled - the original code is 7 rather than
> 8 lines long. (s/,8/,7). Because of this it could not be applied by our
> CI which then did not run the usual tests.

Yeah I messed that up (noticed sashiko couldn't apply it either), not
sure what happened.

Thanks,
Davidlohr