Am Mittwoch, 9. September 2015, 10:16:16 schrieb Tadeusz Struk: Hi Tadeusz,
>On 09/09/2015 10:05 AM, Stephan Mueller wrote: >>> Yes, sorry, you are right. sg_len() will only return positive numbers or >>> >>> >zero. rsa.c checks it in all four operations: >>> >if (unlikely(!pkey->n || !pkey->d || !src_len)) >> >> Great, I am not disputing the check for 0, I just want an unsigned int, >> because sg->length is unsigned int too. :-) > >I see, maybe we can check for negative numbers in PF_ALG? My request for turning the implementation of sg_len and the callers of it to use unsigned int is simply to avoid overflows of the counter. Note, I usually am very zealous about using the correct data types, especially with integers. I have seen way to many security related bugs by overflowing a signed integer. Surely, PF_ALG will ensure that user space will only provide buffers up to a max number (PAGE_SIZE * ALG_MAX_PAGES is the maximum user space can provide at all considering my current user space approach). So, we have at most 65536 bytes from user space in one request. This boundary is to allow at most ALG_MAX_PAGES individual SGL members (i.e. at most ALG_MAX_PAGES individual calls to splice) but also tries to squeeze the data coming with sendmsg into one page. But, surely we can discuss these limits once I post algif_akcipher. Considering that, I do not feel that the code we discuss here should have a check for the maximum size of the SGL. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
