[PATCH iproute2] ss: bound fscanf width when reading comm in user_ent_hash_build_task

[PATCH iproute2] ss: bound fscanf width when reading comm in user_ent_hash_build_task

[Prashanth Swaminathan]

user_ent_hash_build_task() reads the process comm name from
/proc/<pid>/stat into a 16-byte stack buffer (char name[16]) using an
unbounded fscanf("%*d (%[^)])", name).

Although the Linux kernel bounds the comm field to TASK_COMM_LEN - 1
(15) bytes, bound the conversion specifier to %15[^)] so a malformed
stat entry (e.g., via PROC_ROOT or non-standard procfs implementations)
cannot overflow the stack buffer.

Signed-off-by: Prashanth Swaminathan <prashanthsw@google.com>
---
 misc/ss.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/misc/ss.c b/misc/ss.c
index 26520cee..bc30d950 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -601,7 +601,7 @@ static void user_ent_hash_build_task(char *path,
int pid, int tid)

 			fp = fopen(stat, "r");
 			if (fp) {
-				if (fscanf(fp, "%*d (%[^)])", name) == 1)
+				if (fscanf(fp, "%*d (%15[^)])", name) == 1)
 					escape_str(task, name, sizeof(task));
 				fclose(fp);
 			}
-- 
2.56.0.212.g129ede20d9-goog

Re: [PATCH iproute2] ss: bound fscanf width when reading comm in user_ent_hash_build_task

[Stephen Hemminger]

On Tue, 20 Oct 2026 09:59:56 -0700
Prashanth Swaminathan <prashanthsw@google.com> wrote:

> user_ent_hash_build_task() reads the process comm name from
> /proc/<pid>/stat into a 16-byte stack buffer (char name[16]) using an
> unbounded fscanf("%*d (%[^)])", name).
> 
> Although the Linux kernel bounds the comm field to TASK_COMM_LEN - 1
> (15) bytes, bound the conversion specifier to %15[^)] so a malformed
> stat entry (e.g., via PROC_ROOT or non-standard procfs implementations)
> cannot overflow the stack buffer.
> 
> Signed-off-by: Prashanth Swaminathan <prashanthsw@google.com>
> ---

If you have a non-standard procfs, that is not our problem.

Re: [PATCH iproute2] ss: bound fscanf width when reading comm in user_ent_hash_build_task

[Stephen Hemminger]

On Tue, 20 Oct 2026 15:13:58 -0700
Prashanth Swaminathan <prashanthsw@google.com> wrote:

> No problem. I couldn't find any definitive source on the org's current
> thinking regarding whether these types of hardening changes, which don't
> actually cover a security vulnerability, are desirable, so I erred on the
> side of caution. Apologies for the thrash!

It did motivate me to replace fscanf there, there already is a helper
in lib/fs.c just needs some small changes.