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:	Wed, 1 Feb 2012 02:35:06 +0100 (CET)
From:	Jan Engelhardt <jengelh@...ozas.de>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] treewide: fix memory corruptions when TASK_COMM_LEN
 != 16


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?
--
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/