Hi, I'm Hádrien Romero Soria - @Kaiwaiata, I am a 16 year old boy, passionate about computer security, since more than 2h searching and finding various possible vulnerabilities in source code of Linux Kernel.. I will tell you some vulnerabilities now, if they treat me well I will tell the other.. foolish or important things? linux3.16.tar\linux-3.16\arch\um\os-Linux\drivers\ethertap_user.c: lines: 30: struct addr_change { enum { ADD_ADDR, DEL_ADDR } what; unsigned char addr[4]; // look here unsigned char netmask[4]; // look here }; static void etap_change(int op, unsigned char *addr, unsigned char *netmask, int fd) { struct addr_change change; // look here char *output; int n; change.what = op; memcpy(change.addr, addr, sizeof(change.addr)); // look here memcpy(change.netmask, netmask, sizeof(change.netmask)); // look here .. .. .. .. } linux3.16.tar\linux-3.16\arch\um\os-Linux\drivers\ethertap_user.c: lines: 108: strcpy(gate_buf, gate); # if an attacker manages to take control e.g:addr_change, gate.. may cause a buffer overflow, which would be directed toward .bss (an uninitialized global, so he goes to the BSS segment) it's not too dangerous but is a vulnerability. linux3.16.tar\linux-3.16\arch\um\os-Linux\drivers\ethertap_user.c: lines: 47: if (n != sizeof(change)) { # Compare an unsigned numeric value with a signed numeric value, ccould cause extremely long numbers (negative and positive) i hope answer, thanks a lot!, HádrienR - kaiwaiata
Don't see the etap problem ? 108: I don't think ethertap_user.c is exploitable because all the inputs that matter check. That said I can't prove it's so - so yes it would be a sensible change (um is very old code and probably ought to just go away, it's not a secure kernel in that form anyway but no excuses) 47: doesn't matter. The types will be co-erced for the comparison and only one matching bit pattern exists. With > or < tests more care can be needed however.