commit 71ea1738746efcffab98ff04a8a634a2e2a94400 Author: Greg Kroah-Hartman Date: Fri Nov 29 10:50:58 2013 -0800 Linux 3.4.71 commit 778409c66ec599e51e5c1901b9f3631356df5a13 Author: Mauro Carvalho Chehab Date: Tue Nov 12 15:06:49 2013 -0800 cris: media platform drivers: fix build commit 72a0c5571351f5184195754d23db3e14495b2080 upstream. On cris arch, the functions below aren't defined: drivers/media/platform/sh_veu.c: In function 'sh_veu_reg_read': drivers/media/platform/sh_veu.c:228:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration] drivers/media/platform/sh_veu.c: In function 'sh_veu_reg_write': drivers/media/platform/sh_veu.c:234:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration] drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_read': drivers/media/platform/vsp1/vsp1.h:66:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration] drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_write': drivers/media/platform/vsp1/vsp1.h:71:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration] drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_read': drivers/media/platform/vsp1/vsp1.h:66:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration] drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_write': drivers/media/platform/vsp1/vsp1.h:71:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration] drivers/media/platform/soc_camera/rcar_vin.c: In function 'rcar_vin_setup': drivers/media/platform/soc_camera/rcar_vin.c:284:3: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration] drivers/media/platform/soc_camera/rcar_vin.c: In function 'rcar_vin_request_capture_stop': drivers/media/platform/soc_camera/rcar_vin.c:353:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration] Yet, they're available, as CONFIG_GENERIC_IOMAP is defined. What happens is that asm/io.h was not including asm-generic/iomap.h. Suggested-by: Ben Hutchings Signed-off-by: Mauro Carvalho Chehab Cc: Mikael Starvik Cc: Jesper Nilsson Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b4db55f32a9b0172a24fb52143f10609708c17ff Author: Junxiao Bi Date: Thu Nov 21 14:31:56 2013 -0800 configfs: fix race between dentry put and lookup commit 76ae281f6307331aa063288edb6422ae99f435f0 upstream. A race window in configfs, it starts from one dentry is UNHASHED and end before configfs_d_iput is called. In this window, if a lookup happen, since the original dentry was UNHASHED, so a new dentry will be allocated, and then in configfs_attach_attr(), sd->s_dentry will be updated to the new dentry. Then in configfs_d_iput(), BUG_ON(sd->s_dentry != dentry) will be triggered and system panic. sys_open: sys_close: ... fput dput dentry_kill __d_drop <--- dentry unhashed here, but sd->dentry still point to this dentry. lookup_real configfs_lookup configfs_attach_attr---> update sd->s_dentry to new allocated dentry here. d_kill configfs_d_iput <--- BUG_ON(sd->s_dentry != dentry) triggered here. To fix it, change configfs_d_iput to not update sd->s_dentry if sd->s_count > 2, that means there are another dentry is using the sd beside the one that is going to be put. Use configfs_dirent_lock in configfs_attach_attr to sync with configfs_d_iput. With the following steps, you can reproduce the bug. 1. enable ocfs2, this will mount configfs at /sys/kernel/config and fill configure in it. 2. run the following script. while [ 1 ]; do cat /sys/kernel/config/cluster/$your_cluster_name/idle_timeout_ms > /dev/null; done & while [ 1 ]; do cat /sys/kernel/config/cluster/$your_cluster_name/idle_timeout_ms > /dev/null; done & Signed-off-by: Junxiao Bi Cc: Joel Becker Cc: Al Viro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f087a3e5c6d46a7ce7eeb5481612118104abebb8 Author: Stanislaw Gruszka Date: Fri Oct 18 11:36:54 2013 +0200 rt2800usb: slow down TX status polling commit 36165fd5b00bf8163f89c21bb16a3e9834555b10 upstream. Polling TX statuses too frequently has two negative effects. First is randomly peek CPU usage, causing overall system functioning delays. Second bad effect is that device is not able to fill TX statuses in H/W register on some workloads and we get lot of timeouts like below: ieee80211 phy4: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 7 in queue 2 ieee80211 phy4: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 7 in queue 2 ieee80211 phy4: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping This not only cause flood of messages in dmesg, but also bad throughput, since rate scaling algorithm can not work optimally. In the future, we should probably make polling interval be adjusted automatically, but for now just increase values, this make mentioned problems gone. Resolve: https://bugzilla.kernel.org/show_bug.cgi?id=62781 Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 53c620ea44ffb999ab52975e42ff3dce19937a86 Author: Trond Myklebust Date: Fri Nov 8 16:03:50 2013 -0500 SUNRPC: Fix a data corruption issue when retransmitting RPC calls commit a6b31d18b02ff9d7915c5898c9b5ca41a798cd73 upstream. The following scenario can cause silent data corruption when doing NFS writes. It has mainly been observed when doing database writes using O_DIRECT. 1) The RPC client uses sendpage() to do zero-copy of the page data. 2) Due to networking issues, the reply from the server is delayed, and so the RPC client times out. 3) The client issues a second sendpage of the page data as part of an RPC call retransmission. 4) The reply to the first transmission arrives from the server _before_ the client hardware has emptied the TCP socket send buffer. 5) After processing the reply, the RPC state machine rules that the call to be done, and triggers the completion callbacks. 6) The application notices the RPC call is done, and reuses the pages to store something else (e.g. a new write). 7) The client NIC drains the TCP socket send buffer. Since the page data has now changed, it reads a corrupted version of the initial RPC call, and puts it on the wire. This patch fixes the problem in the following manner: The ordering guarantees of TCP ensure that when the server sends a reply, then we know that the _first_ transmission has completed. Using zero-copy in that situation is therefore safe. If a time out occurs, we then send the retransmission using sendmsg() (i.e. no zero-copy), We then know that the socket contains a full copy of the data, and so it will retransmit a faithful reproduction even if the RPC call completes, and the application reuses the O_DIRECT buffer in the meantime. Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 6beceb767ed86175601237fb3f2d2ff9678fca86 Author: Michael Neuling Date: Wed Nov 20 16:18:54 2013 +1100 powerpc/signals: Mark VSX not saved with small contexts commit c13f20ac48328b05cd3b8c19e31ed6c132b44b42 upstream. The VSX MSR bit in the user context indicates if the context contains VSX state. Currently we set this when the process has touched VSX at any stage. Unfortunately, if the user has not provided enough space to save the VSX state, we can't save it but we currently still set the MSR VSX bit. This patch changes this to clear the MSR VSX bit when the user doesn't provide enough space. This indicates that there is no valid VSX state in the user context. This is needed to support get/set/make/swapcontext for applications that use VSX but only provide a small context. For example, getcontext in glibc provides a smaller context since the VSX registers don't need to be saved over the glibc function call. But since the program calling getcontext may have used VSX, the kernel currently says the VSX state is valid when it's not. If the returned context is then used in setcontext (ie. a small context without VSX but with MSR VSX set), the kernel will refuse the context. This situation has been reported by the glibc community. Based on patch from Carlos O'Donell. Tested-by: Haren Myneni Signed-off-by: Michael Neuling Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit b745b007adf0d7786a9b63a8e2ec91b8bbcdbb61 Author: Gavin Shan Date: Mon Nov 4 16:32:46 2013 +0800 powerpc/powernv: Add PE to its own PELTV commit 631ad691b5818291d89af9be607d2fe40be0886e upstream. We need add PE to its own PELTV. Otherwise, the errors originated from the PE might contribute to other PEs. In the result, we can't clear up the error successfully even we're checking and clearing errors during access to PCI config space. Reported-by: kalshett@in.ibm.com Signed-off-by: Gavin Shan Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 49aa69febe1dc8643e2d75ffcdf9504337fe4f7e Author: Prarit Bhargava Date: Thu Oct 17 08:00:11 2013 -0400 powerpc/vio: use strcpy in modalias_show commit 411cabf79e684171669ad29a0628c400b4431e95 upstream. Commit e82b89a6f19bae73fb064d1b3dd91fcefbb478f4 used strcat instead of strcpy which can result in an overflow of newlines on the buffer. Signed-off-by: Prarit Bhargava Cc: benh@kernel.crashing.org Cc: ben@decadent.org.uk Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 801327994060b0ae3749257d264a7bfea119b46c Author: Mike Snitzer Date: Fri Oct 18 09:44:49 2013 -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 Signed-off-by: Mike Snitzer Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 82b80fae0eb0c2d18414f7e678e04a4e7f88ecbe Author: Mikulas Patocka Date: Mon Oct 14 12:13:24 2013 -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: [] __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:[] [] __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: [] ? blkdev_get_by_dev+0x60/0x60 [] blkdev_get+0x1dd/0x370 [] ? blkdev_get_by_dev+0x60/0x60 [] ? _raw_spin_unlock+0x2c/0x50 [] ? blkdev_get_by_dev+0x60/0x60 [] blkdev_open+0x65/0x80 [] do_dentry_open.isra.18+0x23e/0x2f0 [] finish_open+0x34/0x50 [] do_last.isra.62+0x2d2/0xc50 [] path_openat.isra.63+0xb8/0x4d0 [] ? might_fault+0x4e/0xa0 [] do_filp_open+0x40/0x90 [] ? _raw_spin_unlock+0x2c/0x50 [] ? __alloc_fd+0xa5/0x1f0 [] do_sys_open+0xef/0x1d0 [] SyS_open+0x19/0x20 [] 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 [] __blkdev_get+0x28/0x450 RSP 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 Acked-by: Tejun Heo Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 5413d6c032afde960c16c735eef40f9b85fa9132 Author: Jeff Moyer Date: Tue Oct 8 14:36:41 2013 -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:[] [] 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: [] __scsi_queue_insert+0xa3/0x150 [] ? scsi_eh_ready_devs+0x5e3/0x850 [] scsi_queue_insert+0x13/0x20 [] scsi_eh_flush_done_q+0x104/0x160 [] scsi_error_handler+0x35b/0x660 [] ? scsi_error_handler+0x0/0x660 [] kthread+0x96/0xa0 [] child_rip+0xa/0x20 [] ? kthread+0x0/0xa0 [] ? 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 [] blk_requeue_request+0x94/0xa0 RSP 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 Acked-by: Hannes Reinecke Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit cf359232f6c3eaf6ddff242a2b8247e20b29c436 Author: Guenter Roeck Date: Fri Nov 15 10:40:38 2013 +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 Signed-off-by: Guenter Roeck Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit b227aa81f4a892ad31e202aba1de8449d131e670 Author: Thomas Renninger Date: Tue Nov 12 17:39:43 2013 +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 Acked-by: Borislav Petkov Link: http://lkml.kernel.org/r/1384274383-43510-1-git-send-email-trenn@suse.de Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 107bb3cc6b12d800f9949f5ecae808caae38a9f5 Author: Christoph Hellwig Date: Mon Nov 18 05:07:47 2013 -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 Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 6ee4fd261478ff5eed6b83cb5a18421c01707ad3 Author: Christoph Hellwig Date: Mon Nov 18 05:07:30 2013 -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 Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 1ac50b943ce53d5f8ce077240191fc50d0e84662 Author: Trond Myklebust Date: Tue Oct 1 14:24:58 2013 -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: [] _raw_spin_lock+0xe/0x30 Call Trace: [] _atomic_dec_and_lock+0x4d/0x70 [] nfs4_put_lock_state+0x32/0xb0 [nfsv4] [] nfs4_fl_release_lock+0x15/0x20 [nfsv4] [] _nfs4_proc_getlk.isra.40+0x146/0x170 [nfsv4] [] 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 Reported-by: Jorge Mora Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit eaea722ea81a2e9dab5a81ff00b3cf9b88cca9b5 Author: Takashi Iwai Date: Tue Nov 12 08:06:20 2013 +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 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1b443352fed11fd666c719d7b1399674c62437bf Author: Takashi Iwai Date: Mon Oct 28 11:24:23 2013 +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 Signed-off-by: Greg Kroah-Hartman commit c0d30628ff1b424f041d83fee37daea5f84eb0a2 Author: Kees Cook Date: Tue Nov 12 15:11:17 2013 -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 Signed-off-by: Kees Cook Cc: "Luck, Tony" Cc: Oleg Nesterov Cc: "Eric W. Biederman" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 7288f91dd5b55d82e1dee9f0d24e9f4730d57392 Author: Mimi Zohar Date: Thu Oct 17 07:34:02 2013 -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 Signed-off-by: Greg Kroah-Hartman commit 7eebf56b11ac00f164583a217b65fa264f62cb07 Author: Stanislaw Gruszka Date: Tue Oct 15 14:31:12 2013 +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: [] 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:[] [] 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] [] ? rt2x00usb_interrupt_txdone+0x90/0x90 [rt2x00usb] [ 2212.357174] [] rt2x00queue_for_each_entry+0xed/0x170 [rt2x00lib] [ 2212.357244] [] rt2x00usb_kick_queue+0x5c/0x60 [rt2x00usb] [ 2212.357314] [] rt2x00queue_flush_queue+0x62/0xa0 [rt2x00lib] [ 2212.357386] [] rt2x00mac_flush+0x30/0x70 [rt2x00lib] [ 2212.357470] [] ieee80211_flush_queues+0xbd/0x140 [mac80211] [ 2212.357555] [] ieee80211_set_disassoc+0x2d2/0x3d0 [mac80211] [ 2212.357645] [] ieee80211_mgd_deauth+0x1d3/0x240 [mac80211] [ 2212.357718] [] ? try_to_wake_up+0xec/0x290 [ 2212.357788] [] ieee80211_deauth+0x18/0x20 [mac80211] [ 2212.357872] [] cfg80211_mlme_deauth+0x9c/0x140 [cfg80211] [ 2212.357913] [] cfg80211_mlme_down+0x5c/0x60 [cfg80211] [ 2212.357962] [] cfg80211_disconnect+0x188/0x1a0 [cfg80211] [ 2212.358014] [] ? __cfg80211_stop_sched_scan+0x1c/0x130 [cfg80211] [ 2212.358067] [] cfg80211_leave+0xc4/0xe0 [cfg80211] [ 2212.358124] [] cfg80211_netdev_notifier_call+0x3ab/0x5e0 [cfg80211] [ 2212.358177] [] ? inetdev_event+0x38/0x510 [ 2212.358217] [] ? __wake_up+0x44/0x50 [ 2212.358254] [] notifier_call_chain+0x4c/0x70 [ 2212.358293] [] raw_notifier_call_chain+0x16/0x20 [ 2212.358361] [] call_netdevice_notifiers_info+0x35/0x60 [ 2212.358429] [] __dev_close_many+0x49/0xd0 [ 2212.358487] [] dev_close_many+0x88/0x100 [ 2212.358546] [] rollback_registered_many+0xb0/0x220 [ 2212.358612] [] unregister_netdevice_many+0x19/0x60 [ 2212.358694] [] ieee80211_remove_interfaces+0x112/0x190 [mac80211] [ 2212.358791] [] ieee80211_unregister_hw+0x4f/0x100 [mac80211] [ 2212.361994] [] rt2x00lib_remove_dev+0x161/0x1a0 [rt2x00lib] [ 2212.365240] [] rt2x00usb_disconnect+0x2e/0x70 [rt2x00usb] [ 2212.368470] [] usb_unbind_interface+0x64/0x1c0 [ 2212.371734] [] __device_release_driver+0x7f/0xf0 [ 2212.374999] [] device_release_driver+0x23/0x30 [ 2212.378131] [] bus_remove_device+0x108/0x180 [ 2212.381358] [] device_del+0x135/0x1d0 [ 2212.384454] [] usb_disable_device+0xb0/0x270 [ 2212.387451] [] usb_disconnect+0xad/0x1d0 [ 2212.390294] [] hub_thread+0x63d/0x1660 [ 2212.393034] [] ? wake_up_atomic_t+0x30/0x30 [ 2212.395728] [] ? hub_port_debounce+0x130/0x130 [ 2212.398412] [] kthread+0xc0/0xd0 [ 2212.401058] [] ? insert_kthread_work+0x40/0x40 [ 2212.403639] [] ret_from_fork+0x7c/0xb0 [ 2212.406193] [] ? 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 [] rt2x00usb_kick_tx_entry+0x12/0x160 [rt2x00usb] [ 2212.417646] RSP [ 2212.420547] CR2: 0000000000000250 [ 2212.441024] ---[ end trace 5442918f33832bce ]--- Signed-off-by: Stanislaw Gruszka Acked-by: Helmut Schaa Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit d134082b7a9bb0e09158a2cc2e551841a84ddfa7 Author: Steven Rostedt Date: Tue Nov 5 12:51:11 2013 -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 Reported-by: Vince Weaver Tested-by: Vince Weaver Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Jiri Olsa Cc: Frederic Weisbecker CVE: CVE-2013-2930 Fixes: ced39002f5ea ("ftrace, perf: Add support to use function tracepoint in perf") Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit f22ff9d05def87a049c5c8c7b86539bd4f8e3172 Author: Fan Du Date: Tue Apr 30 15:27:27 2013 -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 Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: Zhao Hongjiang Signed-off-by: Greg Kroah-Hartman commit df4011e050b4e80165a317424e6b3367dfa7697c Author: Oleg Nesterov Date: Tue Apr 30 15:28:20 2013 -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 Acked-by: Tejun Heo Acked-by: Li Zefan Signed-off-by: Oleg Nesterov Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [ zhj: adjust context ] Signed-off-by: Zhao Hongjiang Signed-off-by: Greg Kroah-Hartman commit 1a9a8c2c61437bc8ab745c96af936196f4684495 Author: Al Viro Date: Tue Mar 26 18:25:57 2013 -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 Cc: stable@vger.kernel.org Signed-off-by: Al Viro [ zhj: backport to 3.4: - Adjust context - s/&vfsmount_lock/vfsmount_lock/] Signed-off-by: Zhao Hongjiang Signed-off-by: Greg Kroah-Hartman commit acf9ebdebcb3f39a41cf5fead7c11c32372dbf6c Author: Andy Adamson Date: Wed Aug 14 11:59:13 2013 -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 Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 14384c7346f4d6480503b825a474006a654d50e2 Author: Andy Adamson Date: Tue Nov 27 10:34:19 2012 -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 Signed-off-by: Trond Myklebust [bwh: Backported to 3.2: - Adjust context - Drop change to nfs4_handle_reclaim_lease_error()] Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit fa7b5d69efb4db4ee60adcefa86bac1efd8e8b45 Author: Linus Torvalds Date: Tue Oct 29 10:21:34 2013 -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 Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d05ee9e14f71acbc101358ac0659b67794ca644f Author: David Woodhouse Date: Sat Nov 24 12:11:21 2012 +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 Acked-by: Francois Romieu Signed-off-by: David S. Miller Cc: Luis Henriques Signed-off-by: Greg Kroah-Hartman commit 06d5a745ee1257f4dbf49385bf63e2b7554cc9b7 Author: Markus Pargmann Date: Mon Oct 28 09:54:40 2013 +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 Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 4a4c6cd28ac9322f1a69e15eeb314566dfefe23d Author: Neil Horman Date: Tue Sep 17 08:33:11 2013 -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 Reported-by: Stephan Mueller CC: Stephan Mueller CC: Petr Matousek CC: Herbert Xu CC: "David S. Miller" Signed-off-by: Herbert Xu Cc: Luis Henriques Signed-off-by: Greg Kroah-Hartman commit a4f4086ae811ac85d536dadc5ef8387cb404d042 Author: Johan Hovold Date: Wed Oct 9 17:01:09 2013 +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 Signed-off-by: Greg Kroah-Hartman commit 8e5931c319674b15847999e79f90e763f32af663 Author: Bob Moore Date: Fri Sep 6 14:27:15 2013 +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 Signed-off-by: Rafael J. Wysocki Signed-off-by: Lv Zheng Signed-off-by: Greg Kroah-Hartman commit f9a3a293af3ca3cec5240f0c479f0bed84f195cc Author: Bob Moore Date: Thu Aug 8 15:29:58 2013 +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 Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 71a28e49b6566e92f157c871ce50a9613c682caa Author: Bob Moore Date: Thu Aug 8 15:29:32 2013 +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 Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit b6af75b221f4a998dbbf9297fa3ac591974e70ab Author: Bob Moore Date: Mon Dec 31 00:11:45 2012 +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 Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 3a7ed06c1e3a1ec493d97dc5a708bae17dd9e7b0 Author: Mahesh Rajashekhara Date: Thu Oct 31 14:01:02 2013 +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 Reported-by: Nico Golde Reported-by: Fabian Yamaguchi Signed-off-by: Linus Torvalds Cc: Kees Cook Signed-off-by: Greg Kroah-Hartman commit e181e37563a1ef5dcc25565c12b03f6a816b0f36 Author: Dan Carpenter Date: Wed Oct 30 20:12:51 2013 +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 Reported-by: Fabian Yamaguchi Signed-off-by: Dan Carpenter Acked-by: Dan Williams Signed-off-by: John W. Linville Cc: Kees Cook Signed-off-by: Greg Kroah-Hartman commit d92fa5be781c08695c9cb47124a5ac4746964e6d Author: Jeff Layton Date: Wed Feb 27 20:10:34 2013 -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: [] 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:[] [] 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> ffff88082d5f5760 ffff88082d6e8800 ffff88081458bbf8 ffffffffffffffea <4> ffff88082f12d780 ffff88082d6e8800 ffffffffa02a50a0 ffff88082d5f5760 <4>Call Trace: <4> [] __fput+0xf5/0x210 <4> [] ? do_open+0x0/0x20 [nfs] <4> [] fput+0x25/0x30 <4> [] __dentry_open+0x27e/0x360 <4> [] ? inotify_d_instantiate+0x2a/0x60 <4> [] lookup_instantiate_filp+0x69/0x90 <4> [] nfs_intent_set_file+0x59/0x90 [nfs] <4> [] nfs_atomic_lookup+0x1bb/0x310 [nfs] <4> [] __lookup_hash+0x102/0x160 <4> [] ? selinux_inode_permission+0x72/0xb0 <4> [] lookup_hash+0x3a/0x50 <4> [] do_filp_open+0x2eb/0xdd0 <4> [] ? __do_page_fault+0x1ec/0x480 <4> [] ? alloc_fd+0x92/0x160 <4> [] do_sys_open+0x69/0x140 <4> [] ? sys_lseek+0x66/0x80 <4> [] sys_open+0x20/0x30 <4> [] 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 [] nfs_closedir+0x15/0x30 [nfs] <4> RSP <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 Signed-off-by: Jeff Layton Signed-off-by: Trond Myklebust Cc: Rui Xiang Signed-off-by: Greg Kroah-Hartman commit a3b4c0bacef529359f30d85107b6b8af8684ccd0 Author: Linus Torvalds Date: Fri Mar 22 11:44:04 2013 -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//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 Analyzed-by: Al Viro Signed-off-by: Linus Torvalds [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 Cc: Rui Xiang Signed-off-by: Greg Kroah-Hartman