commit d2b6cc8e460494251442a877fcbc150faa175b4f upstream.
skb_linearize(skb) possibly rearranges the skb internal data and then changes the skb->data pointer value. For this reason any other pointer in the code that was assigned skb->data before invoking skb_linearise(skb) must be re-assigned.
In the current tt_query message handling code this is not done and therefore, in case of skb linearization, the pointer used to handle the packet header ends up in pointing to poisoned memory. The packet is then dropped but the translation-table mechanism is corrupted.
Signed-off-by: Antonio Quartulli ordex@autistici.org Cc: stable@vger.kernel.org # 3.3 Signed-off-by: Sven Eckelmann sven@narfation.org --- net/batman-adv/routing.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/net/batman-adv/routing.c b/net/batman-adv/routing.c index 773e606..7d3ac4e 100644 --- a/net/batman-adv/routing.c +++ b/net/batman-adv/routing.c @@ -622,6 +622,8 @@ int recv_tt_query(struct sk_buff *skb, struct hard_iface *recv_if) * changes */ if (skb_linearize(skb) < 0) goto out; + /* skb_linearize() possibly changed skb->data */ + tt_query = (struct tt_query_packet *)skb->data;
tt_len = tt_query->tt_data * sizeof(struct tt_change);
From: Antonio Quartulli ordex@autistici.org Date: Tue, 19 Jun 2012 09:20:30 +0200
commit d2b6cc8e460494251442a877fcbc150faa175b4f upstream.
That commit does not exist in Linus's tree.
It exists in the net-next tree.
You must only make stable submissions for patches that have made their way into Linus's tree.
On Tuesday 19 June 2012 00:41:40 David Miller wrote: [....]
You must only make stable submissions for patches that have made their way into Linus's tree.
That is correct. These patches were meant to be sent as reply to the patch you pulled today (that contained the initial Cc: stable@...). These were sent to avoid the cherry-pick of feature patches necessary to merge it and still give an idea how these versions could be fixed after the mentioned commit hit Linus' tree.
Somebody forgot the set the In-Reply-To:.. that made these mails missing the right context.
But we were wondering how to handle this situation anyway. The stable_kernel_rules.txt didn't gave us the correct information (or we did not understand them correctly) how to submit backported patches for affected kernels. Are there some general rules that we should be aware of?
Thanks, Sven
From: Sven Eckelmann sven@narfation.org Date: Tue, 19 Jun 2012 10:07:12 +0200
On Tuesday 19 June 2012 00:41:40 David Miller wrote: [....]
You must only make stable submissions for patches that have made their way into Linus's tree.
That is correct. These patches were meant to be sent as reply to the patch you pulled today (that contained the initial Cc: stable@...). These were sent to avoid the cherry-pick of feature patches necessary to merge it and still give an idea how these versions could be fixed after the mentioned commit hit Linus' tree.
Patches you want to end up in -stable should be submitted for 'net' not 'net-next'.
There is no other valid submission scheme.
On Tuesday 19 June 2012 02:02:27 David Miller wrote: [....]
Patches you want to end up in -stable should be submitted for 'net' not 'net-next'.
There is no other valid submission scheme.
I know that. This is also completely right and not contested by me. I did not submit/create the pull request and don't want to talk about that part too much. At least I am not very good in speaking for other people and don't want to create more hiccups than I already caused :)
The part that was more interesting for me is the backporting (+ submission of these patches) or annotation to which kernel that patch should be backported. The stable_kernel_rules.txt gives a nice overview about how to say which other patches should be cherry-picked to get this fix applied. But we could also have the problem with kernel version that are not obvious (since the patch doesn't apply directly on that version) and a backported patch is a better choice than cherry-picking many other things.
Is it correct as Antonio did it (submitting more than one patch, but with a special "# 3.x" for each one after the Cc: )?
I don't want a big discussion. Just a small hint how it is preferred (maybe nothing should be done and the stable committee will guess it.. for example the commit id that introduced the problem was missing, but could be used to find the affected kernels quite easily).
Thanks, Sven
On Tue, 2012-06-19 at 11:51 +0200, Sven Eckelmann wrote:
On Tuesday 19 June 2012 02:02:27 David Miller wrote: [....]
Patches you want to end up in -stable should be submitted for 'net' not 'net-next'.
There is no other valid submission scheme.
I know that. This is also completely right and not contested by me. I did not submit/create the pull request and don't want to talk about that part too much. At least I am not very good in speaking for other people and don't want to create more hiccups than I already caused :)
The part that was more interesting for me is the backporting (+ submission of these patches) or annotation to which kernel that patch should be backported. The stable_kernel_rules.txt gives a nice overview about how to say which other patches should be cherry-picked to get this fix applied. But we could also have the problem with kernel version that are not obvious (since the patch doesn't apply directly on that version) and a backported patch is a better choice than cherry-picking many other things.
Is it correct as Antonio did it (submitting more than one patch, but with a special "# 3.x" for each one after the Cc: )?
[...]
There's not much sense in a 'cc' if you're sending a new message (the backport) specificaly to stable. Instead, use a subject like '[PATCH 3.x] original commit summary'. You do need to make clear that this is a backport and not just a request to cherry-pick the upstream commit.
Also, you should wait and send it after the original goes upstream, because stable maintainers will usually want to either apply or reject immediately rather than storing things up. Greg's scripts will tell you when this happens, or at least when he next checks.
Ben.
On Tuesday 19 June 2012 13:10:11 Ben Hutchings wrote:
[...]
There's not much sense in a 'cc' if you're sending a new message (the backport) specificaly to stable. Instead, use a subject like '[PATCH 3.x] original commit summary'. You do need to make clear that this is a backport and not just a request to cherry-pick the upstream commit.
Also, you should wait and send it after the original goes upstream, because stable maintainers will usually want to either apply or reject immediately rather than storing things up. Greg's scripts will tell you when this happens, or at least when he next checks.
Thanks a lot.
Regards, Sven
b.a.t.m.a.n@lists.open-mesh.org
-
Antonio Quartulli -
Ben Hutchings -
David Miller -
Sven Eckelmann