Messages in this thread | | | Date | Thu, 2 Jun 2005 10:48:40 +0200 | From | Jörn Engel <> | Subject | Re: Suggestion on "int len" sanity |
| |
On Thu, 2 June 2005 09:28:55 +0200, XIAO Gang wrote: > > Examples: > > 1. In the types of sys_[gs]ethostname, sys_[gs]etdomainname, "int len" > could be replaced > by "unsigned int" or "size_t" and sanity check simplified.
If you really want that fun, try changing it to "unsigned long long" on your private machine and do some testing.
Hint: arch/i386/kernel/syscall_table.S
> 2. In mm/shmem.c, shmem_symlink(), we have "len = strlen(symname) + 1;". > Although it is highly > improbable that strlen(symname) overflows, it is more correct to declare > "size_t len;".
Yep, looks sane.
> 3. The similar situation occurs in fs/namei.c, vfs_readlink(). Here it does > not matter if len > is declared to be unsigned, but for size_t, we have to take care about the > size of size_t.
You could possibly change the code to:
int vfs_readlink(struct dentry *dentry, char __user *buffer, int buflen, const char *link) { union { unsigned len; int ret; } u;
u.ret = PTR_ERR(link); if (IS_ERR(link)) goto out;
u.len = strlen(link); if (u.len > (unsigned) buflen) u.len = buflen; if (copy_to_user(buffer, link, u.len)) u.ret = -EFAULT; out: return u.ret; }
But what would we gain, except for a few additional lines?
Jörn
-- Happiness isn't having what you want, it's wanting what you have. -- unknown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |