Messages in this thread | | | Date | Thu, 09 Aug 2007 17:08:05 -0500 | From | Eric Sandeen <> | Subject | Re: [PATCH V2] limit minixfs printks on corrupted dir i_size, CVE-2006-6058 |
| |
Bodo Eggert wrote:
> Warning: I'm only looking at the patch. > > You are supposed to print an error message for a user, not to write in a > chat window to a 1337 script kiddie. OK, you just matched the current style, > and your patch is IMHO OK for a quick security fix, but: > > - Security fixes should be CCed to the security mailing list, shouldn't they? > (It might be security@ or stable@, I'll remember tomorrow, but then I'd > forget to comment)
ok.
> - Imagine you have three mounts containing a minix fs, how can you tell which > one is the the defective one?
good point.
> - The message says "minix_bmap", while the patch suggests it's in > block_to_path. Therefore I asume "minix_bmap" to have only random > informational value.
Yup, you're right.
> - Does block < 0 or block > $size make a difference?
well, block > size is likely to arrive from a corrupt i_size, and the insistence upon going ahead and checking the next page after encountering an error on the last one... I don't have any scenario in mind where we'd be repeatedly trying to check blocks < 0.
> - the printk lacks the loglevel.
As do all other printk's in minixfs... (hm and 11,619 other printk's in the kernel :) )
> - Asuming minix supports error handling, shouldn't it do something? > > I'd suggest a message saying something like "minix: Bad block address on > device 08:15, needs fsck".
Fair enough, as you said I was just fixing up the issue, not rewriting the code around it. But yes, I should probably have considered at least a better message here. I can fix this up & resend. But I'm not promising to audit all other printk's in minixfs this time around. ;-)
-Eric - 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/
| |