The 2.6.31.2 changelog contains these two snippets: net ax25: Fix signed comparison in the sockopt handler net: Make the copy length in af_packet sockopt handler unsigned The ax25 flaw looks real, the af_packet one is probably just a bug. I'm assigning CVE-2009-2909 to the ax25 flaw. Here is my analysis, if someone sees an issue with it, please feel free to speak up. ax25 (CVE-2009-2909) http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commit;h=b7058842c940ad2c08dd829b21e5c92ebe3b8758 http://article.gmane.org/gmane.linux.kernel/896907 In the file af_ax25.c there is this bit: case SO_BINDTODEVICE: if (optlen > IFNAMSIZ) optlen=IFNAMSIZ; if (copy_from_user(devname, optval, optlen)) return -EFAULT; If a user can make the value of optlen wrap to a negative number, the check should pass, but the call to copy_from_user has this check in it: BUG_ON((long) n < 0); Where n is optlen. I'm told this will OOPS the kernel. That means that this flaw should only be a DoS. af_packet (No CVE id, just a bug) http://article.gmane.org/gmane.linux.kernel/896917 I don't think the missed check in af_packet.c is an issue. The check if (len < 0) return -EINVAL; Will never fail, but just beneath that bit in the code, you have if (len > sizeof(struct tpacket_stats)) len = sizeof(struct tpacket_stats); and if (len > sizeof(int)) len = sizeof(int); As our error condition would need len to be a negative number, but the sizeof check will cast it as unsigned, these checks would effectively fail, resetting len to something sane. Even then, all that happens with len, is a copy_to_user, which wouldn't hurt the kernel, but could crash the app (which we likely don't care about in this instance). Thanks.