- Nov 28, 2016
-
-
Jeff Mahoney authored
This reverts commit 2f36db71009304b3f0b95afacd8eba1f9f046b87. It fixed a local root exploit but also introduced a dependency on the lower file system implementing an mmap operation just to open a file, which is a bit of a heavy hammer. The right fix is to have mmap depend on the existence of the mmap handler instead. Change-Id: I29aea438b02dda1170384cbc3629b705bd7b0273 Tracked-On: https://jira01.devtools.intel.com/browse/AW-2810 Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Cc: stable@vger.kernel.org Signed-off-by:
Tyler Hicks <tyhicks@canonical.com> Reviewed-on: https://android.intel.com/553592 Reviewed-by:
Louis, FabienX <fabienx.louis@intel.com> Tested-by:
Dubray, SimonX <simonx.dubray@intel.com> Reviewed-by:
Mahe, Erwan <erwan.mahe@intel.com> Reviewed-by:
Ledentec, AlexandreX <alexandrex.ledentec@intel.com> Reviewed-by:
Tasayco Loarte, VictorX <victorx.tasayco.loarte@intel.com> Tested-by:
Maalem, Saadi <saadi.maalem@intel.com>
-
Louis Fabien authored
The original fix used -EIO as the error return code but the function signatures had unsigned int as the return type. The updated fix uses -1 as the error return code instead of -EIO so the error return code is more clearly defined. It fixes CVE-2016-6690. Bug: 28838221 Change-Id: Ib0cc139d9785fbe0808dfd127901bfdec6cc4467 Tracked-On: https://jira01.devtools.intel.com/browse/AW-2810 Signed-off-by:
-
Louis Fabien authored
It fixes following CVE's: CVE-2016-8401 CVE-2016-8406 CVE-2016-8402 Change-Id: I2f8819e32379da3cf6b0b4b2c249d77ab259fe49 Tracked-On: https://jira01.devtools.intel.com/browse/AW-2810 Signed-off-by:
jenkins_ndg <jenkins_ndg@intel.com> Reviewed-by:
-
Louis Fabien authored
There is no validation of the len variable passed to the ping_common_sendmsg function to check if it is less than icmph_len leading to a potential overflow. The fix is designed to add additional validation to prevent the potential overflow. It fixes CVE-2016-8399. Bug: 31349935 Change-Id: I97d893a2e207bb614ca6632c147d7af81f701a8c Tracked-On: https://jira01.devtools.intel.com/browse/AW-2810 Signed-off-by:
-
Victor Tasayco Loarte authored
In the fwu_get_image_firmware_id function, there is no limiting of the index accessing fimware_id leading to a potential heap buffer overflow. The fix is designed to add additional bounds check to prevent the potential heap buffer overflow. It fixes CVE-2016-8393 Bug: 31911920 Change-Id: I23715fe1f4ef26800ad7fd2f0c7f1990e0a5513a Tracked-On: https://jira01.devtools.intel.com/browse/AW-2810 Signed-off-by:
Hu, Bingquan <bingquan.hu@intel.com> Reviewed-by:
Li, PeiqianX <peiqianx.li@intel.com> Reviewed-by:
Nassiet, GaelleX <gaellex.nassiet@intel.com> Reviewed-by:
-
Eun Taik Lee authored
There is a use-after-free problem in the ion driver. This is caused by a race condition in the ion_ioctl() function. A handle has ref count of 1 and two tasks on different cpus calls ION_IOC_FREE simultaneously. cpu 0 cpu 1 ------------------------------------------------------- ion_handle_get_by_id() (ref == 2) ion_handle_get_by_id() (ref == 3) ion_free() (ref == 2) ion_handle_put() (ref == 1) ion_free() (ref == 0 so ion_handle_destroy() is called and the handle is freed.) ion_handle_put() is called and it decreases the slub's next free pointer The problem is detected as an unaligned access in the spin lock functions since it uses load exclusive instruction. In some cases it corrupts the slub's free pointer which causes a mis-aligned access to the next free pointer.(kmalloc returns a pointer like ffffc0745b4580aa). And it causes lots of other hard-to-debug problems. This symptom is caused since the first member in the ion_handle structure is the reference count and the ion driver decrements the reference after it has been freed. To fix this problem client->lock mutex is extended to protect all the codes that uses the handle. Change-Id: I4b03f98c7e7db9eb0f12d640eaf1d641b3748f4b Tracked-On: https://jira01.devtools.intel.com/browse/AW-2810 Signed-off-by:Eun Taik Lee <eun.taik.lee@samsung.com> Reviewed-by:
Laura Abbott <labbott@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-on: https://android.intel.com/552532 Reviewed-by:
-
- Nov 18, 2016
-
-
Linus Torvalds authored
commit 19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619 upstream. This is an ancient bug that was actually attempted to be fixed once (badly) by me eleven years ago in commit 4ceb5db9 ("Fix get_user_pages() race for write access") but that was then undone due to problems on s390 by commit f33ea7f4 ("fix get_user_pages bug"). In the meantime, the s390 situation has long been fixed, and we can now fix it by checking the pte_dirty() bit properly (and do it better). The s390 dirty bit was implemented in abf09bed ("s390/mm: implement software dirty bits") which made it into v3.9. Earlier kernels will have to look at the page state itself. Also, the VM has become more scalable, and what used a purely theoretical race back then has become easier to trigger. To fix it, we introduce a new internal FOLL_COW flag to mark the "yes, we already did a COW" rather than play racy games with FOLL_WRITE that is very fundamental, and then use the pte dirty flag to validate that the FOLL_COW flag is still valid. Change-Id: I96c39846ae8e0b6a57c82ddab8eb9a3da1d067a0 Tracked-On: https://jira01.devtools.intel.com/browse/AW-2838 Reported-and-tested-by:
Phil "not Paul" Oester <kernel@linuxace.com> Acked-by:
Hugh Dickins <hughd@google.com> Reviewed-by:
Michal Hocko <mhocko@suse.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Kees Cook <keescook@chromium.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Willy Tarreau <w@1wt.eu> Cc: Nick Piggin <npiggin@gmail.com> Cc: Greg Thelen <gthelen@google.com> Cc: stable@vger.kernel.org Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> [wt: s/gup.c/memory.c; s/follow_page_pte/follow_page_mask; s/faultin_page/__get_user_page] Signed-off-by:
Willy Tarreau <w@1wt.eu> Reviewed-on: https://android.intel.com/552008 Reviewed-by:
Deverge, Jean-francoisX <jean-francoisx.deverge@intel.com> Tested-by:
-
Sophia Gong authored
This commit is to adjust display frame memory size as 390x390. Relevant mipi commands are updated in display power on and low power mode functions. Change-Id: Iea34534f26322f0ad2ea0e3e32f66698952271b2 Tracked-On: https://jira01.devtools.intel.com/browse/AW-2647 Signed-off-by:
Sophia Gong <sophia.gong@intel.com> Reviewed-on: https://android.intel.com/551839 Reviewed-by:
-
- Nov 16, 2016
-
-
MorganX Binet authored
add GOOD health status removed by a previous patch add COLD & OVERHEAT health status for NTC fault Change-Id: I796063b90aef03887be59ae4448a5671749425eb Tracked-On: https://jira01.devtools.intel.com/browse/AW-2778 Signed-off-by:
MorganX Binet <morganx.binet@intel.com> Reviewed-on: https://android.intel.com/551445 Reviewed-by:
Chaumette, HubertX <hubertx.chaumette@intel.com> Reviewed-by:
Ghaddab, RiadhX <riadhx.ghaddab@intel.com> Reviewed-by:
Jarzmik, Robert <robert.jarzmik@intel.com>
-
- Nov 09, 2016
-
-
Victor Tasayco Loarte authored
It fixes CVE-2016-6753 Bug: 30149174 Change-Id: Ife48f060e2192f1377077aef6f45aee137b299ea Tracked-On: https://jira01.devtools.intel.com/browse/AW-2339 Signed-off-by:
-
Mathias Krause authored
If /proc/<PID>/environ gets read before the envp[] array is fully set up in create_{aout,elf,elf_fdpic,flat}_tables(), we might end up trying to read more bytes than are actually written, as env_start will already be set but env_end will still be zero, making the range calculation underflow, allowing to read beyond the end of what has been written. Fix this as it is done for /proc/<PID>/cmdline by testing env_end for zero. It is, apparently, intentionally set last in create_*_tables(). This bug was found by the PaX size_overflow plugin that detected the arithmetic underflow of 'this_len = env_end - (env_start + src)' when env_end is still zero. The expected consequence is that userland trying to access /proc/<PID>/environ of a not yet fully set up process may get inconsistent data as we're in the middle of copying in the environment variables. Change-Id: Ib7372a565d4b1f7d09454c55e14624b734c64a5d Tracked-On: https://jira01.devtools.intel.com/browse/AW-2339 Fixes: https://forums.grsecurity.net/viewtopic.php?f=3&t=4363 Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=116461 Signed-off-by:Mathias Krause <minipli@googlemail.com> Cc: Emese Revfy <re.emese@gmail.com> Cc: Pax Team <pageexec@freemail.hu> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Mateusz Guzik <mguzik@redhat.com> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Cyrill Gorcunov <gorcunov@openvz.org> Cc: Jarod Wilson <jarod@redhat.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Benjamin Tissoires authored
Plugging a Logitech DJ receiver with KASAN activated raises a bunch of out-of-bound readings. The fields are allocated up to MAX_USAGE, meaning that potentially, we do not have enough fields to fit the incoming values. Add checks and silence KASAN. Change-Id: I0db71540d9db5db7f797aa227a3dbfb8b6539c0c Tracked-On: https://jira01.devtools.intel.com/browse/AW-2339 Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Reviewed-on: https://android.intel.com/546405 Reviewed-by:
-
Peter Hurley authored
Line discipline drivers may mistakenly misuse ldisc-related fields when initializing. For example, a failure to initialize tty->receive_room in the N_GIGASET_M101 line discipline was recently found and fixed [1]. Now, the N_X25 line discipline has been discovered accessing the previous line discipline's already-freed private data [2]. Harden the ldisc interface against misuse by initializing revelant tty fields before instancing the new line discipline. [1] commit fd98e941 Author: Tilman Schmidt <tilman@imap.cc> Date: Tue Jul 14 00:37:13 2015 +0200 isdn/gigaset: reset tty->receive_room when attaching ser_gigaset [2] Report from Sasha Levin <sasha.levin@oracle.com> [ 634.336761] ================================================================== [ 634.338226] BUG: KASAN: use-after-free in x25_asy_open_tty+0x13d/0x490 at addr ffff8800a743efd0 [ 634.339558] Read of size 4 by task syzkaller_execu/8981 [ 634.340359] ============================================================================= [ 634.341598] BUG kmalloc-512 (Not tainted): kasan: bad access detected ... [ 634.405018] Call Trace: [ 634.405277] dump_stack (lib/dump_stack.c:52) [ 634.405775] print_trailer (mm/slub.c:655) [ 634.406361] object_err (mm/slub.c:662) [ 634.406824] kasan_report_error (mm/kasan/report.c:138 mm/kasan/report.c:236) [ 634.409581] __asan_report_load4_noabort (mm/kasan/report.c:279) [ 634.411355] x25_asy_open_tty (drivers/net/wan/x25_asy.c:559 (discriminator 1)) [ 634.413997] tty_ldisc_open.isra.2 (drivers/tty/tty_ldisc.c:447) [ 634.414549] tty_set_ldisc (drivers/tty/tty_ldisc.c:567) [ 634.415057] tty_ioctl (drivers/tty/tty_io.c:2646 drivers/tty/tty_io.c:2879) [ 634.423524] do_vfs_ioctl (fs/ioctl.c:43 fs/ioctl.c:607) [ 634.427491] SyS_ioctl (fs/ioctl.c:622 fs/ioctl.c:613) [ 634.427945] entry_SYSCALL_64_fastpath (arch/x86/entry/entry_64.S:188) Change-Id: I4a6357f3900762dea5542b2f38946a3db0d754d0 Tracked-On: https://jira01.devtools.intel.com/browse/AW-2339 Cc: Tilman Schmidt <tilman@imap.cc> Cc: Sasha Levin <sasha.levin@oracle.com> Signed-off-by:Peter Hurley <peter@hurleysoftware.com> Signed-off-by:
-
Peter Zijlstra authored
There's a race on CPU unplug where we free the swevent hash array while it can still have events on. This will result in a use-after-free which is BAD. Simply do not free the hash array on unplug. This leaves the thing around and no use-after-free takes place. When the last swevent dies, we do a for_each_possible_cpu() iteration anyway to clean these up, at which time we'll free it, so no leakage will occur. Change-Id: I270df3151cf315659763e2792655ff9138e4817a Tracked-On: https://jira01.devtools.intel.com/browse/AW-2339 Reported-by:
Sasha Levin <sasha.levin@oracle.com> Tested-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Signed-off-by:
Ingo Molnar <mingo@kernel.org> Reviewed-on: https://android.intel.com/546404 Reviewed-by:
-
Victor Tasayco Loarte authored
it fixes CVE-2016-6745 The global variable fwu is accessible in the fwu_sysfs_image_size_store and fwu_sysfs_store_image functions without any locks. This results in a potential race condition leading to a heap overflow. Bug: 31252388 Change-Id: I2f012c36a2d543aeb22c225071c014f0fe267e37 Tracked-On: https://jira01.devtools.intel.com/browse/AW-2339 Signed-off-by:
-
Paul Moore authored
There is a double fetch problem in audit_log_single_execve_arg() where we first check the execve(2) argumnets for any "bad" characters which would require hex encoding and then re-fetch the arguments for logging in the audit record[1]. Of course this leaves a window of opportunity for an unsavory application to munge with the data. This patch reworks things by only fetching the argument data once[2] into a buffer where it is scanned and logged into the audit records(s). In addition to fixing the double fetch, this patch improves on the original code in a few other ways: better handling of large arguments which require encoding, stricter record length checking, and some performance improvements (completely unverified, but we got rid of some strlen() calls, that's got to be a good thing). As part of the development of this patch, I've also created a basic regression test for the audit-testsuite, the test can be tracked on GitHub at the following link: * https://github.com/linux-audit/audit-testsuite/issues/25 [1] If you pay careful attention, there is actually a triple fetch problem due to a strnlen_user() call at the top of the function. [2] This is a tiny white lie, we do make a call to strnlen_user() prior to fetching the argument data. I don't like it, but due to the way the audit record is structured we really have no choice unless we copy the entire argument at once (which would require a rather wasteful allocation). The good news is that with this patch the kernel no longer relies on this strnlen_user() value for anything beyond recording it in the log, we also update it with a trustworthy value whenever possible. Change-Id: I937ff20b0c466c9b130da5c8c0697fc5c3a7ef9d Tracked-On: https://jira01.devtools.intel.com/browse/AW-2339 Reported-by:
Pengfei Wang <wpengfeinudt@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Paul Moore <paul@paul-moore.com> Reviewed-on: https://android.intel.com/546506 Reviewed-by:
-
Rainer Weikusat authored
The unix_dgram_sendmsg routine use the following test if (unlikely(unix_peer(other) != sk && unix_recvq_full(other))) { to determine if sk and other are in an n:1 association (either established via connect or by using sendto to send messages to an unrelated socket identified by address). This isn't correct as the specified address could have been bound to the sending socket itself or because this socket could have been connected to itself by the time of the unix_peer_get but disconnected before the unix_state_lock(other). In both cases, the if-block would be entered despite other == sk which might either block the sender unintentionally or lead to trying to unlock the same spin lock twice for a non-blocking send. Add a other != sk check to guard against this. Change-Id: I7c1c3be6b9cd6ec02b299794a1a6b6030fe9364b Tracked-On: https://jira01.devtools.intel.com/browse/AW-2339 Fixes: 7d267278 ("unix: avoid use-after-free in ep_remove_wait_queue") Reported-By:Philipp Hahn <pmhahn@pmhahn.de> Signed-off-by:
Rainer Weikusat <rweikusat@mobileactivedefense.com> Tested-by:
David S. Miller <davem@davemloft.net> Reviewed-on: https://android.intel.com/546403 Reviewed-by:
-
Mauro Carvalho Chehab authored
If struct xc2028_config is passed without a firmware name, the following trouble may happen: [11009.907205] xc2028 5-0061: type set to XCeive xc2028/xc3028 tuner [11009.907491] ================================================================== [11009.907750] BUG: KASAN: use-after-free in strcmp+0x96/0xb0 at addr ffff8803bd78ab40 [11009.907992] Read of size 1 by task modprobe/28992 [11009.907994] ============================================================================= [11009.907997] BUG kmalloc-16 (Tainted: G W ): kasan: bad access detected [11009.907999] ----------------------------------------------------------------------------- [11009.908008] INFO: Allocated in xhci_urb_enqueue+0x214/0x14c0 [xhci_hcd] age=0 cpu=3 pid=28992 [11009.908012] ___slab_alloc+0x581/0x5b0 [11009.908014] __slab_alloc+0x51/0x90 [11009.908017] __kmalloc+0x27b/0x350 [11009.908022] xhci_urb_enqueue+0x214/0x14c0 [xhci_hcd] [11009.908026] usb_hcd_submit_urb+0x1e8/0x1c60 [11009.908029] usb_submit_urb+0xb0e/0x1200 [11009.908032] usb_serial_generic_write_start+0xb6/0x4c0 [11009.908035] usb_serial_generic_write+0x92/0xc0 [11009.908039] usb_console_write+0x38a/0x560 [11009.908045] call_console_drivers.constprop.14+0x1ee/0x2c0 [11009.908051] console_unlock+0x40d/0x900 [11009.908056] vprintk_emit+0x4b4/0x830 [11009.908061] vprintk_default+0x1f/0x30 [11009.908064] printk+0x99/0xb5 [11009.908067] kasan_report_error+0x10a/0x550 [11009.908070] __asan_report_load1_noabort+0x43/0x50 [11009.908074] INFO: Freed in xc2028_set_config+0x90/0x630 [tuner_xc2028] age=1 cpu=3 pid=28992 [11009.908077] __slab_free+0x2ec/0x460 [11009.908080] kfree+0x266/0x280 [11009.908083] xc2028_set_config+0x90/0x630 [tuner_xc2028] [11009.908086] xc2028_attach+0x310/0x8a0 [tuner_xc2028] [11009.908090] em28xx_attach_xc3028.constprop.7+0x1f9/0x30d [em28xx_dvb] [11009.908094] em28xx_dvb_init.part.3+0x8e4/0x5cf4 [em28xx_dvb] [11009.908098] em28xx_dvb_init+0x81/0x8a [em28xx_dvb] [11009.908101] em28xx_register_extension+0xd9/0x190 [em28xx] [11009.908105] em28xx_dvb_register+0x10/0x1000 [em28xx_dvb] [11009.908108] do_one_initcall+0x141/0x300 [11009.908111] do_init_module+0x1d0/0x5ad [11009.908114] load_module+0x6666/0x9ba0 [11009.908117] SyS_finit_module+0x108/0x130 [11009.908120] entry_SYSCALL_64_fastpath+0x16/0x76 [11009.908123] INFO: Slab 0xffffea000ef5e280 objects=25 used=25 fp=0x (null) flags=0x2ffff8000004080 [11009.908126] INFO: Object 0xffff8803bd78ab40 @offset=2880 fp=0x0000000000000001 [11009.908130] Bytes b4 ffff8803bd78ab30: 01 00 00 00 2a 07 00 00 9d 28 00 00 01 00 00 00 ....*....(...... [11009.908133] Object ffff8803bd78ab40: 01 00 00 00 00 00 00 00 b0 1d c3 6a 00 88 ff ff ...........j.... [11009.908137] CPU: 3 PID: 28992 Comm: modprobe Tainted: G B W 4.5.0-rc1+ #43 [11009.908140] Hardware name: /NUC5i7RYB, BIOS RYBDWi35.86A.0350.2015.0812.1722 08/12/2015 [11009.908142] ffff8803bd78a000 ffff8802c273f1b8 ffffffff81932007 ffff8803c6407a80 [11009.908148] ffff8802c273f1e8 ffffffff81556759 ffff8803c6407a80 ffffea000ef5e280 [11009.908153] ffff8803bd78ab40 dffffc0000000000 ffff8802c273f210 ffffffff8155ccb4 [11009.908158] Call Trace: [11009.908162] [<ffffffff81932007>] dump_stack+0x4b/0x64 [11009.908165] [<ffffffff81556759>] print_trailer+0xf9/0x150 [11009.908168] [<ffffffff8155ccb4>] object_err+0x34/0x40 [11009.908171] [<ffffffff8155f260>] kasan_report_error+0x230/0x550 [11009.908175] [<ffffffff81237d71>] ? trace_hardirqs_off_caller+0x21/0x290 [11009.908179] [<ffffffff8155e926>] ? kasan_unpoison_shadow+0x36/0x50 [11009.908182] [<ffffffff8155f5c3>] __asan_report_load1_noabort+0x43/0x50 [11009.908185] [<ffffffff8155ea00>] ? __asan_register_globals+0x50/0xa0 [11009.908189] [<ffffffff8194cea6>] ? strcmp+0x96/0xb0 [11009.908192] [<ffffffff8194cea6>] strcmp+0x96/0xb0 [11009.908196] [<ffffffffa13ba4ac>] xc2028_set_config+0x15c/0x630 [tuner_xc2028] [11009.908200] [<ffffffffa13bac90>] xc2028_attach+0x310/0x8a0 [tuner_xc2028] [11009.908203] [<ffffffff8155ea78>] ? memset+0x28/0x30 [11009.908206] [<ffffffffa13ba980>] ? xc2028_set_config+0x630/0x630 [tuner_xc2028] [11009.908211] [<ffffffffa157a59a>] em28xx_attach_xc3028.constprop.7+0x1f9/0x30d [em28xx_dvb] [11009.908215] [<ffffffffa157aa2a>] ? em28xx_dvb_init.part.3+0x37c/0x5cf4 [em28xx_dvb] [11009.908219] [<ffffffffa157a3a1>] ? hauppauge_hvr930c_init+0x487/0x487 [em28xx_dvb] [11009.908222] [<ffffffffa01795ac>] ? lgdt330x_attach+0x1cc/0x370 [lgdt330x] [11009.908226] [<ffffffffa01793e0>] ? i2c_read_demod_bytes.isra.2+0x210/0x210 [lgdt330x] [11009.908230] [<ffffffff812e87d0>] ? ref_module.part.15+0x10/0x10 [11009.908233] [<ffffffff812e56e0>] ? module_assert_mutex_or_preempt+0x80/0x80 [11009.908238] [<ffffffffa157af92>] em28xx_dvb_init.part.3+0x8e4/0x5cf4 [em28xx_dvb] [11009.908242] [<ffffffffa157a6ae>] ? em28xx_attach_xc3028.constprop.7+0x30d/0x30d [em28xx_dvb] [11009.908245] [<ffffffff8195222d>] ? string+0x14d/0x1f0 [11009.908249] [<ffffffff8195381f>] ? symbol_string+0xff/0x1a0 [11009.908253] [<ffffffff81953720>] ? uuid_string+0x6f0/0x6f0 [11009.908257] [<ffffffff811a775e>] ? __kernel_text_address+0x7e/0xa0 [11009.908260] [<ffffffff8104b02f>] ? print_context_stack+0x7f/0xf0 [11009.908264] [<ffffffff812e9846>] ? __module_address+0xb6/0x360 [11009.908268] [<ffffffff8137fdc9>] ? is_ftrace_trampoline+0x99/0xe0 [11009.908271] [<ffffffff811a775e>] ? __kernel_text_address+0x7e/0xa0 [11009.908275] [<ffffffff81240a70>] ? debug_check_no_locks_freed+0x290/0x290 [11009.908278] [<ffffffff8104a24b>] ? dump_trace+0x11b/0x300 [11009.908282] [<ffffffffa13e8143>] ? em28xx_register_extension+0x23/0x190 [em28xx] [11009.908285] [<ffffffff81237d71>] ? trace_hardirqs_off_caller+0x21/0x290 [11009.908289] [<ffffffff8123ff56>] ? trace_hardirqs_on_caller+0x16/0x590 [11009.908292] [<ffffffff812404dd>] ? trace_hardirqs_on+0xd/0x10 [11009.908296] [<ffffffffa13e8143>] ? em28xx_register_extension+0x23/0x190 [em28xx] [11009.908299] [<ffffffff822dcbb0>] ? mutex_trylock+0x400/0x400 [11009.908302] [<ffffffff810021a1>] ? do_one_initcall+0x131/0x300 [11009.908306] [<ffffffff81296dc7>] ? call_rcu_sched+0x17/0x20 [11009.908309] [<ffffffff8159e708>] ? put_object+0x48/0x70 [11009.908314] [<ffffffffa1579f11>] em28xx_dvb_init+0x81/0x8a [em28xx_dvb] [11009.908317] [<ffffffffa13e81f9>] em28xx_register_extension+0xd9/0x190 [em28xx] [11009.908320] [<ffffffffa0150000>] ? 0xffffffffa0150000 [11009.908324] [<ffffffffa0150010>] em28xx_dvb_register+0x10/0x1000 [em28xx_dvb] [11009.908327] [<ffffffff810021b1>] do_one_initcall+0x141/0x300 [11009.908330] [<ffffffff81002070>] ? try_to_run_init_process+0x40/0x40 [11009.908333] [<ffffffff8123ff56>] ? trace_hardirqs_on_caller+0x16/0x590 [11009.908337] [<ffffffff8155e926>] ? kasan_unpoison_shadow+0x36/0x50 [11009.908340] [<ffffffff8155e926>] ? kasan_unpoison_shadow+0x36/0x50 [11009.908343] [<ffffffff8155e926>] ? kasan_unpoison_shadow+0x36/0x50 [11009.908346] [<ffffffff8155ea37>] ? __asan_register_globals+0x87/0xa0 [11009.908350] [<ffffffff8144da7b>] do_init_module+0x1d0/0x5ad [11009.908353] [<ffffffff812f2626>] load_module+0x6666/0x9ba0 [11009.908356] [<ffffffff812e9c90>] ? symbol_put_addr+0x50/0x50 [11009.908361] [<ffffffffa1580037>] ? em28xx_dvb_init.part.3+0x5989/0x5cf4 [em28xx_dvb] [11009.908366] [<ffffffff812ebfc0>] ? module_frob_arch_sections+0x20/0x20 [11009.908369] [<ffffffff815bc940>] ? open_exec+0x50/0x50 [11009.908374] [<ffffffff811671bb>] ? ns_capable+0x5b/0xd0 [11009.908377] [<ffffffff812f5e58>] SyS_finit_module+0x108/0x130 [11009.908379] [<ffffffff812f5d50>] ? SyS_init_module+0x1f0/0x1f0 [11009.908383] [<ffffffff81004044>] ? lockdep_sys_exit_thunk+0x12/0x14 [11009.908394] [<ffffffff822e6936>] entry_SYSCALL_64_fastpath+0x16/0x76 [11009.908396] Memory state around the buggy address: [11009.908398] ffff8803bd78aa00: 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc [11009.908401] ffff8803bd78aa80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [11009.908403] >ffff8803bd78ab00: fc fc fc fc fc fc fc fc 00 00 fc fc fc fc fc fc [11009.908405] ^ [11009.908407] ffff8803bd78ab80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [11009.908409] ffff8803bd78ac00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [11009.908411] ================================================================== In order to avoid it, let's set the cached value of the firmware name to NULL after freeing it. While here, return an error if the memory allocation fails. Change-Id: I853a7cbc804cde3043d7c560b8877f67a0094c9e Tracked-On: https://jira01.devtools.intel.com/browse/AW-2339 Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com> Reviewed-on: https://android.intel.com/546402 Reviewed-by:
-
Calvin Owens authored
In sg_common_write(), we free the block request and return -ENODEV if the device is detached in the middle of the SG_IO ioctl(). Unfortunately, sg_finish_rem_req() also tries to free srp->rq, so we end up freeing rq->cmd in the already free rq object, and then free the object itself out from under the current user. This ends up corrupting random memory via the list_head on the rq object. The most common crash trace I saw is this: ------------[ cut here ]------------ kernel BUG at block/blk-core.c:1420! Call Trace: [<ffffffff81281eab>] blk_put_request+0x5b/0x80 [<ffffffffa0069e5b>] sg_finish_rem_req+0x6b/0x120 [sg] [<ffffffffa006bcb9>] sg_common_write.isra.14+0x459/0x5a0 [sg] [<ffffffff8125b328>] ? selinux_file_alloc_security+0x48/0x70 [<ffffffffa006bf95>] sg_new_write.isra.17+0x195/0x2d0 [sg] [<ffffffffa006cef4>] sg_ioctl+0x644/0xdb0 [sg] [<ffffffff81170f80>] do_vfs_ioctl+0x90/0x520 [<ffffffff81258967>] ? file_has_perm+0x97/0xb0 [<ffffffff811714a1>] SyS_ioctl+0x91/0xb0 [<ffffffff81602afb>] tracesys+0xdd/0xe2 RIP [<ffffffff81281e04>] __blk_put_request+0x154/0x1a0 The solution is straightforward: just set srp->rq to NULL in the failure branch so that sg_finish_rem_req() doesn't attempt to re-free it. Additionally, since sg_rq_end_io() will never be called on the object when this happens, we need to free memory backing ->cmd if it isn't embedded in the object itself. KASAN was extremely helpful in finding the root cause of this bug. Change-Id: I53ebaf6b9bfece0a5125f168bce21a8dad008247 Tracked-On: https://jira01.devtools.intel.com/browse/AW-2339 Signed-off-by:Calvin Owens <calvinowens@fb.com> Acked-by:
Douglas Gilbert <dgilbert@interlog.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Reviewed-on: https://android.intel.com/546401 Reviewed-by:
-
Lukas Czerner authored
There is a use-after-free possibility in __ext4_journal_stop() in the case that we free the handle in the first jbd2_journal_stop() because we're referencing handle->h_err afterwards. This was introduced in 9705acd6 and it is wrong. Fix it by storing the handle->h_err value beforehand and avoid referencing potentially freed handle. Change-Id: I70e65cd81e147c4fb320fd7bc1846bf8fe4fc7bf Tracked-On: https://jira01.devtools.intel.com/browse/AW-2339 Fixes: 9705acd6 Signed-off-by:
Lukas Czerner <lczerner@redhat.com> Reviewed-by:
Andreas Dilger <adilger@dilger.ca> Cc: stable@vger.kernel.org Reviewed-on: https://android.intel.com/546400 Reviewed-by:
-
Lukas Czerner authored
Currently when journal restart fails, we'll have the h_transaction of the handle set to NULL to indicate that the handle has been effectively aborted. We handle this situation quietly in the jbd2_journal_stop() and just free the handle and exit because everything else has been done before we attempted (and failed) to restart the journal. Unfortunately there are a number of problems with that approach introduced with commit 41a5b913 "jbd2: invalidate handle if jbd2_journal_restart() fails" First of all in ext4 jbd2_journal_stop() will be called through __ext4_journal_stop() where we would try to get a hold of the superblock by dereferencing h_transaction which in this case would lead to NULL pointer dereference and crash. In addition we're going to free the handle regardless of the refcount which is bad as well, because others up the call chain will still reference the handle so we might potentially reference already freed memory. Moreover it's expected that we'll get aborted handle as well as detached handle in some of the journalling function as the error propagates up the stack, so it's unnecessary to call WARN_ON every time we get detached handle. And finally we might leak some memory by forgetting to free reserved handle in jbd2_journal_stop() in the case where handle was detached from the transaction (h_transaction is NULL). Fix the NULL pointer dereference in __ext4_journal_stop() by just calling jbd2_journal_stop() quietly as suggested by Jan Kara. Also fix the potential memory leak in jbd2_journal_stop() and use proper handle refcounting before we attempt to free it to avoid use-after-free issues. And finally remove all WARN_ON(!transaction) from the code so that we do not get random traces when something goes wrong because when journal restart fails we will get to some of those functions. Change-Id: I29d9ceb812c72caf2f6b9ef0e6a9a79b4e52c69b Tracked-On: https://jira01.devtools.intel.com/browse/AW-2339 Cc: stable@vger.kernel.org Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Reviewed-by:
Jan Kara <jack@suse.cz> Reviewed-on: https://android.intel.com/549191 Reviewed-by:
-
Omar Sandoval authored
get_task_ioprio() accesses the task->io_context without holding the task lock and thus can race with exit_io_context(), leading to a use-after-free. The reproducer below hits this within a few seconds on my 4-core QEMU VM: int main(int argc, char **argv) { pid_t pid, child; long nproc, i; /* ioprio_set(IOPRIO_WHO_PROCESS, 0, IOPRIO_PRIO_VALUE(IOPRIO_CLASS_IDLE, 0)); */ syscall(SYS_ioprio_set, 1, 0, 0x6000); nproc = sysconf(_SC_NPROCESSORS_ONLN); for (i = 0; i < nproc; i++) { pid = fork(); assert(pid != -1); if (pid == 0) { for (;;) { pid = fork(); assert(pid != -1); if (pid == 0) { _exit(0); } else { child = wait(NULL); assert(child == pid); } } } pid = fork(); assert(pid != -1); if (pid == 0) { for (;;) { /* ioprio_get(IOPRIO_WHO_PGRP, 0); */ syscall(SYS_ioprio_get, 2, 0); } } } for (;;) { /* ioprio_get(IOPRIO_WHO_PGRP, 0); */ syscall(SYS_ioprio_get, 2, 0); } return 0; } This gets us KASAN dumps like this: [ 35.526914] ================================================================== [ 35.530009] BUG: KASAN: out-of-bounds in get_task_ioprio+0x7b/0x90 at addr ffff880066f34e6c [ 35.530009] Read of size 2 by task ioprio-gpf/363 [ 35.530009] ============================================================================= [ 35.530009] BUG blkdev_ioc (Not tainted): kasan: bad access detected [ 35.530009] ----------------------------------------------------------------------------- [ 35.530009] Disabling lock debugging due to kernel taint [ 35.530009] INFO: Allocated in create_task_io_context+0x2b/0x370 age=0 cpu=0 pid=360 [ 35.530009] ___slab_alloc+0x55d/0x5a0 [ 35.530009] __slab_alloc.isra.20+0x2b/0x40 [ 35.530009] kmem_cache_alloc_node+0x84/0x200 [ 35.530009] create_task_io_context+0x2b/0x370 [ 35.530009] get_task_io_context+0x92/0xb0 [ 35.530009] copy_process.part.8+0x5029/0x5660 [ 35.530009] _do_fork+0x155/0x7e0 [ 35.530009] SyS_clone+0x19/0x20 [ 35.530009] do_syscall_64+0x195/0x3a0 [ 35.530009] return_from_SYSCALL_64+0x0/0x6a [ 35.530009] INFO: Freed in put_io_context+0xe7/0x120 age=0 cpu=0 pid=1060 [ 35.530009] __slab_free+0x27b/0x3d0 [ 35.530009] kmem_cache_free+0x1fb/0x220 [ 35.530009] put_io_context+0xe7/0x120 [ 35.530009] put_io_context_active+0x238/0x380 [ 35.530009] exit_io_context+0x66/0x80 [ 35.530009] do_exit+0x158e/0x2b90 [ 35.530009] do_group_exit+0xe5/0x2b0 [ 35.530009] SyS_exit_group+0x1d/0x20 [ 35.530009] entry_SYSCALL_64_fastpath+0x1a/0xa4 [ 35.530009] INFO: Slab 0xffffea00019bcd00 objects=20 used=4 fp=0xffff880066f34ff0 flags=0x1fffe0000004080 [ 35.530009] INFO: Object 0xffff880066f34e58 @offset=3672 fp=0x0000000000000001 [ 35.530009] ================================================================== Fix it by grabbing the task lock while we poke at the io_context. Change-Id: I6752c22873cc281ff6a71267166e99a2e18ac86d Tracked-On: https://jira01.devtools.intel.com/browse/AW-2339 Cc: stable@vger.kernel.org Reported-by:Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
Omar Sandoval <osandov@fb.com> Signed-off-by:
Jens Axboe <axboe@fb.com> Reviewed-on: https://android.intel.com/546399 Reviewed-by:
-
Vegard Nossum authored
I got a KASAN report of use-after-free: ================================================================== BUG: KASAN: use-after-free in klist_iter_exit+0x61/0x70 at addr ffff8800b6581508 Read of size 8 by task trinity-c1/315 ============================================================================= BUG kmalloc-32 (Not tainted): kasan: bad access detected ----------------------------------------------------------------------------- Disabling lock debugging due to kernel taint INFO: Allocated in disk_seqf_start+0x66/0x110 age=144 cpu=1 pid=315 ___slab_alloc+0x4f1/0x520 __slab_alloc.isra.58+0x56/0x80 kmem_cache_alloc_trace+0x260/0x2a0 disk_seqf_start+0x66/0x110 traverse+0x176/0x860 seq_read+0x7e3/0x11a0 proc_reg_read+0xbc/0x180 do_loop_readv_writev+0x134/0x210 do_readv_writev+0x565/0x660 vfs_readv+0x67/0xa0 do_preadv+0x126/0x170 SyS_preadv+0xc/0x10 do_syscall_64+0x1a1/0x460 return_from_SYSCALL_64+0x0/0x6a INFO: Freed in disk_seqf_stop+0x42/0x50 age=160 cpu=1 pid=315 __slab_free+0x17a/0x2c0 kfree+0x20a/0x220 disk_seqf_stop+0x42/0x50 traverse+0x3b5/0x860 seq_read+0x7e3/0x11a0 proc_reg_read+0xbc/0x180 do_loop_readv_writev+0x134/0x210 do_readv_writev+0x565/0x660 vfs_readv+0x67/0xa0 do_preadv+0x126/0x170 SyS_preadv+0xc/0x10 do_syscall_64+0x1a1/0x460 return_from_SYSCALL_64+0x0/0x6a CPU: 1 PID: 315 Comm: trinity-c1 Tainted: G B 4.7.0+ #62 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 ffffea0002d96000 ffff880119b9f918 ffffffff81d6ce81 ffff88011a804480 ffff8800b6581500 ffff880119b9f948 ffffffff8146c7bd ffff88011a804480 ffffea0002d96000 ffff8800b6581500 fffffffffffffff4 ffff880119b9f970 Call Trace: [<ffffffff81d6ce81>] dump_stack+0x65/0x84 [<ffffffff8146c7bd>] print_trailer+0x10d/0x1a0 [<ffffffff814704ff>] object_err+0x2f/0x40 [<ffffffff814754d1>] kasan_report_error+0x221/0x520 [<ffffffff8147590e>] __asan_report_load8_noabort+0x3e/0x40 [<ffffffff83888161>] klist_iter_exit+0x61/0x70 [<ffffffff82404389>] class_dev_iter_exit+0x9/0x10 [<ffffffff81d2e8ea>] disk_seqf_stop+0x3a/0x50 [<ffffffff8151f812>] seq_read+0x4b2/0x11a0 [<ffffffff815f8fdc>] proc_reg_read+0xbc/0x180 [<ffffffff814b24e4>] do_loop_readv_writev+0x134/0x210 [<ffffffff814b4c45>] do_readv_writev+0x565/0x660 [<ffffffff814b8a17>] vfs_readv+0x67/0xa0 [<ffffffff814b8de6>] do_preadv+0x126/0x170 [<ffffffff814b92ec>] SyS_preadv+0xc/0x10 This problem can occur in the following situation: open() - pread() - .seq_start() - iter = kmalloc() // succeeds - seqf->private = iter - .seq_stop() - kfree(seqf->private) - pread() - .seq_start() - iter = kmalloc() // fails - .seq_stop() - class_dev_iter_exit(seqf->private) // boom! old pointer As the comment in disk_seqf_stop() says, stop is called even if start failed, so we need to reinitialise the private pointer to NULL when seq iteration stops. An alternative would be to set the private pointer to NULL when the kmalloc() in disk_seqf_start() fails. Change-Id: Idc9a23a52c4f543cef6784eff90bbc02c429f916 Tracked-On: https://jira01.devtools.intel.com/browse/AW-2339 Cc: stable@vger.kernel.org Signed-off-by:Vegard Nossum <vegard.nossum@oracle.com> Acked-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Vladis Dronov authored
create_fixed_stream_quirk(), snd_usb_parse_audio_interface() and create_uaxx_quirk() functions allocate the audioformat object by themselves and free it upon error before returning. However, once the object is linked to a stream, it's freed again in snd_usb_audio_pcm_free(), thus it'll be double-freed, eventually resulting in a memory corruption. This patch fixes these failures in the error paths by unlinking the audioformat object before freeing it. Based on a patch by Takashi Iwai <tiwai@suse.de> [Note for stable backports: this patch requires the commit 902eb7fd1e4a ('ALSA: usb-audio: Minor code cleanup in create_fixed_stream_quirk()')] Change-Id: Iea7ca20e51eaf63daa377e1c799eeed26fb73723 Tracked-On: https://jira01.devtools.intel.com/browse/AW-2339 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1283358 Reported-by:Ralf Spenneberg <ralf@spenneberg.net> Cc: <stable@vger.kernel.org> # see the note above Signed-off-by:
Vladis Dronov <vdronov@redhat.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Reviewed-on: https://android.intel.com/546397 Reviewed-by:
-
Tao, JianX authored
HW odr of accel already arbitrated while sensor enabled. No need to buffer odr for accel none wakeup and wakeup sensor. Which will have some side effect when sensor disabled. Change-Id: I01cf25ff16da3c0751889b43a80d5304f0796fda Tracked-On: https://jira01.devtools.intel.com/browse/AW-2300 Signed-off-by:
Tao, JianX <jianx.tao@intel.com> Reviewed-on: https://android.intel.com/548764 Reviewed-by:
Whitfield, MichaelX <michaelx.whitfield@intel.com>
-
Eric Dumazet authored
When tcp_sendmsg() allocates a fresh and empty skb, it puts it at the tail of the write queue using tcp_add_write_queue_tail() Then it attempts to copy user data into this fresh skb. If the copy fails, we undo the work and remove the fresh skb. Unfortunately, this undo lacks the change done to tp->highest_sack and we can leave a dangling pointer (to a freed skb) Later, tcp_xmit_retransmit_queue() can dereference this pointer and access freed memory. For regular kernels where memory is not unmapped, this might cause SACK bugs because tcp_highest_sack_seq() is buggy, returning garbage instead of tp->snd_nxt, but with various debug features like CONFIG_DEBUG_PAGEALLOC, this can crash the kernel. This bug was found by Marco Grassi thanks to syzkaller. Change-Id: I7c23cf11d5cbcc76aa916ed14253d36e8c1cd2ce Tracked-On: https://jira01.devtools.intel.com/browse/AW-2339 Fixes: 6859d494 ("[TCP]: Abstract tp->highest_sack accessing & point to next skb") Reported-by:
Marco Grassi <marco.gra@gmail.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Cc: Yuchung Cheng <ycheng@google.com> Cc: Neal Cardwell <ncardwell@google.com> Acked-by:
Neal Cardwell <ncardwell@google.com> Reviewed-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
-
- Nov 04, 2016
-
-
Liu YangX D authored
For easy debugging and fine-tuning the configurable parameters of Wrist Tilt on different HW platforms, expose them to sys nodes, readable and writable. The parameters include latency,axes,threshold and filter timer. Change-Id: I22f6d9702aee01b809a4d809085b6c77dcc8b0fd Tracked-On: https://jira01.devtools.intel.com/browse/AW-2484 Signed-off-by:
Liu, YangX D <yangx.d.liu@intel.com> Reviewed-on: https://android.intel.com/547507 Reviewed-by:
-
Sophia Gong authored
Change-Id: I56f238e8a2146e5f1a5cb3fb47576e5f6548ef0d Tracked-On: https://jira01.devtools.intel.com/browse/AW-2547 Signed-off-by:
-
- Oct 28, 2016
-
-
Riadh GHADDAB authored
- This patch corrects the bug related to battery capacity not reaching 100% - When the postcharging is launched the status_reg stored value is not updated. As a result, the next postcharging phase is not started Change-Id: I56da91765dc5fddfc20652fa179d8f03d1d6791b Tracked-On: https://jira01.devtools.intel.com/browse/AW-2510 Signed-off-by:
Ferrari, AlainX <alainx.ferrari@intel.com>
-
Guillaume Ranquet authored
Change-Id: Ib5adb5be3250c6a3219c3f0e99f437070ef3fcc6 Tracked-On: https://jira01.devtools.intel.com/browse/AW-2542 Signed-off-by:
Guillaume Ranquet <guillaume.ranquet@intel.com> Reviewed-on: https://android.intel.com/547959 Reviewed-by:
-
Guillaume Ranquet authored
Change-Id: If2bc3a6a958bdc28747ccd66a9895c7e0c2990b4 Tracked-On: https://jira01.devtools.intel.com/browse/AW-2542 Signed-off-by:
-
- Oct 27, 2016
-
-
Simon Dubray authored
Since we can enter s0i3 with display on, there is no good reason to prevent s0ix in any case in intel_media driver. Change-Id: I40a246adee8b54e461b9de8e969257cdafe8baa9 Tracked-On: https://jira01.devtools.intel.com/browse/AW-2449 Signed-off-by:
Korpershoek, MattijsX <mattijsx.korpershoek@intel.com> Reviewed-by:
Afonso, PhilippeX <philippex.afonso@intel.com> Reviewed-by:
Lachaud, EtienneX <etiennex.lachaud@intel.com> Tested-by:
-
Liu YangX D authored
Make the workflow more reasonable and avoid memory leak before return error in function st_lsm6ds3h_upload_algo. Change-Id: I17a9134ead7be4778e5a63f5cfbf9915c9cc6234 Tracked-On: https://jira01.devtools.intel.com/browse/AW-2437 Signed-off-by:
-
- Oct 19, 2016
-
-
liuW3X authored
As use cmds to let device enter idle, and display off at once but device not,then will triger the vsync log as SF polling the display status off. On DOZE/DOZE_SUSPEND, we should make sure panel status on and display on when device not in idle. Change-Id: I7a9a8c04d32b325f48a28c2ca83aa2b252d33cc8 Tracked-On: https://jira01.devtools.intel.com/browse/AW-1308 Signed-off-by:
liuW3X <weix.w.liu@intel.com> Reviewed-on: https://android.intel.com/533891 Reviewed-by:
Wang, WenshengX <wenshengx.wang@intel.com> Reviewed-by:
-
Eric Dumazet authored
(cherry picked from commit 75ff39ccc1bd5d3c455b6822ab09e533c551f758) CVE-2016-5696 Yue Cao claims that current host rate limiting of challenge ACKS (RFC 5961) could leak enough information to allow a patient attacker to hijack TCP sessions. He will soon provide details in an academic paper. This patch increases the default limit from 100 to 1000, and adds some randomization so that the attacker can no longer hijack sessions without spending a considerable amount of probes. Based on initial analysis and patch from Linus. Note that we also have per socket rate limiting, so it is tempting to remove the host limit in the future. v2: randomize the count of challenge acks per second, not the period. Tracked-On: https://jira01.devtools.intel.com/browse/AW-2263 Fixes: 282f23c6 ("tcp: implement RFC 5961 3.2") Reported-by:
Yue Cao <ycao009@ucr.edu> Signed-off-by:
Yuchung Cheng <ycheng@google.com> Signed-off-by:
-
Daniel Borkmann authored
CVE-2016-5696 Many functions have open coded a function that returns a random number in range [0,N-1]. Under the assumption that we have a PRNG such as taus113 with being well distributed in [0, ~0U] space, we can implement such a function as uword t = (n*m')>>32, where m' is a random number obtained from PRNG, n the right open interval border and t our resulting random number, with n,m',t in u32 universe. Lets go with Joe and simply call it prandom_u32_max(), although technically we have an right open interval endpoint, but that we have documented. Other users can further be migrated to the new prandom_u32_max() function later on; for now, we need to make sure to migrate reciprocal_divide() users for the reciprocal_divide() follow-up fixup since their function signatures are going to change. Joint work with Hannes Frederic Sowa. Change-Id: Ib62946c0432a63345723df0d891186cd939bec09 Tracked-On: https://jira01.devtools.intel.com/browse/AW-2263 Cc: Jakub Zawadzki <darkjames-ws@darkjames.pl> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: linux-kernel@vger.kernel.org Signed-off-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
Daniel Borkmann <dborkman@redhat.com> Signed-off-by:
-
Christian Borntraeger authored
CVE-2016-5696 Feedback has shown that WRITE_ONCE(x, val) is easier to use than ASSIGN_ONCE(val,x). There are no in-tree users yet, so lets change it for 3.19. Change-Id: Iac0bfaf6998f7632963528d03873cc779b2eea74 Tracked-On: https://jira01.devtools.intel.com/browse/AW-2263 Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com> Acked-by:
Davidlohr Bueso <dave@stgolabs.net> Acked-by:
Paul E. McKenney <paulmck@linux.vnet.ibm.com> Reviewed-on: https://android.intel.com/545359 Reviewed-by:
-
Christian Borntraeger authored
CVE-2016-5696 ACCESS_ONCE does not work reliably on non-scalar types. For example gcc 4.6 and 4.7 might remove the volatile tag for such accesses during the SRA (scalar replacement of aggregates) step https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145) Let's provide READ_ONCE/ASSIGN_ONCE that will do all accesses via scalar types as suggested by Linus Torvalds. Accesses larger than the machines word size cannot be guaranteed to be atomic. These macros will use memcpy and emit a build warning. Change-Id: Id93ef5c30bbf35bc773d5ed24eee709aadecca15 Tracked-On: https://jira01.devtools.intel.com/browse/AW-2263 Signed-off-by:
-
Al Viro authored
CVE-2015-2686 Change-Id: I6a2403a206493c2ca20218ded25483db26759c6a Tracked-On: https://jira01.devtools.intel.com/browse/AW-2263 Cc: stable@vger.kernel.org # v3.19 Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Erwan Mahe authored
CVE-2016-6690 Adding check for null function pointer for dummy sound driver read/write to prevent kernel panic. Bug: 28838221 Change-Id: Ie1aee966167dc5e04555ee11105c5cc3725665dd Tracked-On: https://jira01.devtools.intel.com/browse/AW-2263 Signed-off-by:
Yuan Lin <yualin@google.com> Signed-off-by:
-
