Select Git revision
Search by author
- Any Author
- authors
-
72162444 72162444 gaochangning
-
Aakash Dave aakash.dave
-
Aaron Kim akim
-
Aaron Kloc akloc
-
Aaron Lan aaron.lan
-
Aaron Nabil aaronna
-
Aaron Pohle aaron.pohle
-
Abbott Chung chung.abbott
-
Abdallah Omar abdallah_omar
-
Abdessamii Chalbi abdessamii.chalbi
-
Abdul Hussain Sirajudeen abdul.hussain
-
Abdullah Alghamdi a.alghamdi
-
Abdullah Elmarghany abdullah_elmarghany
-
Abel Fang abel_fang
-
Abhijeet Badurkar abhijeet.badurkar
-
Abhijit Adsule adsule
-
Abhijit Murthy abhijit
-
Abhi Khanal akhanal
-
Abhilash Sahoo abhilashsahoo
-
Abhimanyu Raj abhimanyu.raj
- Oct 21, 2016
-
-
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-2264 Fixes: 282f23c6 ("tcp: implement RFC 5961 3.2") Reported-by:
Yue Cao <ycao009@ucr.edu> Signed-off-by:
Eric Dumazet <edumazet@google.com> Suggested-by:
Linus Torvalds <torvalds@linux-foundation.org> Cc: Yuchung Cheng <ycheng@google.com> Cc: Neal Cardwell <ncardwell@google.com> Acked-by:
Neal Cardwell <ncardwell@google.com> Acked-by:
Yuchung Cheng <ycheng@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Change-Id: Ib46ba66f5e4a5a7c81bfccd7b0aa83c3d9e1b3bb Bug: 30809774 Reviewed-on: https://android.intel.com/545361 Reviewed-by:
Mahe, Erwan <erwan.mahe@intel.com> Reviewed-by:
Dubray, SimonX <simonx.dubray@intel.com> Tested-by:
Tasayco Loarte, VictorX <victorx.tasayco.loarte@intel.com> Reviewed-by:
Maalem, Saadi <saadi.maalem@intel.com>
-
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-2264 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-2264 Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com> Acked-by:
Peter Zijlstra <peterz@infradead.org> 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-2264 Signed-off-by:
-
Al Viro authored
CVE-2015-2686 Change-Id: I6a2403a206493c2ca20218ded25483db26759c6a Tracked-On: https://jira01.devtools.intel.com/browse/AW-2264 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-2264 Signed-off-by:
Yuan Lin <yualin@google.com> Signed-off-by:
-
Erwan Mahe authored
CVE-2016-6689 Prevents leaking pointers between processes BUG: 30768347 Change-Id: I0742878827d069940dbaef94a7d39824fc5d55b1 Tracked-On: https://jira01.devtools.intel.com/browse/AW-2264 Signed-off-by:
Arve Hjønnevåg <arve@android.com> Signed-off-by:
-
Erwan Mahe authored
(cherry picked from 951b6a07) CVE-2016-8956 addr can be NULL and it should not be dereferenced before NULL checking. Signed-off-by:
Jaganath Kanakkassery <jaganath.k@samsung.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Change-Id: Iaaf4824d277cd26e83619a2d4bb50ba49837fdb7 Tracked-On: https://jira01.devtools.intel.com/browse/AW-2264 Signed-off-by:
-
Erwan Mahe authored
CVE-2016-6684 The format specifier %p can leak kernel addresses while not valuing the kptr_restrict system settings. Use %pK instead of %p, which also evaluates whether kptr_restrict is set. Bug: 30148243 Change-Id: I7db3b6445453e4f3397f3dd5e33faef49d4541d9 Tracked-On: https://jira01.devtools.intel.com/browse/AW-2264 Signed-off-by:
Divya Ponnusamy <pdivya@codeaurora.org> Reviewed-on: https://android.intel.com/545353 Reviewed-by:
jenkins_ndg <jenkins_ndg@intel.com> Reviewed-by:
-
Erwan Mahe authored
CVE-2016-6683 Works in conjunction with kptr_restrict. Bug: 30143283 Change-Id: I3e74016ef0048867bc03e2ecfbb290ad9dc715a9 Tracked-On: https://jira01.devtools.intel.com/browse/AW-2264 Signed-off-by:
-
Erwan Mahe authored
CVE-2016-6674 Prevent using a binder_ref with only weak references where a strong reference is required. BUG: 30445380 Change-Id: I39a39e2f9cb80a603fc98f7c4af9230ff2b884b2 Tracked-On: https://jira01.devtools.intel.com/browse/AW-2264 Signed-off-by:
-
Erwan Mahe authored
CVE-2016-3940 dsx i2c operations structure include i2c write and i2c read which accepts data from user space. Temp buffers are allocated through variable length arrays which can pose security problems. So allocate memory on heap instead of stack to avoid this. Bug: 30141991 Change-Id: I84ce047ceb79809437a2e428e65ba0623d71ccca Tracked-On: https://jira01.devtools.intel.com/browse/AW-2264 Signed-off-by:
Yueyao <Zhu<yueyao@google.com> Signed-off-by:
-
Arnaldo Carvalho de Melo authored
CVE-2016-7117 The syzkaller fuzzer hit the following use-after-free: Call Trace: [<ffffffff8175ea0e>] __asan_report_load8_noabort+0x3e/0x40 mm/kasan/report.c:295 [<ffffffff851cc31a>] __sys_recvmmsg+0x6fa/0x7f0 net/socket.c:2261 [< inline >] SYSC_recvmmsg net/socket.c:2281 [<ffffffff851cc57f>] SyS_recvmmsg+0x16f/0x180 net/socket.c:2270 [<ffffffff86332bb6>] entry_SYSCALL_64_fastpath+0x16/0x7a arch/x86/entry/entry_64.S:185 And, as Dmitry rightly assessed, that is because we can drop the reference and then touch it when the underlying recvmsg calls return some packets and then hit an error, which will make recvmmsg to set sock->sk->sk_err, oops, fix it. Change-Id: I21e39b219f862e06aee4e4ef82571a739df55112 Tracked-On: https://jira01.devtools.intel.com/browse/AW-2264 Reported-and-Tested-by:
Dmitry Vyukov <dvyukov@google.com> Cc: Alexander Potapenko <glider@google.com> Cc: Eric Dumazet <edumazet@google.com> Cc: Kostya Serebryany <kcc@google.com> Cc: Sasha Levin <sasha.levin@oracle.com> Fixes: a2e27255 ("net: Introduce recvmmsg socket syscall") http://lkml.kernel.org/r/20160122211644.GC2470@redhat.com Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
David Howells authored
This fixes CVE-2016-0758. In the ASN.1 decoder, when the length field of an ASN.1 value is extracted, it isn't validated against the remaining amount of data before being added to the cursor. With a sufficiently large size indicated, the check: datalen - dp < 2 may then fail due to integer overflow. Fix this by checking the length indicated against the amount of remaining data in both places a definite length is determined. Whilst we're at it, make the following changes: (1) Check the maximum size of extended length does not exceed the capacity of the variable it's being stored in (len) rather than the type that variable is assumed to be (size_t). (2) Compare the EOC tag to the symbolic constant ASN1_EOC rather than the integer 0. (3) To reduce confusion, move the initialisation of len outside of: for (len = 0; n > 0; n--) { since it doesn't have anything to do with the loop counter n. Change-Id: I17e4ffccf0608af9e277915c02b02e1bd151494b Tracked-On: https://jira01.devtools.intel.com/browse/AW-2264 Signed-off-by:David Howells <dhowells@redhat.com> Reviewed-by:
Mimi Zohar <zohar@linux.vnet.ibm.com> Acked-by:
David Woodhouse <David.Woodhouse@intel.com> Acked-by:
Peter Jones <pjones@redhat.com> Reviewed-on: https://android.intel.com/545348 Reviewed-by:
-
- Sep 27, 2016
-
-
Tasayco Loarte, VictorX authored
This change is already present in current kernel 3.10 via commit a70b52ec. This reverts commit 99315b97. Change-Id: I514162e7cd0a6dfd05c16c246b7954537f0af109 Tracked-On: https://jira01.devtools.intel.com/browse/AW-2060 Signed-off-by:
-
- Sep 26, 2016
-
-
D.S. Ljungmark authored
A local route may have a lower hop_limit set than global routes do. RFC 3756, Section 4.2.7, "Parameter Spoofing" > 1. The attacker includes a Current Hop Limit of one or another small > number which the attacker knows will cause legitimate packets to > be dropped before they reach their destination. > As an example, one possible approach to mitigate this threat is to > ignore very small hop limits. The nodes could implement a > configurable minimum hop limit, and ignore attempts to set it below > said limit. Bug: 29409847 Signed-off-by:
D.S. Ljungmark <ljungmark@modio.se> Acked-by:
-
Florian Westphal authored
(cherry picked from commit bdf533de6968e9686df777dc178486f600c6e617) We should check that e->target_offset is sane before mark_source_chains gets called since it will fetch the target entry for loop detection. Bug: 29637687 Bug: 31554728 Change-Id: Ida3d7055b4905cf4c18550f3989f529a8ff5e8a9 Tracked-On: https://jira01.devtools.intel.com/browse/AW-1795 Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
Mekala Natarajan <mnatarajan@google.com> Signed-off-by:
-
Florian Westphal authored
Otherwise this function may read data beyond the ruleset blob. Bug: 29637687 Signed-off-by:
-
Nick Desaulniers authored
Bug: 28760453 Bug: 31554728 Change-Id: I019c2de559db9e4b95860ab852211b456d78c4ca Tracked-On: https://jira01.devtools.intel.com/browse/AW-1795 Signed-off-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
-
Eric Dumazet authored
We have two problems in UDP stack related to bogus checksums : 1) We return -EAGAIN to application even if receive queue is not empty. This breaks applications using edge trigger epoll() 2) Under UDP flood, we can loop forever without yielding to other processes, potentially hanging the host, especially on non SMP. This patch is an attempt to make things better. We might in the future add extra support for rt applications wanting to better control time spent doing a recv() in a hostile environment. For example we could validate checksums before queuing packets in socket receive queue. Bug:29507402 Signed-off-by:
-
Jann Horn authored
This prevents users from triggering a stack overflow through a recursive invocation of pagefault handling that involves mapping procfs files into virtual memory. Signed-off-by:
Jann Horn <jannh@google.com> Acked-by:
Tyler Hicks <tyhicks@canonical.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Jerry Lee authored
Protect array overflow in parsing PNO batching cmd Bug: 29009982 Bug: 31554728 Change-Id: I4e36f580336cacd6e3efcb8caf91eef33003753b Tracked-On: https://jira01.devtools.intel.com/browse/AW-1795 Signed-off-by:
Jerry Lee <jerrylee@broadcom.com> Signed-off-by:
-
Victor Tasayco Loarte authored
rmidev file operations structure include write() and read() which accepts data from user space. Temp buffers are allocated through variable length arrays which can pose security problems. So allocate memory on heap instead of stack to avoid this. Bug: 28799389 Bug: 31554728 CRs-Fixed: 1032459 Change-Id: I44443f91d435715dd0097ef8e8dfc48e291f93fc Tracked-On: https://jira01.devtools.intel.com/browse/AW-1795 Signed-off-by:
Mohan Pallaka <mpallaka@codeaurora.org> Signed-off-by:
Biswajit Paul <biswajitpaul@codeaurora.org> Signed-off-by:
-
Guillaume Nault authored
Let channels hold a reference on their network namespace. Some channel types, like ppp_async and ppp_synctty, can have their userspace controller running in a different namespace. Therefore they can't rely on them to preclude their netns from being removed from under them. ================================================================== BUG: KASAN: use-after-free in ppp_unregister_channel+0x372/0x3a0 at addr ffff880064e217e0 Read of size 8 by task syz-executor/11581 ============================================================================= BUG net_namespace (Not tainted): kasan: bad access detected ----------------------------------------------------------------------------- Disabling lock debugging due to kernel taint INFO: Allocated in copy_net_ns+0x6b/0x1a0 age=92569 cpu=3 pid=6906 [< none >] ___slab_alloc+0x4c7/0x500 kernel/mm/slub.c:2440 [< none >] __slab_alloc+0x4c/0x90 kernel/mm/slub.c:2469 [< inline >] slab_alloc_node kernel/mm/slub.c:2532 [< inline >] slab_alloc kernel/mm/slub.c:2574 [< none >] kmem_cache_alloc+0x23a/0x2b0 kernel/mm/slub.c:2579 [< inline >] kmem_cache_zalloc kernel/include/linux/slab.h:597 [< inline >] net_alloc kernel/net/core/net_namespace.c:325 [< none >] copy_net_ns+0x6b/0x1a0 kernel/net/core/net_namespace.c:360 [< none >] create_new_namespaces+0x2f6/0x610 kernel/kernel/nsproxy.c:95 [< none >] copy_namespaces+0x297/0x320 kernel/kernel/nsproxy.c:150 [< none >] copy_process.part.35+0x1bf4/0x5760 kernel/kernel/fork.c:1451 [< inline >] copy_process kernel/kernel/fork.c:1274 [< none >] _do_fork+0x1bc/0xcb0 kernel/kernel/fork.c:1723 [< inline >] SYSC_clone kernel/kernel/fork.c:1832 [< none >] SyS_clone+0x37/0x50 kernel/kernel/fork.c:1826 [< none >] entry_SYSCALL_64_fastpath+0x16/0x7a kernel/arch/x86/entry/entry_64.S:185 INFO: Freed in net_drop_ns+0x67/0x80 age=575 cpu=2 pid=2631 [< none >] __slab_free+0x1fc/0x320 kernel/mm/slub.c:2650 [< inline >] slab_free kernel/mm/slub.c:2805 [< none >] kmem_cache_free+0x2a0/0x330 kernel/mm/slub.c:2814 [< inline >] net_free kernel/net/core/net_namespace.c:341 [< none >] net_drop_ns+0x67/0x80 kernel/net/core/net_namespace.c:348 [< none >] cleanup_net+0x4e5/0x600 kernel/net/core/net_namespace.c:448 [< none >] process_one_work+0x794/0x1440 kernel/kernel/workqueue.c:2036 [< none >] worker_thread+0xdb/0xfc0 kernel/kernel/workqueue.c:2170 [< none >] kthread+0x23f/0x2d0 kernel/drivers/block/aoe/aoecmd.c:1303 [< none >] ret_from_fork+0x3f/0x70 kernel/arch/x86/entry/entry_64.S:468 INFO: Slab 0xffffea0001938800 objects=3 used=0 fp=0xffff880064e20000 flags=0x5fffc0000004080 INFO: Object 0xffff880064e20000 @offset=0 fp=0xffff880064e24200 CPU: 1 PID: 11581 Comm: syz-executor Tainted: G B 4.4.0+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014 00000000ffffffff ffff8800662c7790 ffffffff8292049d ffff88003e36a300 ffff880064e20000 ffff880064e20000 ffff8800662c77c0 ffffffff816f2054 ffff88003e36a300 ffffea0001938800 ffff880064e20000 0000000000000000 Call Trace: [< inline >] __dump_stack kernel/lib/dump_stack.c:15 [<ffffffff8292049d>] dump_stack+0x6f/0xa2 kernel/lib/dump_stack.c:50 [<ffffffff816f2054>] print_trailer+0xf4/0x150 kernel/mm/slub.c:654 [<ffffffff816f875f>] object_err+0x2f/0x40 kernel/mm/slub.c:661 [< inline >] print_address_description kernel/mm/kasan/report.c:138 [<ffffffff816fb0c5>] kasan_report_error+0x215/0x530 kernel/mm/kasan/report.c:236 [< inline >] kasan_report kernel/mm/kasan/report.c:259 [<ffffffff816fb4de>] __asan_report_load8_noabort+0x3e/0x40 kernel/mm/kasan/report.c:280 [< inline >] ? ppp_pernet kernel/include/linux/compiler.h:218 [<ffffffff83ad71b2>] ? ppp_unregister_channel+0x372/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392 [< inline >] ppp_pernet kernel/include/linux/compiler.h:218 [<ffffffff83ad71b2>] ppp_unregister_channel+0x372/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392 [< inline >] ? ppp_pernet kernel/drivers/net/ppp/ppp_generic.c:293 [<ffffffff83ad6f26>] ? ppp_unregister_channel+0xe6/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392 [<ffffffff83ae18f3>] ppp_asynctty_close+0xa3/0x130 kernel/drivers/net/ppp/ppp_async.c:241 [<ffffffff83ae1850>] ? async_lcp_peek+0x5b0/0x5b0 kernel/drivers/net/ppp/ppp_async.c:1000 [<ffffffff82c33239>] tty_ldisc_close.isra.1+0x99/0xe0 kernel/drivers/tty/tty_ldisc.c:478 [<ffffffff82c332c0>] tty_ldisc_kill+0x40/0x170 kernel/drivers/tty/tty_ldisc.c:744 [<ffffffff82c34943>] tty_ldisc_release+0x1b3/0x260 kernel/drivers/tty/tty_ldisc.c:772 [<ffffffff82c1ef21>] tty_release+0xac1/0x13e0 kernel/drivers/tty/tty_io.c:1901 [<ffffffff82c1e460>] ? release_tty+0x320/0x320 kernel/drivers/tty/tty_io.c:1688 [<ffffffff8174de36>] __fput+0x236/0x780 kernel/fs/file_table.c:208 [<ffffffff8174e405>] ____fput+0x15/0x20 kernel/fs/file_table.c:244 [<ffffffff813595ab>] task_work_run+0x16b/0x200 kernel/kernel/task_work.c:115 [< inline >] exit_task_work kernel/include/linux/task_work.h:21 [<ffffffff81307105>] do_exit+0x8b5/0x2c60 kernel/kernel/exit.c:750 [<ffffffff813fdd20>] ? debug_check_no_locks_freed+0x290/0x290 kernel/kernel/locking/lockdep.c:4123 [<ffffffff81306850>] ? mm_update_next_owner+0x6f0/0x6f0 kernel/kernel/exit.c:357 [<ffffffff813215e6>] ? __dequeue_signal+0x136/0x470 kernel/kernel/signal.c:550 [<ffffffff8132067b>] ? recalc_sigpending_tsk+0x13b/0x180 kernel/kernel/signal.c:145 [<ffffffff81309628>] do_group_exit+0x108/0x330 kernel/kernel/exit.c:880 [<ffffffff8132b9d4>] get_signal+0x5e4/0x14f0 kernel/kernel/signal.c:2307 [< inline >] ? kretprobe_table_lock kernel/kernel/kprobes.c:1113 [<ffffffff8151d355>] ? kprobe_flush_task+0xb5/0x450 kernel/kernel/kprobes.c:1158 [<ffffffff8115f7d3>] do_signal+0x83/0x1c90 kernel/arch/x86/kernel/signal.c:712 [<ffffffff8151d2a0>] ? recycle_rp_inst+0x310/0x310 kernel/include/linux/list.h:655 [<ffffffff8115f750>] ? setup_sigcontext+0x780/0x780 kernel/arch/x86/kernel/signal.c:165 [<ffffffff81380864>] ? finish_task_switch+0x424/0x5f0 kernel/kernel/sched/core.c:2692 [< inline >] ? finish_lock_switch kernel/kernel/sched/sched.h:1099 [<ffffffff81380560>] ? finish_task_switch+0x120/0x5f0 kernel/kernel/sched/core.c:2678 [< inline >] ? context_switch kernel/kernel/sched/core.c:2807 [<ffffffff85d794e9>] ? __schedule+0x919/0x1bd0 kernel/kernel/sched/core.c:3283 [<ffffffff81003901>] exit_to_usermode_loop+0xf1/0x1a0 kernel/arch/x86/entry/common.c:247 [< inline >] prepare_exit_to_usermode kernel/arch/x86/entry/common.c:282 [<ffffffff810062ef>] syscall_return_slowpath+0x19f/0x210 kernel/arch/x86/entry/common.c:344 [<ffffffff85d88022>] int_ret_from_sys_call+0x25/0x9f kernel/arch/x86/entry/entry_64.S:281 Memory state around the buggy address: ffff880064e21680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff880064e21700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff880064e21780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff880064e21800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff880064e21880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Bug:28979703 Fixes: 273ec51d ("net: ppp_generic - introduce net-namespace functionality v2") Reported-by:Baozeng Ding <sploving1@gmail.com> Signed-off-by:
Guillaume Nault <g.nault@alphalink.fr> Reviewed-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
-
David Howells authored
(cherry-pick from commit 0d62e9dd) If the ASN.1 decoder is asked to parse a sequence of objects, non-optional matches get skipped if there's no more data to be had rather than a data-overrun error being reported. This is due to the code segment that decides whether to skip optional matches (ie. matches that could get ignored because an element is marked OPTIONAL in the grammar) due to a lack of data also skips non-optional elements if the data pointer has reached the end of the buffer. This can be tested with the data decoder for the new RSA akcipher algorithm that takes three non-optional integers. Currently, it skips the last integer if there is insufficient data. Without the fix, #defining DEBUG in asn1_decoder.c will show something like: next_op: pc=0/13 dp=0/270 C=0 J=0 - match? 30 30 00 - TAG: 30 266 CONS next_op: pc=2/13 dp=4/270 C=1 J=0 - match? 02 02 00 - TAG: 02 257 - LEAF: 257 next_op: pc=5/13 dp=265/270 C=1 J=0 - match? 02 02 00 - TAG: 02 3 - LEAF: 3 next_op: pc=8/13 dp=270/270 C=1 J=0 next_op: pc=11/13 dp=270/270 C=1 J=0 - end cons t=4 dp=270 l=270/270 The next_op line for pc=8/13 should be followed by a match line. This is not exploitable for X.509 certificates by means of shortening the message and fixing up the ASN.1 CONS tags because: (1) The relevant records being built up are cleared before use. (2) If the message is shortened sufficiently to remove the public key, the ASN.1 parse of the RSA key will fail quickly due to a lack of data. (3) Extracted signature data is either turned into MPIs (which cope with a 0 length) or is simpler integers specifying algoritms and suchlike (which can validly be 0); and (4) The AKID and SKID extensions are optional and their removal is handled without risking passing a NULL to asymmetric_key_generate_id(). (5) If the certificate is truncated sufficiently to remove the subject, issuer or serialNumber then the ASN.1 decoder will fail with a 'Cons stack underflow' return. This is not exploitable for PKCS#7 messages by means of removal of elements from such a message from the tail end of a sequence: (1) Any shortened X.509 certs embedded in the PKCS#7 message are survivable as detailed above. (2) The message digest content isn't used if it shows a NULL pointer, similarly, the authattrs aren't used if that shows a NULL pointer. (3) A missing signature results in a NULL MPI - which the MPI routines deal with. (4) If data is NULL, it is expected that the message has detached content and that is handled appropriately. (5) If the serialNumber is excised, the unconditional action associated with it will pick up the containing SEQUENCE instead, so no NULL pointer will be seen here. If both the issuer and the serialNumber are excised, the ASN.1 decode will fail with an 'Unexpected tag' return. In either case, there's no way to get to asymmetric_key_generate_id() with a NULL pointer. (6) Other fields are decoded to simple integers. Shortening the message to omit an algorithm ID field will cause checks on this to fail early in the verification process. This can also be tested by snipping objects off of the end of the ASN.1 stream such that mandatory tags are removed - or even from the end of internal SEQUENCEs. If any mandatory tag is missing, the error EBADMSG *should* be produced. Without this patch ERANGE or ENOPKG might be produced or the parse may apparently succeed, perhaps with ENOKEY or EKEYREJECTED being produced later, depending on what gets snipped. Just snipping off the final BIT_STRING or OCTET_STRING from either sample should be a start since both are mandatory and neither will cause an EBADMSG without the patches Reported-by:
-
Yueyao (Nathan) Zhu authored
Bug: 28744625 usbnet_link_change will call schedule_work and should be avoided if bind is failing. Otherwise we will end up with scheduled work referring to a netdev which has gone away. Instead of making the call conditional, we can just defer it to usbnet_probe, using the driver_info flag made for this purpose. (cherry picked from commit 4d06dd537f95683aba3651098ae288b7cbff8274) Bug: 31554728 Change-Id: I30a0b5858a4d7b0f2574175f40d3095891ea7751 Tracked-On: https://jira01.devtools.intel.com/browse/AW-1795 Signed-off-by:
-
Oliver Neukum authored
Bug: 28744625 In case bind() works, but a later error forces bailing in probe() in error cases work and a timer may be scheduled. They must be killed. This fixes an error case related to the double free reported in http://www.spinics.net/lists/netdev/msg367669.html and needs to go on top of Linus' fix to cdc-ncm. (cherry picked from commit 1666984c8625b3db19a9abc298931d35ab7bc64b) Bug: 31554728 Change-Id: Iec7d659d903eab0adee1c91cb8f5b84e9775c09d Tracked-On: https://jira01.devtools.intel.com/browse/AW-1795 Signed-off-by:
Oliver Neukum <ONeukum@suse.com> Signed-off-by:
Yueyao (Nathan) Zhu <yueyao@google.com> Signed-off-by:
-
- Sep 21, 2016
-
-
Florian Westphal authored
Ben Hawkes says: In the mark_source_chains function (net/ipv4/netfilter/ip_tables.c) it is possible for a user-supplied ipt_entry structure to have a large next_offset field. This field is not bounds checked prior to writing a counter value at the supplied offset. Problem is that mark_source_chains should not have been called -- the rule doesn't have a next entry, so its supposed to return an absolute verdict of either ACCEPT or DROP. However, the function conditional() doesn't work as the name implies. It only checks that the rule is using wildcard address matching. However, an unconditional rule must also not be using any matches (no -m args). The underflow validator only checked the addresses, therefore passing the 'unconditional absolute verdict' test, while mark_source_chains also tested for presence of matches, and thus proceeeded to the next (not-existent) rule. Unify this so that all the callers have same idea of 'unconditional rule'. Bug: 28940694 Reported-by:
Ben Hawkes <hawkes@google.com> Signed-off-by:
-
Rainer Weikusat authored
Rainer Weikusat <rweikusat@mobileactivedefense.com> writes: An AF_UNIX datagram socket being the client in an n:1 association with some server socket is only allowed to send messages to the server if the receive queue of this socket contains at most sk_max_ack_backlog datagrams. This implies that prospective writers might be forced to go to sleep despite none of the message presently enqueued on the server receive queue were sent by them. In order to ensure that these will be woken up once space becomes again available, the present unix_dgram_poll routine does a second sock_poll_wait call with the peer_wait wait queue of the server socket as queue argument (unix_dgram_recvmsg does a wake up on this queue after a datagram was received). This is inherently problematic because the server socket is only guaranteed to remain alive for as long as the client still holds a reference to it. In case the connection is dissolved via connect or by the dead peer detection logic in unix_dgram_sendmsg, the server socket may be freed despite "the polling mechanism" (in particular, epoll) still has a pointer to the corresponding peer_wait queue. There's no way to forcibly deregister a wait queue with epoll. Based on an idea by Jason Baron, the patch below changes the code such that a wait_queue_t belonging to the client socket is enqueued on the peer_wait queue of the server whenever the peer receive queue full condition is detected by either a sendmsg or a poll. A wake up on the peer queue is then relayed to the ordinary wait queue of the client socket via wake function. The connection to the peer wait queue is again dissolved if either a wake up is about to be relayed or the client socket reconnects or a dead peer is detected or the client socket is itself closed. This enables removing the second sock_poll_wait from unix_dgram_poll, thus avoiding the use-after-free, while still ensuring that no blocked writer sleeps forever. Signed-off-by:
Rainer Weikusat <rweikusat@mobileactivedefense.com> Fixes: ec0d215f ("af_unix: fix 'poll for write'/connected DGRAM sockets") Reviewed-by:
Jason Baron <jbaron@akamai.com> Signed-off-by:
Aarthi Thiruvengadam <athiru@google.com> Bug: 31554728 Change-Id: Ia374ee061195088f8c777940baa75cedbe897f4e Tracked-On: https://jira01.devtools.intel.com/browse/AW-1795 Signed-off-by:
-
Yueyao (Nathan) Zhu authored
Bug: 29823941 If __key_link_begin() failed then "edit" would be uninitialized. I've added a check to fix that. This allows a random user to crash the kernel, though it's quite difficult to achieve. There are three ways it can be done as the user would have to cause an error to occur in __key_link(): (1) Cause the kernel to run out of memory. In practice, this is difficult to achieve without ENOMEM cropping up elsewhere and aborting the attempt. (2) Revoke the destination keyring between the keyring ID being looked up and it being tested for revocation. In practice, this is difficult to time correctly because the KEYCTL_REJECT function can only be used from the request-key upcall process. Further, users can only make use of what's in /sbin/request-key.conf, though this does including a rejection debugging test - which means that the destination keyring has to be the caller's session keyring in practice. (3) Have just enough key quota available to create a key, a new session keyring for the upcall and a link in the session keyring, but not then sufficient quota to create a link in the nominated destination keyring so that it fails with EDQUOT. The bug can be triggered using option (3) above using something like the following: echo 80 >/proc/sys/kernel/keys/root_maxbytes keyctl request2 user debug:fred negate @t The above sets the quota to something much lower (80) to make the bug easier to trigger, but this is dependent on the system. Note also that the name of the keyring created contains a random number that may be between 1 and 10 characters in size, so may throw the test off by changing the amount of quota used. Assuming the failure occurs, something like the following will be seen: kfree_debugcheck: out of range ptr 6b6b6b6b6b6b6b68h ------------[ cut here ]------------ kernel BUG at ../mm/slab.c:2821! ... RIP: 0010:[<ffffffff811600f9>] kfree_debugcheck+0x20/0x25 RSP: 0018:ffff8804014a7de8 EFLAGS: 00010092 RAX: 0000000000000034 RBX: 6b6b6b6b6b6b6b68 RCX: 0000000000000000 RDX: 0000000000040001 RSI: 00000000000000f6 RDI: 0000000000000300 RBP: ffff8804014a7df0 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8804014a7e68 R11: 0000000000000054 R12: 0000000000000202 R13: ffffffff81318a66 R14: 0000000000000000 R15: 0000000000000001 ... Call Trace: kfree+0xde/0x1bc assoc_array_cancel_edit+0x1f/0x36 __key_link_end+0x55/0x63 key_reject_and_link+0x124/0x155 keyctl_reject_key+0xb6/0xe0 keyctl_negate_key+0x10/0x12 SyS_keyctl+0x9f/0xe7 do_syscall_64+0x63/0x13a entry_SYSCALL64_slow_path+0x25/0x25 Fixes: f70e2e06 ('KEYS: Do preallocation for __key_link()') Signed-off-by:Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
- Sep 13, 2016
-
-
Kangjie Lu authored
The stack object “map” has a total size of 32 bytes. Its last 4 bytes are padding generated by compiler. These padding bytes are not initialized and sent out via “nla_put”. Bug: 30609570 Change-Id: I2a6f83631853e395f2e618faaebf7e3d5620fbff Tracked-On: https://jira01.devtools.intel.com/browse/AW-1818 Signed-off-by:
Kangjie Lu <kjlu@gatech.edu> Signed-off-by:
-
Erwan Mahe authored
An elevation of privilege vulnerability in the ION driver could enable a local malicious application to execute arbitrary code within the context of the kernel. This issue is rated as High because it first requires compromising a privileged process. Bug: 30609570 Change-Id: I550acbf7bb641e3d044dbbdebb77ee77df30573c Tracked-On: https://jira01.devtools.intel.com/browse/AW-1818 Signed-off-by:
-
Kangjie Lu authored
The stack object “r1” has a total size of 32 bytes. Its field “event” and “val” both contain 4 bytes padding. These 8 bytes padding bytes are sent to user without being initialized. Bug: 30609570 Change-Id: I3c04e39cdc47e70817d93dfe5d17ac6d228a0dc7 Tracked-On: https://jira01.devtools.intel.com/browse/AW-1818 Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Kangjie Lu authored
The stack object “r1” has a total size of 32 bytes. Its field “event” and “val” both contain 4 bytes padding. These 8 bytes padding bytes are sent to user without being initialized. Bug: 30609570 Change-Id: I633f3603c00a89e7fa71862d840199e9eeeaf22e Tracked-On: https://jira01.devtools.intel.com/browse/AW-1818 Signed-off-by:
-
Kangjie Lu authored
The stack object “tread” has a total size of 32 bytes. Its field “event” and “val” both contain 4 bytes padding. These 8 bytes padding bytes are sent to user without being initialized. Bug: 30609570 Change-Id: Ic18aa03a7c8726ff9ed937659088fc3b4a75f6ce Tracked-On: https://jira01.devtools.intel.com/browse/AW-1818 Signed-off-by:
-
Kangjie Lu authored
The stack object “ci” has a total size of 8 bytes. Its last 3 bytes are padding bytes which are not initialized and leaked to userland via “copy_to_user”. Bug: 30609570 Change-Id: I6714f9732c1e797be262f5f92d27d3d3513bf5d9 Tracked-On: https://jira01.devtools.intel.com/browse/AW-1818 Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Mekala Natarajan authored
Bug: 30609570 Change-Id: I1b1384d5aed35a0c5f7618373274de77c54a6fea Tracked-On: https://jira01.devtools.intel.com/browse/AW-1818 Signed-off-by:
-
Jeff Vander Stoep authored
Add: CONFIG_SECURITY_PERF_EVENTS_RESTRICT=y to android-base.cfg The kernel.perf_event_paranoid sysctl is set to 3 by default. No unprivileged use of the perf_event_open syscall will be permitted unless it is changed. Bug: 30609570 Change-Id: Ie7512259150e146d8e382dc64d40e8faaa438917 Tracked-On: https://jira01.devtools.intel.com/browse/AW-1818 Signed-off-by:
-
Erwan Mahe authored
When kernel.perf_event_open is set to 3 (or greater), disallow all access to performance events by users without CAP_SYS_ADMIN. Add a Kconfig symbol CONFIG_SECURITY_PERF_EVENTS_RESTRICT that makes this value the default. This is based on a similar feature in grsecurity (CONFIG_GRKERNSEC_PERF_HARDEN). This version doesn't include making the variable read-only. It also allows enabling further restriction at run-time regardless of whether the default is changed. https://lkml.org/lkml/2016/1/11/587 Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Bug: 30609570 Change-Id: Ie120da23fbfe5ca260cab69c1dffb191a01600c6 Tracked-On: https://jira01.devtools.intel.com/browse/AW-1818 Signed-off-by:
-
Ben Hutchings authored
perf_event_paranoid was only documented in source code and a perf error message. Copy the documentation from the error message to Documentation/sysctl/kernel.txt. Signed-off-by:
-
