- 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:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit 6fd99094) Bug: 31554728 Change-Id: I24ee5723e4bcb3fbdbf4308531ab58e9ff215e82 Tracked-On: https://jira01.devtools.intel.com/browse/AW-1795 Signed-off-by:
Victor Tasayco Loarte <victorx.tasayco.loarte@intel.com>
-
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:
Eric Dumazet <edumazet@google.com> Cc: Willem de Bruijn <willemb@google.com> 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:
Linus Torvalds <torvalds@linux-foundation.org> Bug: 29444228 Bug: 31554728 Change-Id: I4af443d43bdc4bc7681dad1f42a56aa4c1c16582 Tracked-On: https://jira01.devtools.intel.com/browse/AW-1795 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:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
David Howells <dhowells@redhat.com> Tested-by:
David Woodhouse <David.Woodhouse@intel.com> Bug: 31554728 Change-Id: Ib87d197e44b265b291fb6735223a751fb4858d04 Tracked-On: https://jira01.devtools.intel.com/browse/AW-1795 Signed-off-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 <erwan.mahe@intel.com>
-
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:
Arnaldo Carvalho de Melo <acme@redhat.com> Bug: 30609570 Change-Id: I13e73cfb2ad761c94762d0c8196df7725abdf5c5 Tracked-On: https://jira01.devtools.intel.com/browse/AW-1818 Signed-off-by:
-
Linus Torvalds authored
We had for some reason overlooked the AIO interface, and it didn't use the proper rw_verify_area() helper function that checks (for example) mandatory locking on the file, and that the size of the access doesn't cause us to overflow the provided offset limits etc. Instead, AIO did just the security_file_permission() thing (that rw_verify_area() also does) directly. This fixes it to do all the proper helper functions, which not only means that now mandatory file locking works with AIO too, we can actually remove lines of code. Bug: 30609570 Change-Id: I3ad4b846f19c60cb12224020cd20c9ee7c761f23 Tracked-On: https://jira01.devtools.intel.com/browse/AW-1818 Reported-by:
Manish Honap <manish_honap_vit@yahoo.co.in> Cc: stable@vger.kernel.org Signed-off-by:
-
Dan Carpenter authored
I previously added an integer overflow check here but looking at it now, it's still buggy. The bug happens in snd_compr_allocate_buffer(). We multiply ".fragments" and ".fragment_size" and that doesn't overflow but then we save it in an unsigned int so it truncates the high bits away and we allocate a smaller than expected size. Bug: 30609570 Change-Id: I0823fae32063a64d677f504de6686f99a233acdb Tracked-On: https://jira01.devtools.intel.com/browse/AW-1818 Fixes: b35cc822 ('ALSA: compress_core: integer overflow in snd_compr_allocate_buffer()') Signed-off-by:
-
Takashi Iwai authored
ALSA timer ioctls have an open race and this may lead to a use-after-free of timer instance object. A simplistic fix is to make each ioctl exclusive. We have already tread_sem for controlling the tread, and extend this as a global mutex to be applied to each ioctl. The downside is, of course, the worse concurrency. But these ioctls aren't to be parallel accessible, in anyway, so it should be fine to serialize there. Bug: 30609570 Change-Id: I8fd084a0535cc39b3e4eebe924adccc3c0b8d732 Tracked-On: https://jira01.devtools.intel.com/browse/AW-1818 Reported-by:
Dmitry Vyukov <dvyukov@google.com> Tested-by:
-
Takashi Iwai authored
ALSA sequencer code has an open race between the timer setup ioctl and the close of the client. This was triggered by syzkaller fuzzer, and a use-after-free was caught there as a result. This patch papers over it by adding a proper queue->timer_mutex lock around the timer-related calls in the relevant code path. Bug: 30609570 Change-Id: I0fa8940a4f15a4f2a4b2a288e0b728fb0d925ec6 Tracked-On: https://jira01.devtools.intel.com/browse/AW-1818 Reported-by:
-
- Sep 12, 2016
-
-
Hector Marco-Gisbert authored
Currently on i386 and on X86_64 when emulating X86_32 in legacy mode, only the stack and the executable are randomized but not other mmapped files (libraries, vDSO, etc.). This patch enables randomization for the libraries, vDSO and mmap requests on i386 and in X86_32 in legacy mode. By default on i386 there are 8 bits for the randomization of the libraries, vDSO and mmaps which only uses 1MB of VA. This patch preserves the original randomness, using 1MB of VA out of 3GB or 4GB. We think that 1MB out of 3GB is not a big cost for having the ASLR. The first obvious security benefit is that all objects are randomized (not only the stack and the executable) in legacy mode which highly increases the ASLR effectiveness, otherwise the attackers may use these non-randomized areas. But also sensitive setuid/setgid applications are more secure because currently, attackers can disable the randomization of these applications by setting the ulimit stack to "unlimited". This is a very old and widely known trick to disable the ASLR in i386 which has been allowed for too long. Another trick used to disable the ASLR was to set the ADDR_NO_RANDOMIZE personality flag, but fortunately this doesn't work on setuid/setgid applications because there is security checks which clear Security-relevant flags. This patch always randomizes the mmap_legacy_base address, removing the possibility to disable the ASLR by setting the stack to "unlimited". Bug: 30609570 Change-Id: Idbea7473e2f0713b8ae126c9de6de38ab0dac3f4 Tracked-On: https://jira01.devtools.intel.com/browse/AW-1818 Signed-off-by:
Hector Marco-Gisbert <hecmargi@upv.es> Acked-by:
Ismael Ripoll Ripoll <iripoll@upv.es> Acked-by:
Kees Cook <keescook@chromium.org> Acked-by:
Arjan van de Ven <arjan@linux.intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: akpm@linux-foundation.org Cc: kees Cook <keescook@chromium.org> Link: http://lkml.kernel.org/r/1457639460-5242-1-git-send-email-hecmargi@upv.es Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
- Aug 16, 2016
-
-
Julie Regairaz authored
This patch is to downgrade SDIO host controller from 3.0 version to 2.0 Version to force registering the wifi chip as a 2.0 SDIO HW since it is advertising that it's 3.0 while the datasheet shows that it only supports 2.0, know that this didn't cause an issue with CDP platform, but with Shasta, it leads to have WIFI chip not correctly probed. Change-Id: I015123c8899263f9b505cf1c0ce86155f794754d Tracked-On: https://jira01.devtools.intel.com/browse/AW-181 Signed-off-by:
Julie Regairaz <julie.regairaz@intel.com> Signed-off-by:
Amr BEN ABDESSALEM <amrx.ben.abdessalem@intel.com> Reviewed-on: https://android.intel.com/489688 Reviewed-by:
jenkins_ndg <jenkins_ndg@intel.com> Reviewed-by:
Jarzmik, Robert <robert.jarzmik@intel.com>
-
Sophia Gong authored
At each display power on, flip panel and DC frame buffer from one direction to the other (0°->180° and 180°->0°). Change-Id: I273852d2147f272fad85f9ffaf78afd1dc7d1410 Tracked-On: https://jira.ndg.intel.com/browse/SUS-163 Signed-off-by:
Sophia Gong <sophia.gong@intel.com> Signed-off-by:
Alexandre Ledentec <alexandrex.ledentec@intel.com> Reviewed-on: https://android.intel.com/521188 Reviewed-by:
-
- Jul 21, 2016
-
-
Saadi Maalem authored
Bug: 28447556 Change-Id: I3916c50903fe7d16f28f28d4b4360f1205e596ef Tracked-On: https://jira01.devtools.intel.com/browse/AW-1173 Signed-off-by:
Saadi Maalem <saadi.maalem@intel.com>
-
Saadi Maalem authored
Bug: 27532522 Change-Id: Ia0967c5a070534f91c2fea858403486c84bd6ec2 Tracked-On: https://jira01.devtools.intel.com/browse/AW-1173 Signed-off-by:
-
Greg Kroah-Hartman authored
commit ff19ac8f upstream In Linus's tree, the iovec code has been reworked massively, but in older kernels the AIO layer should be checking this before passing the request on to other layers. Many thanks to Ben Hawkes of Google Project Zero for pointing out the issue. Bug: 28588279 Reported-by:
Benjamin LaHaise <bcrl@kvack.org> Tested-by:
Willy Tarreau <w@1wt.eu> [backported to 3.10 - willy] Signed-off-by:
Greg Kroah-Hartman <gregkh@google.com> Change-Id: I409982523282bcff0eacb8b4285670abe9c90793
-
Alan Stern authored
Commit 8520f380 ("USB: change hub initialization sleeps to delayed_work") changed the hub_activate() routine to make part of it run in a workqueue. However, the commit failed to take a reference to the usb_hub structure or to lock the hub interface while doing so. As a result, if a hub is plugged in and quickly unplugged before the work routine can run, the routine will try to access memory that has been deallocated. Or, if the hub is unplugged while the routine is running, the memory may be deallocated while it is in active use. This patch fixes the problem by taking a reference to the usb_hub at the start of hub_activate() and releasing it at the end (when the work is finished), and by locking the hub interface while the work routine is running. It also adds a check at the start of the routine to see if the hub has already been disconnected, in which nothing should be done. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reported-by:
Alexandru Cornea <alexandru.cornea@intel.com> Tested-by:
-
Mark Salyzyn authored
(cherry pick from commit 179448bfe4cd201e98e728391c6b01b25c849fe8) This patch adds a max block check for get_data_block_bmap. Trinity test program will send a block number as parameter into ioctl_fibmap, which will be used in get_node_path(), when the block number large than f2fs max blocks, it will trigger kernel bug. Signed-off-by:
Yunlei He <heyunlei@huawei.com> Signed-off-by:
Xue Liu <liuxueliu.liu@huawei.com> [Jaegeuk Kim: fix missing condition, pointed by Chao Yu] Signed-off-by:
Jaegeuk Kim <jaegeuk@kernel.org> Bug: 28271368 Change-Id: Ia5acae04522993d5b60a0bcb5ccc184c66532be8
-
Mohamad Ayyash authored
BUG: 27577101 BUG: 27532522 Change-Id: I890831a72e5ad4485fdf30e51a146712b18052ed Signed-off-by:Mohamad Ayyash <mkayyash@google.com>
-
Peter Hurley authored
ioctl(TIOCGETD) retrieves the line discipline id directly from the ldisc because the line discipline id (c_line) in termios is untrustworthy; userspace may have set termios via ioctl(TCSETS*) without actually changing the line discipline via ioctl(TIOCSETD). However, directly accessing the current ldisc via tty->ldisc is unsafe; the ldisc ptr dereferenced may be stale if the line discipline is changing via ioctl(TIOCSETD) or hangup. Wait for the line discipline reference (just like read() or write()) to retrieve the "current" line discipline id. Change-Id: I3b451e3d0d9e90d9ecf838d10510118e9bcf8a7d Cc: <stable@vger.kernel.org> Signed-off-by:
Peter Hurley <peter@hurleysoftware.com> Signed-off-by:
-
Saadi Maalem authored
Ensure SSID length is checked unsigned maximum Bug: 26571522 Bug: 27241903 Change-Id: Ica71368b26d4a6036396d92cb372d69c79e497cc Tracked-On: https://jira01.devtools.intel.com/browse/AW-1173 Signed-off-by:
Mark Salyzyn <salyzyn@google.com> Signed-off-by:
-
