linux-kernel - Re: [UPDATED PATCH] fix memory corruption from misinterpreted bad_inode

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:	Thu, 4 Jan 2007 10:26:59 -0800
From:	Andrew Morton <akpm@...l.org>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [UPDATED PATCH] fix memory corruption from misinterpreted
 bad_inode_ops return values

On Thu, 04 Jan 2007 11:51:10 -0600
Eric Sandeen <sandeen@...hat.com> wrote:

> Andrew Morton wrote:
> 
> > Al is correct, of course.  But the patch takes bad_inode.o from 280 up to 703
> > bytes, which is a bit sad for some cosmetic thing which nobody ever looks
> > at or modifies.
> >
> > Perhaps you can do
> >
> > static int return_EIO_int(void)
> > {
> > 	return -EIO;
> > }
> >
> > static int bad_file_release(struct inode * inode, struct file * filp)
> > 	__attribute__((alias("return_EIO_int")));
> > static int bad_file_fsync(struct inode * inode, struct file * filp)
> > 	__attribute__((alias("return_EIO_int")));
> >
> > etcetera?
> Ok, try this on for size.  Even though the gcc manual says alias doesn't work
> on all target machines, I assume linux arches are ok since alias is used
> in the core module init & exit code...
> 
> Also - is it ok to alias a function with one signature to a function with
> another signature?

Ordinarily I'd say no wucking fay, but that's effectively what we've been
doing in there for ages, and it seems to work.

I'd be a bit worried if any of these functions were returning pointers,
because one could certainly conceive of an arch+compiler combo which
returns pointers in a different register from integers (680x0?) but that's
not happening here.

> Note... I also realized that there are a couple of file ops which expect unsigned
> returns... poll and get_unmapped_area.  The latter seems to be handled just fine by
> the caller, which does IS_ERR gyrations to check for errnos.
> 
> I'm not so sure about poll; some callers put the return in a signed int, others
> unsigned, not sure anyone is really checking for -EIO... I think this op should
> probably be returning POLLERR, so that's what I've got in this version.

Yeah, that should all be OK.

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