The 184.108.40.206 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
In the file af_ax25.c there is this bit:
if (optlen > IFNAMSIZ) optlen=IFNAMSIZ;
if (copy_from_user(devname, optval, optlen))
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)
I don't think the missed check in af_packet.c is an issue. The check
if (len < 0)
Will never fail, but just beneath that bit in the code, you have
if (len > sizeof(struct tpacket_stats))
len = sizeof(struct tpacket_stats);
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).