Commit message (Collapse) | Author | Age | Files | Lines | |
---|---|---|---|---|---|
* | [L2TP]: Add the ability to autoload a pppox protocol module. | James Chapman | 2007-04-30 | 1 | -0/+8 |
| | | | | | | | | This patch allows a name "pppox-proto-nnn" to be used in modprobe.conf to autoload a PPPoX protocol nnn. Signed-off-by: James Chapman <jchapman@katalix.com> Signed-off-by: David S. Miller <davem@davemloft.net> | ||||
* | [PPPOE]: memory leak when socket is release()d before PPPIOCGCHAN has been ↵ | Florian Zumbiehl | 2007-04-25 | 1 | -1/+1 |
| | | | | | | | | | | | | | | | | | | | | | | | | called on it below you find a patch that fixes a memory leak when a PPPoE socket is release()d after it has been connect()ed, but before the PPPIOCGCHAN ioctl ever has been called on it. This is somewhat of a security problem, too, since PPPoE sockets can be created by any user, so any user can easily allocate all the machine's RAM to non-swappable address space and thus DoS the system. Is there any specific reason for PPPoE sockets being available to any unprivileged process, BTW? After all, you need a packet socket for the discovery stage anyway, so it's unlikely that any unprivileged process will ever need to create a PPPoE socket, no? Allocating all session IDs for a known AC is a kind of DoS, too, after all - with Juniper ERXes, this is really easy, actually, since they don't ever assign session ids above 8000 ... Signed-off-by: Florian Zumbiehl <florz@florz.de> Acked-by: Michal Ostrowski <mostrows@earthlink.net> Signed-off-by: David S. Miller <davem@davemloft.net> | ||||
* | [PPPOX]: Fix assignment into const proto_ops. | David S. Miller | 2006-01-03 | 1 | -7/+3 |
| | | | | | | | | | And actually, with this, the whole pppox layer can basically be removed and subsumed into pppoe.c, no other pppox sub-protocol implementation exists and we've had this thing for at least 4 years. Signed-off-by: David S. Miller <davem@davemloft.net> | ||||
* | Linux-2.6.12-rc2v2.6.12-rc2 | Linus Torvalds | 2005-04-16 | 1 | -0/+153 |
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip! |