linux-toradex.git, branch v2.6.32.65 Linux kernel for Apalis and Colibri modules Linux 2.6.32.65 2014-12-13T14:16:21+00:00 Willy Tarreau w@1wt.eu 2014-12-13T14:16:05+00:00 3bd0d1ad14c3566107e391732e4df658b005ad67 Signed-off-by: Willy Tarreau <w@1wt.eu> 
Signed-off-by: Willy Tarreau <w@1wt.eu>
proc connector: Delete spurious memset in proc_exit_connector() 2014-12-13T14:16:20+00:00 Ben Hutchings ben@decadent.org.uk 2014-12-07T19:57:36+00:00 6eef90fc28562f7b4fb9f7f1661da08e90673e25 Upstream commit e727ca82e0e9 ("proc connector: fix info leaks") changed many functions that don't exist in 2.6.32.y. When it was cherry-picked into 2.6.32.61, one extra memset() calls was inserted into proc_exit_connector(). This results in clearing the cpu field of exit events. Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Acked-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Willy Tarreau <w@1wt.eu> 
Upstream commit e727ca82e0e9 ("proc connector: fix info leaks")
changed many functions that don't exist in 2.6.32.y.  When it was
cherry-picked into 2.6.32.61, one extra memset() calls was inserted
into proc_exit_connector().  This results in clearing the cpu
field of exit events.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Acked-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
cciss: Fix misapplied "cciss: fix info leak in cciss_ioctl32_passthru()" 2014-12-13T14:16:20+00:00 Ben Hutchings ben@decadent.org.uk 2014-12-07T19:57:15+00:00 a99c4d9b097701ce465042c61d7eabf1ff26b4ae Upstream commit 58f09e00ae09 was applied to the wrong function when cherry-picked for 2.6.32.61. Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Willy Tarreau <w@1wt.eu> 
Upstream commit 58f09e00ae09 was applied to the wrong function when
cherry-picked for 2.6.32.61.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Willy Tarreau <w@1wt.eu>
block: Fix blk_execute_rq_nowait() dead queue handling 2014-12-13T14:16:19+00:00 Muthukumar Ratty muthur@gmail.com 2014-12-07T19:56:48+00:00 d22e4c7890e18c3c6565fca208a9ac910a6f8bf5 commit e81ca6fe85b77109a32489a5db82f575d51dfc98 upstream. If the queue is dead blk_execute_rq_nowait() doesn't invoke the done() callback function. That will result in blk_execute_rq() being stuck in wait_for_completion(). Avoid this by initializing rq->end_io to the done() callback before we check the queue state. Also, make sure the queue lock is held around the invocation of the done() callback. Found this through source code review. Signed-off-by: Muthukumar Ratty <muthur@gmail.com> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Tejun Heo <tj@kernel.org> Acked-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: James Bottomley <JBottomley@Parallels.com> [bwh: Backported to 2.6.32: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Willy Tarreau <w@1wt.eu> 
commit e81ca6fe85b77109a32489a5db82f575d51dfc98 upstream.

If the queue is dead blk_execute_rq_nowait() doesn't invoke the done()
callback function. That will result in blk_execute_rq() being stuck
in wait_for_completion(). Avoid this by initializing rq->end_io to the
done() callback before we check the queue state. Also, make sure the
queue lock is held around the invocation of the done() callback. Found
this through source code review.

Signed-off-by: Muthukumar Ratty <muthur@gmail.com>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Tejun Heo <tj@kernel.org>
Acked-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
[bwh: Backported to 2.6.32: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Willy Tarreau <w@1wt.eu>
block: add missing blk_queue_dead() checks 2014-12-13T14:16:19+00:00 Tejun Heo tj@kernel.org 2014-12-07T19:55:49+00:00 3b77fc36cefaacba19a48db43ab3b8dc57cbfc1b commit 8ba61435d73f2274e12d4d823fde06735e8f6a54 upstream. blk_insert_cloned_request(), blk_execute_rq_nowait() and blk_flush_plug_list() either didn't check whether the queue was dead or did it without holding queue_lock. Update them so that dead state is checked while holding queue_lock. AFAICS, this plugs all holes (requeue doesn't matter as the request is transitioning atomically from in_flight to queued). Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Jens Axboe <axboe@kernel.dk> [bwh: Backported to 2.6.32: - Drop inapplicable changes to queue_unplugged() and blk_flush_plug_list() - We don't have blk_queue_dead() so open-code it - Adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Willy Tarreau <w@1wt.eu> 
commit 8ba61435d73f2274e12d4d823fde06735e8f6a54 upstream.

blk_insert_cloned_request(), blk_execute_rq_nowait() and
blk_flush_plug_list() either didn't check whether the queue was dead
or did it without holding queue_lock.  Update them so that dead state
is checked while holding queue_lock.

AFAICS, this plugs all holes (requeue doesn't matter as the request is
transitioning atomically from in_flight to queued).

Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
[bwh: Backported to 2.6.32:
 - Drop inapplicable changes to queue_unplugged() and
   blk_flush_plug_list()
 - We don't have blk_queue_dead() so open-code it
 - Adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Willy Tarreau <w@1wt.eu>
md/raid6: Fix misapplied backport in 2.6.32.64 2014-12-13T14:16:18+00:00 Ben Hutchings ben@decadent.org.uk 2014-12-07T20:00:27+00:00 d49465185ef41bea43666e349b72b6d1e1fbd296 Upstream commit 9c4bdf697c39 ("md/raid6: avoid data corruption during recovery of double-degraded RAID6") changes handle_stripe(), but we have separate functions for RAID5 and RAID6 and need to apply the change to handle_stripe6(). When cherry-picked, the change was wrongly applied to handle_stripe5(). Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Willy Tarreau <w@1wt.eu> 
Upstream commit 9c4bdf697c39 ("md/raid6: avoid data corruption during
recovery of double-degraded RAID6") changes handle_stripe(), but we
have separate functions for RAID5 and RAID6 and need to apply the
change to handle_stripe6().  When cherry-picked, the change was
wrongly applied to handle_stripe5().

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Willy Tarreau <w@1wt.eu>
sctp: Fix double-free introduced by bad backport in 2.6.32.62 2014-12-13T14:16:18+00:00 Ben Hutchings ben@decadent.org.uk 2014-12-07T19:59:23+00:00 7185a7199b3e6540e72c718db0ad1a91676e37d0 One deletion was omitted from the backport of upstream commit c485658bae87 ("net: sctp: fix skb leakage in COOKIE ECHO path of chunk->auth_chunk"). Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Willy Tarreau <w@1wt.eu> 
One deletion was omitted from the backport of upstream commit c485658bae87
("net: sctp: fix skb leakage in COOKIE ECHO path of chunk->auth_chunk").

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Willy Tarreau <w@1wt.eu>
vlan: Don't propagate flag changes on down interfaces. 2014-12-13T14:16:17+00:00 Matthijs Kooijman matthijs@stdin.nl 2014-12-07T19:58:41+00:00 04b872de72b9ddc84d4a0feae477ca7a484af9c1 commit deede2fabe24e00bd7e246eb81cd5767dc6fcfc7 upstream. When (de)configuring a vlan interface, the IFF_ALLMULTI ans IFF_PROMISC flags are cleared or set on the underlying interface. So, if these flags are changed on a vlan interface that is not up, the flags underlying interface might be set or cleared twice. Only propagating flag changes when a device is up makes sure this does not happen. It also makes sure that an underlying device is not set to promiscuous or allmulti mode for a vlan device that is down. Signed-off-by: Matthijs Kooijman <matthijs@stdin.nl> Signed-off-by: David S. Miller <davem@davemloft.net> [bwh: This is a dependency of commit d2615bf45069 ("net: core: Always propagate flag changes to interfaces"), already backported in 2.6.32.62] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Willy Tarreau <w@1wt.eu> 
commit deede2fabe24e00bd7e246eb81cd5767dc6fcfc7 upstream.

When (de)configuring a vlan interface, the IFF_ALLMULTI ans IFF_PROMISC
flags are cleared or set on the underlying interface. So, if these flags
are changed on a vlan interface that is not up, the flags underlying
interface might be set or cleared twice.

Only propagating flag changes when a device is up makes sure this does
not happen. It also makes sure that an underlying device is not set to
promiscuous or allmulti mode for a vlan device that is down.

Signed-off-by: Matthijs Kooijman <matthijs@stdin.nl>
Signed-off-by: David S. Miller <davem@davemloft.net>
[bwh: This is a dependency of commit d2615bf45069 ("net: core: Always
 propagate flag changes to interfaces"), already backported in 2.6.32.62]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Willy Tarreau <w@1wt.eu>
ttusb-dec: buffer overflow in ioctl 2014-12-13T14:16:17+00:00 Dan Carpenter dan.carpenter@oracle.com 2014-11-24T12:16:11+00:00 44023d2f627574ac8a22c2ede35b7f8528bc7912 commit dc0ab1ddeb0c5f5eb3f37a72eadb394792b3c40d upstream We need to add a limit check here so we don't overflow the buffer. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> (backported from commit f2e323ec96077642d397bb1c355def536d489d16) CVE-2014-8884 BugLink: http://bugs.launchpad.net/bugs/1395187 Signed-off-by: Luis Henriques <luis.henriques@canonical.com> Acked-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Andy Whitcroft <apw@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Willy Tarreau <w@1wt.eu> 
commit dc0ab1ddeb0c5f5eb3f37a72eadb394792b3c40d upstream

We need to add a limit check here so we don't overflow the buffer.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
(backported from commit f2e323ec96077642d397bb1c355def536d489d16)
CVE-2014-8884
BugLink: http://bugs.launchpad.net/bugs/1395187
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Acked-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
mac80211: fix fragmentation code, particularly for encryption 2014-12-13T14:16:16+00:00 Johannes Berg johannes.berg@intel.com 2014-11-24T12:16:18+00:00 ed99f57702c1173908edfc079abb54de412117b0 commit a722a419815ed203b519151f9556859ff256638b upstream The "new" fragmentation code (since my rewrite almost 5 years ago) erroneously sets skb->len rather than using skb_trim() to adjust the length of the first fragment after copying out all the others. This leaves the skb tail pointer pointing to after where the data originally ended, and thus causes the encryption MIC to be written at that point, rather than where it belongs: immediately after the data. The impact of this is that if software encryption is done, then a) encryption doesn't work for the first fragment, the connection becomes unusable as the first fragment will never be properly verified at the receiver, the MIC is practically guaranteed to be wrong b) we leak up to 8 bytes of plaintext (!) of the packet out into the air This is only mitigated by the fact that many devices are capable of doing encryption in hardware, in which case this can't happen as the tail pointer is irrelevant in that case. Additionally, fragmentation is not used very frequently and would normally have to be configured manually. Fix this by using skb_trim() properly. Cc: stable@vger.kernel.org Fixes: 2de8e0d999b8 ("mac80211: rewrite fragmentation") Reported-by: Jouni Malinen <j@w1.fi> Signed-off-by: Johannes Berg <johannes.berg@intel.com> (backported from commit 338f977f4eb441e69bb9a46eaa0ac715c931a67f) CVE-2014-8709 BugLink: http://bugs.launchpad.net/bugs/1392013 Signed-off-by: Luis Henriques <luis.henriques@canonical.com> Acked-by: Andy Whitcroft <apw@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Willy Tarreau <w@1wt.eu> 
commit a722a419815ed203b519151f9556859ff256638b upstream

The "new" fragmentation code (since my rewrite almost 5 years ago)
erroneously sets skb->len rather than using skb_trim() to adjust
the length of the first fragment after copying out all the others.
This leaves the skb tail pointer pointing to after where the data
originally ended, and thus causes the encryption MIC to be written
at that point, rather than where it belongs: immediately after the
data.

The impact of this is that if software encryption is done, then
 a) encryption doesn't work for the first fragment, the connection
    becomes unusable as the first fragment will never be properly
    verified at the receiver, the MIC is practically guaranteed to
    be wrong
 b) we leak up to 8 bytes of plaintext (!) of the packet out into
    the air

This is only mitigated by the fact that many devices are capable
of doing encryption in hardware, in which case this can't happen
as the tail pointer is irrelevant in that case. Additionally,
fragmentation is not used very frequently and would normally have
to be configured manually.

Fix this by using skb_trim() properly.

Cc: stable@vger.kernel.org
Fixes: 2de8e0d999b8 ("mac80211: rewrite fragmentation")
Reported-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
(backported from commit 338f977f4eb441e69bb9a46eaa0ac715c931a67f)
CVE-2014-8709
BugLink: http://bugs.launchpad.net/bugs/1392013
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Acked-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>