[PATCH 0/4] RFC: tipc int vs size_t fixes

[PATCH 0/4] RFC: tipc int vs size_t fixes

[Paul Gortmaker]

This is a starting point for fixing up the mix of int vs. size_t
usage that Dan spotted in TIPC as being open to possible exploits.

Open questions I had remaining with these patches were whether we could
trim out some of the unrequired casts, and whether we wanted to use a
size_t for everything that at any time was based on or compared to
an iov_len, including all instances of num_sect, when things like
iov_length() in <linux/uio.h> use unsigned long for looping over segments.
Also, whether we should give up at INT_MAX or LONG_MAX...

Please suggest changes as required, and I'll integrate them into this
pass1 of draft of patches from Al and resend as required until we've
got a final acceptable solution.

Thanks,
Paul.

Re: [PATCH 1/4] tipc: Fix bugs in tipc_msg_calc_data_size()

[David Miller]

From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Wed, 27 Oct 2010 15:13:33 -0400

> From: Allan Stephens <Allan.Stephens@windriver.com>
> 
> Enhances TIPC's computation of the amount of data to be sent so that
> it works properly when large values are involved. Calculations are now
> done using "size_t" instead of "int", and a check has been added to
> handle cases where the total amount of data exceeds the range of "size_t".
> 
> Signed-off-by: Allan Stephens <Allan.Stephens@windriver.com>

The protocol socket I/O call ops can't even return anything larger
than an 'int' because of the signature for those function pointers
(check out *sendmsg and *recvmsg in include/linux/net.h).

So returning "long" from here doesn't make any sense.

You really have to limit the usable lengths to the range of
an 'int' all the way up to the code in net/socket.c

[PATCH 0/4] RFC: tipc int vs size_t fixes

[Paul Gortmaker]

[apologies if you get this 2x ; a bogus Status: header caused them
 to fail vger's sanity check for netdev, so resending.]

This is a starting point for fixing up the mix of int vs. size_t
usage that Dan spotted in TIPC as being open to possible exploits.

Open questions I had remaining with these patches were whether we could
trim out some of the unrequired casts, and whether we wanted to use a
size_t for everything that at any time was based on or compared to
an iov_len, including all instances of num_sect, when things like
iov_length() in <linux/uio.h> use unsigned long for looping over segments.
Also, whether we should give up at INT_MAX or LONG_MAX...

Please suggest changes as required, and I'll integrate them into this
pass1 of draft of patches from Al and resend as required until we've
got a final acceptable solution.

Thanks,
Paul.