On Wed, Jul 06, 2005 at 04:24:53PM -0400, jaegert wrote:
>
> diff -puN net/core/flow.c~lsm-xfrm-nethooks net/core/flow.c
> --- linux-2.6.12-git3-xfrm/net/core/flow.c~lsm-xfrm-nethooks 2005-06-21
> 15:56:40.000000000 -0400
> +++ linux-2.6.12-git3-xfrm-root/net/core/flow.c 2005-06-21
> 15:56:40.000000000 -0400
> @@ -162,7 +162,7 @@ static int flow_key_compare(struct flowi
> return 0;
> }
>
> -void *flow_cache_lookup(struct flowi *key, u16 family, u8 dir,
> +void *flow_cache_lookup(struct flowi *key, struct sock *sk, u16 family, u8
> dir,
> flow_resolve_t resolver)
> {
> struct flow_cache_entry *fle, **head;
> @@ -221,7 +221,7 @@ nocache:
> void *obj;
> atomic_t *obj_ref;
>
> - resolver(key, family, dir, &obj, &obj_ref);
> + resolver(key, sk, family, dir, &obj, &obj_ref);
>
> if (fle) {
> fle->genid = atomic_read(&flow_cache_genid);
This bit looks problematic. For raw sockets you can have the same
flow corresponding to multiple sockets. However, let's put that aside
for now since at least you'll need to be root to get them.
However, even with TCP/UDP sockets, this could happen:
Socket 1 with security context A does flow_cache_lookup thus populating
the cache with the appropriate entry.
Socket 1 is closed.
Socket 2 is opened with the same src/dst addr/port but with a different
security context B. When it does flow_cache_lookup it could pick up the
cached entry from the first socket, right?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
