* Re: + proc-fix-comm_write-return-value-when-truncated-or-error.patch added to mm-nonmm-unstable branch
[not found] <20260424105325.B0E0BC19425@smtp.kernel.org>
@ 2026-04-24 13:40 ` Alexey Dobriyan
0 siblings, 0 replies; only message in thread
From: Alexey Dobriyan @ 2026-04-24 13:40 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, jstultz, me, mm-commits
On Fri, Apr 24, 2026 at 03:53:25AM -0700, Andrew Morton wrote:
> From: "Shengzhuo Wei" <me@cherr.cc>
> Subject: proc: fix comm_write return value when truncated or error
> Date: Fri, 24 Apr 2026 04:06:21 +0800
>
> When count exceeds TASK_COMM_LEN-1, comm_write() copies at most
> TASK_COMM_LEN-1 bytes but returns the original count. This violates
> write(2) semantics, which require returning the number of bytes actually
> written.
This is sketchy for reasons:
1) not consuming whole buffer may (and will) break programs which write
overlong string _and_ use "while (len > 0) { len -= write(); } "
full write idiom.
2) adding filesystems semantics of writing into the middle of the file
is counter productive here.
If "comm" was regular API, there would be "read comm", "write comm"
+ some locking inside of the kernel. Partial update is kind of silly
here because string is small.
IIRC there was sysctl fixes banning partial update of modprobe path
or something like that for security/predictability reasons.
> --- a/fs/proc/base.c~proc-fix-comm_write-return-value-when-truncated-or-error
> +++ a/fs/proc/base.c
> @@ -1727,8 +1727,10 @@ static ssize_t comm_write(struct file *f
> - return count;
> + return ret;
^ permalink raw reply [flat|nested] only message in thread