On Sunday 02 August 2009 03:50:12 Henrique de Moraes Holschuh wrote:
> > Note that it turns out this is not a real-life bug after all.
> > The VFS code checks count for signedness (high bit set) and bails
> > out if this is the case.
> > Well, it might probably be a good idea to restrict the count range to
> > something sane here anyway, so...
>
> It is a good idea to restrict the maximum size to something sane anyway.
>
> But the commit message needs to be fixed if there is no security hole.
>
> Anyway, in which function and file is the VFS code that restricts the
> maximum size?
>
Well there are two things. It happens that access_ok() on x86 does such a
check. It does _not_ do this on all arches, but as a thinkpad is x86...
And there are sanity checks in fs/read_write.c:
208 /*
209 * rw_verify_area doesn't like huge counts. We limit
210 * them to something that fits in "int" so that others
211 * won't have to do range checks all the time.
212 */
213 #define MAX_RW_COUNT (INT_MAX & PAGE_CACHE_MASK)
214
215 int rw_verify_area(int read_write, struct file *file, loff_t *ppos, size_t count)
216 {
217 struct inode *inode;
218 loff_t pos;
219 int retval = -EINVAL;
220
221 inode = file->f_path.dentry->d_inode;
222 if (unlikely((ssize_t) count < 0))
223 return retval;
224 pos = *ppos;
225 if (unlikely((pos < 0) || (loff_t) (pos + count) < 0))
226 return retval;
227
228 if (unlikely(inode->i_flock && mandatory_lock(inode))) {
229 retval = locks_mandatory_area(
230 read_write == READ ? FLOCK_VERIFY_READ : FLOCK_VERIFY_WRITE,
231 inode, file, pos, count);
232 if (retval < 0)
233 return retval;
234 }
235 retval = security_file_permission(file,
236 read_write == READ ? MAY_READ : MAY_WRITE);
237 if (retval)
238 return retval;
239 return count > MAX_RW_COUNT ? MAX_RW_COUNT : count;
240 }
--
Greetings, Michael.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
