{"push_id":1202032821,"size":3,"distinct_size":3,"ref":"refs/heads/aosp-common/android-3.18","head":"0433cb108bc229a51dc63e411f3f9e34158b5ca6","before":"a0a6fa706d7c3439646301a0d2eeb07646364e39","commits":[{"sha":"3faa33e5b07b973aaf133b005eb5d5dd5d7232f2","author":{"name":"Florian Westphal","email":"dbfaf6a80dfd937969ef4cfe4989863cfe354fce@strlen.de"},"message":"UPSTREAM: netfilter: x_tables: fix unconditional helper\n\n(cherry pick from commit 54d83fc74aa9ec72794373cb47432c5f7fb1a309)\n\nBen Hawkes says:\n\n In the mark_source_chains function (net/ipv4/netfilter/ip_tables.c) it\n is possible for a user-supplied ipt_entry structure to have a large\n next_offset field. This field is not bounds checked prior to writing a\n counter value at the supplied offset.\n\nProblem is that mark_source_chains should not have been called --\nthe rule doesn't have a next entry, so its supposed to return\nan absolute verdict of either ACCEPT or DROP.\n\nHowever, the function conditional() doesn't work as the name implies.\nIt only checks that the rule is using wildcard address matching.\n\nHowever, an unconditional rule must also not be using any matches\n(no -m args).\n\nThe underflow validator only checked the addresses, therefore\npassing the 'unconditional absolute verdict' test, while\nmark_source_chains also tested for presence of matches, and thus\nproceeeded to the next (not-existent) rule.\n\nUnify this so that all the callers have same idea of 'unconditional rule'.\n\nReported-by: Ben Hawkes <hawkes@google.com>\nSigned-off-by: Florian Westphal <fw@strlen.de>\nSigned-off-by: Pablo Neira Ayuso <pablo@netfilter.org>\nChange-Id: I47ec0713ac563ac244200c7b2c54f09a91aceabc\nBug: 28940694","distinct":true,"url":"https://api.github.com/repos/olivieer/kernel_msm/commits/3faa33e5b07b973aaf133b005eb5d5dd5d7232f2"},{"sha":"2627cc9ff5cbc6c6bae8cdd7f870132d9b029805","author":{"name":"Eric Dumazet","email":"b3d77ad2db30f558882cc0c038be5a3cf96611f9@google.com"},"message":"BACKPORT: ipv6: tcp: add rcu locking in tcp_v6_send_synack()\n\n(cherry pick from commit 3e4006f0b86a5ae5eb0e8215f9a9e1db24506977)\n\nWhen first SYNACK is sent, we already hold rcu_read_lock(), but this\nis not true if a SYNACK is retransmitted, as a timer (soft) interrupt\ndoes not hold rcu_read_lock()\n\nFixes: 45f6fad84cc30 (\"ipv6: add complete rcu protection around np->opt\")\nReported-by: Dave Jones <davej@codemonkey.org.uk>\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\n\nFixes: Change-Id: I9654ba44a4a710a08f8b23bfd8205d205a95607c (\"BACKPORT:\nipv6: add complete rcu protection around np->opt\")\nSigned-off-by: Amit Pundir <amit.pundir@linaro.org>","distinct":true,"url":"https://api.github.com/repos/olivieer/kernel_msm/commits/2627cc9ff5cbc6c6bae8cdd7f870132d9b029805"},{"sha":"0433cb108bc229a51dc63e411f3f9e34158b5ca6","author":{"name":"Guillaume Nault","email":"3f2beb9890afcf959ec304431b991035a559d9bd@alphalink.fr"},"message":"UPSTREAM: ppp: take reference on channels netns\n\n(cherry pick from commit 1f461dcdd296eecedaffffc6bae2bfa90bd7eb89)\n\nLet channels hold a reference on their network namespace.\nSome channel types, like ppp_async and ppp_synctty, can have their\nuserspace controller running in a different namespace. Therefore they\ncan't rely on them to preclude their netns from being removed from\nunder them.\n\n==================================================================\nBUG: KASAN: use-after-free in ppp_unregister_channel+0x372/0x3a0 at\naddr ffff880064e217e0\nRead of size 8 by task syz-executor/11581\n=============================================================================\nBUG net_namespace (Not tainted): kasan: bad access detected\n-----------------------------------------------------------------------------\n\nDisabling lock debugging due to kernel taint\nINFO: Allocated in copy_net_ns+0x6b/0x1a0 age=92569 cpu=3 pid=6906\n[<      none      >] ___slab_alloc+0x4c7/0x500 kernel/mm/slub.c:2440\n[<      none      >] __slab_alloc+0x4c/0x90 kernel/mm/slub.c:2469\n[<     inline     >] slab_alloc_node kernel/mm/slub.c:2532\n[<     inline     >] slab_alloc kernel/mm/slub.c:2574\n[<      none      >] kmem_cache_alloc+0x23a/0x2b0 kernel/mm/slub.c:2579\n[<     inline     >] kmem_cache_zalloc kernel/include/linux/slab.h:597\n[<     inline     >] net_alloc kernel/net/core/net_namespace.c:325\n[<      none      >] copy_net_ns+0x6b/0x1a0 kernel/net/core/net_namespace.c:360\n[<      none      >] create_new_namespaces+0x2f6/0x610 kernel/kernel/nsproxy.c:95\n[<      none      >] copy_namespaces+0x297/0x320 kernel/kernel/nsproxy.c:150\n[<      none      >] copy_process.part.35+0x1bf4/0x5760 kernel/kernel/fork.c:1451\n[<     inline     >] copy_process kernel/kernel/fork.c:1274\n[<      none      >] _do_fork+0x1bc/0xcb0 kernel/kernel/fork.c:1723\n[<     inline     >] SYSC_clone kernel/kernel/fork.c:1832\n[<      none      >] SyS_clone+0x37/0x50 kernel/kernel/fork.c:1826\n[<      none      >] entry_SYSCALL_64_fastpath+0x16/0x7a kernel/arch/x86/entry/entry_64.S:185\n\nINFO: Freed in net_drop_ns+0x67/0x80 age=575 cpu=2 pid=2631\n[<      none      >] __slab_free+0x1fc/0x320 kernel/mm/slub.c:2650\n[<     inline     >] slab_free kernel/mm/slub.c:2805\n[<      none      >] kmem_cache_free+0x2a0/0x330 kernel/mm/slub.c:2814\n[<     inline     >] net_free kernel/net/core/net_namespace.c:341\n[<      none      >] net_drop_ns+0x67/0x80 kernel/net/core/net_namespace.c:348\n[<      none      >] cleanup_net+0x4e5/0x600 kernel/net/core/net_namespace.c:448\n[<      none      >] process_one_work+0x794/0x1440 kernel/kernel/workqueue.c:2036\n[<      none      >] worker_thread+0xdb/0xfc0 kernel/kernel/workqueue.c:2170\n[<      none      >] kthread+0x23f/0x2d0 kernel/drivers/block/aoe/aoecmd.c:1303\n[<      none      >] ret_from_fork+0x3f/0x70 kernel/arch/x86/entry/entry_64.S:468\nINFO: Slab 0xffffea0001938800 objects=3 used=0 fp=0xffff880064e20000\nflags=0x5fffc0000004080\nINFO: Object 0xffff880064e20000 @offset=0 fp=0xffff880064e24200\n\nCPU: 1 PID: 11581 Comm: syz-executor Tainted: G    B           4.4.0+\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\nrel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014\n 00000000ffffffff ffff8800662c7790 ffffffff8292049d ffff88003e36a300\n ffff880064e20000 ffff880064e20000 ffff8800662c77c0 ffffffff816f2054\n ffff88003e36a300 ffffea0001938800 ffff880064e20000 0000000000000000\nCall Trace:\n [<     inline     >] __dump_stack kernel/lib/dump_stack.c:15\n [<ffffffff8292049d>] dump_stack+0x6f/0xa2 kernel/lib/dump_stack.c:50\n [<ffffffff816f2054>] print_trailer+0xf4/0x150 kernel/mm/slub.c:654\n [<ffffffff816f875f>] object_err+0x2f/0x40 kernel/mm/slub.c:661\n [<     inline     >] print_address_description kernel/mm/kasan/report.c:138\n [<ffffffff816fb0c5>] kasan_report_error+0x215/0x530 kernel/mm/kasan/report.c:236\n [<     inline     >] kasan_report kernel/mm/kasan/report.c:259\n [<ffffffff816fb4de>] __asan_report_load8_noabort+0x3e/0x40 kernel/mm/kasan/report.c:280\n [<     inline     >] ? ppp_pernet kernel/include/linux/compiler.h:218\n [<ffffffff83ad71b2>] ? ppp_unregister_channel+0x372/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392\n [<     inline     >] ppp_pernet kernel/include/linux/compiler.h:218\n [<ffffffff83ad71b2>] ppp_unregister_channel+0x372/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392\n [<     inline     >] ? ppp_pernet kernel/drivers/net/ppp/ppp_generic.c:293\n [<ffffffff83ad6f26>] ? ppp_unregister_channel+0xe6/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392\n [<ffffffff83ae18f3>] ppp_asynctty_close+0xa3/0x130 kernel/drivers/net/ppp/ppp_async.c:241\n [<ffffffff83ae1850>] ? async_lcp_peek+0x5b0/0x5b0 kernel/drivers/net/ppp/ppp_async.c:1000\n [<ffffffff82c33239>] tty_ldisc_close.isra.1+0x99/0xe0 kernel/drivers/tty/tty_ldisc.c:478\n [<ffffffff82c332c0>] tty_ldisc_kill+0x40/0x170 kernel/drivers/tty/tty_ldisc.c:744\n [<ffffffff82c34943>] tty_ldisc_release+0x1b3/0x260 kernel/drivers/tty/tty_ldisc.c:772\n [<ffffffff82c1ef21>] tty_release+0xac1/0x13e0 kernel/drivers/tty/tty_io.c:1901\n [<ffffffff82c1e460>] ? release_tty+0x320/0x320 kernel/drivers/tty/tty_io.c:1688\n [<ffffffff8174de36>] __fput+0x236/0x780 kernel/fs/file_table.c:208\n [<ffffffff8174e405>] ____fput+0x15/0x20 kernel/fs/file_table.c:244\n [<ffffffff813595ab>] task_work_run+0x16b/0x200 kernel/kernel/task_work.c:115\n [<     inline     >] exit_task_work kernel/include/linux/task_work.h:21\n [<ffffffff81307105>] do_exit+0x8b5/0x2c60 kernel/kernel/exit.c:750\n [<ffffffff813fdd20>] ? debug_check_no_locks_freed+0x290/0x290 kernel/kernel/locking/lockdep.c:4123\n [<ffffffff81306850>] ? mm_update_next_owner+0x6f0/0x6f0 kernel/kernel/exit.c:357\n [<ffffffff813215e6>] ? __dequeue_signal+0x136/0x470 kernel/kernel/signal.c:550\n [<ffffffff8132067b>] ? recalc_sigpending_tsk+0x13b/0x180 kernel/kernel/signal.c:145\n [<ffffffff81309628>] do_group_exit+0x108/0x330 kernel/kernel/exit.c:880\n [<ffffffff8132b9d4>] get_signal+0x5e4/0x14f0 kernel/kernel/signal.c:2307\n [<     inline     >] ? kretprobe_table_lock kernel/kernel/kprobes.c:1113\n [<ffffffff8151d355>] ? kprobe_flush_task+0xb5/0x450 kernel/kernel/kprobes.c:1158\n [<ffffffff8115f7d3>] do_signal+0x83/0x1c90 kernel/arch/x86/kernel/signal.c:712\n [<ffffffff8151d2a0>] ? recycle_rp_inst+0x310/0x310 kernel/include/linux/list.h:655\n [<ffffffff8115f750>] ? setup_sigcontext+0x780/0x780 kernel/arch/x86/kernel/signal.c:165\n [<ffffffff81380864>] ? finish_task_switch+0x424/0x5f0 kernel/kernel/sched/core.c:2692\n [<     inline     >] ? finish_lock_switch kernel/kernel/sched/sched.h:1099\n [<ffffffff81380560>] ? finish_task_switch+0x120/0x5f0 kernel/kernel/sched/core.c:2678\n [<     inline     >] ? context_switch kernel/kernel/sched/core.c:2807\n [<ffffffff85d794e9>] ? __schedule+0x919/0x1bd0 kernel/kernel/sched/core.c:3283\n [<ffffffff81003901>] exit_to_usermode_loop+0xf1/0x1a0 kernel/arch/x86/entry/common.c:247\n [<     inline     >] prepare_exit_to_usermode kernel/arch/x86/entry/common.c:282\n [<ffffffff810062ef>] syscall_return_slowpath+0x19f/0x210 kernel/arch/x86/entry/common.c:344\n [<ffffffff85d88022>] int_ret_from_sys_call+0x25/0x9f kernel/arch/x86/entry/entry_64.S:281\nMemory state around the buggy address:\n ffff880064e21680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ffff880064e21700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n>ffff880064e21780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n                                                       ^\n ffff880064e21800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ffff880064e21880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n==================================================================\n\nFixes: 273ec51dd7ce (\"net: ppp_generic - introduce net-namespace functionality v2\")\nReported-by: Baozeng Ding <sploving1@gmail.com>\nSigned-off-by: Guillaume Nault <g.nault@alphalink.fr>\nReviewed-by: Cyrill Gorcunov <gorcunov@openvz.org>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nChange-Id: Iee0015eca5bd181954bb4896a3720f7549c5ed0b\nBug: 28979703","distinct":true,"url":"https://api.github.com/repos/olivieer/kernel_msm/commits/0433cb108bc229a51dc63e411f3f9e34158b5ca6"}]}
{"actor":{"display_login":"pepe-bot"}}