aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2013-04-08cpufreq / intel_pstate: Set timer timeout correctlyDirk Brandewie1-1/+0
The current calculation of the delay time is wrong and a cut and paste error from a previous experimental driver. This can result in the timeout being set to jiffies + 1 which setup the driver to race with itself if the APIC timer interrupt happens at just the right time. References: https://bugzilla.redhat.com/show_bug.cgi?id=920289 Reported-by: Adam Williamson <[email protected]> Reported-and-tested-by: Parag Warudkar <[email protected]> Signed-off-by: Dirk Brandewie <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2013-04-08tty: mxser: fix cycle termination condition in mxser_probe() and ↵Alexey Khoroshilov1-4/+4
mxser_module_init() There is a bug in resources deallocation code in mxser_probe() and mxser_module_init(). As soon as variable 'i' is unsigned int, cycle termination condition i >= 0 is always true. The patch fixes the issue. Signed-off-by: Alexey Khoroshilov <[email protected]> Acked-by: Jiri Slaby <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-04-08Revert "tty/8250_pnp: serial port detection regression since v3.7"Sean Young1-7/+5
This reverts commit 77e372a3d82e5e4878ce1962207edd766773cc76. Checking for disabled resources board breaks detection pnp on another board "AMI UEFI implementation (Version: 0406 Release Date: 06/06/2012)". I'm working with the reporter of the original bug to write and test a better fix. https://bugzilla.redhat.com/show_bug.cgi?id=928246 Signed-off-by: Sean Young <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-04-08Merge branch 'master' of ↵John W. Linville15-290/+390
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
2013-04-08ftrace: Do not call stub functions in control loopSteven Rostedt (Red Hat)2-2/+5
The function tracing control loop used by perf spits out a warning if the called function is not a control function. This is because the control function references a per cpu allocated data structure on struct ftrace_ops that is not allocated for other types of functions. commit 0a016409e42 "ftrace: Optimize the function tracer list loop" Had an optimization done to all function tracing loops to optimize for a single registered ops. Unfortunately, this allows for a slight race when tracing starts or ends, where the stub function might be called after the current registered ops is removed. In this case we get the following dump: root# perf stat -e ftrace:function sleep 1 [ 74.339105] WARNING: at include/linux/ftrace.h:209 ftrace_ops_control_func+0xde/0xf0() [ 74.349522] Hardware name: PRIMERGY RX200 S6 [ 74.357149] Modules linked in: sg igb iTCO_wdt ptp pps_core iTCO_vendor_support i7core_edac dca lpc_ich i2c_i801 coretemp edac_core crc32c_intel mfd_core ghash_clmulni_intel dm_multipath acpi_power_meter pcspk r microcode vhost_net tun macvtap macvlan nfsd kvm_intel kvm auth_rpcgss nfs_acl lockd sunrpc uinput xfs libcrc32c sd_mod crc_t10dif sr_mod cdrom mgag200 i2c_algo_bit drm_kms_helper ttm qla2xxx mptsas ahci drm li bahci scsi_transport_sas mptscsih libata scsi_transport_fc i2c_core mptbase scsi_tgt dm_mirror dm_region_hash dm_log dm_mod [ 74.446233] Pid: 1377, comm: perf Tainted: G W 3.9.0-rc1 #1 [ 74.453458] Call Trace: [ 74.456233] [<ffffffff81062e3f>] warn_slowpath_common+0x7f/0xc0 [ 74.462997] [<ffffffff810fbc60>] ? rcu_note_context_switch+0xa0/0xa0 [ 74.470272] [<ffffffff811041a2>] ? __unregister_ftrace_function+0xa2/0x1a0 [ 74.478117] [<ffffffff81062e9a>] warn_slowpath_null+0x1a/0x20 [ 74.484681] [<ffffffff81102ede>] ftrace_ops_control_func+0xde/0xf0 [ 74.491760] [<ffffffff8162f400>] ftrace_call+0x5/0x2f [ 74.497511] [<ffffffff8162f400>] ? ftrace_call+0x5/0x2f [ 74.503486] [<ffffffff8162f400>] ? ftrace_call+0x5/0x2f [ 74.509500] [<ffffffff810fbc65>] ? synchronize_sched+0x5/0x50 [ 74.516088] [<ffffffff816254d5>] ? _cond_resched+0x5/0x40 [ 74.522268] [<ffffffff810fbc65>] ? synchronize_sched+0x5/0x50 [ 74.528837] [<ffffffff811041a2>] ? __unregister_ftrace_function+0xa2/0x1a0 [ 74.536696] [<ffffffff816254d5>] ? _cond_resched+0x5/0x40 [ 74.542878] [<ffffffff8162402d>] ? mutex_lock+0x1d/0x50 [ 74.548869] [<ffffffff81105c67>] unregister_ftrace_function+0x27/0x50 [ 74.556243] [<ffffffff8111eadf>] perf_ftrace_event_register+0x9f/0x140 [ 74.563709] [<ffffffff816254d5>] ? _cond_resched+0x5/0x40 [ 74.569887] [<ffffffff8162402d>] ? mutex_lock+0x1d/0x50 [ 74.575898] [<ffffffff8111e94e>] perf_trace_destroy+0x2e/0x50 [ 74.582505] [<ffffffff81127ba9>] tp_perf_event_destroy+0x9/0x10 [ 74.589298] [<ffffffff811295d0>] free_event+0x70/0x1a0 [ 74.595208] [<ffffffff8112a579>] perf_event_release_kernel+0x69/0xa0 [ 74.602460] [<ffffffff816254d5>] ? _cond_resched+0x5/0x40 [ 74.608667] [<ffffffff8112a640>] put_event+0x90/0xc0 [ 74.614373] [<ffffffff8112a740>] perf_release+0x10/0x20 [ 74.620367] [<ffffffff811a3044>] __fput+0xf4/0x280 [ 74.625894] [<ffffffff811a31de>] ____fput+0xe/0x10 [ 74.631387] [<ffffffff81083697>] task_work_run+0xa7/0xe0 [ 74.637452] [<ffffffff81014981>] do_notify_resume+0x71/0xb0 [ 74.643843] [<ffffffff8162fa92>] int_signal+0x12/0x17 To fix this a new ftrace_ops flag is added that denotes the ftrace_list_end ftrace_ops stub as just that, a stub. This flag is now checked in the control loop and the function is not called if the flag is set. Thanks to Jovi for not just reporting the bug, but also pointing out where the bug was in the code. Link: http://lkml.kernel.org/r/[email protected] Link: http://lkml.kernel.org/r/[email protected] Tested-by: WANG Chao <[email protected]> Reported-by: WANG Chao <[email protected]> Reported-by: zhangwei(Jovi) <[email protected]> Signed-off-by: Steven Rostedt <[email protected]>
2013-04-08ftrace: Consistently restore trace function on sysctl enablingJan Kiszka1-6/+2
If we reenable ftrace via syctl, we currently set ftrace_trace_function based on the previous simplistic algorithm. This is inconsistent with what update_ftrace_function does. So better call that helper instead. Link: http://lkml.kernel.org/r/[email protected] Cc: [email protected] Signed-off-by: Jan Kiszka <[email protected]> Signed-off-by: Steven Rostedt <[email protected]>
2013-04-08tracing: Fix race with update_max_tr_single and changing tracersSteven Rostedt (Red Hat)1-1/+4
The commit 34600f0e9 "tracing: Fix race with max_tr and changing tracers" fixed the updating of the main buffers with the race of changing tracers, but left out the fix to the updating of just a per cpu buffer. Signed-off-by: Steven Rostedt <[email protected]>
2013-04-08net: mvneta: enable features before registering the driverwilly tarreau1-4/+5
It seems that the reason why the dev features were ignored was because they were enabled after registeration. Signed-off-by: Willy Tarreau <[email protected]> Acked-by: Thomas Petazzoni <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-04-08hyperv: Fix RNDIS send_completion code pathHaiyang Zhang2-18/+13
In some cases, the VM_PKT_COMP message can arrive later than RNDIS completion message, which will free the packet memory. This may cause panic due to access to freed memory in netvsc_send_completion(). This patch fixes this problem by removing rndis_filter_send_request_completion() from the code path. The function was a no-op. Reported-by: Long Li <[email protected]> Tested-by: Long Li <[email protected]> Signed-off-by: Haiyang Zhang <[email protected]> Reviewed-by: K. Y. Srinivasan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-04-08hyperv: Fix a kernel warning from netvsc_linkstatus_callback()Haiyang Zhang1-2/+0
The warning about local_bh_enable inside IRQ happens when disconnecting a virtual NIC. The reason for the warning is -- netif_tx_disable() is called when the NIC is disconnected. And it's called within irq context. netif_tx_disable() calls local_bh_enable() which displays warning if in irq. The fix is to remove the unnecessary netif_tx_disable & wake_queue() in the netvsc_linkstatus_callback(). Reported-by: Richard Genoud <[email protected]> Tested-by: Long Li <[email protected]> Tested-by: Richard Genoud <[email protected]> Signed-off-by: Haiyang Zhang <[email protected]> Reviewed-by: K. Y. Srinivasan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-04-08net: ipv4: fix schedule while atomic bug in check_lifetime()Jiri Pirko1-16/+42
move might_sleep operations out of the rcu_read_lock() section. Also fix iterating over ifa_dev->ifa_list Introduced by: commit 5c766d642bcaf "ipv4: introduce address lifetime" Signed-off-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-04-08net: ipv4: reset check_lifetime_work after changing lifetimeJiri Pirko1-0/+2
This will result in calling check_lifetime in nearest opportunity and that function will adjust next time to call check_lifetime correctly. Without this, check_lifetime is called in time computed by previous run, not affecting modified lifetime. Introduced by: commit 5c766d642bcaf "ipv4: introduce address lifetime" Signed-off-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-04-08Merge tag 'mxs-fixes-3.9-4' of ↵Arnd Bergmann271-1512/+3051
git://git.linaro.org/people/shawnguo/linux-2.6 into fixes From Shawn Guo <[email protected]>: The mxs fixes for 3.9, take 4: - A couple mxs boards that run I2C at 400 kHz experience some unstable issue occasionally. Slow down the clock speed to have I2C work reliably. * tag 'mxs-fixes-3.9-4' of git://git.linaro.org/people/shawnguo/linux-2.6: ARM: mxs: Slow down the I2C clock speed Signed-off-by: Arnd Bergmann <[email protected]>
2013-04-08sched/cputime: Fix accounting on multi-threaded processesStanislaw Gruszka1-1/+1
Recent commit 6fac4829 ("cputime: Use accessors to read task cputime stats") introduced a bug, where we account many times the cputime of the first thread, instead of cputimes of all the different threads. Signed-off-by: Stanislaw Gruszka <[email protected]> Acked-by: Frederic Weisbecker <[email protected]> Cc: Oleg Nesterov <[email protected]> Cc: Peter Zijlstra <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2013-04-08ftrace: Fix strncpy() use, use strlcpy() instead of strncpy()Chen Gang1-2/+2
For NUL terminated string we always need to set '\0' at the end. Signed-off-by: Chen Gang <[email protected]> Cc: [email protected] Cc: Frederic Weisbecker <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2013-04-08perf: Fix strncpy() use, use strlcpy() instead of strncpy()Chen Gang1-2/+2
For NUL terminated string we always need to set '\0' at the end. Signed-off-by: Chen Gang <[email protected]> Cc: [email protected] Cc: Frederic Weisbecker <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2013-04-08perf: Fix strncpy() use, always make sure it's NUL terminatedChen Gang1-1/+2
For NUL terminated string, always make sure that there's '\0' at the end. In our case we need a return value, so still use strncpy() and fix up the tail explicitly. (strlcpy() returns the size, not the pointer) Signed-off-by: Chen Gang <[email protected]> Cc: [email protected] <[email protected]> Cc: [email protected] <[email protected]> Cc: [email protected] <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2013-04-08sched/debug: Fix sd->*_idx limit range avoiding overflowlibin1-1/+1
Commit 201c373e8e ("sched/debug: Limit sd->*_idx range on sysctl") was an incomplete bug fix. This patch fixes sd->*_idx limit range to [0 ~ CPU_LOAD_IDX_MAX-1] avoiding array overflow caused by setting sd->*_idx to CPU_LOAD_IDX_MAX on sysctl. Signed-off-by: Libin <[email protected]> Cc: <[email protected]> Cc: <[email protected]> Cc: Peter Zijlstra <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2013-04-08sched_clock: Prevent 64bit inatomicity on 32bit systemsThomas Gleixner1-0/+26
The sched_clock_remote() implementation has the following inatomicity problem on 32bit systems when accessing the remote scd->clock, which is a 64bit value. CPU0 CPU1 sched_clock_local() sched_clock_remote(CPU0) ... remote_clock = scd[CPU0]->clock read_low32bit(scd[CPU0]->clock) cmpxchg64(scd->clock,...) read_high32bit(scd[CPU0]->clock) While the update of scd->clock is using an atomic64 mechanism, the readout on the remote cpu is not, which can cause completely bogus readouts. It is a quite rare problem, because it requires the update to hit the narrow race window between the low/high readout and the update must go across the 32bit boundary. The resulting misbehaviour is, that CPU1 will see the sched_clock on CPU1 ~4 seconds ahead of it's own and update CPU1s sched_clock value to this bogus timestamp. This stays that way due to the clamping implementation for about 4 seconds until the synchronization with CLOCK_MONOTONIC undoes the problem. The issue is hard to observe, because it might only result in a less accurate SCHED_OTHER timeslicing behaviour. To create observable damage on realtime scheduling classes, it is necessary that the bogus update of CPU1 sched_clock happens in the context of an realtime thread, which then gets charged 4 seconds of RT runtime, which results in the RT throttler mechanism to trigger and prevent scheduling of RT tasks for a little less than 4 seconds. So this is quite unlikely as well. The issue was quite hard to decode as the reproduction time is between 2 days and 3 weeks and intrusive tracing makes it less likely, but the following trace recorded with trace_clock=global, which uses sched_clock_local(), gave the final hint: <idle>-0 0d..30 400269.477150: hrtimer_cancel: hrtimer=0xf7061e80 <idle>-0 0d..30 400269.477151: hrtimer_start: hrtimer=0xf7061e80 ... irq/20-S-587 1d..32 400273.772118: sched_wakeup: comm= ... target_cpu=0 <idle>-0 0dN.30 400273.772118: hrtimer_cancel: hrtimer=0xf7061e80 What happens is that CPU0 goes idle and invokes sched_clock_idle_sleep_event() which invokes sched_clock_local() and CPU1 runs a remote wakeup for CPU0 at the same time, which invokes sched_remote_clock(). The time jump gets propagated to CPU0 via sched_remote_clock() and stays stale on both cores for ~4 seconds. There are only two other possibilities, which could cause a stale sched clock: 1) ktime_get() which reads out CLOCK_MONOTONIC returns a sporadic wrong value. 2) sched_clock() which reads the TSC returns a sporadic wrong value. #1 can be excluded because sched_clock would continue to increase for one jiffy and then go stale. #2 can be excluded because it would not make the clock jump forward. It would just result in a stale sched_clock for one jiffy. After quite some brain twisting and finding the same pattern on other traces, sched_clock_remote() remained the only place which could cause such a problem and as explained above it's indeed racy on 32bit systems. So while on 64bit systems the readout is atomic, we need to verify the remote readout on 32bit machines. We need to protect the local->clock readout in sched_clock_remote() on 32bit as well because an NMI could hit between the low and the high readout, call sched_clock_local() and modify local->clock. Thanks to Siegfried Wulsch for bearing with my debug requests and going through the tedious tasks of running a bunch of reproducer systems to generate the debug information which let me decode the issue. Reported-by: Siegfried Wulsch <[email protected]> Acked-by: Peter Zijlstra <[email protected]> Cc: Steven Rostedt <[email protected]> Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1304051544160.21884@ionos Signed-off-by: Thomas Gleixner <[email protected]> Cc: [email protected]
2013-04-08Revert "loop: cleanup partitions when detaching loop device"Jens Axboe2-20/+2
This reverts commit 8761a3dc1f07b163414e2215a2cadbb4cfe2a107. There are situations where the destruction path is called with the bdev->bd_mutex already held, which then deadlocks in loop_clr_fd(). The normal partition cleanup does a trylock() on the mutex, but it'd be nice to have a more bullet proof method in loop. So punt this more involved fix to the next merge window, and just back out this buggy fix for now. Signed-off-by: Jens Axboe <[email protected]>
2013-04-08powerpc: pSeries_lpar_hpte_remove fails from Adjunct partition being ↵Michael Wolf1-1/+7
performed before the ANDCOND test Some versions of pHyp will perform the adjunct partition test before the ANDCOND test. The result of this is that H_RESOURCE can be returned and cause the BUG_ON condition to occur. The HPTE is not removed. So add a check for H_RESOURCE, it is ok if this HPTE is not removed as pSeries_lpar_hpte_remove is looking for an HPTE to remove and not a specific HPTE to remove. So it is ok to just move on to the next slot and try again. Cc: [email protected] Signed-off-by: Michael Wolf <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]>
2013-04-07Linux 3.9-rc6Linus Torvalds1-1/+1
2013-04-07bnx2x: Fix KR2 rapid link flapYaniv Rosner1-7/+11
Check KR2 recovery time at the beginning of the work-around function. Signed-off-by: Yaniv Rosner <[email protected]> Signed-off-by: Eilon Greenstein <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-04-07sctp: remove 'sridhar' from maintainers listSridhar Samudrala1-1/+0
Update SCTP maintainers list. Signed-off-by: Sridhar Samudrala <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-04-07Merge branch 'infoleaks'David S. Miller16-3/+32
Mathias Krause says: ==================== a few more info leak fixes in the recvmsg path. The error pattern here is the protocol specific recvmsg function is missing the msg_namelen assignment -- either completely or in early exit paths that do not result in errors in __sys_recvmsg()/sys_recvfrom() and, in turn, make them call move_addr_to_user(), leaking the then still uninitialized sockaddr_storage stack variable to userland. My audit was initiated by a rather coarse fix of the leak that can be found in the grsecurity patch, putting a penalty on protocols complying to the rules of recvmsg. So credits for finding the leak in the recvmsg path in __sys_recvmsg() should go to Brad! The buggy protocols/subsystems are rather obscure anyway. As a missing assignment of msg_namelen coupled with a missing filling of msg_name would only result in garbage -- the leak -- in case userland would care about that information, i.e. would provide a msg_name pointer. But obviously current userland does not. While auditing the code for the above pattern I found a few more 'uninitialized members' kind of leaks related to the msg_name filling. Those are fixed in this series, too. I have to admit, I failed to test all of the patches due to missing hardware, e.g. iucv depends on S390 -- hardware I've no access to :/ ==================== Signed-off-by: David S. Miller <[email protected]>
2013-04-07VSOCK: Fix missing msg_namelen update in vsock_stream_recvmsg()Mathias Krause1-0/+2
The code misses to update the msg_namelen member to 0 and therefore makes net/socket.c leak the local, uninitialized sockaddr_storage variable to userland -- 128 bytes of kernel stack memory. Cc: Andy King <[email protected]> Cc: Dmitry Torokhov <[email protected]> Cc: George Zhang <[email protected]> Signed-off-by: Mathias Krause <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-04-07VSOCK: vmci - fix possible info leak in vmci_transport_dgram_dequeue()Mathias Krause1-1/+2
In case we received no data on the call to skb_recv_datagram(), i.e. skb->data is NULL, vmci_transport_dgram_dequeue() will return with 0 without updating msg_namelen leading to net/socket.c leaking the local, uninitialized sockaddr_storage variable to userland -- 128 bytes of kernel stack memory. Fix this by moving the already existing msg_namelen assignment a few lines above. Cc: Andy King <[email protected]> Cc: Dmitry Torokhov <[email protected]> Cc: George Zhang <[email protected]> Signed-off-by: Mathias Krause <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-04-07tipc: fix info leaks via msg_name in recv_msg/recv_streamMathias Krause1-0/+7
The code in set_orig_addr() does not initialize all of the members of struct sockaddr_tipc when filling the sockaddr info -- namely the union is only partly filled. This will make recv_msg() and recv_stream() -- the only users of this function -- leak kernel stack memory as the msg_name member is a local variable in net/socket.c. Additionally to that both recv_msg() and recv_stream() fail to update the msg_namelen member to 0 while otherwise returning with 0, i.e. "success". This is the case for, e.g., non-blocking sockets. This will lead to a 128 byte kernel stack leak in net/socket.c. Fix the first issue by initializing the memory of the union with memset(0). Fix the second one by setting msg_namelen to 0 early as it will be updated later if we're going to fill the msg_name member. Cc: Jon Maloy <[email protected]> Cc: Allan Stephens <[email protected]> Signed-off-by: Mathias Krause <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-04-07rose: fix info leak via msg_name in rose_recvmsg()Mathias Krause1-0/+1
The code in rose_recvmsg() does not initialize all of the members of struct sockaddr_rose/full_sockaddr_rose when filling the sockaddr info. Nor does it initialize the padding bytes of the structure inserted by the compiler for alignment. This will lead to leaking uninitialized kernel stack bytes in net/socket.c. Fix the issue by initializing the memory used for sockaddr info with memset(0). Cc: Ralf Baechle <[email protected]> Signed-off-by: Mathias Krause <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-04-07NFC: llcp: fix info leaks via msg_name in llcp_sock_recvmsg()Mathias Krause1-0/+3
The code in llcp_sock_recvmsg() does not initialize all the members of struct sockaddr_nfc_llcp when filling the sockaddr info. Nor does it initialize the padding bytes of the structure inserted by the compiler for alignment. Also, if the socket is in state LLCP_CLOSED or is shutting down during receive the msg_namelen member is not updated to 0 while otherwise returning with 0, i.e. "success". The msg_namelen update is also missing for stream and seqpacket sockets which don't fill the sockaddr info. Both issues lead to the fact that the code will leak uninitialized kernel stack bytes in net/socket.c. Fix the first issue by initializing the memory used for sockaddr info with memset(0). Fix the second one by setting msg_namelen to 0 early. It will be updated later if we're going to fill the msg_name member. Cc: Lauro Ramos Venancio <[email protected]> Cc: Aloisio Almeida Jr <[email protected]> Cc: Samuel Ortiz <[email protected]> Signed-off-by: Mathias Krause <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-04-07netrom: fix info leak via msg_name in nr_recvmsg()Mathias Krause1-0/+1
In case msg_name is set the sockaddr info gets filled out, as requested, but the code fails to initialize the padding bytes of struct sockaddr_ax25 inserted by the compiler for alignment. Also the sax25_ndigis member does not get assigned, leaking four more bytes. Both issues lead to the fact that the code will leak uninitialized kernel stack bytes in net/socket.c. Fix both issues by initializing the memory with memset(0). Cc: Ralf Baechle <[email protected]> Signed-off-by: Mathias Krause <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-04-07llc: Fix missing msg_namelen update in llc_ui_recvmsg()Mathias Krause1-0/+2
For stream sockets the code misses to update the msg_namelen member to 0 and therefore makes net/socket.c leak the local, uninitialized sockaddr_storage variable to userland -- 128 bytes of kernel stack memory. The msg_namelen update is also missing for datagram sockets in case the socket is shutting down during receive. Fix both issues by setting msg_namelen to 0 early. It will be updated later if we're going to fill the msg_name member. Cc: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Mathias Krause <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-04-07l2tp: fix info leak in l2tp_ip6_recvmsg()Mathias Krause1-0/+1
The L2TP code for IPv6 fails to initialize the l2tp_conn_id member of struct sockaddr_l2tpip6 and therefore leaks four bytes kernel stack in l2tp_ip6_recvmsg() in case msg_name is set. Initialize l2tp_conn_id with 0 to avoid the info leak. Signed-off-by: Mathias Krause <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-04-07iucv: Fix missing msg_namelen update in iucv_sock_recvmsg()Mathias Krause1-0/+2
The current code does not fill the msg_name member in case it is set. It also does not set the msg_namelen member to 0 and therefore makes net/socket.c leak the local, uninitialized sockaddr_storage variable to userland -- 128 bytes of kernel stack memory. Fix that by simply setting msg_namelen to 0 as obviously nobody cared about iucv_sock_recvmsg() not filling the msg_name in case it was set. Cc: Ursula Braun <[email protected]> Signed-off-by: Mathias Krause <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-04-07irda: Fix missing msg_namelen update in irda_recvmsg_dgram()Mathias Krause1-0/+2
The current code does not fill the msg_name member in case it is set. It also does not set the msg_namelen member to 0 and therefore makes net/socket.c leak the local, uninitialized sockaddr_storage variable to userland -- 128 bytes of kernel stack memory. Fix that by simply setting msg_namelen to 0 as obviously nobody cared about irda_recvmsg_dgram() not filling the msg_name in case it was set. Cc: Samuel Ortiz <[email protected]> Signed-off-by: Mathias Krause <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-04-07caif: Fix missing msg_namelen update in caif_seqpkt_recvmsg()Mathias Krause1-0/+2
The current code does not fill the msg_name member in case it is set. It also does not set the msg_namelen member to 0 and therefore makes net/socket.c leak the local, uninitialized sockaddr_storage variable to userland -- 128 bytes of kernel stack memory. Fix that by simply setting msg_namelen to 0 as obviously nobody cared about caif_seqpkt_recvmsg() not filling the msg_name in case it was set. Cc: Sjur Braendeland <[email protected]> Signed-off-by: Mathias Krause <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-04-07Bluetooth: SCO - Fix missing msg_namelen update in sco_sock_recvmsg()Mathias Krause1-0/+1
If the socket is in state BT_CONNECT2 and BT_SK_DEFER_SETUP is set in the flags, sco_sock_recvmsg() returns early with 0 without updating the possibly set msg_namelen member. This, in turn, leads to a 128 byte kernel stack leak in net/socket.c. Fix this by updating msg_namelen in this case. For all other cases it will be handled in bt_sock_recvmsg(). Cc: Marcel Holtmann <[email protected]> Cc: Gustavo Padovan <[email protected]> Cc: Johan Hedberg <[email protected]> Signed-off-by: Mathias Krause <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-04-07Bluetooth: RFCOMM - Fix missing msg_namelen update in rfcomm_sock_recvmsg()Mathias Krause1-0/+1
If RFCOMM_DEFER_SETUP is set in the flags, rfcomm_sock_recvmsg() returns early with 0 without updating the possibly set msg_namelen member. This, in turn, leads to a 128 byte kernel stack leak in net/socket.c. Fix this by updating msg_namelen in this case. For all other cases it will be handled in bt_sock_stream_recvmsg(). Cc: Marcel Holtmann <[email protected]> Cc: Gustavo Padovan <[email protected]> Cc: Johan Hedberg <[email protected]> Signed-off-by: Mathias Krause <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-04-07Bluetooth: fix possible info leak in bt_sock_recvmsg()Mathias Krause1-2/+2
In case the socket is already shutting down, bt_sock_recvmsg() returns with 0 without updating msg_namelen leading to net/socket.c leaking the local, uninitialized sockaddr_storage variable to userland -- 128 bytes of kernel stack memory. Fix this by moving the msg_namelen assignment in front of the shutdown test. Cc: Marcel Holtmann <[email protected]> Cc: Gustavo Padovan <[email protected]> Cc: Johan Hedberg <[email protected]> Signed-off-by: Mathias Krause <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-04-07ax25: fix info leak via msg_name in ax25_recvmsg()Mathias Krause1-0/+1
When msg_namelen is non-zero the sockaddr info gets filled out, as requested, but the code fails to initialize the padding bytes of struct sockaddr_ax25 inserted by the compiler for alignment. Additionally the msg_namelen value is updated to sizeof(struct full_sockaddr_ax25) but is not always filled up to this size. Both issues lead to the fact that the code will leak uninitialized kernel stack bytes in net/socket.c. Fix both issues by initializing the memory with memset(0). Cc: Ralf Baechle <[email protected]> Signed-off-by: Mathias Krause <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-04-07atm: update msg_namelen in vcc_recvmsg()Mathias Krause1-0/+2
The current code does not fill the msg_name member in case it is set. It also does not set the msg_namelen member to 0 and therefore makes net/socket.c leak the local, uninitialized sockaddr_storage variable to userland -- 128 bytes of kernel stack memory. Fix that by simply setting msg_namelen to 0 as obviously nobody cared about vcc_recvmsg() not filling the msg_name in case it was set. Signed-off-by: Mathias Krause <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-04-07Merge git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds5-19/+46
Pull KVM fix from Gleb Natapov: "Bugfix for the regression introduced by commit c300aa64ddf5" * git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: Allow cross page reads and writes from cached translations.
2013-04-07Merge branch 'x86-urgent-for-linus' of ↵Linus Torvalds2-5/+4
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Peter Anvin: "Two quite small fixes: one a build problem, and the other fixes seccomp filters on x32." * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86: Fix rebuild with EFI_STUB enabled x86: remove the x32 syscall bitmask from syscall_get_nr()
2013-04-07alpha: irq: remove deprecated use of IRQF_DISABLEDWill Deacon3-9/+8
Interrupt handlers are always invoked with interrupts disabled, so remove all uses of the deprecated IRQF_DISABLED flag. Cc: Richard Henderson <[email protected]> Cc: Ivan Kokshaysky <[email protected]> Reviewed-by: Matt Turner <[email protected]> Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Michael Cree <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2013-04-07alpha: irq: run all handlers with interrupts disabledWill Deacon2-8/+8
Linux has expected that interrupt handlers are executed with local interrupts disabled for a while now, so ensure that this is the case on Alpha even for non-device interrupts such as IPIs. Without this patch, secondary boot results in the following backtrace: warning: at kernel/softirq.c:139 __local_bh_enable+0xb8/0xd0() trace: __local_bh_enable+0xb8/0xd0 irq_enter+0x74/0xa0 scheduler_ipi+0x50/0x100 handle_ipi+0x84/0x260 do_entint+0x1ac/0x2e0 irq_exit+0x60/0xa0 handle_irq+0x98/0x100 do_entint+0x2c8/0x2e0 ret_from_sys_call+0x0/0x10 load_balance+0x3e4/0x870 cpu_idle+0x24/0x80 rcu_eqs_enter_common.isra.38+0x0/0x120 cpu_idle+0x40/0x80 rest_init+0xc0/0xe0 _stext+0x1c/0x20 A similar dump occurs if you try to reboot using magic-sysrq. Cc: Richard Henderson <[email protected]> Cc: Ivan Kokshaysky <[email protected]> Cc: Matt Turner <[email protected]> Reviewed-by: Matt Turner <[email protected]> Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Michael Cree <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2013-04-07alpha: makefile: don't enforce small data model for kernel buildsWill Deacon1-1/+1
Due to all of the goodness being packed into today's kernels, the resulting image isn't as slim as it once was. In light of this, don't pass -msmall-data to gcc, which otherwise results in link failures due to impossible relocations when compiling anything but the most trivial configurations. Cc: Richard Henderson <[email protected]> Cc: Ivan Kokshaysky <[email protected]> Reviewed-by: Matt Turner <[email protected]> Tested-by: Thorsten Kranzkowski <[email protected]> Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Michael Cree <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2013-04-07alpha: Add irongate_io to PCI bus resourcesJay Estabrook1-0/+5
Fixes a NULL pointer dereference at boot on UP1500. Cc: [email protected] Reviewed-and-Tested-by: Matt Turner <[email protected]> Signed-off-by: Jay Estabrook <[email protected]> Signed-off-by: Matt Turner <[email protected]> Signed-off-by: Michael Cree <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2013-04-07ipv6/tcp: Stop processing ICMPv6 redirect messagesChristoph Paasch1-0/+1
Tetja Rediske found that if the host receives an ICMPv6 redirect message after sending a SYN+ACK, the connection will be reset. He bisected it down to 093d04d (ipv6: Change skb->data before using icmpv6_notify() to propagate redirect), but the origin of the bug comes from ec18d9a26 (ipv6: Add redirect support to all protocol icmp error handlers.). The bug simply did not trigger prior to 093d04d, because skb->data did not point to the inner IP header and thus icmpv6_notify did not call the correct err_handler. This patch adds the missing "goto out;" in tcp_v6_err. After receiving an ICMPv6 Redirect, we should not continue processing the ICMP in tcp_v6_err, as this may trigger the removal of request-socks or setting sk_err(_soft). Reported-by: Tetja Rediske <[email protected]> Signed-off-by: Christoph Paasch <[email protected]> Acked-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-04-07remoteproc: fix FW_CONFIG typoRobert Tivy1-1/+1
Fix obvious typo introduced in commit e121aefa7d9f10eee5cf26ed47129237a05d940b ("remoteproc: fix missing CONFIG_FW_LOADER configurations"). Cc: [email protected] Signed-off-by: Robert Tivy <[email protected]> [cc stable, slight subject change] Signed-off-by: Ohad Ben-Cohen <[email protected]>
2013-04-07KVM: Allow cross page reads and writes from cached translations.Andrew Honig5-19/+46
This patch adds support for kvm_gfn_to_hva_cache_init functions for reads and writes that will cross a page. If the range falls within the same memslot, then this will be a fast operation. If the range is split between two memslots, then the slower kvm_read_guest and kvm_write_guest are used. Tested: Test against kvm_clock unit tests. Signed-off-by: Andrew Honig <[email protected]> Signed-off-by: Gleb Natapov <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.