mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Cheng Yongkang <teel4res@gmail.com>
Cc: linux-kernel@vger.kernel.org,
	"Shubhang Kaushik (Ampere)" <sh@gentwo.org>,
	Davidlohr Bueso <dave@stgolabs.net>,
	Manfred Spraul <manfred@colorfullife.com>
Subject: Re: [PATCH] ipc/msg: align compat version-0 msqid_ds with native IPC_OLD
Date: Thu, 29 Oct 2026 11:55:14 -0700	[thread overview]
Message-ID: <20261029115514.fd04df0fb01f070f0e960eb1@linux-foundation.org> (raw)
In-Reply-To: <179328314077.648427.7284615104475689945@gmail.com>

On Thu, 29 Oct 2026 07:12:20 -0700 Cheng Yongkang <teel4res@gmail.com> wrote:

> The compat version-0 IPC_STAT path copies the 64-bit counters into the
> 16-bit msg_cbytes/msg_qnum/msg_qbytes fields without clamping, and leaves
> msg_lcbytes/msg_lqbytes zero.  A queue with 65536 bytes, 8 messages and
> q_qbytes=200000 is reported as cbytes=0, qnum=8, qbytes=3392,
> lcbytes=lqbytes=0, while the native IPC_OLD path reports the clamped
> counters and the full values in the l fields.
> 
> The compat version-0 IPC_SET path reads only the 16-bit msg_qbytes and
> ignores msg_lqbytes.  A caller following the old ABI with msg_qbytes=0
> and msg_lqbytes=131072 gets q_qbytes=0 and the queue stops accepting
> messages, while the native IPC_OLD path falls back to msg_lqbytes.
> 
> Mirror the native IPC_OLD handling in both compat version-0 branches:
> clamp the counters to USHRT_MAX and fill the l fields on stat, and fall
> back to msg_lqbytes when the 16-bit qbytes is zero on set.  The compat
> IPC_64 branches and the native paths are unchanged.
> 

Thanks.  I had LLM poke at this and it had things to say:

: The conversion changes look right, but the Fixes tag needs correcting.
: 4693916846269d only moved the compat code. Both omissions are already
: present in 1da177e4c3f4 ("Linux-2.6.12-rc2"), the initial Git import.
: Please drop the incorrect attribution; the actual introduction predates
: that history. Keep the stable CC.
: 
: Please also coordinate this with the unsigned-long msgctl_down() fix
: from Shubhang Kaushik's "[PATCH v2] ipc/msg: prevent msg_qbytes limit
: bypass in IPC_SET".
: (https://lore.kernel.org/20261027-ipc-msg-qbytes-v2-1-48d8f72f1359@gentwo.org)
: On the current base, your new fallback lets a
: privileged old-ABI caller supply msg_lqbytes=UINT_MAX, but msgctl_down()
: still narrows that to int and installs ULONG_MAX on a 64-bit kernel.
: That downstream bug already affects other interfaces; this patch makes
: it reachable through the repaired fallback too.
: 
: The original bugs give legacy 32-bit programs wrapped queue statistics
: or unexpectedly set the queue capacity to zero. Subsequent sends then
: block or return EAGAIN with IPC_NOWAIT, even for zero-length messages.
: The ordinary capacity permission checks still apply to the long value.


> --- a/ipc/msg.c
> +++ b/ipc/msg.c
> @@ -686,10 +686,17 @@ static int copy_compat_msqid_from_user(struct msqid64_ds *out, void __user *buf,
>  			return -EFAULT;
>  	} else {
>  		struct compat_msqid_ds __user *p = buf;
> +		compat_ulong_t qbytes;
> +
>  		if (get_compat_ipc_perm(&out->msg_perm, &p->msg_perm))
>  			return -EFAULT;
> -		if (get_user(out->msg_qbytes, &p->msg_qbytes))
> +		if (get_user(qbytes, &p->msg_qbytes))
>  			return -EFAULT;
> +		if (qbytes == 0) {
> +			if (get_user(qbytes, &p->msg_lqbytes))
> +				return -EFAULT;
> +		}
> +		out->msg_qbytes = qbytes;
>  	}
>  	return 0;
>  }
> @@ -720,9 +727,23 @@ static int copy_compat_msqid_to_user(void __user *buf, struct msqid64_ds *in,
>  		v.msg_stime = in->msg_stime;
>  		v.msg_rtime = in->msg_rtime;
>  		v.msg_ctime = in->msg_ctime;
> -		v.msg_cbytes = in->msg_cbytes;
> -		v.msg_qnum = in->msg_qnum;
> -		v.msg_qbytes = in->msg_qbytes;
> +		if (in->msg_cbytes > USHRT_MAX)
> +			v.msg_cbytes = USHRT_MAX;
> +		else
> +			v.msg_cbytes = in->msg_cbytes;
> +		v.msg_lcbytes = in->msg_cbytes;
> +
> +		if (in->msg_qnum > USHRT_MAX)
> +			v.msg_qnum = USHRT_MAX;
> +		else
> +			v.msg_qnum = in->msg_qnum;
> +
> +		if (in->msg_qbytes > USHRT_MAX)
> +			v.msg_qbytes = USHRT_MAX;
> +		else
> +			v.msg_qbytes = in->msg_qbytes;
> +		v.msg_lqbytes = in->msg_qbytes;
> +
>  		v.msg_lspid = in->msg_lspid;
>  		v.msg_lrpid = in->msg_lrpid;
>  		return copy_to_user(buf, &v, sizeof(v));
> -- 
> 2.34.1

      reply	other threads:[~2026-10-29 18:55 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-29 14:12 Cheng Yongkang
2026-10-29 18:55 ` Andrew Morton [this message]

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=20261029115514.fd04df0fb01f070f0e960eb1@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=dave@stgolabs.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    --cc=sh@gentwo.org \
    --cc=teel4res@gmail.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®