From 48dca1a0d26ae4b9cb88b471444534b5c6f569f7 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Tue, 19 Oct 2010 17:43:33 -0700 Subject: [PATCH] .27 patches --- queue-2.6.27/atl1-fix-resume.patch | 40 +++++++++ ...ne-fix-interrupt-clearing-for-mv_xor.patch | 42 +++++++++ queue-2.6.27/series | 4 + ...compat-microcode-loading-translation.patch | 88 +++++++++++++++++++ ...al-private-ioctl-memory-content-leak.patch | 39 ++++++++ 5 files changed, 213 insertions(+) create mode 100644 queue-2.6.27/atl1-fix-resume.patch create mode 100644 queue-2.6.27/dmaengine-fix-interrupt-clearing-for-mv_xor.patch create mode 100644 queue-2.6.27/v4l1-fix-32-bit-compat-microcode-loading-translation.patch create mode 100644 queue-2.6.27/wext-fix-potential-private-ioctl-memory-content-leak.patch diff --git a/queue-2.6.27/atl1-fix-resume.patch b/queue-2.6.27/atl1-fix-resume.patch new file mode 100644 index 00000000000..4c5bb508d06 --- /dev/null +++ b/queue-2.6.27/atl1-fix-resume.patch @@ -0,0 +1,40 @@ +From ec5a32f67c603b11d68eb283d94eb89a4f6cfce1 Mon Sep 17 00:00:00 2001 +From: Luca Tettamanti +Date: Wed, 22 Sep 2010 10:41:58 +0000 +Subject: atl1: fix resume + +From: Luca Tettamanti + +commit ec5a32f67c603b11d68eb283d94eb89a4f6cfce1 upstream. + +adapter->cmb.cmb is initialized when the device is opened and freed when +it's closed. Accessing it unconditionally during resume results either +in a crash (NULL pointer dereference, when the interface has not been +opened yet) or data corruption (when the interface has been used and +brought down adapter->cmb.cmb points to a deallocated memory area). + +Signed-off-by: Luca Tettamanti +Acked-by: Chris Snook +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/atlx/atl1.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/drivers/net/atlx/atl1.c ++++ b/drivers/net/atlx/atl1.c +@@ -2881,10 +2881,11 @@ static int atl1_resume(struct pci_dev *p + pci_enable_wake(pdev, PCI_D3cold, 0); + + atl1_reset_hw(&adapter->hw); +- adapter->cmb.cmb->int_stats = 0; + +- if (netif_running(netdev)) ++ if (netif_running(netdev)) { ++ adapter->cmb.cmb->int_stats = 0; + atl1_up(adapter); ++ } + netif_device_attach(netdev); + + return 0; diff --git a/queue-2.6.27/dmaengine-fix-interrupt-clearing-for-mv_xor.patch b/queue-2.6.27/dmaengine-fix-interrupt-clearing-for-mv_xor.patch new file mode 100644 index 00000000000..e43a62c914b --- /dev/null +++ b/queue-2.6.27/dmaengine-fix-interrupt-clearing-for-mv_xor.patch @@ -0,0 +1,42 @@ +From cc60f8878eab892c03d06b10f389232b9b66bd83 Mon Sep 17 00:00:00 2001 +From: Simon Guinot +Date: Fri, 17 Sep 2010 23:33:51 +0200 +Subject: dmaengine: fix interrupt clearing for mv_xor + +From: Simon Guinot + +commit cc60f8878eab892c03d06b10f389232b9b66bd83 upstream. + +When using simultaneously the two DMA channels on a same engine, some +transfers are never completed. For example, an endless lock can occur +while writing heavily on a RAID5 array (with async-tx offload support +enabled). + +Note that this issue can also be reproduced by using the DMA test +client. + +On a same engine, the interrupt cause register is shared between two +DMA channels. This patch make sure that the cause bit is only cleared +for the requested channel. + +Signed-off-by: Simon Guinot +Tested-by: Luc Saillard +Acked-by: saeed bishara +Signed-off-by: Dan Williams +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/dma/mv_xor.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/dma/mv_xor.c ++++ b/drivers/dma/mv_xor.c +@@ -162,7 +162,7 @@ static int mv_is_err_intr(u32 intr_cause + + static void mv_xor_device_clear_eoc_cause(struct mv_xor_chan *chan) + { +- u32 val = (1 << (1 + (chan->idx * 16))); ++ u32 val = ~(1 << (chan->idx * 16)); + dev_dbg(chan->device->common.dev, "%s, val 0x%08x\n", __func__, val); + __raw_writel(val, XOR_INTR_CAUSE(chan)); + } diff --git a/queue-2.6.27/series b/queue-2.6.27/series index 2212e0c33c7..4585a4349e3 100644 --- a/queue-2.6.27/series +++ b/queue-2.6.27/series @@ -2,3 +2,7 @@ aio-check-for-multiplication-overflow-in-do_io_submit.patch guard-page-for-stacks-that-grow-upwards.patch alsa-sound-pci-rme9652-prevent-reading-uninitialized-stack-memory.patch alsa-prevent-heap-corruption-in-snd_ctl_new.patch +v4l1-fix-32-bit-compat-microcode-loading-translation.patch +dmaengine-fix-interrupt-clearing-for-mv_xor.patch +wext-fix-potential-private-ioctl-memory-content-leak.patch +atl1-fix-resume.patch diff --git a/queue-2.6.27/v4l1-fix-32-bit-compat-microcode-loading-translation.patch b/queue-2.6.27/v4l1-fix-32-bit-compat-microcode-loading-translation.patch new file mode 100644 index 00000000000..cd5e0fa852a --- /dev/null +++ b/queue-2.6.27/v4l1-fix-32-bit-compat-microcode-loading-translation.patch @@ -0,0 +1,88 @@ +From 3e645d6b485446c54c6745c5e2cf5c528fe4deec Mon Sep 17 00:00:00 2001 +From: Linus Torvalds +Date: Fri, 15 Oct 2010 11:12:38 -0700 +Subject: v4l1: fix 32-bit compat microcode loading translation + +From: Linus Torvalds + +commit 3e645d6b485446c54c6745c5e2cf5c528fe4deec upstream. + +The compat code for the VIDIOCSMICROCODE ioctl is totally buggered. +It's only used by the VIDEO_STRADIS driver, and that one is scheduled to +staging and eventually removed unless somebody steps up to maintain it +(at which point it should use request_firmware() rather than some magic +ioctl). So we'll get rid of it eventually. + +But in the meantime, the compatibility ioctl code is broken, and this +tries to get it to at least limp along (even if Mauro suggested just +deleting it entirely, which may be the right thing to do - I don't think +the compatibility translation code has ever worked unless you were very +lucky). + +Reported-by: Kees Cook +Cc: Mauro Carvalho Chehab +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/media/video/compat_ioctl32.c | 32 +++++++++++++++++++++----------- + 1 file changed, 21 insertions(+), 11 deletions(-) + +--- a/drivers/media/video/compat_ioctl32.c ++++ b/drivers/media/video/compat_ioctl32.c +@@ -499,17 +499,24 @@ struct video_code32 + { + char loadwhat[16]; /* name or tag of file being passed */ + compat_int_t datasize; +- unsigned char *data; ++ compat_uptr_t data; + }; + +-static inline int microcode32(struct video_code *kp, struct video_code32 __user *up) ++static struct video_code __user *get_microcode32(struct video_code32 *kp) + { +- if(!access_ok(VERIFY_READ, up, sizeof(struct video_code32)) || +- copy_from_user(kp->loadwhat, up->loadwhat, sizeof (up->loadwhat)) || +- get_user(kp->datasize, &up->datasize) || +- copy_from_user(kp->data, up->data, up->datasize)) +- return -EFAULT; +- return 0; ++ struct video_code __user *up; ++ ++ up = compat_alloc_user_space(sizeof(*up)); ++ ++ /* ++ * NOTE! We don't actually care if these fail. If the ++ * user address is invalid, the native ioctl will do ++ * the error handling for us ++ */ ++ (void) copy_to_user(up->loadwhat, kp->loadwhat, sizeof(up->loadwhat)); ++ (void) put_user(kp->datasize, &up->datasize); ++ (void) put_user(compat_ptr(kp->data), &up->data); ++ return up; + } + + #define VIDIOCGTUNER32 _IOWR('v',4, struct video_tuner32) +@@ -618,7 +625,7 @@ static int do_video_ioctl(struct file *f + struct video_tuner vt; + struct video_buffer vb; + struct video_window vw; +- struct video_code vc; ++ struct video_code32 vc; + struct video_audio va; + #endif + struct v4l2_format v2f; +@@ -745,8 +752,11 @@ static int do_video_ioctl(struct file *f + break; + #ifdef CONFIG_VIDEO_V4L1_COMPAT + case VIDIOCSMICROCODE: +- err = microcode32(&karg.vc, up); +- compatible_arg = 0; ++ /* Copy the 32-bit "video_code32" to kernel space */ ++ if (copy_from_user(&karg.vc, up, sizeof(karg.vc))) ++ return -EFAULT; ++ /* Convert the 32-bit version to a 64-bit version in user space */ ++ up = get_microcode32(&karg.vc); + break; + #endif + }; diff --git a/queue-2.6.27/wext-fix-potential-private-ioctl-memory-content-leak.patch b/queue-2.6.27/wext-fix-potential-private-ioctl-memory-content-leak.patch new file mode 100644 index 00000000000..c1363737e0f --- /dev/null +++ b/queue-2.6.27/wext-fix-potential-private-ioctl-memory-content-leak.patch @@ -0,0 +1,39 @@ +From df6d02300f7c2fbd0fbe626d819c8e5237d72c62 Mon Sep 17 00:00:00 2001 +From: Johannes Berg +Date: Fri, 17 Sep 2010 00:38:25 +0200 +Subject: wext: fix potential private ioctl memory content leak + +From: Johannes Berg + +commit df6d02300f7c2fbd0fbe626d819c8e5237d72c62 upstream. + +When a driver doesn't fill the entire buffer, old +heap contents may remain, and if it also doesn't +update the length properly, this old heap content +will be copied back to userspace. + +It is very unlikely that this happens in any of +the drivers using private ioctls since it would +show up as junk being reported by iwpriv, but it +seems better to be safe here, so use kzalloc. + +Reported-by: Jeff Mahoney +Signed-off-by: Johannes Berg +Signed-off-by: John W. Linville +Signed-off-by: Greg Kroah-Hartman + +--- + net/wireless/wext.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/net/wireless/wext.c ++++ b/net/wireless/wext.c +@@ -947,7 +947,7 @@ static int ioctl_private_iw_point(struct + } else if (!iwp->pointer) + return -EFAULT; + +- extra = kmalloc(extra_size, GFP_KERNEL); ++ extra = kzalloc(extra_size, GFP_KERNEL); + if (!extra) + return -ENOMEM; + -- 2.47.2