Mike Snitzer [Fri, 18 Oct 2013 15:44:49 +0000 (09:44 -0600)]
block: properly stack underlying max_segment_size to DM device
commit
d82ae52e68892338068e7559a0c0657193341ce4 upstream.
Without this patch all DM devices will default to BLK_MAX_SEGMENT_SIZE
(65536) even if the underlying device(s) have a larger value -- this is
due to blk_stack_limits() using min_not_zero() when stacking the
max_segment_size limit.
1073741824
before patch:
65536
after patch:
1073741824
Reported-by: Lukasz Flis <l.flis@cyfronet.pl>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mikulas Patocka [Mon, 14 Oct 2013 16:13:24 +0000 (12:13 -0400)]
block: fix a probe argument to blk_register_region
commit
a207f5937630dd35bd2550620bef416937a1365e upstream.
The probe function is supposed to return NULL on failure (as we can see in
kobj_lookup: kobj = probe(dev, index, data); ... if (kobj) return kobj;
However, in loop and brd, it returns negative error from ERR_PTR.
This causes a crash if we simulate disk allocation failure and run
less -f /dev/loop0 because the negative number is interpreted as a pointer:
BUG: unable to handle kernel NULL pointer dereference at
00000000000002b4
IP: [<
ffffffff8118b188>] __blkdev_get+0x28/0x450
PGD
23c677067 PUD
23d6d1067 PMD 0
Oops: 0000 [#1] PREEMPT SMP
Modules linked in: loop hpfs nvidia(PO) ip6table_filter ip6_tables uvesafb cfbcopyarea cfbimgblt cfbfillrect fbcon font bitblit fbcon_rotate fbcon_cw fbcon_ud fbcon_ccw softcursor fb fbdev msr ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 xt_state ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc tun ipv6 cpufreq_stats cpufreq_ondemand cpufreq_userspace cpufreq_powersave cpufreq_conservative hid_generic spadfs usbhid hid fuse raid0 snd_usb_audio snd_pcm_oss snd_mixer_oss md_mod snd_pcm snd_timer snd_page_alloc snd_hwdep snd_usbmidi_lib dmi_sysfs snd_rawmidi nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack snd soundcore lm85 hwmon_vid ohci_hcd ehci_pci ehci_hcd serverworks sata_svw libata acpi_cpufreq freq_table mperf ide_core usbcore kvm_amd kvm tg3 i2c_piix4 libphy microcode e100 usb_common ptp skge i2c_core pcspkr k10temp evdev floppy hwmon pps_core mii rtc_cmos button processor unix [last unloaded: nvidia]
CPU: 1 PID: 6831 Comm: less Tainted: P W O 3.10.15-devel #18
Hardware name: empty empty/S3992-E, BIOS 'V1.06 ' 06/09/2009
task:
ffff880203cc6bc0 ti:
ffff88023e47c000 task.ti:
ffff88023e47c000
RIP: 0010:[<
ffffffff8118b188>] [<
ffffffff8118b188>] __blkdev_get+0x28/0x450
RSP: 0018:
ffff88023e47dbd8 EFLAGS:
00010286
RAX:
ffffffffffffff74 RBX:
ffffffffffffff74 RCX:
0000000000000000
RDX:
0000000000000000 RSI:
0000000000000000 RDI:
0000000000000001
RBP:
ffff88023e47dc18 R08:
0000000000000002 R09:
0000000000000000
R10:
0000000000000000 R11:
0000000000000000 R12:
ffff88023f519658
R13:
ffffffff8118c300 R14:
0000000000000000 R15:
ffff88023f519640
FS:
00007f2070bf7700(0000) GS:
ffff880247400000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
00000000000002b4 CR3:
000000023da1d000 CR4:
00000000000007e0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000ffff0ff0 DR7:
0000000000000400
Stack:
0000000000000002 0000001d00000000 000000003e47dc50 ffff88023f519640
ffff88043d5bb668 ffffffff8118c300 ffff88023d683550 ffff88023e47de60
ffff88023e47dc98 ffffffff8118c10d 0000001d81605698 0000000000000292
Call Trace:
[<
ffffffff8118c300>] ? blkdev_get_by_dev+0x60/0x60
[<
ffffffff8118c10d>] blkdev_get+0x1dd/0x370
[<
ffffffff8118c300>] ? blkdev_get_by_dev+0x60/0x60
[<
ffffffff813cea6c>] ? _raw_spin_unlock+0x2c/0x50
[<
ffffffff8118c300>] ? blkdev_get_by_dev+0x60/0x60
[<
ffffffff8118c365>] blkdev_open+0x65/0x80
[<
ffffffff8114d12e>] do_dentry_open.isra.18+0x23e/0x2f0
[<
ffffffff8114d214>] finish_open+0x34/0x50
[<
ffffffff8115e122>] do_last.isra.62+0x2d2/0xc50
[<
ffffffff8115eb58>] path_openat.isra.63+0xb8/0x4d0
[<
ffffffff81115a8e>] ? might_fault+0x4e/0xa0
[<
ffffffff8115f4f0>] do_filp_open+0x40/0x90
[<
ffffffff813cea6c>] ? _raw_spin_unlock+0x2c/0x50
[<
ffffffff8116db85>] ? __alloc_fd+0xa5/0x1f0
[<
ffffffff8114e45f>] do_sys_open+0xef/0x1d0
[<
ffffffff8114e559>] SyS_open+0x19/0x20
[<
ffffffff813cff16>] system_call_fastpath+0x1a/0x1f
Code: 44 00 00 55 48 89 e5 41 57 49 89 ff 41 56 41 89 d6 41 55 41 54 4c 8d 67 18 53 48 83 ec 18 89 75 cc e9 f2 00 00 00 0f 1f 44 00 00 <48> 8b 80 40 03 00 00 48 89 df 4c 8b 68 58 e8 d5
a4 07 00 44 89
RIP [<
ffffffff8118b188>] __blkdev_get+0x28/0x450
RSP <
ffff88023e47dbd8>
CR2:
00000000000002b4
---[ end trace
bb7f32dbf02398dc ]---
The brd change should be backported to stable kernels starting with 2.6.25.
The loop change should be backported to stable kernels starting with 2.6.22.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jeff Moyer [Tue, 8 Oct 2013 18:36:41 +0000 (14:36 -0400)]
block: fix race between request completion and timeout handling
commit
4912aa6c11e6a5d910264deedbec2075c6f1bb73 upstream.
crocode i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support shpchp ioatdma dca be2net sg ses enclosure ext4 mbcache jbd2 sd_mod crc_t10dif ahci megaraid_sas(U) dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan]
Pid: 491, comm: scsi_eh_0 Tainted: G W ---------------- 2.6.32-220.13.1.el6.x86_64 #1 IBM -[8722PAX]-/00D1461
RIP: 0010:[<
ffffffff8124e424>] [<
ffffffff8124e424>] blk_requeue_request+0x94/0xa0
RSP: 0018:
ffff881057eefd60 EFLAGS:
00010012
RAX:
ffff881d99e3e8a8 RBX:
ffff881d99e3e780 RCX:
ffff881d99e3e8a8
RDX:
ffff881d99e3e8a8 RSI:
ffff881d99e3e780 RDI:
ffff881d99e3e780
RBP:
ffff881057eefd80 R08:
ffff881057eefe90 R09:
0000000000000000
R10:
0000000000000000 R11:
0000000000000000 R12:
ffff881057f92338
R13:
0000000000000000 R14:
ffff881057f92338 R15:
ffff883058188000
FS:
0000000000000000(0000) GS:
ffff880040200000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0:
000000008005003b
CR2:
00000000006d3ec0 CR3:
000000302cd7d000 CR4:
00000000000406b0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000ffff0ff0 DR7:
0000000000000400
Process scsi_eh_0 (pid: 491, threadinfo
ffff881057eee000, task
ffff881057e29540)
Stack:
0000000000001057 0000000000000286 ffff8810275efdc0 ffff881057f16000
<0>
ffff881057eefdd0 ffffffff81362323 ffff881057eefe20 ffffffff8135f393
<0>
ffff881057e29af8 ffff8810275efdc0 ffff881057eefe78 ffff881057eefe90
Call Trace:
[<
ffffffff81362323>] __scsi_queue_insert+0xa3/0x150
[<
ffffffff8135f393>] ? scsi_eh_ready_devs+0x5e3/0x850
[<
ffffffff81362a23>] scsi_queue_insert+0x13/0x20
[<
ffffffff8135e4d4>] scsi_eh_flush_done_q+0x104/0x160
[<
ffffffff8135fb6b>] scsi_error_handler+0x35b/0x660
[<
ffffffff8135f810>] ? scsi_error_handler+0x0/0x660
[<
ffffffff810908c6>] kthread+0x96/0xa0
[<
ffffffff8100c14a>] child_rip+0xa/0x20
[<
ffffffff81090830>] ? kthread+0x0/0xa0
[<
ffffffff8100c140>] ? child_rip+0x0/0x20
Code: 00 00 eb d1 4c 8b 2d 3c 8f 97 00 4d 85 ed 74 bf 49 8b 45 00 49 83 c5 08 48 89 de 4c 89 e7 ff d0 49 8b 45 00 48 85 c0 75 eb eb a4 <0f> 0b eb fe 0f 1f 84 00 00 00 00 00 55 48 89 e5 0f 1f 44 00 00
RIP [<
ffffffff8124e424>] blk_requeue_request+0x94/0xa0
RSP <
ffff881057eefd60>
The RIP is this line:
BUG_ON(blk_queued_rq(rq));
After digging through the code, I think there may be a race between the
request completion and the timer handler running.
A timer is started for each request put on the device's queue (see
blk_start_request->blk_add_timer). If the request does not complete
before the timer expires, the timer handler (blk_rq_timed_out_timer)
will mark the request complete atomically:
static inline int blk_mark_rq_complete(struct request *rq)
{
return test_and_set_bit(REQ_ATOM_COMPLETE, &rq->atomic_flags);
}
and then call blk_rq_timed_out. The latter function will call
scsi_times_out, which will return one of BLK_EH_HANDLED,
BLK_EH_RESET_TIMER or BLK_EH_NOT_HANDLED. If BLK_EH_RESET_TIMER is
returned, blk_clear_rq_complete is called, and blk_add_timer is again
called to simply wait longer for the request to complete.
Now, if the request happens to complete while this is going on, what
happens? Given that we know the completion handler will bail if it
finds the REQ_ATOM_COMPLETE bit set, we need to focus on the completion
handler running after that bit is cleared. So, from the above
paragraph, after the call to blk_clear_rq_complete. If the completion
sets REQ_ATOM_COMPLETE before the BUG_ON in blk_add_timer, we go boom
there (I haven't seen this in the cores). Next, if we get the
completion before the call to list_add_tail, then the timer will
eventually fire for an old req, which may either be freed or reallocated
(there is evidence that this might be the case). Finally, if the
completion comes in *after* the addition to the timeout list, I think
it's harmless. The request will be removed from the timeout list,
req_atom_complete will be set, and all will be well.
This will only actually explain the coredumps *IF* the request
structure was freed, reallocated *and* queued before the error handler
thread had a chance to process it. That is possible, but it may make
sense to keep digging for another race. I think that if this is what
was happening, we would see other instances of this problem showing up
as null pointer or garbage pointer dereferences, for example when the
request structure was not re-used. It looks like we actually do run
into that situation in other reports.
This patch moves the BUG_ON(test_bit(REQ_ATOM_COMPLETE,
&req->atomic_flags)); from blk_add_timer to the only caller that could
trip over it (blk_start_request). It then inverts the calls to
blk_clear_rq_complete and blk_add_timer in blk_rq_timed_out to address
the race. I've boot tested this patch, but nothing more.
Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
Acked-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guenter Roeck [Fri, 15 Nov 2013 09:40:38 +0000 (10:40 +0100)]
hwmon: (lm90) Fix max6696 alarm handling
commit
e41fae2b1ed8c78283d73651cd65be0228c0dd1c upstream.
Bit 2 of status register 2 on MAX6696 (external diode 2 open)
sets ALERT; the bit thus has to be listed in alert_alarms.
Also display a message in the alert handler if the condition
is encountered.
Even though not all overtemperature conditions cause ALERT
to be set, we should not ignore them in the alert handler.
Display messages for all out-of-range conditions.
Reported-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Renninger [Tue, 12 Nov 2013 16:39:43 +0000 (17:39 +0100)]
x86/microcode/amd: Tone down printk(), don't treat a missing firmware file as an error
commit
11f918d3e2d3861b6931e97b3aa778e4984935aa upstream.
Do it the same way as done in microcode_intel.c: use pr_debug()
for missing firmware files.
There seem to be CPUs out there for which no microcode update
has been submitted to kernel-firmware repo yet resulting in
scary sounding error messages in dmesg:
microcode: failed to load file amd-ucode/microcode_amd_fam16h.bin
Signed-off-by: Thomas Renninger <trenn@suse.de>
Acked-by: Borislav Petkov <bp@suse.de>
Link: http://lkml.kernel.org/r/1384274383-43510-1-git-send-email-trenn@suse.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christoph Hellwig [Mon, 18 Nov 2013 13:07:47 +0000 (05:07 -0800)]
nfsd: make sure to balance get/put_write_access
commit
987da4791052fa298b7cfcde4dea9f6f2bbc786b upstream.
Use a straight goto error label style in nfsd_setattr to make sure
we always do the put_write_access call after we got it earlier.
Note that the we have been failing to do that in the case
nfsd_break_lease() returns an error, a bug introduced into 2.6.38 with
6a76bebefe15d9a08864f824d7f8d5beaf37c997 "nfsd4: break lease on nfsd
setattr".
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christoph Hellwig [Mon, 18 Nov 2013 13:07:30 +0000 (05:07 -0800)]
nfsd: split up nfsd_setattr
commit
818e5a22e907fbae75e9c1fd78233baec9fa64b6 upstream.
Split out two helpers to make the code more readable and easier to verify
for correctness.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Trond Myklebust [Tue, 1 Oct 2013 18:24:58 +0000 (14:24 -0400)]
NFSv4: Fix a use-after-free situation in _nfs4_proc_getlk()
commit
a6f951ddbdfb7bd87d31a44f61abe202ed6ce57f upstream.
In nfs4_proc_getlk(), when some error causes a retry of the call to
_nfs4_proc_getlk(), we can end up with Oopses of the form
BUG: unable to handle kernel NULL pointer dereference at
0000000000000134
IP: [<
ffffffff8165270e>] _raw_spin_lock+0xe/0x30
<snip>
Call Trace:
[<
ffffffff812f287d>] _atomic_dec_and_lock+0x4d/0x70
[<
ffffffffa053c4f2>] nfs4_put_lock_state+0x32/0xb0 [nfsv4]
[<
ffffffffa053c585>] nfs4_fl_release_lock+0x15/0x20 [nfsv4]
[<
ffffffffa0522c06>] _nfs4_proc_getlk.isra.40+0x146/0x170 [nfsv4]
[<
ffffffffa052ad99>] nfs4_proc_lock+0x399/0x5a0 [nfsv4]
The problem is that we don't clear the request->fl_ops after the first
try and so when we retry, nfs4_set_lock_state() exits early without
setting the lock stateid.
Regression introduced by commit
70cc6487a4e08b8698c0e2ec935fb48d10490162
(locks: make ->lock release private data before returning in GETLK case)
Reported-by: Weston Andros Adamson <dros@netapp.com>
Reported-by: Jorge Mora <mora@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Tue, 12 Nov 2013 07:06:20 +0000 (08:06 +0100)]
ALSA: msnd: Avoid duplicated driver name
commit
092f9cd16aac7d054af1755c945f37c1b33399e6 upstream.
msnd_pinnacle.c is used for both snd-msnd-pinnacle and
snd-msnd-classic drivers, and both should have different driver
names. Using the same driver name results in the sysfs warning for
duplicated entries like
kobject: 'msnd-pinnacle.7' (
cec33408): kobject_release, parent (null) (delayed)
kobject: 'msnd-pinnacle' (
cecd4980): kobject_release, parent
cf3ad9b0 (delayed)
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at fs/sysfs/dir.c:486 sysfs_warn_dup+0x7d/0xa0()
sysfs: cannot create duplicate filename '/bus/isa/drivers/msnd-pinnacle'
......
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Mon, 28 Oct 2013 10:24:23 +0000 (11:24 +0100)]
ALSA: 6fire: Fix probe of multiple cards
commit
9b389a8a022110b4bc055a19b888283544d9eba6 upstream.
The probe code of snd-usb-6fire driver overrides the devices[] pointer
wrongly without checking whether it's already occupied or not. This
would screw up the device disconnection later.
Spotted by coverity CID 141423.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kees Cook [Tue, 12 Nov 2013 23:11:17 +0000 (15:11 -0800)]
exec/ptrace: fix get_dumpable() incorrect tests
commit
d049f74f2dbe71354d43d393ac3a188947811348 upstream.
The get_dumpable() return value is not boolean. Most users of the
function actually want to be testing for non-SUID_DUMP_USER(1) rather than
SUID_DUMP_DISABLE(0). The SUID_DUMP_ROOT(2) is also considered a
protected state. Almost all places did this correctly, excepting the two
places fixed in this patch.
Wrong logic:
if (dumpable == SUID_DUMP_DISABLE) { /* be protective */ }
or
if (dumpable == 0) { /* be protective */ }
or
if (!dumpable) { /* be protective */ }
Correct logic:
if (dumpable != SUID_DUMP_USER) { /* be protective */ }
or
if (dumpable != 1) { /* be protective */ }
Without this patch, if the system had set the sysctl fs/suid_dumpable=2, a
user was able to ptrace attach to processes that had dropped privileges to
that user. (This may have been partially mitigated if Yama was enabled.)
The macros have been moved into the file that declares get/set_dumpable(),
which means things like the ia64 code can see them too.
CVE-2013-2929
Reported-by: Vasily Kulikov <segoon@openwall.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: "Luck, Tony" <tony.luck@intel.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mimi Zohar [Thu, 17 Oct 2013 11:34:02 +0000 (07:34 -0400)]
Revert "ima: policy for RAMFS"
commit
08de59eb144d7c41351a467442f898d720f0f15f upstream.
This reverts commit
4c2c392763a682354fac65b6a569adec4e4b5387.
Everything in the initramfs should be measured and appraised,
but until the initramfs has extended attribute support, at
least measured.
Signed-off-by: Mimi Zohar <zohar@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stanislaw Gruszka [Tue, 15 Oct 2013 12:31:12 +0000 (14:31 +0200)]
rt2x00: check if device is still available on rt2x00mac_flush()
commit
5671ab05cf2a579218985ef56595387932d78ee4 upstream.
Fix random kernel panic with below messages when remove dongle.
[ 2212.355447] BUG: unable to handle kernel NULL pointer dereference at
0000000000000250
[ 2212.355527] IP: [<
ffffffffa02667f2>] rt2x00usb_kick_tx_entry+0x12/0x160 [rt2x00usb]
[ 2212.355599] PGD 0
[ 2212.355626] Oops: 0000 [#1] SMP
[ 2212.355664] Modules linked in: rt2800usb rt2x00usb rt2800lib crc_ccitt rt2x00lib mac80211 cfg80211 tun arc4 fuse rfcomm bnep snd_hda_codec_realtek snd_hda_intel snd_hda_codec btusb uvcvideo bluetooth snd_hwdep x86_pkg_temp_thermal snd_seq coretemp aesni_intel aes_x86_64 snd_seq_device glue_helper snd_pcm ablk_helper videobuf2_vmalloc sdhci_pci videobuf2_memops videobuf2_core sdhci videodev mmc_core serio_raw snd_page_alloc microcode i2c_i801 snd_timer hid_multitouch thinkpad_acpi lpc_ich mfd_core snd tpm_tis wmi tpm tpm_bios soundcore acpi_cpufreq i915 i2c_algo_bit drm_kms_helper drm i2c_core video [last unloaded: cfg80211]
[ 2212.356224] CPU: 0 PID: 34 Comm: khubd Not tainted 3.12.0-rc3-wl+ #3
[ 2212.356268] Hardware name: LENOVO 3444CUU/3444CUU, BIOS G6ET93WW (2.53 ) 02/04/2013
[ 2212.356319] task:
ffff880212f687c0 ti:
ffff880212f66000 task.ti:
ffff880212f66000
[ 2212.356392] RIP: 0010:[<
ffffffffa02667f2>] [<
ffffffffa02667f2>] rt2x00usb_kick_tx_entry+0x12/0x160 [rt2x00usb]
[ 2212.356481] RSP: 0018:
ffff880212f67750 EFLAGS:
00010202
[ 2212.356519] RAX:
000000000000000c RBX:
000000000000000c RCX:
0000000000000293
[ 2212.356568] RDX:
ffff8801f4dc219a RSI:
0000000000000000 RDI:
0000000000000240
[ 2212.356617] RBP:
ffff880212f67778 R08:
ffffffffa02667e0 R09:
0000000000000002
[ 2212.356665] R10:
0001f95254ab4b40 R11:
ffff880212f675be R12:
ffff8801f4dc2150
[ 2212.356712] R13:
0000000000000000 R14:
ffffffffa02667e0 R15:
000000000000000d
[ 2212.356761] FS:
0000000000000000(0000) GS:
ffff88021e200000(0000) knlGS:
0000000000000000
[ 2212.356813] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 2212.356852] CR2:
0000000000000250 CR3:
0000000001a0c000 CR4:
00000000001407f0
[ 2212.356899] Stack:
[ 2212.356917]
000000000000000c ffff8801f4dc2150 0000000000000000 ffffffffa02667e0
[ 2212.356980]
000000000000000d ffff880212f677b8 ffffffffa03a31ad ffff8801f4dc219a
[ 2212.357038]
ffff8801f4dc2150 0000000000000000 ffff8800b93217a0 ffff8801f49bc800
[ 2212.357099] Call Trace:
[ 2212.357122] [<
ffffffffa02667e0>] ? rt2x00usb_interrupt_txdone+0x90/0x90 [rt2x00usb]
[ 2212.357174] [<
ffffffffa03a31ad>] rt2x00queue_for_each_entry+0xed/0x170 [rt2x00lib]
[ 2212.357244] [<
ffffffffa026701c>] rt2x00usb_kick_queue+0x5c/0x60 [rt2x00usb]
[ 2212.357314] [<
ffffffffa03a3682>] rt2x00queue_flush_queue+0x62/0xa0 [rt2x00lib]
[ 2212.357386] [<
ffffffffa03a2930>] rt2x00mac_flush+0x30/0x70 [rt2x00lib]
[ 2212.357470] [<
ffffffffa04edded>] ieee80211_flush_queues+0xbd/0x140 [mac80211]
[ 2212.357555] [<
ffffffffa0502e52>] ieee80211_set_disassoc+0x2d2/0x3d0 [mac80211]
[ 2212.357645] [<
ffffffffa0506da3>] ieee80211_mgd_deauth+0x1d3/0x240 [mac80211]
[ 2212.357718] [<
ffffffff8108b17c>] ? try_to_wake_up+0xec/0x290
[ 2212.357788] [<
ffffffffa04dbd18>] ieee80211_deauth+0x18/0x20 [mac80211]
[ 2212.357872] [<
ffffffffa0418ddc>] cfg80211_mlme_deauth+0x9c/0x140 [cfg80211]
[ 2212.357913] [<
ffffffffa041907c>] cfg80211_mlme_down+0x5c/0x60 [cfg80211]
[ 2212.357962] [<
ffffffffa041cd18>] cfg80211_disconnect+0x188/0x1a0 [cfg80211]
[ 2212.358014] [<
ffffffffa04013bc>] ? __cfg80211_stop_sched_scan+0x1c/0x130 [cfg80211]
[ 2212.358067] [<
ffffffffa03f8954>] cfg80211_leave+0xc4/0xe0 [cfg80211]
[ 2212.358124] [<
ffffffffa03f8d1b>] cfg80211_netdev_notifier_call+0x3ab/0x5e0 [cfg80211]
[ 2212.358177] [<
ffffffff815140f8>] ? inetdev_event+0x38/0x510
[ 2212.358217] [<
ffffffff81085a94>] ? __wake_up+0x44/0x50
[ 2212.358254] [<
ffffffff8155995c>] notifier_call_chain+0x4c/0x70
[ 2212.358293] [<
ffffffff81081156>] raw_notifier_call_chain+0x16/0x20
[ 2212.358361] [<
ffffffff814b6dd5>] call_netdevice_notifiers_info+0x35/0x60
[ 2212.358429] [<
ffffffff814b6ec9>] __dev_close_many+0x49/0xd0
[ 2212.358487] [<
ffffffff814b7028>] dev_close_many+0x88/0x100
[ 2212.358546] [<
ffffffff814b8150>] rollback_registered_many+0xb0/0x220
[ 2212.358612] [<
ffffffff814b8319>] unregister_netdevice_many+0x19/0x60
[ 2212.358694] [<
ffffffffa04d8eb2>] ieee80211_remove_interfaces+0x112/0x190 [mac80211]
[ 2212.358791] [<
ffffffffa04c585f>] ieee80211_unregister_hw+0x4f/0x100 [mac80211]
[ 2212.361994] [<
ffffffffa03a1221>] rt2x00lib_remove_dev+0x161/0x1a0 [rt2x00lib]
[ 2212.365240] [<
ffffffffa0266e2e>] rt2x00usb_disconnect+0x2e/0x70 [rt2x00usb]
[ 2212.368470] [<
ffffffff81419ce4>] usb_unbind_interface+0x64/0x1c0
[ 2212.371734] [<
ffffffff813b446f>] __device_release_driver+0x7f/0xf0
[ 2212.374999] [<
ffffffff813b4503>] device_release_driver+0x23/0x30
[ 2212.378131] [<
ffffffff813b3c98>] bus_remove_device+0x108/0x180
[ 2212.381358] [<
ffffffff813b0565>] device_del+0x135/0x1d0
[ 2212.384454] [<
ffffffff81417760>] usb_disable_device+0xb0/0x270
[ 2212.387451] [<
ffffffff8140d9cd>] usb_disconnect+0xad/0x1d0
[ 2212.390294] [<
ffffffff8140f6cd>] hub_thread+0x63d/0x1660
[ 2212.393034] [<
ffffffff8107c860>] ? wake_up_atomic_t+0x30/0x30
[ 2212.395728] [<
ffffffff8140f090>] ? hub_port_debounce+0x130/0x130
[ 2212.398412] [<
ffffffff8107baa0>] kthread+0xc0/0xd0
[ 2212.401058] [<
ffffffff8107b9e0>] ? insert_kthread_work+0x40/0x40
[ 2212.403639] [<
ffffffff8155de3c>] ret_from_fork+0x7c/0xb0
[ 2212.406193] [<
ffffffff8107b9e0>] ? insert_kthread_work+0x40/0x40
[ 2212.408732] Code: 24 58 08 00 00 bf 80 00 00 00 e8 3a c3 e0 e0 5b 41 5c 5d c3 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 <48> 8b 47 10 48 89 fb 4c 8b 6f 28 4c 8b 20 49 8b 04 24 4c 8b 30
[ 2212.414671] RIP [<
ffffffffa02667f2>] rt2x00usb_kick_tx_entry+0x12/0x160 [rt2x00usb]
[ 2212.417646] RSP <
ffff880212f67750>
[ 2212.420547] CR2:
0000000000000250
[ 2212.441024] ---[ end trace
5442918f33832bce ]---
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steven Rostedt [Tue, 5 Nov 2013 17:51:11 +0000 (12:51 -0500)]
perf/ftrace: Fix paranoid level for enabling function tracer
commit
12ae030d54ef250706da5642fc7697cc60ad0df7 upstream.
The current default perf paranoid level is "1" which has
"perf_paranoid_kernel()" return false, and giving any operations that
use it, access to normal users. Unfortunately, this includes function
tracing and normal users should not be allowed to enable function
tracing by default.
The proper level is defined at "-1" (full perf access), which
"perf_paranoid_tracepoint_raw()" will only give access to. Use that
check instead for enabling function tracing.
Reported-by: Dave Jones <davej@redhat.com>
Reported-by: Vince Weaver <vincent.weaver@maine.edu>
Tested-by: Vince Weaver <vincent.weaver@maine.edu>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
CVE: CVE-2013-2930
Fixes:
ced39002f5ea ("ftrace, perf: Add support to use function tracepoint in perf")
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fan Du [Tue, 30 Apr 2013 22:27:27 +0000 (15:27 -0700)]
include/linux/fs.h: disable preempt when acquire i_size_seqcount write lock
commit
74e3d1e17b2e11d175970b85acd44f5927000ba2 upstream.
Two rt tasks bind to one CPU core.
The higher priority rt task A preempts a lower priority rt task B which
has already taken the write seq lock, and then the higher priority rt
task A try to acquire read seq lock, it's doomed to lockup.
rt task A with lower priority: call write
i_size_write rt task B with higher priority: call sync, and preempt task A
write_seqcount_begin(&inode->i_size_seqcount); i_size_read
inode->i_size = i_size; read_seqcount_begin <-- lockup here...
So disable preempt when acquiring every i_size_seqcount *write* lock will
cure the problem.
Signed-off-by: Fan Du <fan.du@windriver.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Zhao Hongjiang <zhaohongjiang@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oleg Nesterov [Tue, 30 Apr 2013 22:28:20 +0000 (15:28 -0700)]
exec: do not abuse ->cred_guard_mutex in threadgroup_lock()
commit
e56fb2874015370e3b7f8d85051f6dce26051df9 upstream.
threadgroup_lock() takes signal->cred_guard_mutex to ensure that
thread_group_leader() is stable. This doesn't look nice, the scope of
this lock in do_execve() is huge.
And as Dave pointed out this can lead to deadlock, we have the
following dependencies:
do_execve: cred_guard_mutex -> i_mutex
cgroup_mount: i_mutex -> cgroup_mutex
attach_task_by_pid: cgroup_mutex -> cred_guard_mutex
Change de_thread() to take threadgroup_change_begin() around the
switch-the-leader code and change threadgroup_lock() to avoid
->cred_guard_mutex.
Note that de_thread() can't sleep with ->group_rwsem held, this can
obviously deadlock with the exiting leader if the writer is active, so it
does threadgroup_change_end() before schedule().
Reported-by: Dave Jones <davej@redhat.com>
Acked-by: Tejun Heo <tj@kernel.org>
Acked-by: Li Zefan <lizefan@huawei.com>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[ zhj: adjust context ]
Signed-off-by: Zhao Hongjiang <zhaohongjiang@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Al Viro [Tue, 26 Mar 2013 22:25:57 +0000 (18:25 -0400)]
Nest rename_lock inside vfsmount_lock
commit
7ea600b5314529f9d1b9d6d3c41cb26fce6a7a4a upstream.
... lest we get livelocks between path_is_under() and d_path() and friends.
The thing is, wrt fairness lglocks are more similar to rwsems than to rwlocks;
it is possible to have thread B spin on attempt to take lock shared while thread
A is already holding it shared, if B is on lower-numbered CPU than A and there's
a thread C spinning on attempt to take the same lock exclusive.
As the result, we need consistent ordering between vfsmount_lock (lglock) and
rename_lock (seq_lock), even though everything that takes both is going to take
vfsmount_lock only shared.
Spotted-by: Brad Spengler <spender@grsecurity.net>
Cc: stable@vger.kernel.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
[ zhj: backport to 3.4:
- Adjust context
- s/&vfsmount_lock/vfsmount_lock/]
Signed-off-by: Zhao Hongjiang <zhaohongjiang@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andy Adamson [Wed, 14 Aug 2013 15:59:13 +0000 (11:59 -0400)]
SUNRPC: don't map EKEYEXPIRED to EACCES in call_refreshresult
commit
f1ff0c27fd9987c59d707cd1a6b6c1fc3ae0a250 upstream.
The NFS layer needs to know when a key has expired.
This change also returns -EKEYEXPIRED to the application, and the informative
"Key has expired" error message is displayed. The user then knows that
credential renewal is required.
Signed-off-by: Andy Adamson <andros@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andy Adamson [Tue, 27 Nov 2012 15:34:19 +0000 (10:34 -0500)]
SUNRPC handle EKEYEXPIRED in call_refreshresult
commit
eb96d5c97b0825d542e9c4ba5e0a22b519355166 upstream.
Currently, when an RPCSEC_GSS context has expired or is non-existent
and the users (Kerberos) credentials have also expired or are non-existent,
the client receives the -EKEYEXPIRED error and tries to refresh the context
forever. If an application is performing I/O, or other work against the share,
the application hangs, and the user is not prompted to refresh/establish their
credentials. This can result in a denial of service for other users.
Users are expected to manage their Kerberos credential lifetimes to mitigate
this issue.
Move the -EKEYEXPIRED handling into the RPC layer. Try tk_cred_retry number
of times to refresh the gss_context, and then return -EACCES to the application.
Signed-off-by: Andy Adamson <andros@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
[bwh: Backported to 3.2:
- Adjust context
- Drop change to nfs4_handle_reclaim_lease_error()]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linus Torvalds [Tue, 29 Oct 2013 17:21:34 +0000 (10:21 -0700)]
Fix a few incorrectly checked [io_]remap_pfn_range() calls
commit
7314e613d5ff9f0934f7a0f74ed7973b903315d1 upstream.
Nico Golde reports a few straggling uses of [io_]remap_pfn_range() that
really should use the vm_iomap_memory() helper. This trivially converts
two of them to the helper, and comments about why the third one really
needs to continue to use remap_pfn_range(), and adds the missing size
check.
Reported-by: Nico Golde <nico@ngolde.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org.
[lizf: backported to 3.4:
- adjust context
- no uio_physical_vm_ops]
Signed-off-by: Li Zefan <lizefan@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Woodhouse [Sat, 24 Nov 2012 12:11:21 +0000 (12:11 +0000)]
8139cp: re-enable interrupts after tx timeout
commit
01ffc0a7f1c1801a2354719dedbc32aff45b987d upstream.
Recovery doesn't work too well if we leave interrupts disabled...
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Acked-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Markus Pargmann [Mon, 28 Oct 2013 08:54:40 +0000 (09:54 +0100)]
can: c_can: Fix RX message handling, handle lost message before EOB
commit
5d0f801a2ccec3b1fdabc3392c8d99ed0413d216 upstream.
If we handle end of block messages with higher priority than a lost message,
we can run into an endless interrupt loop.
This is reproducable with a am335x processor and "cansequence -r" at 1Mbit.
As soon as we loose a packet we can't escape from an interrupt loop.
This patch fixes the problem by handling lost packets before EOB packets.
Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Neil Horman [Tue, 17 Sep 2013 12:33:11 +0000 (08:33 -0400)]
crypto: ansi_cprng - Fix off by one error in non-block size request
commit
714b33d15130cbb5ab426456d4e3de842d6c5b8a upstream.
Stephan Mueller reported to me recently a error in random number generation in
the ansi cprng. If several small requests are made that are less than the
instances block size, the remainder for loop code doesn't increment
rand_data_valid in the last iteration, meaning that the last bytes in the
rand_data buffer gets reused on the subsequent smaller-than-a-block request for
random data.
The fix is pretty easy, just re-code the for loop to make sure that
rand_data_valid gets incremented appropriately
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Reported-by: Stephan Mueller <stephan.mueller@atsec.com>
CC: Stephan Mueller <stephan.mueller@atsec.com>
CC: Petr Matousek <pmatouse@redhat.com>
CC: Herbert Xu <herbert@gondor.apana.org.au>
CC: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Wed, 9 Oct 2013 15:01:09 +0000 (17:01 +0200)]
USB: mos7840: fix tiocmget error handling
commit
a91ccd26e75235d86248d018fe3779732bcafd8d upstream.
Make sure to return errors from tiocmget rather than rely on
uninitialised stack data.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bob Moore [Fri, 6 Sep 2013 06:27:15 +0000 (14:27 +0800)]
ACPICA: Fix for a Store->ArgX when ArgX contains a reference to a field.
commit
4be4be8fee2ee99a52f94f90d03d2f287ee1db86 upstream.
This change fixes a problem where a Store operation to an ArgX object
that contained a reference to a field object did not complete the
automatic dereference and then write to the actual field object.
Instead, the object type of the field object was inadvertently changed
to match the type of the source operand. The new behavior will actually
write to the field object (buffer field or field unit), thus matching
the correct ACPI-defined behavior.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bob Moore [Thu, 8 Aug 2013 07:29:58 +0000 (15:29 +0800)]
ACPICA: Return error if DerefOf resolves to a null package element.
commit
a50abf4842dd7d603a2ad6dcc7f1467fd2a66f03 upstream.
Disallow the dereference of a reference (via index) to an uninitialized
package element. Provides compatibility with other ACPI
implementations. ACPICA BZ 1003.
References: https://bugs.acpica.org/show_bug.cgi?id=431
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bob Moore [Thu, 8 Aug 2013 07:29:32 +0000 (15:29 +0800)]
ACPICA: DeRefOf operator: Update to fully resolve FieldUnit and BufferField refs.
commit
63660e05ec719613b518547b40a1c501c10f0bc4 upstream.
Previously, references to these objects were resolved only to the actual
FieldUnit or BufferField object. The correct behavior is to resolve these
references to an actual value.
The problem is that DerefOf did not resolve these objects to actual
values. An "Integer" object is simple, return the value. But a field in
an operation region will require a read operation. For a BufferField, the
appropriate data must be extracted from the parent buffer.
NOTE: It appears that this issues is present in Windows7 but not
Windows8.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bob Moore [Mon, 31 Dec 2012 00:11:45 +0000 (00:11 +0000)]
ACPICA: Interpreter: Fix Store() when implicit conversion is not possible.
commit
3f654bad3257427bea7ba1c4d43a23d99a03622b upstream.
For the cases such as a store of a string to an existing package
object, implement the store as a CopyObject().
This is a small departure from the ACPI specification which states
that the control method should be aborted in this case. However,
ASLTS suite depends on this behavior.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mahesh Rajashekhara [Thu, 31 Oct 2013 08:31:02 +0000 (14:01 +0530)]
aacraid: prevent invalid pointer dereference
commit
b4789b8e6be3151a955ade74872822f30e8cd914 upstream.
It appears that driver runs into a problem here if fibsize is too small
because we allocate user_srbcmd with fibsize size only but later we
access it until user_srbcmd->sg.count to copy it over to srbcmd.
It is not correct to test (fibsize < sizeof(*user_srbcmd)) because this
structure already includes one sg element and this is not needed for
commands without data. So, we would recommend to add the following
(instead of test for fibsize == 0).
Signed-off-by: Mahesh Rajashekhara <Mahesh.Rajashekhara@pmcs.com>
Reported-by: Nico Golde <nico@ngolde.de>
Reported-by: Fabian Yamaguchi <fabs@goesec.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Wed, 30 Oct 2013 17:12:51 +0000 (20:12 +0300)]
libertas: potential oops in debugfs
commit
a497e47d4aec37aaf8f13509f3ef3d1f6a717d88 upstream.
If we do a zero size allocation then it will oops. Also we can't be
sure the user passes us a NUL terminated string so I've added a
terminator.
This code can only be triggered by root.
Reported-by: Nico Golde <nico@ngolde.de>
Reported-by: Fabian Yamaguchi <fabs@goesec.de>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jeff Layton [Thu, 28 Feb 2013 01:10:34 +0000 (20:10 -0500)]
nfs: don't allow nfs_find_actor to match inodes of the wrong type
commit
f6488c9ba51d65410e2dbc4345413c0d9120971e upstream.
Benny Halevy reported the following oops when testing RHEL6:
<7>nfs_update_inode: inode 892950 mode changed, 0040755 to 0100644
<1>BUG: unable to handle kernel NULL pointer dereference at (null)
<1>IP: [<
ffffffffa02a52c5>] nfs_closedir+0x15/0x30 [nfs]
<4>PGD
81448a067 PUD
831632067 PMD 0
<4>Oops: 0000 [#1] SMP
<4>last sysfs file: /sys/kernel/mm/redhat_transparent_hugepage/enabled
<4>CPU 6
<4>Modules linked in: fuse bonding 8021q garp ebtable_nat ebtables be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi cxgb3 mdio ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi softdog bridge stp llc xt_physdev ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 xt_multiport iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 dm_round_robin dm_multipath objlayoutdriver2(U) nfs(U) lockd fscache auth_rpcgss nfs_acl sunrpc vhost_net macvtap macvlan tun kvm_intel kvm be2net igb dca ptp pps_core microcode serio_raw sg iTCO_wdt iTCO_vendor_support i7core_edac edac_core shpchp ext4 mbcache jbd2 sd_mod crc_t10dif ahci dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan]
<4>
<4>Pid: 6332, comm: dd Not tainted 2.6.32-358.el6.x86_64 #1 HP ProLiant DL170e G6 /ProLiant DL170e G6
<4>RIP: 0010:[<
ffffffffa02a52c5>] [<
ffffffffa02a52c5>] nfs_closedir+0x15/0x30 [nfs]
<4>RSP: 0018:
ffff88081458bb98 EFLAGS:
00010292
<4>RAX:
ffffffffa02a52b0 RBX:
0000000000000000 RCX:
0000000000000003
<4>RDX:
ffffffffa02e45a0 RSI:
ffff88081440b300 RDI:
ffff88082d5f5760
<4>RBP:
ffff88081458bba8 R08:
0000000000000000 R09:
0000000000000000
<4>R10:
0000000000000772 R11:
0000000000400004 R12:
0000000040000008
<4>R13:
ffff88082d5f5760 R14:
ffff88082d6e8800 R15:
ffff88082f12d780
<4>FS:
00007f728f37e700(0000) GS:
ffff8800456c0000(0000) knlGS:
0000000000000000
<4>CS: 0010 DS: 0000 ES: 0000 CR0:
000000008005003b
<4>CR2:
0000000000000000 CR3:
0000000831279000 CR4:
00000000000007e0
<4>DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
<4>DR3:
0000000000000000 DR6:
00000000ffff0ff0 DR7:
0000000000000400
<4>Process dd (pid: 6332, threadinfo
ffff88081458a000, task
ffff88082fa0e040)
<4>Stack:
<4>
0000000040000008 ffff88081440b300 ffff88081458bbf8 ffffffff81182745
<4><d>
ffff88082d5f5760 ffff88082d6e8800 ffff88081458bbf8 ffffffffffffffea
<4><d>
ffff88082f12d780 ffff88082d6e8800 ffffffffa02a50a0 ffff88082d5f5760
<4>Call Trace:
<4> [<
ffffffff81182745>] __fput+0xf5/0x210
<4> [<
ffffffffa02a50a0>] ? do_open+0x0/0x20 [nfs]
<4> [<
ffffffff81182885>] fput+0x25/0x30
<4> [<
ffffffff8117e23e>] __dentry_open+0x27e/0x360
<4> [<
ffffffff811c397a>] ? inotify_d_instantiate+0x2a/0x60
<4> [<
ffffffff8117e4b9>] lookup_instantiate_filp+0x69/0x90
<4> [<
ffffffffa02a6679>] nfs_intent_set_file+0x59/0x90 [nfs]
<4> [<
ffffffffa02a686b>] nfs_atomic_lookup+0x1bb/0x310 [nfs]
<4> [<
ffffffff8118e0c2>] __lookup_hash+0x102/0x160
<4> [<
ffffffff81225052>] ? selinux_inode_permission+0x72/0xb0
<4> [<
ffffffff8118e76a>] lookup_hash+0x3a/0x50
<4> [<
ffffffff81192a4b>] do_filp_open+0x2eb/0xdd0
<4> [<
ffffffff8104757c>] ? __do_page_fault+0x1ec/0x480
<4> [<
ffffffff8119f562>] ? alloc_fd+0x92/0x160
<4> [<
ffffffff8117de79>] do_sys_open+0x69/0x140
<4> [<
ffffffff811811f6>] ? sys_lseek+0x66/0x80
<4> [<
ffffffff8117df90>] sys_open+0x20/0x30
<4> [<
ffffffff8100b072>] system_call_fastpath+0x16/0x1b
<4>Code: 65 48 8b 04 25 c8 cb 00 00 83 a8 44 e0 ff ff 01 5b 41 5c c9 c3 90 55 48 89 e5 53 48 83 ec 08 0f 1f 44 00 00 48 8b 9e a0 00 00 00 <48> 8b 3b e8 13 0c f7 ff 48 89 df e8 ab 3d ec e0 48 83 c4 08 31
<1>RIP [<
ffffffffa02a52c5>] nfs_closedir+0x15/0x30 [nfs]
<4> RSP <
ffff88081458bb98>
<4>CR2:
0000000000000000
I think this is ultimately due to a bug on the server. The client had
previously found a directory dentry. It then later tried to do an atomic
open on a new (regular file) dentry. The attributes it got back had the
same filehandle as the previously found directory inode. It then tried
to put the filp because it failed the aops tests for O_DIRECT opens, and
oopsed here because the ctx was still NULL.
Obviously the root cause here is a server issue, but we can take steps
to mitigate this on the client. When nfs_fhget is called, we always know
what type of inode it is. In the event that there's a broken or
malicious server on the other end of the wire, the client can end up
crashing because the wrong ops are set on it.
Have nfs_find_actor check that the inode type is correct after checking
the fileid. The fileid check should rarely ever match, so it should only
rarely ever get to this check. In the case where we have a broken
server, we may see two different inodes with the same i_ino, but the
client should be able to cope with them without crashing.
This should fix the oops reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=913660
Reported-by: Benny Halevy <bhalevy@tonian.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Rui Xiang <rui.xiang@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linus Torvalds [Fri, 22 Mar 2013 18:44:04 +0000 (11:44 -0700)]
vfs,proc: guarantee unique inodes in /proc
commit
51f0885e5415b4cc6535e9cdcc5145bfbc134353 upstream.
Dave Jones found another /proc issue with his Trinity tool: thanks to
the namespace model, we can have multiple /proc dentries that point to
the same inode, aliasing directories in /proc/<pid>/net/ for example.
This ends up being a total disaster, because it acts like hardlinked
directories, and causes locking problems. We rely on the topological
sort of the inodes pointed to by dentries, and if we have aliased
directories, that odering becomes unreliable.
In short: don't do this. Multiple dentries with the same (directory)
inode is just a bad idea, and the namespace code should never have
exposed things this way. But we're kind of stuck with it.
This solves things by just always allocating a new inode during /proc
dentry lookup, instead of using "iget_locked()" to look up existing
inodes by superblock and number. That actually simplies the code a bit,
at the cost of potentially doing more inode [de]allocations.
That said, the inode lookup wasn't free either (and did a lot of locking
of inodes), so it is probably not that noticeable. We could easily keep
the old lookup model for non-directory entries, but rather than try to
be excessively clever this just implements the minimal and simplest
workaround for the problem.
Reported-and-tested-by: Dave Jones <davej@redhat.com>
Analyzed-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[bwh: Backported to 3.2:
- Adjust context
- Never drop the pde reference in proc_get_inode(), as callers only
expect this when we return an existing inode, and we never do that now]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Rui Xiang <rui.xiang@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Wed, 20 Nov 2013 18:43:41 +0000 (10:43 -0800)]
Linux 3.4.70
Krzysztof Mazur [Thu, 22 Aug 2013 12:49:38 +0000 (14:49 +0200)]
usb: fix cleanup after failure in hub_configure()
commit
d0308d4b6b02597f39fc31a9bddf7bb3faad5622 upstream.
If the hub_configure() fails after setting the hdev->maxchild
the hub->ports might be NULL or point to uninitialized kzallocated
memory causing NULL pointer dereference in hub_quiesce() during cleanup.
Now after such error the hdev->maxchild is set to 0 to avoid cleanup
of uninitialized ports.
Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rafael J. Wysocki [Mon, 4 Feb 2013 11:56:05 +0000 (15:56 +0400)]
PCI/PM: Clear state_saved during suspend
commit
82fee4d67ab86d6fe5eb0f9a9e988ca9d654d765 upstream.
This patch clears pci_dev->state_saved at the beginning of suspending.
PCI config state may be saved long before that. Some drivers call
pci_save_state() from the ->probe() callback to get snapshot of sane
configuration space to use in the ->slot_reset() callback.
[wangyj: adjust context]
Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org> # add comment
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicolas Pitre [Tue, 12 Mar 2013 12:00:42 +0000 (13:00 +0100)]
ARM: 7670/1: fix the memset fix
commit
418df63adac56841ef6b0f1fcf435bc64d4ed177 upstream.
Commit
455bd4c430b0 ("ARM: 7668/1: fix memset-related crashes caused by
recent GCC (4.7.2) optimizations") attempted to fix a compliance issue
with the memset return value. However the memset itself became broken
by that patch for misaligned pointers.
This fixes the above by branching over the entry code from the
misaligned fixup code to avoid reloading the original pointer.
Also, because the function entry alignment is wrong in the Thumb mode
compilation, that fixup code is moved to the end.
While at it, the entry instructions are slightly reworked to help dual
issue pipelines.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
Tested-by: Alexander Holler <holler@ahsoftware.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Eric Bénard <eric@eukrea.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ivan Djelic [Wed, 6 Mar 2013 19:09:27 +0000 (20:09 +0100)]
ARM: 7668/1: fix memset-related crashes caused by recent GCC (4.7.2) optimizations
commit
455bd4c430b0c0a361f38e8658a0d6cb469942b5 upstream.
Recent GCC versions (e.g. GCC-4.7.2) perform optimizations based on
assumptions about the implementation of memset and similar functions.
The current ARM optimized memset code does not return the value of
its first argument, as is usually expected from standard implementations.
For instance in the following function:
void debug_mutex_lock_common(struct mutex *lock, struct mutex_waiter *waiter)
{
memset(waiter, MUTEX_DEBUG_INIT, sizeof(*waiter));
waiter->magic = waiter;
INIT_LIST_HEAD(&waiter->list);
}
compiled as:
800554d0 <debug_mutex_lock_common>:
800554d0:
e92d4008 push {r3, lr}
800554d4:
e1a00001 mov r0, r1
800554d8:
e3a02010 mov r2, #16 ; 0x10
800554dc:
e3a01011 mov r1, #17 ; 0x11
800554e0:
eb04426e bl
80165ea0 <memset>
800554e4:
e1a03000 mov r3, r0
800554e8:
e583000c str r0, [r3, #12]
800554ec:
e5830000 str r0, [r3]
800554f0:
e5830004 str r0, [r3, #4]
800554f4:
e8bd8008 pop {r3, pc}
GCC assumes memset returns the value of pointer 'waiter' in register r0; causing
register/memory corruptions.
This patch fixes the return value of the assembly version of memset.
It adds a 'mov' instruction and merges an additional load+store into
existing load/store instructions.
For ease of review, here is a breakdown of the patch into 4 simple steps:
Step 1
======
Perform the following substitutions:
ip -> r8, then
r0 -> ip,
and insert 'mov ip, r0' as the first statement of the function.
At this point, we have a memset() implementation returning the proper result,
but corrupting r8 on some paths (the ones that were using ip).
Step 2
======
Make sure r8 is saved and restored when (! CALGN(1)+0) == 1:
save r8:
- str lr, [sp, #-4]!
+ stmfd sp!, {r8, lr}
and restore r8 on both exit paths:
- ldmeqfd sp!, {pc} @ Now <64 bytes to go.
+ ldmeqfd sp!, {r8, pc} @ Now <64 bytes to go.
(...)
tst r2, #16
stmneia ip!, {r1, r3, r8, lr}
- ldr lr, [sp], #4
+ ldmfd sp!, {r8, lr}
Step 3
======
Make sure r8 is saved and restored when (! CALGN(1)+0) == 0:
save r8:
- stmfd sp!, {r4-r7, lr}
+ stmfd sp!, {r4-r8, lr}
and restore r8 on both exit paths:
bgt 3b
- ldmeqfd sp!, {r4-r7, pc}
+ ldmeqfd sp!, {r4-r8, pc}
(...)
tst r2, #16
stmneia ip!, {r4-r7}
- ldmfd sp!, {r4-r7, lr}
+ ldmfd sp!, {r4-r8, lr}
Step 4
======
Rewrite register list "r4-r7, r8" as "r4-r8".
Signed-off-by: Ivan Djelic <ivan.djelic@parrot.com>
Reviewed-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Dirk Behme <dirk.behme@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Eric Bénard <eric@eukrea.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steven Rostedt [Thu, 10 Oct 2013 02:23:23 +0000 (22:23 -0400)]
tracing: Fix potential out-of-bounds in trace_get_user()
commit
057db8488b53d5e4faa0cedb2f39d4ae75dfbdbb upstream.
Andrey reported the following report:
ERROR: AddressSanitizer: heap-buffer-overflow on address
ffff8800359c99f3
ffff8800359c99f3 is located 0 bytes to the right of 243-byte region [
ffff8800359c9900,
ffff8800359c99f3)
Accessed by thread T13003:
#0
ffffffff810dd2da (asan_report_error+0x32a/0x440)
#1
ffffffff810dc6b0 (asan_check_region+0x30/0x40)
#2
ffffffff810dd4d3 (__tsan_write1+0x13/0x20)
#3
ffffffff811cd19e (ftrace_regex_release+0x1be/0x260)
#4
ffffffff812a1065 (__fput+0x155/0x360)
#5
ffffffff812a12de (____fput+0x1e/0x30)
#6
ffffffff8111708d (task_work_run+0x10d/0x140)
#7
ffffffff810ea043 (do_exit+0x433/0x11f0)
#8
ffffffff810eaee4 (do_group_exit+0x84/0x130)
#9
ffffffff810eafb1 (SyS_exit_group+0x21/0x30)
#10
ffffffff81928782 (system_call_fastpath+0x16/0x1b)
Allocated by thread T5167:
#0
ffffffff810dc778 (asan_slab_alloc+0x48/0xc0)
#1
ffffffff8128337c (__kmalloc+0xbc/0x500)
#2
ffffffff811d9d54 (trace_parser_get_init+0x34/0x90)
#3
ffffffff811cd7b3 (ftrace_regex_open+0x83/0x2e0)
#4
ffffffff811cda7d (ftrace_filter_open+0x2d/0x40)
#5
ffffffff8129b4ff (do_dentry_open+0x32f/0x430)
#6
ffffffff8129b668 (finish_open+0x68/0xa0)
#7
ffffffff812b66ac (do_last+0xb8c/0x1710)
#8
ffffffff812b7350 (path_openat+0x120/0xb50)
#9
ffffffff812b8884 (do_filp_open+0x54/0xb0)
#10
ffffffff8129d36c (do_sys_open+0x1ac/0x2c0)
#11
ffffffff8129d4b7 (SyS_open+0x37/0x50)
#12
ffffffff81928782 (system_call_fastpath+0x16/0x1b)
Shadow bytes around the buggy address:
ffff8800359c9700: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
ffff8800359c9780: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
ffff8800359c9800: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
ffff8800359c9880: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
ffff8800359c9900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>
ffff8800359c9980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00[03]fb
ffff8800359c9a00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
ffff8800359c9a80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
ffff8800359c9b00: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
ffff8800359c9b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff8800359c9c00: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap redzone: fa
Heap kmalloc redzone: fb
Freed heap region: fd
Shadow gap: fe
The out-of-bounds access happens on 'parser->buffer[parser->idx] = 0;'
Although the crash happened in ftrace_regex_open() the real bug
occurred in trace_get_user() where there's an incrementation to
parser->idx without a check against the size. The way it is triggered
is if userspace sends in 128 characters (EVENT_BUF_SIZE + 1), the loop
that reads the last character stores it and then breaks out because
there is no more characters. Then the last character is read to determine
what to do next, and the index is incremented without checking size.
Then the caller of trace_get_user() usually nulls out the last character
with a zero, but since the index is equal to the size, it writes a nul
character after the allocated space, which can corrupt memory.
Luckily, only root user has write access to this file.
Link: http://lkml.kernel.org/r/20131009222323.04fd1a0d@gandalf.local.home
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Patrick McHardy [Fri, 5 Apr 2013 08:13:30 +0000 (08:13 +0000)]
netfilter: nf_ct_sip: don't drop packets with offsets pointing outside the packet
commit
3a7b21eaf4fb3c971bdb47a98f570550ddfe4471 upstream.
Some Cisco phones create huge messages that are spread over multiple packets.
After calculating the offset of the SIP body, it is validated to be within
the packet and the packet is dropped otherwise. This breaks operation of
these phones. Since connection tracking is supposed to be passive, just let
those packets pass unmodified and untracked.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: William Roberts <bill.c.roberts@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Wed, 20 Jun 2012 14:32:22 +0000 (16:32 +0200)]
ALSA: hda - Move one-time init codes from generic_hdmi_init()
commit
8b8d654b55648561287bd8baca0f75f964a17038 upstream.
The codes to initialize work struct or create a proc interface should
be called only once and never although it's called many times through
the init callback. Move that stuff into patch_generic_hdmi() so that
it's called only once.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
BugLink: https://bugs.launchpad.net/bugs/1212160
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rui li [Fri, 25 Oct 2013 02:57:21 +0000 (10:57 +0800)]
USB: add new zte 3g-dongle's pid to option.c
commit
0636fc507a976cdc40f21bdbcce6f0b98ff1dfe9 upstream.
Signed-off-by: Rui li <li.rui27@zte.com.cn>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nikhil P Rao [Wed, 20 Jun 2012 19:56:00 +0000 (12:56 -0700)]
PCI: fix truncation of resource size to 32 bits
commit
d6776e6d5c2f8db0252f447b09736075e1bbe387 upstream.
_pci_assign_resource() took an int "size" argument, which meant that
sizes larger than 4GB were truncated. Change type to resource_size_t.
[bhelgaas: changelog]
Signed-off-by: Nikhil P Rao <nikhil.rao@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jason Wang [Fri, 1 Nov 2013 07:01:10 +0000 (15:01 +0800)]
net: flow_dissector: fail on evil iph->ihl
[ Upstream commit
6f092343855a71e03b8d209815d8c45bf3a27fcd ]
We don't validate iph->ihl which may lead a dead loop if we meet a IPIP
skb whose iph->ihl is zero. Fix this by failing immediately when iph->ihl
is evil (less than 5).
This issue were introduced by commit
ec5efe7946280d1e84603389a1030ccec0a767ae
(rps: support IPIP encapsulation).
Signed-off-by: Jason Wang <jasowang@redhat.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Petr Matousek <pmatouse@redhat.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Daniel Borkmann <dborkman@redhat.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wei Liu [Mon, 28 Oct 2013 12:07:57 +0000 (12:07 +0000)]
xen-netback: use jiffies_64 value to calculate credit timeout
[ Upstream commit
059dfa6a93b779516321e5112db9d7621b1367ba ]
time_after_eq() only works if the delta is < MAX_ULONG/2.
For a 32bit Dom0, if netfront sends packets at a very low rate, the time
between subsequent calls to tx_credit_exceeded() may exceed MAX_ULONG/2
and the test for timer_after_eq() will be incorrect. Credit will not be
replenished and the guest may become unable to send packets (e.g., if
prior to the long gap, all credit was exhausted).
Use jiffies_64 variant to mitigate this problem for 32bit Dom0.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Jason Luan <jianhai.luan@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Wed, 13 Nov 2013 03:02:08 +0000 (12:02 +0900)]
Linux 3.4.69
Alex Deucher [Thu, 10 Oct 2013 20:45:27 +0000 (16:45 -0400)]
drm/radeon/atom: workaround vbios bug in transmitter table on rs780
commit
c23632d4e57c0dd20bf50eca08fa0eb8ad3ff680 upstream.
Some rs780 asics seem to be affected as well.
See:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=
91f3a6aaf280294b07c05dfe606e6c27b7ba3c72
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=60791
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chris Wilson [Wed, 16 Oct 2013 10:22:44 +0000 (11:22 +0100)]
drm: Prevent overwriting from userspace underallocating core ioctl structs
commit
b062672e305ce071f21eb9e18b102c2a430e0999 upstream.
Apply the protections from
commit
1b2f1489633888d4a06028315dc19d65768a1c05
Author: Dave Airlie <airlied@redhat.com>
Date: Sat Aug 14 20:20:34 2010 +1000
drm: block userspace under allocating buffer and having drivers overwrite it (v2)
to the core ioctl structs as well, for we found one instance where there
is a 32-/64-bit size mismatch and were guilty of writing beyond the end
of the user's buffer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dave Airlie <airlied@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Khalid Aziz [Wed, 11 Sep 2013 21:22:20 +0000 (14:22 -0700)]
mm: fix aio performance regression for database caused by THP
commit
7cb2ef56e6a8b7b368b2e883a0a47d02fed66911 upstream.
I am working with a tool that simulates oracle database I/O workload.
This tool (orion to be specific -
<http://docs.oracle.com/cd/E11882_01/server.112/e16638/iodesign.htm#autoId24>)
allocates hugetlbfs pages using shmget() with SHM_HUGETLB flag. It then
does aio into these pages from flash disks using various common block
sizes used by database. I am looking at performance with two of the most
common block sizes - 1M and 64K. aio performance with these two block
sizes plunged after Transparent HugePages was introduced in the kernel.
Here are performance numbers:
pre-THP 2.6.39 3.11-rc5
1M read 8384 MB/s 5629 MB/s 6501 MB/s
64K read 7867 MB/s 4576 MB/s 4251 MB/s
I have narrowed the performance impact down to the overheads introduced by
THP in __get_page_tail() and put_compound_page() routines. perf top shows
>40% of cycles being spent in these two routines. Every time direct I/O
to hugetlbfs pages starts, kernel calls get_page() to grab a reference to
the pages and calls put_page() when I/O completes to put the reference
away. THP introduced significant amount of locking overhead to get_page()
and put_page() when dealing with compound pages because hugepages can be
split underneath get_page() and put_page(). It added this overhead
irrespective of whether it is dealing with hugetlbfs pages or transparent
hugepages. This resulted in 20%-45% drop in aio performance when using
hugetlbfs pages.
Since hugetlbfs pages can not be split, there is no reason to go through
all the locking overhead for these pages from what I can see. I added
code to __get_page_tail() and put_compound_page() to bypass all the
locking code when working with hugetlbfs pages. This improved performance
significantly. Performance numbers with this patch:
pre-THP 3.11-rc5 3.11-rc5 + Patch
1M read 8384 MB/s 6501 MB/s 8371 MB/s
64K read 7867 MB/s 4251 MB/s 6510 MB/s
Performance with 64K read is still lower than what it was before THP, but
still a 53% improvement. It does mean there is more work to be done but I
will take a 53% improvement for now.
Please take a look at the following patch and let me know if it looks
reasonable.
[akpm@linux-foundation.org: tweak comments]
Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
Cc: Pravin B Shelar <pshelar@nicira.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Rik van Riel <riel@redhat.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Andi Kleen <andi@firstfloor.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Tue, 29 Oct 2013 19:11:06 +0000 (22:11 +0300)]
aacraid: missing capable() check in compat ioctl
commit
f856567b930dfcdbc3323261bf77240ccdde01f5 upstream.
In commit
d496f94d22d1 ('[SCSI] aacraid: fix security weakness') we
added a check on CAP_SYS_RAWIO to the ioctl. The compat ioctls need the
check as well.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ming Lei [Thu, 31 Oct 2013 23:34:17 +0000 (16:34 -0700)]
lib/scatterlist.c: don't flush_kernel_dcache_page on slab page
commit
3d77b50c5874b7e923be946ba793644f82336b75 upstream.
Commit
b1adaf65ba03 ("[SCSI] block: add sg buffer copy helper
functions") introduces two sg buffer copy helpers, and calls
flush_kernel_dcache_page() on pages in SG list after these pages are
written to.
Unfortunately, the commit may introduce a potential bug:
- Before sending some SCSI commands, kmalloc() buffer may be passed to
block layper, so flush_kernel_dcache_page() can see a slab page
finally
- According to cachetlb.txt, flush_kernel_dcache_page() is only called
on "a user page", which surely can't be a slab page.
- ARCH's implementation of flush_kernel_dcache_page() may use page
mapping information to do optimization so page_mapping() will see the
slab page, then VM_BUG_ON() is triggered.
Aaro Koskinen reported the bug on ARM/kirkwood when DEBUG_VM is enabled,
and this patch fixes the bug by adding test of '!PageSlab(miter->page)'
before calling flush_kernel_dcache_page().
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Tested-by: Simon Baatz <gmbnomis@gmail.com>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Tejun Heo <tj@kernel.org>
Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Baruch Siach [Mon, 14 Oct 2013 22:22:43 +0000 (02:22 +0400)]
xtensa: don't use alternate signal stack on threads
commit
cba9a90053e3b7973eff4f1946f33032e98eeed5 upstream.
According to create_thread(3): "The new thread does not inherit the creating
thread's alternate signal stack". Since commit
f9a3879a (Fix sigaltstack
corruption among cloned threads), current->sas_ss_size is set to 0 for cloned
processes sharing VM with their parent. Don't use the (nonexistent) alternate
signal stack in this case. This has been broken since commit
29c4dfd9 ([XTENSA]
Remove non-rt signal handling).
Fixes the SA_ONSTACK part of the nptl/tst-cancel20 test from uClibc.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Chris Zankel <chris@zankel.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Tue, 29 Oct 2013 19:06:04 +0000 (22:06 +0300)]
uml: check length in exitcode_proc_write()
commit
201f99f170df14ba52ea4c52847779042b7a623b upstream.
We don't cap the size of buffer from the user so we could write past the
end of the array here. Only root can write to this file.
Reported-by: Nico Golde <nico@ngolde.de>
Reported-by: Fabian Yamaguchi <fabs@goesec.de>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Tue, 29 Oct 2013 20:01:11 +0000 (23:01 +0300)]
Staging: bcm: info leak in ioctl
commit
8d1e72250c847fa96498ec029891de4dc638a5ba upstream.
The DevInfo.u32Reserved[] array isn't initialized so it leaks kernel
information to user space.
Reported-by: Nico Golde <nico@ngolde.de>
Reported-by: Fabian Yamaguchi <fabs@goesec.de>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Tue, 29 Oct 2013 19:07:47 +0000 (22:07 +0300)]
staging: ozwpan: prevent overflow in oz_cdev_write()
commit
c2c65cd2e14ada6de44cb527e7f1990bede24e15 upstream.
We need to check "count" so we don't overflow the ei->data buffer.
Reported-by: Nico Golde <nico@ngolde.de>
Reported-by: Fabian Yamaguchi <fabs@goesec.de>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Mon, 28 Oct 2013 13:21:49 +0000 (14:21 +0100)]
ASoC: dapm: Fix source list debugfs outputs
commit
ff18620c2157671a8ee21ebb8e6a3520ea209b1f upstream.
... due to a copy & paste error.
Spotted by coverity CID 710923.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Wed, 30 Oct 2013 07:35:02 +0000 (08:35 +0100)]
ASoC: wm_hubs: Add missing break in hp_supply_event()
commit
268ff14525edba31da29a12a9dd693cdd6a7872e upstream.
Spotted by coverity CID 115170.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Russell King [Thu, 31 Oct 2013 15:01:37 +0000 (15:01 +0000)]
ALSA: fix oops in snd_pcm_info() caused by ASoC DPCM
commit
a4461f41b94cb52e0141af717dcf4ef6558c8e2e upstream.
Unable to handle kernel NULL pointer dereference at virtual address
00000008
pgd =
d5300000
[
00000008] *pgd=
0d265831, *pte=
00000000, *ppte=
00000000
Internal error: Oops: 17 [#1] PREEMPT ARM
CPU: 0 PID: 2295 Comm: vlc Not tainted 3.11.0+ #755
task:
dee74800 ti:
e213c000 task.ti:
e213c000
PC is at snd_pcm_info+0xc8/0xd8
LR is at 0x30232065
pc : [<
c031b52c>] lr : [<
30232065>] psr:
a0070013
sp :
e213dea8 ip :
d81cb0d0 fp :
c05f7678
r10:
c05f7770 r9 :
fffffdfd r8 :
00000000
r7 :
d8a968a8 r6 :
d8a96800 r5 :
d8a96200 r4 :
d81cb000
r3 :
00000000 r2 :
d81cb000 r1 :
00000001 r0 :
d8a96200
Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control:
10c5387d Table:
15300019 DAC:
00000015
Process vlc (pid: 2295, stack limit = 0xe213c248)
[<
c031b52c>] (snd_pcm_info) from [<
c031b570>] (snd_pcm_info_user+0x34/0x9c)
[<
c031b570>] (snd_pcm_info_user) from [<
c03164a4>] (snd_pcm_control_ioctl+0x274/0x280)
[<
c03164a4>] (snd_pcm_control_ioctl) from [<
c0311458>] (snd_ctl_ioctl+0xc0/0x55c)
[<
c0311458>] (snd_ctl_ioctl) from [<
c00eca84>] (do_vfs_ioctl+0x80/0x31c)
[<
c00eca84>] (do_vfs_ioctl) from [<
c00ecd5c>] (SyS_ioctl+0x3c/0x60)
[<
c00ecd5c>] (SyS_ioctl) from [<
c000e500>] (ret_fast_syscall+0x0/0x48)
Code:
e1a00005 e59530dc e3a01001 e1a02004 (
e5933008)
---[ end trace
cb3d9bdb8dfefb3c ]---
This is provoked when the ASoC front end is open along with its backend,
(which causes the backend to have a runtime assigned to it) and then the
SNDRV_CTL_IOCTL_PCM_INFO is requested for the (visible) backend device.
Resolve this by ensuring that ASoC internal backend devices are not
visible to userspace, just as the commentry for snd_pcm_new_internal()
says it should be.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Wed, 30 Oct 2013 11:29:40 +0000 (12:29 +0100)]
ALSA: hda - Add a fixup for ASUS N76VZ
commit
6fc16e58adf50c0f1e4478538983fb5ff6f453d4 upstream.
ASUS N76VZ needs the same fixup as N56VZ for supporting the boost
speaker.
Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=846529
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Helge Deller [Sat, 26 Oct 2013 21:19:25 +0000 (23:19 +0200)]
parisc: Do not crash 64bit SMP kernels on machines with >= 4GB RAM
commit
54e181e073fc1415e41917d725ebdbd7de956455 upstream.
Since the beginning of the parisc-linux port, sometimes 64bit SMP kernels were
not able to bring up other CPUs than the monarch CPU and instead crashed the
kernel. The reason was unclear, esp. since it involved various machines (e.g.
J5600, J6750 and SuperDome). Testing showed, that those crashes didn't happened
when less than 4GB were installed, or if a 32bit Linux kernel was booted.
In the end, the fix for those SMP problems is trivial:
During the early phase of the initialization of the CPUs, including the monarch
CPU, the PDC_PSW firmware function to enable WIDE (=64bit) mode is called.
It's documented that this firmware function may clobber various registers, and
one one of those possibly clobbered registers is %cr30 which holds the task
thread info pointer.
Now, if %cr30 would always have been clobbered, then this bug would have been
detected much earlier. But lots of testing finally showed, that - at least for
%cr30 - on some machines only the upper 32bits of the 64bit register suddenly
turned zero after the firmware call.
So, after finding the root cause, the explanation for the various crashes
became clear:
- On 32bit SMP Linux kernels all upper 32bit were zero, so we didn't faced this
problem.
- Monarch CPUs in 64bit mode always booted sucessfully, because the inital task
thread info pointer was below 4GB.
- Secondary CPUs booted sucessfully on machines with less than 4GB RAM because
the upper 32bit were zero anyay.
- Secondary CPus failed to boot if we had more than 4GB RAM and the task thread
info pointer was located above the 4GB boundary.
Finally, the patch to fix this problem is trivial by saving the %cr30 register
before the firmware call and restoring it afterwards.
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Gleixner [Tue, 24 Sep 2013 19:50:23 +0000 (21:50 +0200)]
clockevents: Sanitize ticks to nsec conversion
commit
97b9410643475d6557d2517c2aff9fd2221141a9 upstream.
Marc Kleine-Budde pointed out, that commit 77cc982 "clocksource: use
clockevents_config_and_register() where possible" caused a regression
for some of the converted subarchs.
The reason is, that the clockevents core code converts the minimal
hardware tick delta to a nanosecond value for core internal
usage. This conversion is affected by integer math rounding loss, so
the backwards conversion to hardware ticks will likely result in a
value which is less than the configured hardware limitation. The
affected subarchs used their own workaround (SIGH!) which got lost in
the conversion.
The solution for the issue at hand is simple: adding evt->mult - 1 to
the shifted value before the integer divison in the core conversion
function takes care of it. But this only works for the case where for
the scaled math mult/shift pair "mult <= 1 << shift" is true. For the
case where "mult > 1 << shift" we can apply the rounding add only for
the minimum delta value to make sure that the backward conversion is
not less than the given hardware limit. For the upper bound we need to
omit the rounding add, because the backwards conversion is always
larger than the original latch value. That would violate the upper
bound of the hardware device.
Though looking closer at the details of that function reveals another
bogosity: The upper bounds check is broken as well. Checking for a
resulting "clc" value greater than KTIME_MAX after the conversion is
pointless. The conversion does:
u64 clc = (latch << evt->shift) / evt->mult;
So there is no sanity check for (latch << evt->shift) exceeding the
64bit boundary. The latch argument is "unsigned long", so on a 64bit
arch the handed in argument could easily lead to an unnoticed shift
overflow. With the above rounding fix applied the calculation before
the divison is:
u64 clc = (latch << evt->shift) + evt->mult - 1;
So we need to make sure, that neither the shift nor the rounding add
is overflowing the u64 boundary.
[ukl: move assignment to rnd after eventually changing mult, fix build
issue and correct comment with the right math]
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: nicolas.ferre@atmel.com
Cc: Marc Pignat <marc.pignat@hevs.ch>
Cc: john.stultz@linaro.org
Cc: kernel@pengutronix.de
Cc: Ronald Wahl <ronald.wahl@raritan.com>
Cc: LAK <linux-arm-kernel@lists.infradead.org>
Cc: Ludovic Desroches <ludovic.desroches@atmel.com>
Link: http://lkml.kernel.org/r/1380052223-24139-1-git-send-email-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lukasz Dorau [Thu, 24 Oct 2013 01:55:17 +0000 (12:55 +1100)]
md: Fix skipping recovery for read-only arrays.
commit
61e4947c99c4494336254ec540c50186d186150b upstream.
Since:
commit
7ceb17e87bde79d285a8b988cfed9eaeebe60b86
md: Allow devices to be re-added to a read-only array.
spares are activated on a read-only array. In case of raid1 and raid10
personalities it causes that not-in-sync devices are marked in-sync
without checking if recovery has been finished.
If a read-only array is degraded and one of its devices is not in-sync
(because the array has been only partially recovered) recovery will be skipped.
This patch adds checking if recovery has been finished before marking a device
in-sync for raid1 and raid10 personalities. In case of raid5 personality
such condition is already present (at raid5.c:6029).
Bug was introduced in 3.10 and causes data corruption.
Signed-off-by: Pawel Baldysiak <pawel.baldysiak@intel.com>
Signed-off-by: Lukasz Dorau <lukasz.dorau@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gwendal Grignou [Fri, 7 Aug 2009 23:17:49 +0000 (16:17 -0700)]
libata: make ata_eh_qc_retry() bump scmd->allowed on bogus failures
commit
f13e220161e738c2710b9904dcb3cf8bb0bcce61 upstream.
libata EH decrements scmd->retries when the command failed for reasons
unrelated to the command itself so that, for example, commands aborted
due to suspend / resume cycle don't get penalized; however,
decrementing scmd->retries isn't enough for ATA passthrough commands.
Without this fix, ATA passthrough commands are not resend to the
drive, and no error is signalled to the caller because:
- allowed retry count is 1
- ata_eh_qc_complete fill the sense data, so result is valid
- sense data is filled with untouched ATA registers.
Signed-off-by: Gwendal Grignou <gwendal@google.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marc Kleine-Budde [Fri, 4 Oct 2013 08:52:36 +0000 (10:52 +0200)]
can: flexcan: flexcan_chip_start: fix regression, mark one MB for TX and abort pending TX
commit
d5a7b406c529e4595ce03dc8f6dcf7fa36f106fa upstream.
In patch
0d1862e can: flexcan: fix flexcan_chip_start() on imx6
the loop in flexcan_chip_start() that iterates over all mailboxes after the
soft reset of the CAN core was removed. This loop put all mailboxes (even the
ones marked as reserved 1...7) into EMPTY/INACTIVE mode. On mailboxes 8...63,
this aborts any pending TX messages.
After a cold boot there is random garbage in the mailboxes, which leads to
spontaneous transmit of CAN frames during first activation. Further if the
interface was disabled with a pending message (usually due to an error
condition on the CAN bus), this message is retransmitted after enabling the
interface again.
This patch fixes the regression by:
1) Limiting the maximum number of used mailboxes to 8, 0...7 are used by the RX
FIFO, 8 is used by TX.
2) Marking the TX mailbox as EMPTY/INACTIVE, so that any pending TX of that
mailbox is aborted.
Cc: Lothar Waßmann <LW@KARO-electronics.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dave Kleikamp [Sat, 7 Sep 2013 02:49:56 +0000 (21:49 -0500)]
jfs: fix error path in ialloc
commit
8660998608cfa1077e560034db81885af8e1e885 upstream.
If insert_inode_locked() fails, we shouldn't be calling
unlock_new_inode().
Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
Tested-by: Michael L. Semon <mlsemon35@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mark Cave-Ayland [Tue, 8 Oct 2013 15:18:20 +0000 (10:18 -0500)]
rtlwifi: rtl8192cu: Fix error in pointer arithmetic
commit
9473ca6e920a3b9ca902753ce52833657f9221cc upstream.
An error in calculating the offset in an skb causes the driver to read
essential device info from the wrong locations. The main effect is that
automatic gain calculations are nonsense.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Felix Fietkau [Sun, 29 Sep 2013 19:39:34 +0000 (21:39 +0200)]
mac80211: update sta->last_rx on acked tx frames
commit
0c5b93290b2f3c7a376567c03ae8d385b0e99851 upstream.
When clients are idle for too long, hostapd sends nullfunc frames for
probing. When those are acked by the client, the idle time needs to be
updated.
To make this work (and to avoid unnecessary probing), update sta->last_rx
whenever an ACK was received for a tx packet. Only do this if the flag
IEEE80211_HW_REPORTS_TX_ACK_STATUS is set.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Emmanuel Grumbach [Mon, 16 Sep 2013 08:12:07 +0000 (11:12 +0300)]
mac80211: correctly close cancelled scans
commit
a754055a1296fcbe6f32de3a5eaca6efb2fd1865 upstream.
__ieee80211_scan_completed is called from a worker. This
means that the following flow is possible.
* driver calls ieee80211_scan_completed
* mac80211 cancels the scan (that is already complete)
* __ieee80211_scan_completed runs
When scan_work will finally run, it will see that the scan
hasn't been aborted and might even trigger another scan on
another band. This leads to a situation where cfg80211's
scan is not done and no further scan can be issued.
Fix this by setting a new flag when a HW scan is being
cancelled so that no other scan will be triggered.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Алексей Крамаренко [Fri, 1 Nov 2013 13:26:38 +0000 (17:26 +0400)]
USB: serial: ftdi_sio: add id for Z3X Box device
commit
e1466ad5b1aeda303f9282463d55798d2eda218c upstream.
Custom VID/PID for Z3X Box device, popular tool for cellphone flashing.
Signed-off-by: Alexey E. Kramarenko <alexeyk13@yandex.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oliver Neukum [Wed, 16 Oct 2013 10:26:07 +0000 (12:26 +0200)]
USB: quirks: add touchscreen that is dazzeled by remote wakeup
commit
614ced91fc6fbb5a1cdd12f0f1b6c9197d9f1350 upstream.
The device descriptors are messed up after remote wakeup
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oliver Neukum [Mon, 14 Oct 2013 14:22:40 +0000 (16:22 +0200)]
USB: quirks.c: add one device that cannot deal with suspension
commit
4294bca7b423d1a5aa24307e3d112a04075e3763 upstream.
The device is not responsive when resumed, unless it is reset.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fangxiaozhi (Franko) [Fri, 11 Oct 2013 03:48:21 +0000 (03:48 +0000)]
USB: support new huawei devices in option.c
commit
d544db293a44a2a3b09feab7dbd59668b692de71 upstream.
Add new supporting declarations to option.c, to support Huawei new
devices with new bInterfaceSubClass value.
Signed-off-by: fangxiaozhi <huananhu@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Mon, 4 Nov 2013 12:23:59 +0000 (04:23 -0800)]
Linux 3.4.68
Enrico Mioso [Tue, 15 Oct 2013 13:06:47 +0000 (15:06 +0200)]
usb: serial: option: blacklist Olivetti Olicard200
commit
fd8573f5828873343903215f203f14dc82de397c upstream.
Interface 6 of this device speaks QMI as per tests done by us.
Credits go to Antonella for providing the hardware.
Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
Signed-off-by: Antonella Pellizzari <anto.pellizzari83@gmail.com>
Tested-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Sun, 6 Oct 2013 01:14:18 +0000 (18:14 -0700)]
USB: serial: option: add support for Inovia SEW858 device
commit
f4c19b8e165cff1a6607c21f8809441d61cab7ec upstream.
This patch adds the device id for the Inovia SEW858 device to the option driver.
Reported-by: Pavel Parkhomenko <ra85551@gmail.com>
Tested-by: Pavel Parkhomenko <ra85551@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diego Elio Pettenò [Tue, 8 Oct 2013 19:03:37 +0000 (20:03 +0100)]
USB: serial: ti_usb_3410_5052: add Abbott strip port ID to combined table as well.
commit
c9d09dc7ad106492c17c587b6eeb99fe3f43e522 upstream.
Without this change, the USB cable for Freestyle Option and compatible
glucometers will not be detected by the driver.
Signed-off-by: Diego Elio Pettenò <flameeyes@flameeyes.eu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johannes Berg [Fri, 11 Oct 2013 12:47:05 +0000 (14:47 +0200)]
wireless: radiotap: fix parsing buffer overrun
commit
f5563318ff1bde15b10e736e97ffce13be08bc1a upstream.
When parsing an invalid radiotap header, the parser can overrun
the buffer that is passed in because it doesn't correctly check
1) the minimum radiotap header size
2) the space for extended bitmaps
The first issue doesn't affect any in-kernel user as they all
check the minimum size before calling the radiotap function.
The second issue could potentially affect the kernel if an skb
is passed in that consists only of the radiotap header with a
lot of extended bitmaps that extend past the SKB. In that case
a read-only buffer overrun by at most 4 bytes is possible.
Fix this by adding the appropriate checks to the parser.
Reported-by: Evan Huus <eapache@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fengguang Wu [Wed, 16 Oct 2013 20:47:03 +0000 (13:47 -0700)]
writeback: fix negative bdi max pause
commit
e3b6c655b91e01a1dade056cfa358581b47a5351 upstream.
Toralf runs trinity on UML/i386. After some time it hangs and the last
message line is
BUG: soft lockup - CPU#0 stuck for 22s! [trinity-child0:1521]
It's found that pages_dirtied becomes very large. More than
1000000000
pages in this case:
period = HZ * pages_dirtied / task_ratelimit;
BUG_ON(pages_dirtied >
2000000000);
BUG_ON(pages_dirtied >
1000000000); <---------
UML debug printf shows that we got negative pause here:
ick: pause : -984
ick: pages_dirtied : 0
ick: task_ratelimit: 0
pause:
+ if (pause < 0) {
+ extern int printf(char *, ...);
+ printf("ick : pause : %li\n", pause);
+ printf("ick: pages_dirtied : %lu\n", pages_dirtied);
+ printf("ick: task_ratelimit: %lu\n", task_ratelimit);
+ BUG_ON(1);
+ }
trace_balance_dirty_pages(bdi,
Since pause is bounded by [min_pause, max_pause] where min_pause is also
bounded by max_pause. It's suspected and demonstrated that the
max_pause calculation goes wrong:
ick: pause : -717
ick: min_pause : -177
ick: max_pause : -717
ick: pages_dirtied : 14
ick: task_ratelimit: 0
The problem lies in the two "long = unsigned long" assignments in
bdi_max_pause() which might go negative if the highest bit is 1, and the
min_t(long, ...) check failed to protect it falling under 0. Fix all of
them by using "unsigned long" throughout the function.
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Reported-by: Toralf Förster <toralf.foerster@gmx.de>
Tested-by: Toralf Förster <toralf.foerster@gmx.de>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: Richard Weinberger <richard@nod.at>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mikulas Patocka [Wed, 16 Oct 2013 02:17:47 +0000 (03:17 +0100)]
dm snapshot: fix data corruption
commit
e9c6a182649f4259db704ae15a91ac820e63b0ca upstream.
This patch fixes a particular type of data corruption that has been
encountered when loading a snapshot's metadata from disk.
When we allocate a new chunk in persistent_prepare, we increment
ps->next_free and we make sure that it doesn't point to a metadata area
by further incrementing it if necessary.
When we load metadata from disk on device activation, ps->next_free is
positioned after the last used data chunk. However, if this last used
data chunk is followed by a metadata area, ps->next_free is positioned
erroneously to the metadata area. A newly-allocated chunk is placed at
the same location as the metadata area, resulting in data or metadata
corruption.
This patch changes the code so that ps->next_free skips the metadata
area when metadata are loaded in function read_exceptions.
The patch also moves a piece of code from persistent_prepare_exception
to a separate function skip_metadata to avoid code duplication.
CVE-2013-4299
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Sandeen [Thu, 26 Apr 2012 18:10:39 +0000 (13:10 -0500)]
ext3: return 32/64-bit dir name hash according to usage type
commit
d7dab39b6e16d5eea78ed3c705d2a2d0772b4f06 upstream.
This is based on commit
d1f5273e9adb40724a85272f248f210dc4ce919a
ext4: return 32/64-bit dir name hash according to usage type
by Fan Yong <yong.fan@whamcloud.com>
Traditionally ext2/3/4 has returned a 32-bit hash value from llseek()
to appease NFSv2, which can only handle a 32-bit cookie for seekdir()
and telldir(). However, this causes problems if there are 32-bit hash
collisions, since the NFSv2 server can get stuck resending the same
entries from the directory repeatedly.
Allow ext3 to return a full 64-bit hash (both major and minor) for
telldir to decrease the chance of hash collisions.
This patch does implement a new ext3_dir_llseek op, because with 64-bit
hashes, nfs will attempt to seek to a hash "offset" which is much
larger than ext3's s_maxbytes. So for dx dirs, we call
generic_file_llseek_size() with the appropriate max hash value as the
maximum seekable size. Otherwise we just pass through to
generic_file_llseek().
Patch-updated-by: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>
Patch-updated-by: Eric Sandeen <sandeen@redhat.com>
(blame us if something is not correct)
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Cc: Benjamin LaHaise <bcrl@kvack.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mariusz Ceier [Mon, 21 Oct 2013 17:45:04 +0000 (19:45 +0200)]
davinci_emac.c: Fix IFF_ALLMULTI setup
[ Upstream commit
d69e0f7ea95fef8059251325a79c004bac01f018 ]
When IFF_ALLMULTI flag is set on interface and IFF_PROMISC isn't,
emac_dev_mcast_set should only enable RX of multicasts and reset
MACHASH registers.
It does this, but afterwards it either sets up multicast MACs
filtering or disables RX of multicasts and resets MACHASH registers
again, rendering IFF_ALLMULTI flag useless.
This patch fixes emac_dev_mcast_set, so that multicast MACs filtering and
disabling of RX of multicasts are skipped when IFF_ALLMULTI flag is set.
Tested with kernel 2.6.37.
Signed-off-by: Mariusz Ceier <mceier+kernel@gmail.com>
Acked-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hannes Frederic Sowa [Mon, 21 Oct 2013 22:07:47 +0000 (00:07 +0200)]
inet: fix possible memory corruption with UDP_CORK and UFO
[ This is a simplified -stable version of a set of upstream commits. ]
This is a replacement patch only for stable which does fix the problems
handled by the following two commits in -net:
"ip_output: do skb ufo init for peeked non ufo skb as well" (
e93b7d748be887cd7639b113ba7d7ef792a7efb9)
"ip6_output: do skb ufo init for peeked non ufo skb as well" (
c547dbf55d5f8cf615ccc0e7265e98db27d3fb8b)
Three frames are written on a corked udp socket for which the output
netdevice has UFO enabled. If the first and third frame are smaller than
the mtu and the second one is bigger, we enqueue the second frame with
skb_append_datato_frags without initializing the gso fields. This leads
to the third frame appended regulary and thus constructing an invalid skb.
This fixes the problem by always using skb_append_datato_frags as soon
as the first frag got enqueued to the skb without marking the packet
as SKB_GSO_UDP.
The problem with only two frames for ipv6 was fixed by "ipv6: udp
packets following an UFO enqueued packet need also be handled by UFO"
(
2811ebac2521ceac84f2bdae402455baa6a7fb47).
Cc: Jiri Pirko <jiri@resnulli.us>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David Miller <davem@davemloft.net>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Seif Mazareeb [Fri, 18 Oct 2013 03:33:21 +0000 (20:33 -0700)]
net: fix cipso packet validation when !NETLABEL
[ Upstream commit
f2e5ddcc0d12f9c4c7b254358ad245c9dddce13b ]
When CONFIG_NETLABEL is disabled, the cipso_v4_validate() function could loop
forever in the main loop if opt[opt_iter +1] == 0, this will causing a kernel
crash in an SMP system, since the CPU executing this function will
stall /not respond to IPIs.
This problem can be reproduced by running the IP Stack Integrity Checker
(http://isic.sourceforge.net) using the following command on a Linux machine
connected to DUT:
"icmpsic -s rand -d <DUT IP address> -r 123456"
wait (1-2 min)
Signed-off-by: Seif Mazareeb <seif@marvell.com>
Acked-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Borkmann [Thu, 17 Oct 2013 20:51:31 +0000 (22:51 +0200)]
net: unix: inherit SOCK_PASS{CRED, SEC} flags from socket to fix race
[ Upstream commit
90c6bd34f884cd9cee21f1d152baf6c18bcac949 ]
In the case of credentials passing in unix stream sockets (dgram
sockets seem not affected), we get a rather sparse race after
commit 16e5726 ("af_unix: dont send SCM_CREDENTIALS by default").
We have a stream server on receiver side that requests credential
passing from senders (e.g. nc -U). Since we need to set SO_PASSCRED
on each spawned/accepted socket on server side to 1 first (as it's
not inherited), it can happen that in the time between accept() and
setsockopt() we get interrupted, the sender is being scheduled and
continues with passing data to our receiver. At that time SO_PASSCRED
is neither set on sender nor receiver side, hence in cmsg's
SCM_CREDENTIALS we get eventually pid:0, uid:65534, gid:65534
(== overflow{u,g}id) instead of what we actually would like to see.
On the sender side, here nc -U, the tests in maybe_add_creds()
invoked through unix_stream_sendmsg() would fail, as at that exact
time, as mentioned, the sender has neither SO_PASSCRED on his side
nor sees it on the server side, and we have a valid 'other' socket
in place. Thus, sender believes it would just look like a normal
connection, not needing/requesting SO_PASSCRED at that time.
As reverting 16e5726 would not be an option due to the significant
performance regression reported when having creds always passed,
one way/trade-off to prevent that would be to set SO_PASSCRED on
the listener socket and allow inheriting these flags to the spawned
socket on server side in accept(). It seems also logical to do so
if we'd tell the listener socket to pass those flags onwards, and
would fix the race.
Before, strace:
recvmsg(4, {msg_name(0)=NULL, msg_iov(1)=[{"blub\n", 4096}],
msg_controllen=32, {cmsg_len=28, cmsg_level=SOL_SOCKET,
cmsg_type=SCM_CREDENTIALS{pid=0, uid=65534, gid=65534}},
msg_flags=0}, 0) = 5
After, strace:
recvmsg(4, {msg_name(0)=NULL, msg_iov(1)=[{"blub\n", 4096}],
msg_controllen=32, {cmsg_len=28, cmsg_level=SOL_SOCKET,
cmsg_type=SCM_CREDENTIALS{pid=11580, uid=1000, gid=1000}},
msg_flags=0}, 0) = 5
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Salva Peiró [Wed, 16 Oct 2013 10:46:50 +0000 (12:46 +0200)]
wanxl: fix info leak in ioctl
[ Upstream commit
2b13d06c9584b4eb773f1e80bbaedab9a1c344e1 ]
The wanxl_ioctl() code fails to initialize the two padding bytes of
struct sync_serial_settings after the ->loopback member. Add an explicit
memset(0) before filling the structure to avoid the info leak.
Signed-off-by: Salva Peiró <speiro@ai2.upv.es>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vlad Yasevich [Wed, 16 Oct 2013 02:01:31 +0000 (22:01 -0400)]
sctp: Perform software checksum if packet has to be fragmented.
[ Upstream commit
d2dbbba77e95dff4b4f901fee236fef6d9552072 ]
IP/IPv6 fragmentation knows how to compute only TCP/UDP checksum.
This causes problems if SCTP packets has to be fragmented and
ipsummed has been set to PARTIAL due to checksum offload support.
This condition can happen when retransmitting after MTU discover,
or when INIT or other control chunks are larger then MTU.
Check for the rare fragmentation condition in SCTP and use software
checksum calculation in this case.
CC: Fan Du <fan.du@windriver.com>
Signed-off-by: Vlad Yasevich <vyasevich@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fan Du [Wed, 16 Oct 2013 02:01:30 +0000 (22:01 -0400)]
sctp: Use software crc32 checksum when xfrm transform will happen.
[ Upstream commit
27127a82561a2a3ed955ce207048e1b066a80a2a ]
igb/ixgbe have hardware sctp checksum support, when this feature is enabled
and also IPsec is armed to protect sctp traffic, ugly things happened as
xfrm_output checks CHECKSUM_PARTIAL to do checksum operation(sum every thing
up and pack the 16bits result in the checksum field). The result is fail
establishment of sctp communication.
Signed-off-by: Fan Du <fan.du@windriver.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Vlad Yasevich <vyasevich@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vlad Yasevich [Wed, 16 Oct 2013 02:01:29 +0000 (22:01 -0400)]
net: dst: provide accessor function to dst->xfrm
[ Upstream commit
e87b3998d795123b4139bc3f25490dd236f68212 ]
dst->xfrm is conditionally defined. Provide accessor funtion that
is always available.
Signed-off-by: Vlad Yasevich <vyasevich@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Sat, 12 Oct 2013 21:08:34 +0000 (14:08 -0700)]
bnx2x: record rx queue for LRO packets
[ Upstream commit
60e66fee56b2256dcb1dc2ea1b2ddcb6e273857d ]
RPS support is kind of broken on bnx2x, because only non LRO packets
get proper rx queue information. This triggers reorders, as it seems
bnx2x like to generate a non LRO packet for segment including TCP PUSH
flag : (this might be pure coincidence, but all the reorders I've
seen involve segments with a PUSH)
11:13:34.335847 IP A > B: . 415808:447136(31328) ack 1 win 457 <nop,nop,timestamp 3789336 3985797>
11:13:34.335992 IP A > B: . 447136:448560(1424) ack 1 win 457 <nop,nop,timestamp 3789336 3985797>
11:13:34.336391 IP A > B: . 448560:479888(31328) ack 1 win 457 <nop,nop,timestamp 3789337 3985797>
11:13:34.336425 IP A > B: P 511216:512640(1424) ack 1 win 457 <nop,nop,timestamp 3789337 3985798>
11:13:34.336423 IP A > B: . 479888:511216(31328) ack 1 win 457 <nop,nop,timestamp 3789337 3985798>
11:13:34.336924 IP A > B: . 512640:543968(31328) ack 1 win 457 <nop,nop,timestamp 3789337 3985798>
11:13:34.336963 IP A > B: . 543968:575296(31328) ack 1 win 457 <nop,nop,timestamp 3789337 3985798>
We must call skb_record_rx_queue() to properly give to RPS (and more
generally for TX queue selection on forward path) the receive queue
information.
Similar fix is needed for skb_mark_napi_id(), but will be handled
in a separate patch to ease stable backports.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Willem de Bruijn <willemb@google.com>
Cc: Eilon Greenstein <eilong@broadcom.com>
Acked-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mathias Krause [Mon, 30 Sep 2013 20:03:07 +0000 (22:03 +0200)]
connector: use nlmsg_len() to check message length
[ Upstream commit
162b2bedc084d2d908a04c93383ba02348b648b0 ]
The current code tests the length of the whole netlink message to be
at least as long to fit a cn_msg. This is wrong as nlmsg_len includes
the length of the netlink message header. Use nlmsg_len() instead to
fix this "off-by-NLMSG_HDRLEN" size check.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mathias Krause [Mon, 30 Sep 2013 20:05:40 +0000 (22:05 +0200)]
unix_diag: fix info leak
[ Upstream commit
6865d1e834be84ddd5808d93d5035b492346c64a ]
When filling the netlink message we miss to wipe the pad field,
therefore leak one byte of heap memory to userland. Fix this by
setting pad to 0.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Salva Peiró [Fri, 11 Oct 2013 09:50:03 +0000 (12:50 +0300)]
farsync: fix info leak in ioctl
[ Upstream commit
96b340406724d87e4621284ebac5e059d67b2194 ]
The fst_get_iface() code fails to initialize the two padding bytes of
struct sync_serial_settings after the ->loopback member. Add an explicit
memset(0) before filling the structure to avoid the info leak.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Thu, 10 Oct 2013 13:30:09 +0000 (06:30 -0700)]
l2tp: must disable bh before calling l2tp_xmit_skb()
[ Upstream commit
455cc32bf128e114455d11ad919321ab89a2c312 ]
François Cachereul made a very nice bug report and suspected
the bh_lock_sock() / bh_unlok_sock() pair used in l2tp_xmit_skb() from
process context was not good.
This problem was added by commit
6af88da14ee284aaad6e4326da09a89191ab6165
("l2tp: Fix locking in l2tp_core.c").
l2tp_eth_dev_xmit() runs from BH context, so we must disable BH
from other l2tp_xmit_skb() users.
[ 452.060011] BUG: soft lockup - CPU#1 stuck for 23s! [accel-pppd:6662]
[ 452.061757] Modules linked in: l2tp_ppp l2tp_netlink l2tp_core pppoe pppox
ppp_generic slhc ipv6 ext3 mbcache jbd virtio_balloon xfs exportfs dm_mod
virtio_blk ata_generic virtio_net floppy ata_piix libata virtio_pci virtio_ring virtio [last unloaded: scsi_wait_scan]
[ 452.064012] CPU 1
[ 452.080015] BUG: soft lockup - CPU#2 stuck for 23s! [accel-pppd:6643]
[ 452.080015] CPU 2
[ 452.080015]
[ 452.080015] Pid: 6643, comm: accel-pppd Not tainted 3.2.46.mini #1 Bochs Bochs
[ 452.080015] RIP: 0010:[<
ffffffff81059f6c>] [<
ffffffff81059f6c>] do_raw_spin_lock+0x17/0x1f
[ 452.080015] RSP: 0018:
ffff88007125fc18 EFLAGS:
00000293
[ 452.080015] RAX:
000000000000aba9 RBX:
ffffffff811d0703 RCX:
0000000000000000
[ 452.080015] RDX:
00000000000000ab RSI:
ffff8800711f6896 RDI:
ffff8800745c8110
[ 452.080015] RBP:
ffff88007125fc18 R08:
0000000000000020 R09:
0000000000000000
[ 452.080015] R10:
0000000000000000 R11:
0000000000000280 R12:
0000000000000286
[ 452.080015] R13:
0000000000000020 R14:
0000000000000240 R15:
0000000000000000
[ 452.080015] FS:
00007fdc0cc24700(0000) GS:
ffff8800b6f00000(0000) knlGS:
0000000000000000
[ 452.080015] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 452.080015] CR2:
00007fdb054899b8 CR3:
0000000074404000 CR4:
00000000000006a0
[ 452.080015] DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
[ 452.080015] DR3:
0000000000000000 DR6:
00000000ffff0ff0 DR7:
0000000000000400
[ 452.080015] Process accel-pppd (pid: 6643, threadinfo
ffff88007125e000, task
ffff8800b27e6dd0)
[ 452.080015] Stack:
[ 452.080015]
ffff88007125fc28 ffffffff81256559 ffff88007125fc98 ffffffffa01b2bd1
[ 452.080015]
ffff88007125fc58 000000000000000c 00000000029490d0 0000009c71dbe25e
[ 452.080015]
000000000000005c 000000080000000e 0000000000000000 ffff880071170600
[ 452.080015] Call Trace:
[ 452.080015] [<
ffffffff81256559>] _raw_spin_lock+0xe/0x10
[ 452.080015] [<
ffffffffa01b2bd1>] l2tp_xmit_skb+0x189/0x4ac [l2tp_core]
[ 452.080015] [<
ffffffffa01c2d36>] pppol2tp_sendmsg+0x15e/0x19c [l2tp_ppp]
[ 452.080015] [<
ffffffff811c7872>] __sock_sendmsg_nosec+0x22/0x24
[ 452.080015] [<
ffffffff811c83bd>] sock_sendmsg+0xa1/0xb6
[ 452.080015] [<
ffffffff81254e88>] ? __schedule+0x5c1/0x616
[ 452.080015] [<
ffffffff8103c7c6>] ? __dequeue_signal+0xb7/0x10c
[ 452.080015] [<
ffffffff810bbd21>] ? fget_light+0x75/0x89
[ 452.080015] [<
ffffffff811c8444>] ? sockfd_lookup_light+0x20/0x56
[ 452.080015] [<
ffffffff811c9b34>] sys_sendto+0x10c/0x13b
[ 452.080015] [<
ffffffff8125cac2>] system_call_fastpath+0x16/0x1b
[ 452.080015] Code: 81 48 89 e5 72 0c 31 c0 48 81 ff 45 66 25 81 0f 92 c0 5d c3 55 b8 00 01 00 00 48 89 e5 f0 66 0f c1 07 0f b6 d4 38 d0 74 06 f3 90 <8a> 07 eb f6 5d c3 90 90 55 48 89 e5 9c 58 0f 1f 44 00 00 5d c3
[ 452.080015] Call Trace:
[ 452.080015] [<
ffffffff81256559>] _raw_spin_lock+0xe/0x10
[ 452.080015] [<
ffffffffa01b2bd1>] l2tp_xmit_skb+0x189/0x4ac [l2tp_core]
[ 452.080015] [<
ffffffffa01c2d36>] pppol2tp_sendmsg+0x15e/0x19c [l2tp_ppp]
[ 452.080015] [<
ffffffff811c7872>] __sock_sendmsg_nosec+0x22/0x24
[ 452.080015] [<
ffffffff811c83bd>] sock_sendmsg+0xa1/0xb6
[ 452.080015] [<
ffffffff81254e88>] ? __schedule+0x5c1/0x616
[ 452.080015] [<
ffffffff8103c7c6>] ? __dequeue_signal+0xb7/0x10c
[ 452.080015] [<
ffffffff810bbd21>] ? fget_light+0x75/0x89
[ 452.080015] [<
ffffffff811c8444>] ? sockfd_lookup_light+0x20/0x56
[ 452.080015] [<
ffffffff811c9b34>] sys_sendto+0x10c/0x13b
[ 452.080015] [<
ffffffff8125cac2>] system_call_fastpath+0x16/0x1b
[ 452.064012]
[ 452.064012] Pid: 6662, comm: accel-pppd Not tainted 3.2.46.mini #1 Bochs Bochs
[ 452.064012] RIP: 0010:[<
ffffffff81059f6e>] [<
ffffffff81059f6e>] do_raw_spin_lock+0x19/0x1f
[ 452.064012] RSP: 0018:
ffff8800b6e83ba0 EFLAGS:
00000297
[ 452.064012] RAX:
000000000000aaa9 RBX:
ffff8800b6e83b40 RCX:
0000000000000002
[ 452.064012] RDX:
00000000000000aa RSI:
000000000000000a RDI:
ffff8800745c8110
[ 452.064012] RBP:
ffff8800b6e83ba0 R08:
000000000000c802 R09:
000000000000001c
[ 452.064012] R10:
ffff880071096c4e R11:
0000000000000006 R12:
ffff8800b6e83b18
[ 452.064012] R13:
ffffffff8125d51e R14:
ffff8800b6e83ba0 R15:
ffff880072a589c0
[ 452.064012] FS:
00007fdc0b81e700(0000) GS:
ffff8800b6e80000(0000) knlGS:
0000000000000000
[ 452.064012] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 452.064012] CR2:
0000000000625208 CR3:
0000000074404000 CR4:
00000000000006a0
[ 452.064012] DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
[ 452.064012] DR3:
0000000000000000 DR6:
00000000ffff0ff0 DR7:
0000000000000400
[ 452.064012] Process accel-pppd (pid: 6662, threadinfo
ffff88007129a000, task
ffff8800744f7410)
[ 452.064012] Stack:
[ 452.064012]
ffff8800b6e83bb0 ffffffff81256559 ffff8800b6e83bc0 ffffffff8121c64a
[ 452.064012]
ffff8800b6e83bf0 ffffffff8121ec7a ffff880072a589c0 ffff880071096c62
[ 452.064012]
0000000000000011 ffffffff81430024 ffff8800b6e83c80 ffffffff8121f276
[ 452.064012] Call Trace:
[ 452.064012] <IRQ>
[ 452.064012] [<
ffffffff81256559>] _raw_spin_lock+0xe/0x10
[ 452.064012] [<
ffffffff8121c64a>] spin_lock+0x9/0xb
[ 452.064012] [<
ffffffff8121ec7a>] udp_queue_rcv_skb+0x186/0x269
[ 452.064012] [<
ffffffff8121f276>] __udp4_lib_rcv+0x297/0x4ae
[ 452.064012] [<
ffffffff8121c178>] ? raw_rcv+0xe9/0xf0
[ 452.064012] [<
ffffffff8121f4a7>] udp_rcv+0x1a/0x1c
[ 452.064012] [<
ffffffff811fe385>] ip_local_deliver_finish+0x12b/0x1a5
[ 452.064012] [<
ffffffff811fe54e>] ip_local_deliver+0x53/0x84
[ 452.064012] [<
ffffffff811fe1d0>] ip_rcv_finish+0x2bc/0x2f3
[ 452.064012] [<
ffffffff811fe78f>] ip_rcv+0x210/0x269
[ 452.064012] [<
ffffffff8101911e>] ? kvm_clock_get_cycles+0x9/0xb
[ 452.064012] [<
ffffffff811d88cd>] __netif_receive_skb+0x3a5/0x3f7
[ 452.064012] [<
ffffffff811d8eba>] netif_receive_skb+0x57/0x5e
[ 452.064012] [<
ffffffff811cf30f>] ? __netdev_alloc_skb+0x1f/0x3b
[ 452.064012] [<
ffffffffa0049126>] virtnet_poll+0x4ba/0x5a4 [virtio_net]
[ 452.064012] [<
ffffffff811d9417>] net_rx_action+0x73/0x184
[ 452.064012] [<
ffffffffa01b2cc2>] ? l2tp_xmit_skb+0x27a/0x4ac [l2tp_core]
[ 452.064012] [<
ffffffff810343b9>] __do_softirq+0xc3/0x1a8
[ 452.064012] [<
ffffffff81013b56>] ? ack_APIC_irq+0x10/0x12
[ 452.064012] [<
ffffffff81256559>] ? _raw_spin_lock+0xe/0x10
[ 452.064012] [<
ffffffff8125e0ac>] call_softirq+0x1c/0x26
[ 452.064012] [<
ffffffff81003587>] do_softirq+0x45/0x82
[ 452.064012] [<
ffffffff81034667>] irq_exit+0x42/0x9c
[ 452.064012] [<
ffffffff8125e146>] do_IRQ+0x8e/0xa5
[ 452.064012] [<
ffffffff8125676e>] common_interrupt+0x6e/0x6e
[ 452.064012] <EOI>
[ 452.064012] [<
ffffffff810b82a1>] ? kfree+0x8a/0xa3
[ 452.064012] [<
ffffffffa01b2cc2>] ? l2tp_xmit_skb+0x27a/0x4ac [l2tp_core]
[ 452.064012] [<
ffffffffa01b2c25>] ? l2tp_xmit_skb+0x1dd/0x4ac [l2tp_core]
[ 452.064012] [<
ffffffffa01c2d36>] pppol2tp_sendmsg+0x15e/0x19c [l2tp_ppp]
[ 452.064012] [<
ffffffff811c7872>] __sock_sendmsg_nosec+0x22/0x24
[ 452.064012] [<
ffffffff811c83bd>] sock_sendmsg+0xa1/0xb6
[ 452.064012] [<
ffffffff81254e88>] ? __schedule+0x5c1/0x616
[ 452.064012] [<
ffffffff8103c7c6>] ? __dequeue_signal+0xb7/0x10c
[ 452.064012] [<
ffffffff810bbd21>] ? fget_light+0x75/0x89
[ 452.064012] [<
ffffffff811c8444>] ? sockfd_lookup_light+0x20/0x56
[ 452.064012] [<
ffffffff811c9b34>] sys_sendto+0x10c/0x13b
[ 452.064012] [<
ffffffff8125cac2>] system_call_fastpath+0x16/0x1b
[ 452.064012] Code: 89 e5 72 0c 31 c0 48 81 ff 45 66 25 81 0f 92 c0 5d c3 55 b8 00 01 00 00 48 89 e5 f0 66 0f c1 07 0f b6 d4 38 d0 74 06 f3 90 8a 07 <eb> f6 5d c3 90 90 55 48 89 e5 9c 58 0f 1f 44 00 00 5d c3 55 48
[ 452.064012] Call Trace:
[ 452.064012] <IRQ> [<
ffffffff81256559>] _raw_spin_lock+0xe/0x10
[ 452.064012] [<
ffffffff8121c64a>] spin_lock+0x9/0xb
[ 452.064012] [<
ffffffff8121ec7a>] udp_queue_rcv_skb+0x186/0x269
[ 452.064012] [<
ffffffff8121f276>] __udp4_lib_rcv+0x297/0x4ae
[ 452.064012] [<
ffffffff8121c178>] ? raw_rcv+0xe9/0xf0
[ 452.064012] [<
ffffffff8121f4a7>] udp_rcv+0x1a/0x1c
[ 452.064012] [<
ffffffff811fe385>] ip_local_deliver_finish+0x12b/0x1a5
[ 452.064012] [<
ffffffff811fe54e>] ip_local_deliver+0x53/0x84
[ 452.064012] [<
ffffffff811fe1d0>] ip_rcv_finish+0x2bc/0x2f3
[ 452.064012] [<
ffffffff811fe78f>] ip_rcv+0x210/0x269
[ 452.064012] [<
ffffffff8101911e>] ? kvm_clock_get_cycles+0x9/0xb
[ 452.064012] [<
ffffffff811d88cd>] __netif_receive_skb+0x3a5/0x3f7
[ 452.064012] [<
ffffffff811d8eba>] netif_receive_skb+0x57/0x5e
[ 452.064012] [<
ffffffff811cf30f>] ? __netdev_alloc_skb+0x1f/0x3b
[ 452.064012] [<
ffffffffa0049126>] virtnet_poll+0x4ba/0x5a4 [virtio_net]
[ 452.064012] [<
ffffffff811d9417>] net_rx_action+0x73/0x184
[ 452.064012] [<
ffffffffa01b2cc2>] ? l2tp_xmit_skb+0x27a/0x4ac [l2tp_core]
[ 452.064012] [<
ffffffff810343b9>] __do_softirq+0xc3/0x1a8
[ 452.064012] [<
ffffffff81013b56>] ? ack_APIC_irq+0x10/0x12
[ 452.064012] [<
ffffffff81256559>] ? _raw_spin_lock+0xe/0x10
[ 452.064012] [<
ffffffff8125e0ac>] call_softirq+0x1c/0x26
[ 452.064012] [<
ffffffff81003587>] do_softirq+0x45/0x82
[ 452.064012] [<
ffffffff81034667>] irq_exit+0x42/0x9c
[ 452.064012] [<
ffffffff8125e146>] do_IRQ+0x8e/0xa5
[ 452.064012] [<
ffffffff8125676e>] common_interrupt+0x6e/0x6e
[ 452.064012] <EOI> [<
ffffffff810b82a1>] ? kfree+0x8a/0xa3
[ 452.064012] [<
ffffffffa01b2cc2>] ? l2tp_xmit_skb+0x27a/0x4ac [l2tp_core]
[ 452.064012] [<
ffffffffa01b2c25>] ? l2tp_xmit_skb+0x1dd/0x4ac [l2tp_core]
[ 452.064012] [<
ffffffffa01c2d36>] pppol2tp_sendmsg+0x15e/0x19c [l2tp_ppp]
[ 452.064012] [<
ffffffff811c7872>] __sock_sendmsg_nosec+0x22/0x24
[ 452.064012] [<
ffffffff811c83bd>] sock_sendmsg+0xa1/0xb6
[ 452.064012] [<
ffffffff81254e88>] ? __schedule+0x5c1/0x616
[ 452.064012] [<
ffffffff8103c7c6>] ? __dequeue_signal+0xb7/0x10c
[ 452.064012] [<
ffffffff810bbd21>] ? fget_light+0x75/0x89
[ 452.064012] [<
ffffffff811c8444>] ? sockfd_lookup_light+0x20/0x56
[ 452.064012] [<
ffffffff811c9b34>] sys_sendto+0x10c/0x13b
[ 452.064012] [<
ffffffff8125cac2>] system_call_fastpath+0x16/0x1b
Reported-by: François Cachereul <f.cachereul@alphalink.fr>
Tested-by: François Cachereul <f.cachereul@alphalink.fr>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: James Chapman <jchapman@katalix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marc Kleine-Budde [Mon, 7 Oct 2013 21:19:58 +0000 (23:19 +0200)]
net: vlan: fix nlmsg size calculation in vlan_get_size()
[ Upstream commit
c33a39c575068c2ea9bffb22fd6de2df19c74b89 ]
This patch fixes the calculation of the nlmsg size, by adding the missing
nla_total_size().
Cc: Patrick McHardy <kaber@trash.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vlad Yasevich [Tue, 15 Oct 2013 18:57:45 +0000 (14:57 -0400)]
bridge: Correctly clamp MAX forward_delay when enabling STP
[ Upstream commit
4b6c7879d84ad06a2ac5b964808ed599187a188d ]
Commit
be4f154d5ef0ca147ab6bcd38857a774133f5450
bridge: Clamp forward_delay when enabling STP
had a typo when attempting to clamp maximum forward delay.
It is possible to set bridge_forward_delay to be higher then
permitted maximum when STP is off. When turning STP on, the
higher then allowed delay has to be clamed down to max value.
Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
CC: Herbert Xu <herbert@gondor.apana.org.au>
CC: Stephen Hemminger <shemminger@vyatta.com>
Reviewed-by: Veaceslav Falico <vfalico@redhat.com>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marcelo Ricardo Leitner [Tue, 8 Oct 2013 14:41:13 +0000 (16:41 +0200)]
ipv6: restrict neighbor entry creation to output flow
This patch is based on 3.2.y branch, the one used by reporter. Please let me
know if it should be different. Thanks.
The patch which introduced the regression was applied on stables:
3.0.64 3.4.31 3.7.8 3.2.39
The patch which introduced the regression was for stable trees only.
---8<---
Commit
0d6a77079c475033cb622c07c5a880b392ef664e "ipv6: do not create
neighbor entries for local delivery" introduced a regression on
which routes to local delivery would not work anymore. Like this:
$ ip -6 route add local 2001::/64 dev lo
$ ping6 -c1 2001::9
PING 2001::9(2001::9) 56 data bytes
ping: sendmsg: Invalid argument
As this is a local delivery, that commit would not allow the creation of a
neighbor entry and thus the packet cannot be sent.
But as TPROXY scenario actually needs to avoid the neighbor entry creation only
for input flow, this patch now limits previous patch to input flow, keeping
output as before that patch.
Reported-by: Debabrata Banerjee <dbavatar@gmail.com>
Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
CC: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marc Kleine-Budde [Sat, 5 Oct 2013 19:25:17 +0000 (21:25 +0200)]
can: dev: fix nlmsg size calculation in can_get_size()
[ Upstream commit
fe119a05f8ca481623a8d02efcc984332e612528 ]
This patch fixes the calculation of the nlmsg size, by adding the missing
nla_total_size().
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jiri Benc [Fri, 4 Oct 2013 15:04:48 +0000 (17:04 +0200)]
ipv4: fix ineffective source address selection
[ Upstream commit
0a7e22609067ff524fc7bbd45c6951dd08561667 ]
When sending out multicast messages, the source address in inet->mc_addr is
ignored and rewritten by an autoselected one. This is caused by a typo in
commit
813b3b5db831 ("ipv4: Use caller's on-stack flowi as-is in output
route lookups").
Signed-off-by: Jiri Benc <jbenc@redhat.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mathias Krause [Mon, 30 Sep 2013 20:03:06 +0000 (22:03 +0200)]
proc connector: fix info leaks
[ Upstream commit
e727ca82e0e9616ab4844301e6bae60ca7327682 ]
Initialize event_data for all possible message types to prevent leaking
kernel stack contents to userland (up to 20 bytes). Also set the flags
member of the connector message to 0 to prevent leaking two more stack
bytes this way.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Wed, 2 Oct 2013 21:27:20 +0000 (00:27 +0300)]
net: heap overflow in __audit_sockaddr()
[ Upstream commit
1661bf364ae9c506bc8795fef70d1532931be1e8 ]
We need to cap ->msg_namelen or it leads to a buffer overflow when we
to the memcpy() in __audit_sockaddr(). It requires CAP_AUDIT_CONTROL to
exploit this bug.
The call tree is:
___sys_recvmsg()
move_addr_to_user()
audit_sockaddr()
__audit_sockaddr()
Reported-by: Jüri Aedla <juri.aedla@gmail.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sebastian Hesselbarth [Wed, 2 Oct 2013 10:57:21 +0000 (12:57 +0200)]
net: mv643xx_eth: fix orphaned statistics timer crash
[ Upstream commit
f564412c935111c583b787bcc18157377b208e2e ]
The periodic statistics timer gets started at port _probe() time, but
is stopped on _stop() only. In a modular environment, this can cause
the timer to access already deallocated memory, if the module is unloaded
without starting the eth device. To fix this, we add the timer right
before the port is started, instead of at _probe() time.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>