Herbert Xu <herb...@gondor.apana.org.au> wrote:
> Huh? If you can't write to csum_iv_head without clobbering others
> then by the same reasoning you can't write to csum_iv either. So
> unless you're saying the existing code is already broken then there
> is nothing wrong with the patch.
Ah, for some reason I read it as being in the normal packet processing. Need
tea before I read security patches;-)
Since it's (more or less) a one off piece of memory, why not kmalloc it
temporarily rather than expanding the connection struct? Also, the bit where
you put a second rxrpc_crypt in just so that it happens to give you a 16-byte
slot by adjacency is pretty icky. It would be much better to use a union
instead:
union {
struct rxrpc_crypt csum_iv; /* packet checksum base */
__be32 tmpbuf[4];
};
Note also that the above doesn't guarantee that the struct will be inside of a
single page. It would need an alignment of 16 for that - but you only have
one sg. Could that be a problem?
David
