summaryrefslogtreecommitdiffstats
path: root/net/xfrm
Commit message (Collapse)AuthorAgeFilesLines
* [XFRM]: Eliminate refcounting confusion by creating __xfrm_state_put().Herbert Xu2006-02-232-5/+5
| | | | | | | | | | | | | We often just do an atomic_dec(&x->refcnt) on an xfrm_state object because we know there is more than 1 reference remaining and thus we can elide the heavier xfrm_state_put() call. Do this behind an inline function called __xfrm_state_put() so that is more obvious and also to allow us to more cleanly add refcount debugging later. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
* [NETFILTER]: Fix bridge netfilter related in xfrm_lookupPatrick McHardy2006-02-231-3/+4
| | | | | | | | | | | | | The bridge-netfilter code attaches a fake dst_entry with dst->ops == NULL to purely bridged packets. When these packets are SNATed and a policy lookup is done, xfrm_lookup crashes because it tries to dereference dst->ops. Change xfrm_lookup not to dereference dst->ops before checking for the DST_NOXFRM flag and set this flag in the fake dst_entry. Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* [XFRM]: Fix policy double putPatrick McHardy2006-02-191-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The policy is put once immediately and once at the error label, which results in the following Oops: kernel BUG at net/xfrm/xfrm_policy.c:250! invalid opcode: 0000 [#2] PREEMPT [...] CPU: 0 EIP: 0060:[<c028caf7>] Not tainted VLI EFLAGS: 00210246 (2.6.16-rc3 #39) EIP is at __xfrm_policy_destroy+0xf/0x46 eax: d49f2000 ebx: d49f2000 ecx: f74bd880 edx: f74bd280 esi: d49f2000 edi: 00000001 ebp: cd506dcc esp: cd506dc8 ds: 007b es: 007b ss: 0068 Process ssh (pid: 31970, threadinfo=cd506000 task=cfb04a70) Stack: <0>cd506000 cd506e34 c028e92b ebde7280 cd506e58 cd506ec0 f74bd280 00000000 00000214 0000000a 0000000a 00000000 00000002 f7ae6000 00000000 cd506e58 cd506e14 c0299e36 f74bd280 e873fe00 c02943fd cd506ec0 ebde7280 f271f440 Call Trace: [<c0103a44>] show_stack_log_lvl+0xaa/0xb5 [<c0103b75>] show_registers+0x126/0x18c [<c0103e68>] die+0x14e/0x1db [<c02b6809>] do_trap+0x7c/0x96 [<c0104237>] do_invalid_op+0x89/0x93 [<c01035af>] error_code+0x4f/0x54 [<c028e92b>] xfrm_lookup+0x349/0x3c2 [<c02b0b0d>] ip6_datagram_connect+0x317/0x452 [<c0281749>] inet_dgram_connect+0x49/0x54 [<c02404d2>] sys_connect+0x51/0x68 [<c0240928>] sys_socketcall+0x6f/0x166 [<c0102aa1>] syscall_call+0x7/0xb Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* [IPSEC]: Fix strange IPsec freeze.Herbert Xu2006-02-131-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem discovered and initial patch by Olaf Kirch: there's a problem with IPsec that has been bugging some of our users for the last couple of kernel revs. Every now and then, IPsec will freeze the machine completely. This is with openswan user land, and with kernels up to and including 2.6.16-rc2. I managed to debug this a little, and what happens is that we end up looping in xfrm_lookup, and never get out. With a bit of debug printks added, I can this happening: ip_route_output_flow calls xfrm_lookup xfrm_find_bundle returns NULL (apparently we're in the middle of negotiating a new SA or something) We therefore call xfrm_tmpl_resolve. This returns EAGAIN We go to sleep, waiting for a policy update. Then we loop back to the top Apparently, the dst_orig that was passed into xfrm_lookup has been dropped from the routing table (obsolete=2) This leads to the endless loop, because we now create a new bundle, check the new bundle and find it's stale (stale_bundle -> xfrm_bundle_ok -> dst_check() return 0) People have been testing with the patch below, which seems to fix the problem partially. They still see connection hangs however (things only clear up when they start a new ping or new ssh). So the patch is obvsiouly not sufficient, and something else seems to go wrong. I'm grateful for any hints you may have... I suggest that we simply bail out always. If the dst decides to die on us later on, the packet will be dropped anyway. So there is no great urgency to retry here. Once we have the proper resolution queueing, we can then do the retry again. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Acked-by: Olaf Kirch <okir@suse.de> Signed-off-by: David S. Miller <davem@davemloft.net>
* [PATCH] remove bogus asm/bug.h includes.Al Viro2006-02-071-1/+0
| | | | | | | A bunch of asm/bug.h includes are both not needed (since it will get pulled anyway) and bogus (since they are done too early). Removed. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
* [NET]: Change some "if (x) BUG();" to "BUG_ON(x);"Kris Katterjohn2006-01-092-8/+4
| | | | | | | This changes some simple "if (x) BUG();" statements to "BUG_ON(x);" Signed-off-by: Kris Katterjohn <kjak@users.sourceforge.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* [NETFILTER]: Handle NAT in IPsec policy checksPatrick McHardy2006-01-071-0/+2
| | | | | | | | | Handle NAT of decapsulated IPsec packets by reconstructing the struct flowi of the original packet from the conntrack information for IPsec policy checks. Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* [NETFILTER]: Fix xfrm lookup in ip_route_me_harder/ip6_route_me_harderPatrick McHardy2006-01-071-4/+5
| | | | | | | | | | | | | | | | | ip_route_me_harder doesn't use the port numbers of the xfrm lookup and uses ip_route_input for non-local addresses which doesn't do a xfrm lookup, ip6_route_me_harder doesn't do a xfrm lookup at all. Use xfrm_decode_session and do the lookup manually, make sure both only do the lookup if the packet hasn't been transformed already. Makeing sure the lookup only happens once needs a new field in the IP6CB, which exceeds the size of skb->cb. The size of skb->cb is increased to 48b. Apparently the IPv6 mobile extensions need some more room anyway. Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* [LSM-IPSec]: Corrections to LSM-IPSec NethooksTrent Jaeger2006-01-061-0/+1
| | | | | | | | | | | | | | | This patch contains two corrections to the LSM-IPsec Nethooks patches previously applied. (1) free a security context on a failed insert via xfrm_user interface in xfrm_add_policy. Memory leak. (2) change the authorization of the allocation of a security context in a xfrm_policy or xfrm_state from both relabelfrom and relabelto to setcontext. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: David S. Miller <davem@davemloft.net>
* [LSM-IPSec]: Security association restriction.Trent Jaeger2006-01-033-44/+201
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch series implements per packet access control via the extension of the Linux Security Modules (LSM) interface by hooks in the XFRM and pfkey subsystems that leverage IPSec security associations to label packets. Extensions to the SELinux LSM are included that leverage the patch for this purpose. This patch implements the changes necessary to the XFRM subsystem, pfkey interface, ipv4/ipv6, and xfrm_user interface to restrict a socket to use only authorized security associations (or no security association) to send/receive network packets. Patch purpose: The patch is designed to enable access control per packets based on the strongly authenticated IPSec security association. Such access controls augment the existing ones based on network interface and IP address. The former are very coarse-grained, and the latter can be spoofed. By using IPSec, the system can control access to remote hosts based on cryptographic keys generated using the IPSec mechanism. This enables access control on a per-machine basis or per-application if the remote machine is running the same mechanism and trusted to enforce the access control policy. Patch design approach: The overall approach is that policy (xfrm_policy) entries set by user-level programs (e.g., setkey for ipsec-tools) are extended with a security context that is used at policy selection time in the XFRM subsystem to restrict the sockets that can send/receive packets via security associations (xfrm_states) that are built from those policies. A presentation available at www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf from the SELinux symposium describes the overall approach. Patch implementation details: On output, the policy retrieved (via xfrm_policy_lookup or xfrm_sk_policy_lookup) must be authorized for the security context of the socket and the same security context is required for resultant security association (retrieved or negotiated via racoon in ipsec-tools). This is enforced in xfrm_state_find. On input, the policy retrieved must also be authorized for the socket (at __xfrm_policy_check), and the security context of the policy must also match the security association being used. The patch has virtually no impact on packets that do not use IPSec. The existing Netfilter (outgoing) and LSM rcv_skb hooks are used as before. Also, if IPSec is used without security contexts, the impact is minimal. The LSM must allow such policies to be selected for the combination of socket and remote machine, but subsequent IPSec processing proceeds as in the original case. Testing: The pfkey interface is tested using the ipsec-tools. ipsec-tools have been modified (a separate ipsec-tools patch is available for version 0.5) that supports assignment of xfrm_policy entries and security associations with security contexts via setkey and the negotiation using the security contexts via racoon. The xfrm_user interface is tested via ad hoc programs that set security contexts. These programs are also available from me, and contain programs for setting, getting, and deleting policy for testing this interface. Testing of sa functions was done by tracing kernel behavior. Signed-off-by: Trent Jaeger <tjaeger@cse.psu.edu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
* [IPSEC]: Fix policy updates missed by socketsDavid S. Miller2005-12-221-1/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The problem is that when new policies are inserted, sockets do not see the update (but all new route lookups do). This bug is related to the SA insertion stale route issue solved recently, and this policy visibility problem can be fixed in a similar way. The fix is to flush out the bundles of all policies deeper than the policy being inserted. Consider beginning state of "outgoing" direction policy list: policy A --> policy B --> policy C --> policy D First, realize that inserting a policy into a list only potentially changes IPSEC routes for that direction. Therefore we need not bother considering the policies for other directions. We need only consider the existing policies in the list we are doing the inserting. Consider new policy "B'", inserted after B. policy A --> policy B --> policy B' --> policy C --> policy D Two rules: 1) If policy A or policy B matched before the insertion, they appear before B' and thus would still match after inserting B' 2) Policy C and D, now "shadowed" and after policy B', potentially contain stale routes because policy B' might be selected instead of them. Therefore we only need flush routes assosciated with policies appearing after a newly inserted policy, if any. Signed-off-by: David S. Miller <davem@davemloft.net>
* [IPSEC]: Perform SA switchover immediately.David S. Miller2005-12-192-5/+19
| | | | | | | | | When we insert a new xfrm_state which potentially subsumes an existing one, make sure all cached bundles are flushed so that the new SA is used immediately. Signed-off-by: David S. Miller <davem@davemloft.net>
* [XFRM]: Use generic netlink receive queue processorThomas Graf2005-11-101-56/+5
| | | | | Signed-off-by: Thomas Graf <tgraf@suug.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* [NETLINK]: Make netlink_callback->done() optionalThomas Graf2005-11-101-7/+1
| | | | | | | | Most netlink families make no use of the done() callback, making it optional gets rid of all unnecessary dummy implementations. Signed-off-by: Thomas Graf <tgraf@suug.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* [NET]: kfree cleanupJesper Juhl2005-11-081-8/+4
| | | | | | | | | | | | | | | From: Jesper Juhl <jesper.juhl@gmail.com> This is the net/ part of the big kfree cleanup patch. Remove pointless checks for NULL prior to calling kfree() in net/. Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Arnaldo Carvalho de Melo <acme@conectiva.com.br> Acked-by: Marcel Holtmann <marcel@holtmann.org> Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by: Andrew Morton <akpm@osdl.org>
* [IPSEC]: Kill obsolete get_mss functionHerbert Xu2005-10-262-43/+6
| | | | | | | | | | | | Now that we've switched over to storing MTUs in the xfrm_dst entries, we no longer need the dst's get_mss methods. This patch gets rid of them. It also documents the fact that our MTU calculation is not optimal for ESP. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
* [PATCH] gfp flags annotations - part 1Al Viro2005-10-081-1/+1
| | | | | | | | | | | | - added typedef unsigned int __nocast gfp_t; - replaced __nocast uses for gfp flags with gfp_t - it gives exactly the same warnings as far as sparse is concerned, doesn't change generated code (from gcc point of view we replaced unsigned int with typedef) and documents what's going on far better. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [IPSEC]: Document that policy direction is derived from the index.Herbert Xu2005-10-051-2/+2
| | | | | | | | | | | Here is a patch that adds a helper called xfrm_policy_id2dir to document the fact that the policy direction can be and is derived from the index. This is based on a patch by YOSHIFUJI Hideaki and 210313105@suda.edu.cn. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
* [XFRM]: fix sparse gfp nocast warningsRandy Dunlap2005-10-041-1/+1
| | | | | | | | Fix implicit nocast warnings in xfrm code: net/xfrm/xfrm_policy.c:232:47: warning: implicit cast to nocast type Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* [XFRM]: Always release dst_entry on error in xfrm_lookupPatrick McHardy2005-09-081-4/+4
| | | | | Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* [NET]: use __read_mostly on kmem_cache_t , DEFINE_SNMP_STAT pointersEric Dumazet2005-08-292-2/+2
| | | | | | | | | | | | | This patch puts mostly read only data in the right section (read_mostly), to help sharing of these data between CPUS without memory ping pongs. On one of my production machine, tcp_statistics was sitting in a heavily modified cache line, so *every* SNMP update had to force a reload. Signed-off-by: Eric Dumazet <dada1@cosmosbay.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* [NETLINK]: Add "groups" argument to netlink_kernel_createPatrick McHardy2005-08-291-2/+2
| | | | | Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* [NETLINK]: Convert netlink users to use group numbers instead of bitmasksPatrick McHardy2005-08-291-21/+14
| | | | | Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* [NETLINK]: Fix missing dst_groups initializations in netlink_broadcast usersPatrick McHardy2005-08-291-0/+8
| | | | | | | | netlink_broadcast users must initialize NETLINK_CB(skb).dst_groups to the destination group mask for netlink_recvmsg. Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* [NETLINK]: Add properly module refcounting for kernel netlink sockets.Harald Welte2005-08-291-1/+3
| | | | | | | | | | | - Remove bogus code for compiling netlink as module - Add module refcounting support for modules implementing a netlink protocol - Add support for autoloading modules that implement a netlink protocol as soon as someone opens a socket for that protocol Signed-off-by: Harald Welte <laforge@netfilter.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* [XFRM]: Fix possible overflow of sock->sk_policyHerbert Xu2005-07-261-0/+3
| | | | | | | Spotted by, and original patch by, Balazs Scheidler. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
* [NET]: move config options out to individual protocolsSam Ravnborg2005-07-111-0/+15
| | | | | | | | | | | | | | | | | Move the protocol specific config options out to the specific protocols. With this change net/Kconfig now starts to become readable and serve as a good basis for further re-structuring. The menu structure is left almost intact, except that indention is fixed in most cases. Most visible are the INET changes where several "depends on INET" are replaced with a single ifdef INET / endif pair. Several new files were created to accomplish this change - they are small but serve the purpose that config options are now distributed out where they belongs. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* [IPSEC]: Add xfrm_state_afinfo->init_flagsHerbert Xu2005-06-201-2/+18
| | | | | | | | | | | | | | | This patch adds the xfrm_state_afinfo->init_flags hook which allows each address family to perform any common initialisation that does not require a corresponding destructor call. It will be used subsequently to set the XFRM_STATE_NOPMTUDISC flag in IPv4. It also fixes up the error codes returned by xfrm_init_state. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Acked-by: James Morris <jmorris@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* [IPSEC]: Add xfrm_init_stateHerbert Xu2005-06-203-9/+22
| | | | | | | | | | | | | | | | This patch adds xfrm_init_state which is simply a wrapper that calls xfrm_get_type and subsequently x->type->init_state. It also gets rid of the unused args argument. Abstracting it out allows us to add common initialisation code, e.g., to set family-specific flags. The add_time setting in xfrm_user.c was deleted because it's already set by xfrm_state_alloc. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Acked-by: James Morris <jmorris@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* [IPSEC]: Add XFRMA_SA/XFRMA_POLICY for delete notificationHerbert Xu2005-06-181-4/+43
| | | | | | | | | | | | | | This patch changes the format of the XFRM_MSG_DELSA and XFRM_MSG_DELPOLICY notification so that the main message sent is of the same format as that received by the kernel if the original message was via netlink. This also means that we won't lose the byid information carried in km_event. Since this user interface is introduced by Jamal's patch we can still afford to change it. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
* [IPSEC] Use NLMSG_LENGTH in xfrm_exp_state_notifyJamal Hadi Salim2005-06-181-2/+2
| | | | | | | | Small fixup to use netlink macros instead of hardcoding. Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
* [IPSEC] Fix xfrm_state leaks in error pathPatrick McHardy2005-06-181-2/+2
| | | | | | | | | | | | | | | | | | | | Herbert Xu wrote: > @@ -1254,6 +1326,7 @@ static int pfkey_add(struct sock *sk, st > if (IS_ERR(x)) > return PTR_ERR(x); > > + xfrm_state_hold(x); This introduces a leak when xfrm_state_add()/xfrm_state_update() fail. We hold two references (one from xfrm_state_alloc(), one from xfrm_state_hold()), but only drop one. We need to take the reference because the reference from xfrm_state_alloc() can be dropped by __xfrm_state_delete(), so the fix is to drop both references on error. Same problem in xfrm_user.c. Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
* [IPSEC] Use XFRM_MSG_* instead of XFRM_SAP_*Herbert Xu2005-06-182-47/+20
| | | | | | | | | | This patch removes XFRM_SAP_* and converts them over to XFRM_MSG_*. The netlink interface is meant to map directly onto the underlying xfrm subsystem. Therefore rather than using a new independent representation for the events we can simply use the existing ones from xfrm_user. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* [IPSEC] Set byid for km_event in xfrm_get_policyHerbert Xu2005-06-181-0/+1
| | | | | | | | This patch fixes policy deletion in xfrm_user so that it sets km_event.data.byid. This puts xfrm_user on par with what af_key does in this case. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* [IPSEC] Turn km_event.data into a unionHerbert Xu2005-06-182-8/+6
| | | | | | | This patch turns km_event.data into a union. This makes code that uses it clearer. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* [IPSEC] Kill spurious hard expire messagesHerbert Xu2005-06-182-12/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch ensures that the hard state/policy expire notifications are only sent when the state/policy is successfully removed from their respective tables. As it is, it's possible for a state/policy to both expire through reaching a hard limit, as well as being deleted by the user. Note that this behaviour isn't actually forbidden by RFC 2367. However, it is a quality of implementation issue. As an added bonus, the restructuring in this patch will help eventually in moving the expire notifications from softirq context into process context, thus improving their reliability. One important side-effect from this change is that SAs reaching their hard byte/packet limits are now deleted immediately, just like SAs that have reached their hard time limits. Previously they were announced immediately but only deleted after 30 seconds. This is bad because it prevents the system from issuing an ACQUIRE command until the existing state was deleted by the user or expires after the time is up. In the scenario where the expire notification was lost this introduces a 30 second delay into the system for no good reason. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* [IPSEC] Add complete xfrm event notificationJamal Hadi Salim2005-06-182-25/+321
| | | | | | | | | | | | | Heres the final patch. What this patch provides - netlink xfrm events - ability to have events generated by netlink propagated to pfkey and vice versa. - fixes the acquire lets-be-happy-with-one-success issue Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* From: Kazunori Miyazawa <kazunori@miyazawa.org>Hideaki YOSHIFUJI2005-05-261-2/+2
| | | | | | | | | | [XFRM] Call dst_check() with appropriate cookie This fixes infinite loop issue with IPv6 tunnel mode. Signed-off-by: Kazunori Miyazawa <kazunori@miyazawa.org> Signed-off-by: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* [IPSEC]: Verify key payload in verify_one_algoHerbert Xu2005-05-191-1/+8
| | | | | | | | We need to verify that the payload contains enough data so that attach_one_algo can copy alg_key_len bits from the payload. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
* [IPSEC]: Fixed alg_key_len usage in attach_one_algoHerbert Xu2005-05-191-2/+4
| | | | | | | | | The variable alg_key_len is in bits and not bytes. The function attach_one_algo is currently using it as if it were in bytes. This causes it to read memory which may not be there. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
* [XFRM]: skb_cow_data() does not set proper owner for new skbs.Evgeniy Polyakov2005-05-181-1/+1
| | | | | | | | | | | | | | | | | | | | | It looks like skb_cow_data() does not set proper owner for newly created skb. If we have several fragments for skb and some of them are shared(?) or cloned (like in async IPsec) there might be a situation when we require recreating skb and thus using skb_copy() for it. Newly created skb has neither a destructor nor a socket assotiated with it, which must be copied from the old skb. As far as I can see, current code sets destructor and socket for the first one skb only and uses truesize of the first skb only to increment sk_wmem_alloc value. If above "analysis" is correct then attached patch fixes that. Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
* [IPSEC]: Store idev entriesHerbert Xu2005-05-031-23/+2
| | | | | | | | | | | | | | | | | | | | I found a bug that stopped IPsec/IPv6 from working. About a month ago IPv6 started using rt6i_idev->dev on the cached socket dst entries. If the cached socket dst entry is IPsec, then rt6i_idev will be NULL. Since we want to look at the rt6i_idev of the original route in this case, the easiest fix is to store rt6i_idev in the IPsec dst entry just as we do for a number of other IPv6 route attributes. Unfortunately this means that we need some new code to handle the references to rt6i_idev. That's why this patch is bigger than it would otherwise be. I've also done the same thing for IPv4 since it is conceivable that once these idev attributes start getting used for accounting, we probably need to dereference them for IPv4 IPsec entries too. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
* [XFRM/RTNETLINK]: Decrement qlen properly in {xfrm_,rt}netlink_rcv().David S. Miller2005-05-031-1/+3
| | | | | | | | | | | If we free up a partially processed packet because it's skb->len dropped to zero, we need to decrement qlen because we are dropping out of the top-level loop so it will do the decrement for us. Spotted by Herbert Xu. Signed-off-by: David S. Miller <davem@davemloft.net>
* [NETLINK]: Fix infinite loops in synchronous netlink changes.David S. Miller2005-05-031-4/+3
| | | | | | | The qlen should continue to decrement, even if we pop partially processed SKBs back onto the receive queue. Signed-off-by: David S. Miller <davem@davemloft.net>
* [NETLINK]: Synchronous message processing.Herbert Xu2005-05-031-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Let's recap the problem. The current asynchronous netlink kernel message processing is vulnerable to these attacks: 1) Hit and run: Attacker sends one or more messages and then exits before they're processed. This may confuse/disable the next netlink user that gets the netlink address of the attacker since it may receive the responses to the attacker's messages. Proposed solutions: a) Synchronous processing. b) Stream mode socket. c) Restrict/prohibit binding. 2) Starvation: Because various netlink rcv functions were written to not return until all messages have been processed on a socket, it is possible for these functions to execute for an arbitrarily long period of time. If this is successfully exploited it could also be used to hold rtnl forever. Proposed solutions: a) Synchronous processing. b) Stream mode socket. Firstly let's cross off solution c). It only solves the first problem and it has user-visible impacts. In particular, it'll break user space applications that expect to bind or communicate with specific netlink addresses (pid's). So we're left with a choice of synchronous processing versus SOCK_STREAM for netlink. For the moment I'm sticking with the synchronous approach as suggested by Alexey since it's simpler and I'd rather spend my time working on other things. However, it does have a number of deficiencies compared to the stream mode solution: 1) User-space to user-space netlink communication is still vulnerable. 2) Inefficient use of resources. This is especially true for rtnetlink since the lock is shared with other users such as networking drivers. The latter could hold the rtnl while communicating with hardware which causes the rtnetlink user to wait when it could be doing other things. 3) It is still possible to DoS all netlink users by flooding the kernel netlink receive queue. The attacker simply fills the receive socket with a single netlink message that fills up the entire queue. The attacker then continues to call sendmsg with the same message in a loop. Point 3) can be countered by retransmissions in user-space code, however it is pretty messy. In light of these problems (in particular, point 3), we should implement stream mode netlink at some point. In the mean time, here is a patch that implements synchronous processing. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
* [XFRM]: Cleanup xfrm_msg_min and xfrm_dispatchThomas Graf2005-05-031-37/+36
| | | | | | | | | Converts xfrm_msg_min and xfrm_dispatch to use c99 designated initializers to make greping a little bit easier. Also replaces two hardcoded message type with meaningful names. Signed-off-by: Thomas Graf <tgraf@suug.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* [XFRM]: Fix existence lookup in xfrm_state_findPatrick McHardy2005-04-211-2/+3
| | | | | | | | | Use 'daddr' instead of &tmpl->id.daddr, since the latter might be zero. Also, only perform the lookup when tmpl->id.spi is non-zero. Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-167-0/+4494
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!
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-12 02:50:42 +0000