This is the start of the stable review cycle for the 3.0.97 release.
There are 28 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Fri Sep 27 00:05:34 UTC 2013.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.97-rc1.gz
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 3.0.97-rc1
Anand Avati <[email protected]>
fuse: invalidate inode attributes on xattr modification
Maxim Patlasov <[email protected]>
fuse: postpone end_page_writeback() in fuse_writepage_locked()
Sergei Shtylyov <[email protected]>
mmc: tmio_mmc_dma: fix PIO fallback on SDHI
Jan Kara <[email protected]>
isofs: Refuse RW mount of the filesystem instead of making it RO
Libin <[email protected]>
mm/huge_memory.c: fix potential NULL pointer dereference
Greg Thelen <[email protected]>
memcg: fix multiple large threshold notifications
Jie Liu <[email protected]>
ocfs2: fix the end cluster offset of FIEMAP
Kees Cook <[email protected]>
HID: check for NULL field when setting values
Kees Cook <[email protected]>
HID: ntrig: validate feature report details
Kees Cook <[email protected]>
HID: validate HID report id size
Kees Cook <[email protected]>
HID: pantherlord: validate output report details
Felix Fietkau <[email protected]>
ath9k: avoid accessing MRC registers on single-chain devices
Felix Fietkau <[email protected]>
ath9k: always clear ps filter bit on new assoc
Takashi Iwai <[email protected]>
ALSA: hda - Add Toshiba Satellite C870 to MSI blacklist
Mike Dyer <[email protected]>
ASoC: wm8960: Fix PLL register writes
Tejun Heo <[email protected]>
rculist: list_first_or_null_rcu() should use list_entry_rcu()
Hans de Goede <[email protected]>
usb: config->desc.bLength may not exceed amount of data returned by the device
Oliver Neukum <[email protected]>
USB: cdc-wdm: fix race between interrupt handler and tasklet
Johan Hovold <[email protected]>
USB: mos7720: fix big-endian control requests
Dan Carpenter <[email protected]>
USB: mos7720: use GFP_ATOMIC under spinlock
Dan Carpenter <[email protected]>
staging: comedi: dt282x: dt282x_ai_insn_read() always fails
Jeff Layton <[email protected]>
cifs: ensure that srv_mutex is held when dealing with ssocket pointer
Shawn Nematbakhsh <[email protected]>
usb: xhci: Disable runtime PM suspend for quirky controllers
Peter Maydell <[email protected]>
ARM: PCI: versatile: Fix SMAP register offsets
Roger Pau Monne <[email protected]>
xen-gnt: prevent adding duplicate gnt callbacks
Anton Blanchard <[email protected]>
powerpc: Handle unaligned ldbrx/stdbrx
Herbert Xu <[email protected]>
crypto: api - Fix race condition in larval lookup
Alan Stern <[email protected]>
SCSI: sd: Fix potential out-of-bounds access
-------------
Diffstat:
Makefile | 4 ++--
arch/arm/mach-versatile/pci.c | 6 +++---
arch/powerpc/kernel/align.c | 10 ++++++++++
crypto/api.c | 7 ++++++-
drivers/hid/hid-core.c | 19 ++++++++++++++-----
drivers/hid/hid-ntrig.c | 3 ++-
drivers/hid/hid-pl.c | 10 ++++++++--
drivers/mmc/host/tmio_mmc_dma.c | 4 ++--
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 4 ++++
drivers/net/wireless/ath/ath9k/xmit.c | 1 +
drivers/scsi/sd.c | 11 +++--------
drivers/staging/comedi/drivers/dt282x.c | 3 ++-
drivers/usb/class/cdc-wdm.c | 13 +++++++++----
drivers/usb/core/config.c | 3 ++-
drivers/usb/host/xhci.c | 22 ++++++++++++++++++++++
drivers/usb/serial/mos7720.c | 6 +++---
drivers/xen/grant-table.c | 13 +++++++++++--
fs/cifs/connect.c | 2 ++
fs/fuse/dir.c | 4 ++++
fs/fuse/file.c | 3 ++-
fs/isofs/inode.c | 16 +++++-----------
fs/ocfs2/extent_map.c | 1 -
include/linux/hid.h | 4 +++-
include/linux/rculist.h | 5 +++--
mm/huge_memory.c | 2 ++
mm/memcontrol.c | 8 +++++++-
sound/pci/hda/hda_intel.c | 1 +
sound/soc/codecs/wm8960.c | 6 +++---
28 files changed, 136 insertions(+), 55 deletions(-)
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alan Stern <[email protected]>
commit 984f1733fcee3fbc78d47e26c5096921c5d9946a upstream.
This patch fixes an out-of-bounds error in sd_read_cache_type(), found
by Google's AddressSanitizer tool. When the loop ends, we know that
"offset" lies beyond the end of the data in the buffer, so no Caching
mode page was found. In theory it may be present, but the buffer size
is limited to 512 bytes.
Signed-off-by: Alan Stern <[email protected]>
Reported-by: Dmitry Vyukov <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/scsi/sd.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -2135,14 +2135,9 @@ sd_read_cache_type(struct scsi_disk *sdk
}
}
- if (modepage == 0x3F) {
- sd_printk(KERN_ERR, sdkp, "No Caching mode page "
- "present\n");
- goto defaults;
- } else if ((buffer[offset] & 0x3f) != modepage) {
- sd_printk(KERN_ERR, sdkp, "Got wrong page\n");
- goto defaults;
- }
+ sd_printk(KERN_ERR, sdkp, "No Caching mode page found\n");
+ goto defaults;
+
Page_found:
if (modepage == 8) {
sdkp->WCE = ((buffer[offset + 2] & 0x04) != 0);
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oliver Neukum <[email protected]>
commit 6dd433e6cf2475ce8abec1b467720858c24450eb upstream.
Both could want to submit the same URB. Some checks of the flag
intended to prevent that were missing.
Signed-off-by: Oliver Neukum <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/class/cdc-wdm.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
--- a/drivers/usb/class/cdc-wdm.c
+++ b/drivers/usb/class/cdc-wdm.c
@@ -171,6 +171,7 @@ skip_error:
static void wdm_int_callback(struct urb *urb)
{
int rv = 0;
+ int responding;
int status = urb->status;
struct wdm_device *desc;
struct usb_ctrlrequest *req;
@@ -244,8 +245,8 @@ static void wdm_int_callback(struct urb
desc->response->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
spin_lock(&desc->iuspin);
clear_bit(WDM_READ, &desc->flags);
- set_bit(WDM_RESPONDING, &desc->flags);
- if (!test_bit(WDM_DISCONNECTING, &desc->flags)
+ responding = test_and_set_bit(WDM_RESPONDING, &desc->flags);
+ if (!responding && !test_bit(WDM_DISCONNECTING, &desc->flags)
&& !test_bit(WDM_SUSPENDING, &desc->flags)) {
rv = usb_submit_urb(desc->response, GFP_ATOMIC);
dev_dbg(&desc->intf->dev, "%s: usb_submit_urb %d",
@@ -635,16 +636,20 @@ static void wdm_rxwork(struct work_struc
{
struct wdm_device *desc = container_of(work, struct wdm_device, rxwork);
unsigned long flags;
- int rv;
+ int rv = 0;
+ int responding;
spin_lock_irqsave(&desc->iuspin, flags);
if (test_bit(WDM_DISCONNECTING, &desc->flags)) {
spin_unlock_irqrestore(&desc->iuspin, flags);
} else {
+ responding = test_and_set_bit(WDM_RESPONDING, &desc->flags);
spin_unlock_irqrestore(&desc->iuspin, flags);
- rv = usb_submit_urb(desc->response, GFP_KERNEL);
+ if (!responding)
+ rv = usb_submit_urb(desc->response, GFP_KERNEL);
if (rv < 0 && rv != -EPERM) {
spin_lock_irqsave(&desc->iuspin, flags);
+ clear_bit(WDM_RESPONDING, &desc->flags);
if (!test_bit(WDM_DISCONNECTING, &desc->flags))
schedule_work(&desc->rxwork);
spin_unlock_irqrestore(&desc->iuspin, flags);
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mike Dyer <[email protected]>
commit 85fa532b6ef920b32598df86b194571a7059a77c upstream.
Bit 9 of PLL2,3 and 4 is reserved as '0'. The 24bit fractional part
should be split across each register in 8bit chunks.
Signed-off-by: Mike Dyer <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/soc/codecs/wm8960.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/sound/soc/codecs/wm8960.c
+++ b/sound/soc/codecs/wm8960.c
@@ -801,9 +801,9 @@ static int wm8960_set_dai_pll(struct snd
if (pll_div.k) {
reg |= 0x20;
- snd_soc_write(codec, WM8960_PLL2, (pll_div.k >> 18) & 0x3f);
- snd_soc_write(codec, WM8960_PLL3, (pll_div.k >> 9) & 0x1ff);
- snd_soc_write(codec, WM8960_PLL4, pll_div.k & 0x1ff);
+ snd_soc_write(codec, WM8960_PLL2, (pll_div.k >> 16) & 0xff);
+ snd_soc_write(codec, WM8960_PLL3, (pll_div.k >> 8) & 0xff);
+ snd_soc_write(codec, WM8960_PLL4, pll_div.k & 0xff);
}
snd_soc_write(codec, WM8960_PLL1, reg);
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sergei Shtylyov <[email protected]>
commit f936f9b67b7f8c2eae01dd303a0e90bd777c4679 upstream.
I'm testing SH-Mobile SDHI driver in DMA mode with a new DMA controller using
'bonnie++' and getting DMA error after which the tmio_mmc_dma.c code falls back
to PIO but all commands time out after that. It turned out that the fallback
code calls tmio_mmc_enable_dma() with RX/TX channels already freed and pointers
to them cleared, so that the function bails out early instead of clearing the
DMA bit in the CTL_DMA_ENABLE register. The regression was introduced by commit
162f43e31c5a376ec16336e5d0ac973373d54c89 (mmc: tmio: fix a deadlock).
Moving tmio_mmc_enable_dma() calls to the top of the PIO fallback code in
tmio_mmc_start_dma_{rx|tx}() helps.
Signed-off-by: Sergei Shtylyov <[email protected]>
Acked-by: Guennadi Liakhovetski <[email protected]>
Signed-off-by: Chris Ball <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/mmc/host/tmio_mmc_dma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/mmc/host/tmio_mmc_dma.c
+++ b/drivers/mmc/host/tmio_mmc_dma.c
@@ -88,6 +88,7 @@ static void tmio_mmc_start_dma_rx(struct
pio:
if (!desc) {
/* DMA failed, fall back to PIO */
+ tmio_mmc_enable_dma(host, false);
if (ret >= 0)
ret = -EIO;
host->chan_rx = NULL;
@@ -100,7 +101,6 @@ pio:
}
dev_warn(&host->pdev->dev,
"DMA failed: %d, falling back to PIO\n", ret);
- tmio_mmc_enable_dma(host, false);
}
dev_dbg(&host->pdev->dev, "%s(): desc %p, cookie %d, sg[%d]\n", __func__,
@@ -169,6 +169,7 @@ static void tmio_mmc_start_dma_tx(struct
pio:
if (!desc) {
/* DMA failed, fall back to PIO */
+ tmio_mmc_enable_dma(host, false);
if (ret >= 0)
ret = -EIO;
host->chan_tx = NULL;
@@ -181,7 +182,6 @@ pio:
}
dev_warn(&host->pdev->dev,
"DMA failed: %d, falling back to PIO\n", ret);
- tmio_mmc_enable_dma(host, false);
}
dev_dbg(&host->pdev->dev, "%s(): desc %p, cookie %d\n", __func__,
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kees Cook <[email protected]>
commit 412f30105ec6735224535791eed5cdc02888ecb4 upstream.
A HID device could send a malicious output report that would cause the
pantherlord HID driver to write beyond the output report allocation
during initialization, causing a heap overflow:
[ 310.939483] usb 1-1: New USB device found, idVendor=0e8f, idProduct=0003
...
[ 315.980774] BUG kmalloc-192 (Tainted: G W ): Redzone overwritten
CVE-2013-2892
Signed-off-by: Kees Cook <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/hid/hid-pl.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
--- a/drivers/hid/hid-pl.c
+++ b/drivers/hid/hid-pl.c
@@ -128,8 +128,14 @@ static int plff_init(struct hid_device *
strong = &report->field[0]->value[2];
weak = &report->field[0]->value[3];
debug("detected single-field device");
- } else if (report->maxfield >= 4 && report->field[0]->maxusage == 1 &&
- report->field[0]->usage[0].hid == (HID_UP_LED | 0x43)) {
+ } else if (report->field[0]->maxusage == 1 &&
+ report->field[0]->usage[0].hid ==
+ (HID_UP_LED | 0x43) &&
+ report->maxfield >= 4 &&
+ report->field[0]->report_count >= 1 &&
+ report->field[1]->report_count >= 1 &&
+ report->field[2]->report_count >= 1 &&
+ report->field[3]->report_count >= 1) {
report->field[0]->value[0] = 0x00;
report->field[1]->value[0] = 0x00;
strong = &report->field[2]->value[0];
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Kara <[email protected]>
commit 17b7f7cf58926844e1dd40f5eb5348d481deca6a upstream.
Refuse RW mount of isofs filesystem. So far we just silently changed it
to RO mount but when the media is writeable, block layer won't notice
this change and thus will think device is used RW and will block eject
button of the drive. That is unexpected by users because for
non-writeable media eject button works just fine.
Userspace mount(8) command handles this just fine and retries mounting
with MS_RDONLY set so userspace shouldn't see any regression. Plus any
tool mounting isofs is likely confronted with the case of read-only
media where block layer already refuses to mount the filesystem without
MS_RDONLY set so our behavior shouldn't be anything new for it.
Reported-by: Hui Wang <[email protected]>
Signed-off-by: Jan Kara <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/isofs/inode.c | 16 +++++-----------
1 file changed, 5 insertions(+), 11 deletions(-)
--- a/fs/isofs/inode.c
+++ b/fs/isofs/inode.c
@@ -119,8 +119,8 @@ static void destroy_inodecache(void)
static int isofs_remount(struct super_block *sb, int *flags, char *data)
{
- /* we probably want a lot more here */
- *flags |= MS_RDONLY;
+ if (!(*flags & MS_RDONLY))
+ return -EROFS;
return 0;
}
@@ -769,15 +769,6 @@ root_found:
*/
s->s_maxbytes = 0x80000000000LL;
- /*
- * The CDROM is read-only, has no nodes (devices) on it, and since
- * all of the files appear to be owned by root, we really do not want
- * to allow suid. (suid or devices will not show up unless we have
- * Rock Ridge extensions)
- */
-
- s->s_flags |= MS_RDONLY /* | MS_NODEV | MS_NOSUID */;
-
/* Set this for reference. Its not currently used except on write
which we don't have .. */
@@ -1528,6 +1519,9 @@ struct inode *isofs_iget(struct super_bl
static struct dentry *isofs_mount(struct file_system_type *fs_type,
int flags, const char *dev_name, void *data)
{
+ /* We don't support read-write mounts */
+ if (!(flags & MS_RDONLY))
+ return ERR_PTR(-EACCES);
return mount_bdev(fs_type, flags, dev_name, data, isofs_fill_super);
}
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Thelen <[email protected]>
commit 2bff24a3707093c435ab3241c47dcdb5f16e432b upstream.
A memory cgroup with (1) multiple threshold notifications and (2) at least
one threshold >=2G was not reliable. Specifically the notifications would
either not fire or would not fire in the proper order.
The __mem_cgroup_threshold() signaling logic depends on keeping 64 bit
thresholds in sorted order. mem_cgroup_usage_register_event() sorts them
with compare_thresholds(), which returns the difference of two 64 bit
thresholds as an int. If the difference is positive but has bit[31] set,
then sort() treats the difference as negative and breaks sort order.
This fix compares the two arbitrary 64 bit thresholds returning the
classic -1, 0, 1 result.
The test below sets two notifications (at 0x1000 and 0x81001000):
cd /sys/fs/cgroup/memory
mkdir x
for x in 4096 2164264960; do
cgroup_event_listener x/memory.usage_in_bytes $x | sed "s/^/$x listener:/" &
done
echo $$ > x/cgroup.procs
anon_leaker 500M
v3.11-rc7 fails to signal the 4096 event listener:
Leaking...
Done leaking pages.
Patched v3.11-rc7 properly notifies:
Leaking...
4096 listener:2013:8:31:14:13:36
Done leaking pages.
The fixed bug is old. It appears to date back to the introduction of
memcg threshold notifications in v2.6.34-rc1-116-g2e72b6347c94 "memcg:
implement memory thresholds"
Signed-off-by: Greg Thelen <[email protected]>
Acked-by: Michal Hocko <[email protected]>
Acked-by: Kirill A. Shutemov <[email protected]>
Acked-by: Johannes Weiner <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
mm/memcontrol.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -4433,7 +4433,13 @@ static int compare_thresholds(const void
const struct mem_cgroup_threshold *_a = a;
const struct mem_cgroup_threshold *_b = b;
- return _a->threshold - _b->threshold;
+ if (_a->threshold > _b->threshold)
+ return 1;
+
+ if (_a->threshold < _b->threshold)
+ return -1;
+
+ return 0;
}
static int mem_cgroup_oom_notify_cb(struct mem_cgroup *mem)
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jie Liu <[email protected]>
commit 28e8be31803b19d0d8f76216cb11b480b8a98bec upstream.
Call fiemap ioctl(2) with given start offset as well as an desired mapping
range should show extents if possible. However, we somehow figure out the
end offset of mapping via 'mapping_end -= cpos' before iterating the
extent records which would cause problems if the given fiemap length is
too small to a cluster size, e.g,
Cluster size 4096:
debugfs.ocfs2 1.6.3
Block Size Bits: 12 Cluster Size Bits: 12
The extended fiemap test utility From David:
https://gist.github.com/anonymous/6172331
# dd if=/dev/urandom of=/ocfs2/test_file bs=1M count=1000
# ./fiemap /ocfs2/test_file 4096 10
start: 4096, length: 10
File /ocfs2/test_file has 0 extents:
# Logical Physical Length Flags
^^^^^ <-- No extent is shown
In this case, at ocfs2_fiemap(): cpos == mapping_end == 1. Hence the
loop of searching extent records was not executed at all.
This patch remove the in question 'mapping_end -= cpos', and loops
until the cpos is larger than the mapping_end as usual.
# ./fiemap /ocfs2/test_file 4096 10
start: 4096, length: 10
File /ocfs2/test_file has 1 extents:
# Logical Physical Length Flags
0: 0000000000000000 0000000056a01000 0000000006a00000 0000
Signed-off-by: Jie Liu <[email protected]>
Reported-by: David Weber <[email protected]>
Tested-by: David Weber <[email protected]>
Cc: Sunil Mushran <[email protected]>
Cc: Mark Fashen <[email protected]>
Cc: Joel Becker <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/ocfs2/extent_map.c | 1 -
1 file changed, 1 deletion(-)
--- a/fs/ocfs2/extent_map.c
+++ b/fs/ocfs2/extent_map.c
@@ -782,7 +782,6 @@ int ocfs2_fiemap(struct inode *inode, st
cpos = map_start >> osb->s_clustersize_bits;
mapping_end = ocfs2_clusters_for_bytes(inode->i_sb,
map_start + map_len);
- mapping_end -= cpos;
is_last = 0;
while (cpos < mapping_end && !is_last) {
u32 fe_flags;
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kees Cook <[email protected]>
commit be67b68d52fa28b9b721c47bb42068f0c1214855 upstream.
Defensively check that the field to be worked on is not NULL.
Signed-off-by: Kees Cook <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/hid/hid-core.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -993,7 +993,12 @@ EXPORT_SYMBOL_GPL(hid_output_report);
int hid_set_field(struct hid_field *field, unsigned offset, __s32 value)
{
- unsigned size = field->report_size;
+ unsigned size;
+
+ if (!field)
+ return -1;
+
+ size = field->report_size;
hid_dump_input(field->report->device, field->usage + offset, value);
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kees Cook <[email protected]>
commit 875b4e3763dbc941f15143dd1a18d10bb0be303b upstream.
A HID device could send a malicious feature report that would cause the
ntrig HID driver to trigger a NULL dereference during initialization:
[57383.031190] usb 3-1: New USB device found, idVendor=1b96, idProduct=0001
...
[57383.315193] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
[57383.315308] IP: [<ffffffffa08102de>] ntrig_probe+0x25e/0x420 [hid_ntrig]
CVE-2013-2896
Signed-off-by: Kees Cook <[email protected]>
Signed-off-by: Rafi Rubin <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/hid/hid-ntrig.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/hid/hid-ntrig.c
+++ b/drivers/hid/hid-ntrig.c
@@ -115,7 +115,8 @@ static inline int ntrig_get_mode(struct
struct hid_report *report = hdev->report_enum[HID_FEATURE_REPORT].
report_id_hash[0x0d];
- if (!report)
+ if (!report || report->maxfield < 1 ||
+ report->field[0]->report_count < 1)
return -EINVAL;
usbhid_submit_report(hdev, report, USB_DIR_IN);
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kees Cook <[email protected]>
commit 43622021d2e2b82ea03d883926605bdd0525e1d1 upstream.
The "Report ID" field of a HID report is used to build indexes of
reports. The kernel's index of these is limited to 256 entries, so any
malicious device that sets a Report ID greater than 255 will trigger
memory corruption on the host:
[ 1347.156239] BUG: unable to handle kernel paging request at ffff88094958a878
[ 1347.156261] IP: [<ffffffff813e4da0>] hid_register_report+0x2a/0x8b
CVE-2013-2888
Signed-off-by: Kees Cook <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/hid/hid-core.c | 12 ++++++++----
include/linux/hid.h | 4 +++-
2 files changed, 11 insertions(+), 5 deletions(-)
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -58,6 +58,8 @@ struct hid_report *hid_register_report(s
struct hid_report_enum *report_enum = device->report_enum + type;
struct hid_report *report;
+ if (id >= HID_MAX_IDS)
+ return NULL;
if (report_enum->report_id_hash[id])
return report_enum->report_id_hash[id];
@@ -379,9 +381,11 @@ static int hid_parser_global(struct hid_
case HID_GLOBAL_ITEM_TAG_REPORT_ID:
parser->global.report_id = item_udata(item);
- if (parser->global.report_id == 0) {
- dbg_hid("report_id 0 is invalid\n");
- return -1;
+ if (parser->global.report_id == 0 ||
+ parser->global.report_id >= HID_MAX_IDS) {
+ hid_err(parser->device, "report_id %u is invalid\n",
+ parser->global.report_id);
+ return -1;
}
return 0;
@@ -551,7 +555,7 @@ static void hid_device_release(struct de
for (i = 0; i < HID_REPORT_TYPES; i++) {
struct hid_report_enum *report_enum = device->report_enum + i;
- for (j = 0; j < 256; j++) {
+ for (j = 0; j < HID_MAX_IDS; j++) {
struct hid_report *report = report_enum->report_id_hash[j];
if (report)
hid_free_report(report);
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -414,10 +414,12 @@ struct hid_report {
struct hid_device *device; /* associated device */
};
+#define HID_MAX_IDS 256
+
struct hid_report_enum {
unsigned numbered;
struct list_head report_list;
- struct hid_report *report_id_hash[256];
+ struct hid_report *report_id_hash[HID_MAX_IDS];
};
#define HID_REPORT_TYPES 3
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jeff Layton <[email protected]>
commit 73e216a8a42c0ef3d08071705c946c38fdbe12b0 upstream.
Oleksii reported that he had seen an oops similar to this:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000088
IP: [<ffffffff814dcc13>] sock_sendmsg+0x93/0xd0
PGD 0
Oops: 0000 [#1] PREEMPT SMP
Modules linked in: ipt_MASQUERADE xt_REDIRECT xt_tcpudp iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables x_tables carl9170 ath usb_storage f2fs nfnetlink_log nfnetlink md4 cifs dns_resolver hid_generic usbhid hid af_packet uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev rfcomm btusb bnep bluetooth qmi_wwan qcserial cdc_wdm usb_wwan usbnet usbserial mii snd_hda_codec_hdmi snd_hda_codec_realtek iwldvm mac80211 coretemp intel_powerclamp kvm_intel kvm iwlwifi snd_hda_intel cfg80211 snd_hda_codec xhci_hcd e1000e ehci_pci snd_hwdep sdhci_pci snd_pcm ehci_hcd microcode psmouse sdhci thinkpad_acpi mmc_core i2c_i801 pcspkr usbcore hwmon snd_timer snd_page_alloc snd ptp rfkill pps_core soundcore evdev usb_common vboxnetflt(O) vboxdrv(O)Oops#2 Part8
loop tun binfmt_misc fuse msr acpi_call(O) ipv6 autofs4
CPU: 0 PID: 21612 Comm: kworker/0:1 Tainted: G W O 3.10.1SIGN #28
Hardware name: LENOVO 2306CTO/2306CTO, BIOS G2ET92WW (2.52 ) 02/22/2013
Workqueue: cifsiod cifs_echo_request [cifs]
task: ffff8801e1f416f0 ti: ffff880148744000 task.ti: ffff880148744000
RIP: 0010:[<ffffffff814dcc13>] [<ffffffff814dcc13>] sock_sendmsg+0x93/0xd0
RSP: 0000:ffff880148745b00 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff880148745b78 RCX: 0000000000000048
RDX: ffff880148745c90 RSI: ffff880181864a00 RDI: ffff880148745b78
RBP: ffff880148745c48 R08: 0000000000000048 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff880181864a00
R13: ffff880148745c90 R14: 0000000000000048 R15: 0000000000000048
FS: 0000000000000000(0000) GS:ffff88021e200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000088 CR3: 000000020c42c000 CR4: 00000000001407b0
Oops#2 Part7
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Stack:
ffff880148745b30 ffffffff810c4af9 0000004848745b30 ffff880181864a00
ffffffff81ffbc40 0000000000000000 ffff880148745c90 ffffffff810a5aab
ffff880148745bc0 ffffffff81ffbc40 ffff880148745b60 ffffffff815a9fb8
Call Trace:
[<ffffffff810c4af9>] ? finish_task_switch+0x49/0xe0
[<ffffffff810a5aab>] ? lock_timer_base.isra.36+0x2b/0x50
[<ffffffff815a9fb8>] ? _raw_spin_unlock_irqrestore+0x18/0x40
[<ffffffff810a673f>] ? try_to_del_timer_sync+0x4f/0x70
[<ffffffff815aa38f>] ? _raw_spin_unlock_bh+0x1f/0x30
[<ffffffff814dcc87>] kernel_sendmsg+0x37/0x50
[<ffffffffa081a0e0>] smb_send_kvec+0xd0/0x1d0 [cifs]
[<ffffffffa081a263>] smb_send_rqst+0x83/0x1f0 [cifs]
[<ffffffffa081ab6c>] cifs_call_async+0xec/0x1b0 [cifs]
[<ffffffffa08245e0>] ? free_rsp_buf+0x40/0x40 [cifs]
Oops#2 Part6
[<ffffffffa082606e>] SMB2_echo+0x8e/0xb0 [cifs]
[<ffffffffa0808789>] cifs_echo_request+0x79/0xa0 [cifs]
[<ffffffff810b45b3>] process_one_work+0x173/0x4a0
[<ffffffff810b52a1>] worker_thread+0x121/0x3a0
[<ffffffff810b5180>] ? manage_workers.isra.27+0x2b0/0x2b0
[<ffffffff810bae00>] kthread+0xc0/0xd0
[<ffffffff810bad40>] ? kthread_create_on_node+0x120/0x120
[<ffffffff815b199c>] ret_from_fork+0x7c/0xb0
[<ffffffff810bad40>] ? kthread_create_on_node+0x120/0x120
Code: 84 24 b8 00 00 00 4c 89 f1 4c 89 ea 4c 89 e6 48 89 df 4c 89 60 18 48 c7 40 28 00 00 00 00 4c 89 68 30 44 89 70 14 49 8b 44 24 28 <ff> 90 88 00 00 00 3d ef fd ff ff 74 10 48 8d 65 e0 5b 41 5c 41
RIP [<ffffffff814dcc13>] sock_sendmsg+0x93/0xd0
RSP <ffff880148745b00>
CR2: 0000000000000088
The client was in the middle of trying to send a frame when the
server->ssocket pointer got zeroed out. In most places, that we access
that pointer, the srv_mutex is held. There's only one spot that I see
that the server->ssocket pointer gets set and the srv_mutex isn't held.
This patch corrects that.
The upstream bug report was here:
https://bugzilla.kernel.org/show_bug.cgi?id=60557
Reported-by: Oleksii Shevchuk <[email protected]>
Signed-off-by: Jeff Layton <[email protected]>
Signed-off-by: Steve French <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/cifs/connect.c | 2 ++
1 file changed, 2 insertions(+)
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -158,6 +158,7 @@ cifs_reconnect(struct TCP_Server_Info *s
try_to_freeze();
/* we should try only the port we connected to before */
+ mutex_lock(&server->srv_mutex);
rc = generic_ip_connect(server);
if (rc) {
cFYI(1, "reconnect error %d", rc);
@@ -169,6 +170,7 @@ cifs_reconnect(struct TCP_Server_Info *s
server->tcpStatus = CifsNeedNegotiate;
spin_unlock(&GlobalMid_Lock);
}
+ mutex_unlock(&server->srv_mutex);
} while (server->tcpStatus == CifsNeedReconnect);
return rc;
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
commit d0bd9a41186e076ea543c397ad8a67a6cf604b55 upstream.
The write_parport_reg_nonblock() function shouldn't sleep because it's
called with spinlocks held.
Signed-off-by: Dan Carpenter <[email protected]>
Acked-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/serial/mos7720.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/serial/mos7720.c
+++ b/drivers/usb/serial/mos7720.c
@@ -383,7 +383,7 @@ static int write_parport_reg_nonblock(st
kfree(urbtrack);
return -ENOMEM;
}
- urbtrack->setup = kmalloc(sizeof(*urbtrack->setup), GFP_KERNEL);
+ urbtrack->setup = kmalloc(sizeof(*urbtrack->setup), GFP_ATOMIC);
if (!urbtrack->setup) {
usb_free_urb(urbtrack->urb);
kfree(urbtrack);
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tejun Heo <[email protected]>
commit c34ac00caefbe49d40058ae7200bd58725cebb45 upstream.
list_first_or_null() should test whether the list is empty and return
pointer to the first entry if not in a RCU safe manner. It's broken
in several ways.
* It compares __kernel @__ptr with __rcu @__next triggering the
following sparse warning.
net/core/dev.c:4331:17: error: incompatible types in comparison expression (different address spaces)
* It doesn't perform rcu_dereference*() and computes the entry address
using container_of() directly from the __rcu pointer which is
inconsitent with other rculist interface. As a result, all three
in-kernel users - net/core/dev.c, macvlan, cgroup - are buggy. They
dereference the pointer w/o going through read barrier.
* While ->next dereference passes through list_next_rcu(), the
compiler is still free to fetch ->next more than once and thus
nullify the "__ptr != __next" condition check.
Fix it by making list_first_or_null_rcu() dereference ->next directly
using ACCESS_ONCE() and then use list_entry_rcu() on it like other
rculist accessors.
v2: Paul pointed out that the compiler may fetch the pointer more than
once nullifying the condition check. ACCESS_ONCE() added on
->next dereference.
v3: Restored () around macro param which was accidentally removed.
Spotted by Paul.
Signed-off-by: Tejun Heo <[email protected]>
Reported-by: Fengguang Wu <[email protected]>
Cc: Dipankar Sarma <[email protected]>
Cc: "Paul E. McKenney" <[email protected]>
Cc: "David S. Miller" <[email protected]>
Cc: Li Zefan <[email protected]>
Cc: Patrick McHardy <[email protected]>
Signed-off-by: Paul E. McKenney <[email protected]>
Reviewed-by: Josh Triplett <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/linux/rculist.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/include/linux/rculist.h
+++ b/include/linux/rculist.h
@@ -254,8 +254,9 @@ static inline void list_splice_init_rcu(
*/
#define list_first_or_null_rcu(ptr, type, member) \
({struct list_head *__ptr = (ptr); \
- struct list_head __rcu *__next = list_next_rcu(__ptr); \
- likely(__ptr != __next) ? container_of(__next, type, member) : NULL; \
+ struct list_head *__next = ACCESS_ONCE(__ptr->next); \
+ likely(__ptr != __next) ? \
+ list_entry_rcu(__next, type, member) : NULL; \
})
/**
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <[email protected]>
commit b4f17a488ae2e09bfcf95c0e0b4219c246f1116a upstream.
While reading the config parsing code I noticed this check is missing, without
this check config->desc.wTotalLength can end up with a value larger then the
dev->rawdescriptors length for the config, and when userspace then tries to
get the rawdescriptors bad things may happen.
Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/core/config.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -424,7 +424,8 @@ static int usb_parse_configuration(struc
memcpy(&config->desc, buffer, USB_DT_CONFIG_SIZE);
if (config->desc.bDescriptorType != USB_DT_CONFIG ||
- config->desc.bLength < USB_DT_CONFIG_SIZE) {
+ config->desc.bLength < USB_DT_CONFIG_SIZE ||
+ config->desc.bLength > size) {
dev_err(ddev, "invalid descriptor for config index %d: "
"type = 0x%X, length = %d\n", cfgidx,
config->desc.bDescriptorType, config->desc.bLength);
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit 3b716caf190ccc6f2a09387210e0e6a26c1d81a4 upstream.
Fix endianess bugs in parallel-port code which caused corrupt
control-requests to be issued on big-endian machines.
Reported-by: kbuild test robot <[email protected]>
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/serial/mos7720.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/usb/serial/mos7720.c
+++ b/drivers/usb/serial/mos7720.c
@@ -391,8 +391,8 @@ static int write_parport_reg_nonblock(st
}
urbtrack->setup->bRequestType = (__u8)0x40;
urbtrack->setup->bRequest = (__u8)0x0e;
- urbtrack->setup->wValue = get_reg_value(reg, dummy);
- urbtrack->setup->wIndex = get_reg_index(reg);
+ urbtrack->setup->wValue = cpu_to_le16(get_reg_value(reg, dummy));
+ urbtrack->setup->wIndex = cpu_to_le16(get_reg_index(reg));
urbtrack->setup->wLength = 0;
usb_fill_control_urb(urbtrack->urb, usbdev,
usb_sndctrlpipe(usbdev, 0),
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Libin <[email protected]>
commit a8f531ebc33052642b4bd7b812eedf397108ce64 upstream.
In collapse_huge_page() there is a race window between releasing the
mmap_sem read lock and taking the mmap_sem write lock, so find_vma() may
return NULL. So check the return value to avoid NULL pointer dereference.
collapse_huge_page
khugepaged_alloc_page
up_read(&mm->mmap_sem)
down_write(&mm->mmap_sem)
vma = find_vma(mm, address)
Signed-off-by: Libin <[email protected]>
Acked-by: Kirill A. Shutemov <[email protected]>
Reviewed-by: Wanpeng Li <[email protected]>
Reviewed-by: Michal Hocko <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
mm/huge_memory.c | 2 ++
1 file changed, 2 insertions(+)
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1838,6 +1838,8 @@ static void collapse_huge_page(struct mm
goto out;
vma = find_vma(mm, address);
+ if (!vma)
+ goto out;
hstart = (vma->vm_start + ~HPAGE_PMD_MASK) & HPAGE_PMD_MASK;
hend = vma->vm_end & HPAGE_PMD_MASK;
if (address < hstart || address + HPAGE_PMD_SIZE > hend)
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
commit 2c4283ca7cdcc6605859c836fc536fcd83a4525f upstream.
In dt282x_ai_insn_read() we call this macro like:
wait_for(!mux_busy(), comedi_error(dev, "timeout\n"); return -ETIME;);
Because the if statement doesn't have curly braces it means we always
return -ETIME and the function never succeeds.
Signed-off-by: Dan Carpenter <[email protected]>
Acked-by: Ian Abbott <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/staging/comedi/drivers/dt282x.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/staging/comedi/drivers/dt282x.c
+++ b/drivers/staging/comedi/drivers/dt282x.c
@@ -406,8 +406,9 @@ struct dt282x_private {
} \
udelay(5); \
} \
- if (_i) \
+ if (_i) { \
b \
+ } \
} while (0)
static int dt282x_attach(struct comedi_device *dev,
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shawn Nematbakhsh <[email protected]>
commit c8476fb855434c733099079063990e5bfa7ecad6 upstream.
If a USB controller with XHCI_RESET_ON_RESUME goes to runtime suspend,
a reset will be performed upon runtime resume. Any previously suspended
devices attached to the controller will be re-enumerated at this time.
This will cause problems, for example, if an open system call on the
device triggered the resume (the open call will fail).
Note that this change is only relevant when persist_enabled is not set
for USB devices.
This patch should be backported to kernels as old as 3.0, that
contain the commit c877b3b2ad5cb9d4fe523c5496185cc328ff3ae9 "xhci: Add
reset on resume quirk for asrock p67 host".
Signed-off-by: Shawn Nematbakhsh <[email protected]>
Signed-off-by: Sarah Sharp <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/host/xhci.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -2713,10 +2713,21 @@ void xhci_free_dev(struct usb_hcd *hcd,
{
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct xhci_virt_device *virt_dev;
+ struct device *dev = hcd->self.controller;
unsigned long flags;
u32 state;
int i, ret;
+#ifndef CONFIG_USB_DEFAULT_PERSIST
+ /*
+ * We called pm_runtime_get_noresume when the device was attached.
+ * Decrement the counter here to allow controller to runtime suspend
+ * if no devices remain.
+ */
+ if (xhci->quirks & XHCI_RESET_ON_RESUME)
+ pm_runtime_put_noidle(dev);
+#endif
+
ret = xhci_check_args(hcd, udev, NULL, 0, true, __func__);
/* If the host is halted due to driver unload, we still need to free the
* device.
@@ -2783,6 +2794,7 @@ static int xhci_reserve_host_control_ep_
int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device *udev)
{
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ struct device *dev = hcd->self.controller;
unsigned long flags;
int timeleft;
int ret;
@@ -2835,6 +2847,16 @@ int xhci_alloc_dev(struct usb_hcd *hcd,
goto disable_slot;
}
udev->slot_id = xhci->slot_id;
+
+#ifndef CONFIG_USB_DEFAULT_PERSIST
+ /*
+ * If resetting upon resume, we can't put the controller into runtime
+ * suspend if there is a device attached.
+ */
+ if (xhci->quirks & XHCI_RESET_ON_RESUME)
+ pm_runtime_get_noresume(dev);
+#endif
+
/* Is this a LS or FS device under a HS hub? */
/* Hub or peripherial? */
return 1;
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anand Avati <[email protected]>
commit d331a415aef98717393dda0be69b7947da08eba3 upstream.
Calls like setxattr and removexattr result in updation of ctime.
Therefore invalidate inode attributes to force a refresh.
Signed-off-by: Anand Avati <[email protected]>
Reviewed-by: Brian Foster <[email protected]>
Signed-off-by: Miklos Szeredi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/fuse/dir.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/fs/fuse/dir.c
+++ b/fs/fuse/dir.c
@@ -1439,6 +1439,8 @@ static int fuse_setxattr(struct dentry *
fc->no_setxattr = 1;
err = -EOPNOTSUPP;
}
+ if (!err)
+ fuse_invalidate_attr(inode);
return err;
}
@@ -1568,6 +1570,8 @@ static int fuse_removexattr(struct dentr
fc->no_removexattr = 1;
err = -EOPNOTSUPP;
}
+ if (!err)
+ fuse_invalidate_attr(inode);
return err;
}
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maxim Patlasov <[email protected]>
commit 4a4ac4eba1010ef9a804569058ab29e3450c0315 upstream.
The patch fixes a race between ftruncate(2), mmap-ed write and write(2):
1) An user makes a page dirty via mmap-ed write.
2) The user performs shrinking truncate(2) intended to purge the page.
3) Before fuse_do_setattr calls truncate_pagecache, the page goes to
writeback. fuse_writepage_locked fills FUSE_WRITE request and releases
the original page by end_page_writeback.
4) fuse_do_setattr() completes and successfully returns. Since now, i_mutex
is free.
5) Ordinary write(2) extends i_size back to cover the page. Note that
fuse_send_write_pages do wait for fuse writeback, but for another
page->index.
6) fuse_writepage_locked proceeds by queueing FUSE_WRITE request.
fuse_send_writepage is supposed to crop inarg->size of the request,
but it doesn't because i_size has already been extended back.
Moving end_page_writeback to the end of fuse_writepage_locked fixes the
race because now the fact that truncate_pagecache is successfully returned
infers that fuse_writepage_locked has already called end_page_writeback.
And this, in turn, infers that fuse_flush_writepages has already called
fuse_send_writepage, and the latter used valid (shrunk) i_size. write(2)
could not extend it because of i_mutex held by ftruncate(2).
Signed-off-by: Maxim Patlasov <[email protected]>
Signed-off-by: Miklos Szeredi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/fuse/file.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -1298,7 +1298,6 @@ static int fuse_writepage_locked(struct
inc_bdi_stat(mapping->backing_dev_info, BDI_WRITEBACK);
inc_zone_page_state(tmp_page, NR_WRITEBACK_TEMP);
- end_page_writeback(page);
spin_lock(&fc->lock);
list_add(&req->writepages_entry, &fi->writepages);
@@ -1306,6 +1305,8 @@ static int fuse_writepage_locked(struct
fuse_flush_writepages(inode);
spin_unlock(&fc->lock);
+ end_page_writeback(page);
+
return 0;
err_free:
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit 83f72151352791836a1b9c1542614cc9bf71ac61 upstream.
Toshiba Satellite C870 shows interrupt problems occasionally when
certain mixer controls like "Mic Switch" is toggled. This seems
worked around by not using MSI.
Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=833585
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/pci/hda/hda_intel.c | 1 +
1 file changed, 1 insertion(+)
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2461,6 +2461,7 @@ static struct snd_pci_quirk msi_black_li
SND_PCI_QUIRK(0x1043, 0x81f2, "ASUS", 0), /* Athlon64 X2 + nvidia */
SND_PCI_QUIRK(0x1043, 0x81f6, "ASUS", 0), /* nvidia */
SND_PCI_QUIRK(0x1043, 0x822d, "ASUS", 0), /* Athlon64 X2 + nvidia MCP55 */
+ SND_PCI_QUIRK(0x1179, 0xfb44, "Toshiba Satellite C870", 0), /* AMD Hudson */
SND_PCI_QUIRK(0x1849, 0x0888, "ASRock", 0), /* Athlon64 X2 + nvidia */
SND_PCI_QUIRK(0xa0a0, 0x0575, "Aopen MZ915-M", 0), /* ICH6 */
{}
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felix Fietkau <[email protected]>
commit 026d5b07c03458f9c0ccd19c3850564a5409c325 upstream.
Otherwise in some cases, EAPOL frames might be filtered during the
initial handshake, causing delays and assoc failures.
Signed-off-by: Felix Fietkau <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/wireless/ath/ath9k/xmit.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2433,6 +2433,7 @@ void ath_tx_node_init(struct ath_softc *
for (acno = 0, ac = &an->ac[acno];
acno < WME_NUM_AC; acno++, ac++) {
ac->sched = false;
+ ac->clear_ps_filter = true;
ac->txq = sc->tx.txq_map[acno];
INIT_LIST_HEAD(&ac->tid_q);
}
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felix Fietkau <[email protected]>
commit a1c781bb20ac1e03280e420abd47a99eb8bbdd3b upstream.
They are not implemented, and accessing them might trigger errors
Signed-off-by: Felix Fietkau <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
@@ -1005,6 +1005,10 @@ static bool ar9003_hw_ani_control(struct
* is_on == 0 means MRC CCK is OFF (more noise imm)
*/
bool is_on = param ? 1 : 0;
+
+ if (ah->caps.rx_chainmask == 1)
+ break;
+
REG_RMW_FIELD(ah, AR_PHY_MRC_CCK_CTRL,
AR_PHY_MRC_CCK_ENABLE, is_on);
REG_RMW_FIELD(ah, AR_PHY_MRC_CCK_CTRL,
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Roger Pau Monne <[email protected]>
commit 5f338d9001094a56cf87bd8a280b4e7ff953bb59 upstream.
With the current implementation, the callback in the tail of the list
can be added twice, because the check done in
gnttab_request_free_callback is bogus, callback->next can be NULL if
it is the last callback in the list. If we add the same callback twice
we end up with an infinite loop, were callback == callback->next.
Replace this check with a proper one that iterates over the list to
see if the callback has already been added.
Signed-off-by: Roger Pau Monné <[email protected]>
Cc: Konrad Rzeszutek Wilk <[email protected]>
Cc: David Vrabel <[email protected]>
Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
Acked-by: Matt Wilson <[email protected]>
Reviewed-by: David Vrabel <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/xen/grant-table.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -355,9 +355,18 @@ void gnttab_request_free_callback(struct
void (*fn)(void *), void *arg, u16 count)
{
unsigned long flags;
+ struct gnttab_free_callback *cb;
+
spin_lock_irqsave(&gnttab_list_lock, flags);
- if (callback->next)
- goto out;
+
+ /* Check if the callback is already on the list */
+ cb = gnttab_free_callback_list;
+ while (cb) {
+ if (cb == callback)
+ goto out;
+ cb = cb->next;
+ }
+
callback->fn = fn;
callback->arg = arg;
callback->count = count;
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Maydell <[email protected]>
commit 99f2b130370b904ca5300079243fdbcafa2c708b upstream.
The SMAP register offsets in the versatile PCI controller code were
all off by four. (This didn't have any observable bad effects
because on this board PHYS_OFFSET is zero, and (a) writing zero to
the flags register at offset 0x10 has no effect and (b) the reset
value of the SMAP register is zero anyway, so failing to write SMAP2
didn't matter.)
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/mach-versatile/pci.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/arch/arm/mach-versatile/pci.c
+++ b/arch/arm/mach-versatile/pci.c
@@ -43,9 +43,9 @@
#define PCI_IMAP0 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x0)
#define PCI_IMAP1 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x4)
#define PCI_IMAP2 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x8)
-#define PCI_SMAP0 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x10)
-#define PCI_SMAP1 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x14)
-#define PCI_SMAP2 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x18)
+#define PCI_SMAP0 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x14)
+#define PCI_SMAP1 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x18)
+#define PCI_SMAP2 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x1c)
#define PCI_SELFID __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0xc)
#define DEVICE_ID_OFFSET 0x00
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anton Blanchard <[email protected]>
commit 230aef7a6a23b6166bd4003bfff5af23c9bd381f upstream.
Normally when we haven't implemented an alignment handler for
a load or store instruction the process will be terminated.
The alignment handler uses the DSISR (or a pseudo one) to locate
the right handler. Unfortunately ldbrx and stdbrx overlap lfs and
stfs so we incorrectly think ldbrx is an lfs and stdbrx is an
stfs.
This bug is particularly nasty - instead of terminating the
process we apply an incorrect fixup and continue on.
With more and more overlapping instructions we should stop
creating a pseudo DSISR and index using the instruction directly,
but for now add a special case to catch ldbrx/stdbrx.
Signed-off-by: Anton Blanchard <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/powerpc/kernel/align.c | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/arch/powerpc/kernel/align.c
+++ b/arch/powerpc/kernel/align.c
@@ -764,6 +764,16 @@ int fix_alignment(struct pt_regs *regs)
nb = aligninfo[instr].len;
flags = aligninfo[instr].flags;
+ /* ldbrx/stdbrx overlap lfs/stfs in the DSISR unfortunately */
+ if (IS_XFORM(instruction) && ((instruction >> 1) & 0x3ff) == 532) {
+ nb = 8;
+ flags = LD+SW;
+ } else if (IS_XFORM(instruction) &&
+ ((instruction >> 1) & 0x3ff) == 660) {
+ nb = 8;
+ flags = ST+SW;
+ }
+
/* Byteswap little endian loads and stores */
swiz = 0;
if (regs->msr & MSR_LE) {
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Herbert Xu <[email protected]>
commit 77dbd7a95e4a4f15264c333a9e9ab97ee27dc2aa upstream.
crypto_larval_lookup should only return a larval if it created one.
Any larval created by another entity must be processed through
crypto_larval_wait before being returned.
Otherwise this will lead to a larval being killed twice, which
will most likely lead to a crash.
Reported-by: Kees Cook <[email protected]>
Tested-by: Kees Cook <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
crypto/api.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/crypto/api.c
+++ b/crypto/api.c
@@ -40,6 +40,8 @@ static inline struct crypto_alg *crypto_
return alg;
}
+static struct crypto_alg *crypto_larval_wait(struct crypto_alg *alg);
+
struct crypto_alg *crypto_mod_get(struct crypto_alg *alg)
{
return try_module_get(alg->cra_module) ? crypto_alg_get(alg) : NULL;
@@ -150,8 +152,11 @@ static struct crypto_alg *crypto_larval_
}
up_write(&crypto_alg_sem);
- if (alg != &larval->alg)
+ if (alg != &larval->alg) {
kfree(larval);
+ if (crypto_is_larval(alg))
+ alg = crypto_larval_wait(alg);
+ }
return alg;
}
On 09/24/2013 06:07 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.0.97 release.
> There are 28 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri Sep 27 00:05:34 UTC 2013.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.97-rc1.gz
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
3.0.97-rc1 applied with the following warning from line 103 to 3.0.96
patch-3.0.97-rc1:103: space before tab in indent.
return -1;
warning: 1 line adds whitespace errors.
Compiled and booted on the following systems:
HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics
dmesgs look good. No regressions compared to the previous dmesgs for
this release. dmesg emerg, crit, alert, err are clean. No regressions in
warn.
Cross-compile testing: HP Compaq dc7700 SFF desktop: x86-64 Intel Core-i2:
Cross-compile tests results:
alpha: defconfig passed
arm: defconfig passed
arm64: not applicable
blackfin: defconfig passed
c6x: not applicable
mips: defconfig passed
mipsel: defconfig passed
powerpc: wii_defconfig passed
sh: defconfig passed
sparc: defconfig passed
tile: tilegx_defconfig passed
-- Shuah
--
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
[email protected] | (970) 672-0658
On Wed, Sep 25, 2013 at 08:22:24PM -0600, Shuah Khan wrote:
> On 09/24/2013 06:07 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.0.97 release.
> > There are 28 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Fri Sep 27 00:05:34 UTC 2013.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.97-rc1.gz
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> 3.0.97-rc1 applied with the following warning from line 103 to 3.0.96
>
> patch-3.0.97-rc1:103: space before tab in indent.
> return -1;
> warning: 1 line adds whitespace errors.
Any hint as to what file that was for?
> Compiled and booted on the following systems:
>
> HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics
>
> dmesgs look good. No regressions compared to the previous dmesgs for
> this release. dmesg emerg, crit, alert, err are clean. No regressions in
> warn.
Great, thanks for testing and letting me know.
greg k-h
On Thu, Sep 26, 2013 at 10:45 AM, Greg Kroah-Hartman
<[email protected]> wrote:
> On Wed, Sep 25, 2013 at 08:22:24PM -0600, Shuah Khan wrote:
>> On 09/24/2013 06:07 PM, Greg Kroah-Hartman wrote:
>> > This is the start of the stable review cycle for the 3.0.97 release.
>> > There are 28 patches in this series, all will be posted as a response
>> > to this one. If anyone has any issues with these being applied, please
>> > let me know.
>> >
>> > Responses should be made by Fri Sep 27 00:05:34 UTC 2013.
>> > Anything received after that time might be too late.
>> >
>> > The whole patch series can be found in one patch at:
>> > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.97-rc1.gz
>> > and the diffstat can be found below.
>> >
>> > thanks,
>> >
>> > greg k-h
>> >
>>
>> 3.0.97-rc1 applied with the following warning from line 103 to 3.0.96
>>
>> patch-3.0.97-rc1:103: space before tab in indent.
>> return -1;
>> warning: 1 line adds whitespace errors.
>
> Any hint as to what file that was for?
git am ../patches/v3.0.97/0019-HID-validate-HID-report-id-size.patch ...
Applying: HID: validate HID report id size
/home/choon/build/choon-GT-I9100-HK-JB-kernel-u2/.git/rebase-apply/patch:30:
space before tab in indent.
return -1;
warning: 1 line adds whitespace errors.
So it is 0019-HID-validate-HID-report-id-size.patch
I got it from doing the following:
git format-patch -o ../patches/v3.0.97 v3.0.96..v3.0.97
Thanks.
Kindest regards,
Giam Teck Choon
>
>> Compiled and booted on the following systems:
>>
>> HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics
>>
>> dmesgs look good. No regressions compared to the previous dmesgs for
>> this release. dmesg emerg, crit, alert, err are clean. No regressions in
>> warn.
>
> Great, thanks for testing and letting me know.
>
> greg k-h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On 09/27/2013 12:52 PM, Teck Choon Giam wrote:
> On Thu, Sep 26, 2013 at 10:45 AM, Greg Kroah-Hartman
> <[email protected]> wrote:
>> On Wed, Sep 25, 2013 at 08:22:24PM -0600, Shuah Khan wrote:
>>> On 09/24/2013 06:07 PM, Greg Kroah-Hartman wrote:
>>>> This is the start of the stable review cycle for the 3.0.97 release.
>>>> There are 28 patches in this series, all will be posted as a response
>>>> to this one. If anyone has any issues with these being applied, please
>>>> let me know.
>>>>
>>>> Responses should be made by Fri Sep 27 00:05:34 UTC 2013.
>>>> Anything received after that time might be too late.
>>>>
>>>> The whole patch series can be found in one patch at:
>>>> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.97-rc1.gz
>>>> and the diffstat can be found below.
>>>>
>>>> thanks,
>>>>
>>>> greg k-h
>>>>
>>>
>>> 3.0.97-rc1 applied with the following warning from line 103 to 3.0.96
>>>
>>> patch-3.0.97-rc1:103: space before tab in indent.
>>> return -1;
>>> warning: 1 line adds whitespace errors.
>>
>> Any hint as to what file that was for?
>
> git am ../patches/v3.0.97/0019-HID-validate-HID-report-id-size.patch ...
> Applying: HID: validate HID report id size
> /home/choon/build/choon-GT-I9100-HK-JB-kernel-u2/.git/rebase-apply/patch:30:
> space before tab in indent.
> return -1;
> warning: 1 line adds whitespace errors.
>
> So it is 0019-HID-validate-HID-report-id-size.patch
>
> I got it from doing the following:
>
> git format-patch -o ../patches/v3.0.97 v3.0.96..v3.0.97
>
> Thanks.
>
> Kindest regards,
> Giam Teck Choon
>
Thanks for the information. Yes that is the right patch.
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.
+ return -1;
There is a whitespace at the beginning.
-- Shuah
--
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
[email protected] | (970) 672-0658