linux-kernel - Re: [PATCH 1/2] treewide: fix memory corruptions when TASK_COMM

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]

Date:	Tue, 31 Jan 2012 17:49:14 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Jan Engelhardt <jengelh@...ozas.de>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] treewide: fix memory corruptions when TASK_COMM_LEN
 != 16

On Wed, 1 Feb 2012 02:35:06 +0100 (CET) Jan Engelhardt <jengelh@...ozas.de> wrote:

> 
> On Wednesday 2012-02-01 02:23, Andrew Morton wrote:
> >>
> >> If there is a piece of kernel code that
> >> assumes/requests that userspace use a 16-byte buffer (such as
> >> cn_proc as mentioned), then it should use a file-level define or
> >> something with a comment above it that this is a fixed user value.
> >> 
> >> I would therefore say that changing TASK_COMM_LEN is possible without 
> >> breaking any userprogram.
> >> 
> >> (In other words, TASK_COMM_LEN can just remain what it is, and 
> >> comm[TASK_COMM_LEN] in struct task_struct could be changed to 
> >> e.g. comm[32]. Using sizeof(x.comm) also seems more proof in general.)
> >
> >Well yes, we could increase the size and provide new and better APIs
> >for accessing it, while teaching the old APIs to truncate.  That might
> >cause some problems for old-API-using userspace during the transition
> >period, but I doubt if they would be large problems.
> 
> Did my patch not change the existing code sites using ->comm
> to always copy at most min(userbufsize aka 16, sizeof(t->comm)) bytes,
> thereby keeping the promise to userspace while at the same time
> making TASK_COMM_LEN's value freely choosable?

That change is pretty pointless as long as we don't provide APIs to let
userspace access the expanded size.  And I've explained why we cannot
alter the existing APIs.

So until and unless we decide to add the new APIs I think that the
cleanup parts of the patch are good, but the parts which increase the
kernel text footprint are not.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/