All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oren Laadan <orenl-RdfvBDnrOixBDgjK7y7TUQ@public.gmane.org>
To: Dan Smith <danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Cc: containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org
Subject: Re: [PATCH 1/3] Record and restore skb header marks (v2)
Date: Thu, 29 Oct 2009 16:10:34 -0400	[thread overview]
Message-ID: <4AE9F6BA.8050601@librato.com> (raw)
In-Reply-To: <1256666008-8231-2-git-send-email-danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>



Dan Smith wrote:
> Save this information when we checkpoint an skb and provide a mechanism
> to restore that information on restart.  This will be used in the
> subsequent INET patch.
> 
> Signed-off-by: Dan Smith <danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
> 
> Changes in v2:
>  - Add range checks to ensure that the header marks we restore
>    are within the data length of the skb

[...]

> +int sock_restore_header_info(struct sk_buff *skb,
> +			     struct ckpt_hdr_socket_buffer *h)
> +{
> +	if ((h->transport_header >= skb->len) ||
> +	    (h->network_header >= skb->len) ||
> +	    (h->mac_header >= skb->len) ||
> +	    (h->mac_len >= skb->len) ||
> +	    (h->hdr_len >= skb->len)) {

I wonder if the sanity test for mac_len and hdr_len are sufficient,
or whether a more constrained test is required.

For example, a quick grep shows that there are several places where:
	skb->mac_len = skb->network_header - skb->mac_header;

I think there is some code that relies on it without validating
that the value makes sense.

> +		ckpt_debug("skb header positions not within data length\n");
> +		return -EINVAL;
> +	}
> +
> +	skb->mac_len = h->mac_len;
> +	skb->hdr_len = h->hdr_len;
> +
> +	skb_set_transport_header(skb, h->transport_header);
> +	skb_set_network_header(skb, h->network_header);
> +	skb_set_mac_header(skb, h->mac_header);
> +
> +	memcpy(skb->cb, h->cb, sizeof(skb->cb));

The skb->cb holds can be used by any layer to put private variables.

Can the user mangle the data in there to create a disaster of some
sort ?

If the answer is "it's possible", and because this is per protocol
data, I suggest to add a per-protocol callback to sanitize the data
in this control buffer.

To not block this patchset infinitely, I guess you can put the
details of the sanity check in a separate patch(set). But I prefer
that the current set will at least mention and provision for such
a mechanism.

> +
> +	return 0;
> +}
> +
>  static int __sock_write_buffers(struct ckpt_ctx *ctx,
>  				struct sk_buff_head *queue,
>  				int dst_objref)
> @@ -123,6 +167,7 @@ static int __sock_write_buffers(struct ckpt_ctx *ctx,
>  			goto end;
>  		h->sk_objref = ret;
>  		h->pr_objref = dst_objref;
> +		sock_record_header_info(skb, h);
>  
>  		ret = ckpt_write_obj(ctx, (struct ckpt_hdr *) h);
>  		if (ret < 0)

Oren.

  parent reply	other threads:[~2009-10-29 20:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-27 17:53 Add support for connected AF_INET sockets Dan Smith
2009-10-27 17:53 ` [PATCH 2/3] [RFC] Add c/r support for connected INET sockets (v3) Dan Smith
2009-10-29 20:15   ` Oren Laadan
     [not found] ` <1256666008-8231-1-git-send-email-danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-10-27 17:53   ` [PATCH 1/3] Record and restore skb header marks (v2) Dan Smith
     [not found]     ` <1256666008-8231-2-git-send-email-danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-10-29 20:10       ` Oren Laadan [this message]
     [not found]         ` <4AE9F6BA.8050601-RdfvBDnrOixBDgjK7y7TUQ@public.gmane.org>
2009-11-10 18:18           ` Dan Smith
2009-10-27 17:53   ` [PATCH 3/3] Add some content to the readme.txt for socket c/r Dan Smith

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4AE9F6BA.8050601@librato.com \
    --to=orenl-rdfvbdnroixbdgjk7y7tuq@public.gmane.org \
    --cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
    --cc=danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.