Yes it's a bug, but not one that bites yet.
It can only happen with copying to user space, and as
<asm-i386/checksum.h> says: "This combination is currently not used, but
possible".
> Since we've already initialized the destination buffer with suitable
> data up to the point of the fault, it's not uninitialized. So do we
> need to clear it at all?
The zeroing when copying _from_ user space was to smooth out some kernel
security issues; it's not an issue copying _to_ user space.
No kernel code is foolish enough to trust data in a user page just
written to. (Another user thread can be diddling with the data). So
there's no kernel security issue.
Faulting writes to user space should just truncate and return -EFAULT.
So that's fine too.
> Is my thinking right here, or am I confused about something? Should I
> worry about the case of an unmapped page in a buffer followed by mapped
> pages which should get cleared? (It can be done just by re-trying the
> clear at page boundaries until there's no more, but it's a bit ugly,
> and network packets aren't usually that big.)
IMO, fix the code the way you suggested. I.e., if the destination
faults, truncate writing and return -EFAULT.
And if you care to change the file to checksum.S instead of checksum.c,
you can use meaningful assembler labels too...
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/