I added the linux-fsdevel list back to the CC. On Fri, Jul 13, 2018 at 12:16:30PM -0400, Jan Harkes wrote: > On Fri, Jul 13, 2018 at 06:10:17PM +0300, Dan Carpenter wrote: > > "dcbuf" is a union that is "size" bytes large. We ensure that "nbytes" > > is large enough to hold the smallest member of the union, but the > > problem is that we might try to use a larger member. If "nbytes" is > > set to sizeof(struct coda_out_hdr) that would cause a problem in > > coda_downcall() when we try to access &out->coda_zapdir.CodaFid; > > > > The union is quite small so we can allocate enough space so everything > > fits. The CODA_ALLOC() macro calls kzalloc() which means the extra > > memory is just zeroed and it's fine. > > > > Signed-off-by: Dan Carpenter <dan.carpenter@xxxxxxxxxx> > > --- > > v2: I forgot to update CODA_FREE() in my first patch. > > You also seem to have missed my comments on your first patch. The > smallest size test is only to make sure we at least get a complete > message header. > > If your concern is that a userspace client might send a CODA_ZAPDIR > downcall but doesn't actually include enough data for the message to > contain the file identifier to be zapped. I don't think this shouldn't > be papered over by just passing along some extra zero bytes. > How would we know these extra zero bytes are fine? How does the > developer implementing this broken Coda client find out that he is not > actually sending a properly formatted message and the intended cache > flush never happens? > > The proper fix should be to check that we received at least enough data > to fully read the received downcall message based on the opcode in the > received message header and log/return an error if it doesn't match. > I just wanted to solve the memory corruption without breaking user space. What you're proposing sounds more complicated and probably someone should test it. Can you fix it and give me a Reported-by tag? regards, dan carpenter
