Messages in this thread | | | Date | Wed, 1 Feb 2012 02:35:06 +0100 (CET) | From | Jan Engelhardt <> | 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?
| |