- 04 Jul, 2017 34 commits
-
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
Elena Reshetova <elena.reshetova@intel.com> Signed-off-by:
Hans Liljestrand <ishkamiel@gmail.com> Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
David Windsor <dwindsor@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
David S. Miller authored
The MPLS code now needs it. Fixes: 397fc9e5 ("mpls: route get support") Signed-off-by:
-
Roopa Prabhu authored
This patch adds RTM_GETROUTE doit handler for mpls routes. Input: RTA_DST - input label RTA_NEWDST - labels in packet for multipath selection By default the getroute handler returns matched nexthop label, via and oif With RTM_F_FIB_MATCH flag, full matched route is returned. example (with patched iproute2): $ip -f mpls route show 101 nexthop as to 102/103 via inet 172.16.2.2 dev virt1-2 nexthop as to 302/303 via inet 172.16.12.2 dev virt1-12 201 nexthop as to 202/203 via inet6 2001:db8:2::2 dev virt1-2 nexthop as to 402/403 via inet6 2001:db8:12::2 dev virt1-12 $ip -f mpls route get 103 RTNETLINK answers: Network is unreachable $ip -f mpls route get 101 101 as to 102/103 via inet 172.16.2.2 dev virt1-2 $ip -f mpls route get as to 302/303 101 101 as to 302/303 via inet 172.16.12.2 dev virt1-12 $ip -f mpls route get fibmatch 103 RTNETLINK answers: Network is unreachable $ip -f mpls route get fibmatch 101 101 nexthop as to 102/103 via inet 172.16.2.2 dev virt1-2 nexthop as to 302/303 via inet 172.16.12.2 dev virt1-12 Signed-off-by:Roopa Prabhu <roopa@cumulusnetworks.com> Signed-off-by:
-
Nikolay Aleksandrov authored
current code silently ignores change of port in the request message. This patch makes sure the port is modified and notification is sent to userspace. Fixes: cf6b8e1e ("bridge: add API to notify bridge driver of learned FBD on offloaded device") Signed-off-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by:
-
Jamal Hadi Salim authored
SYN-ACK responses on a server in response to a SYN from a client did not get the injected skb mark that was tagged on the SYN packet. Fixes: 84f39b08 ("net: support marking accepting TCP sockets") Reviewed-by:
Lorenzo Colitti <lorenzo@google.com> Signed-off-by:
Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by:
-
Sean Wang authored
Lockdep found an inconsistent lock state when mtk_get_stats64 is called in user context while NAPI updates MAC statistics in softirq. Use spin_trylock_bh/spin_unlock_bh fix following lockdep warning. [ 81.321030] WARNING: inconsistent lock state [ 81.325266] 4.12.0-rc1-00035-gd9dda65 #32 Not tainted [ 81.330273] -------------------------------- [ 81.334505] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. [ 81.340464] ksoftirqd/0/7 [HC0[0]:SC1[1]:HE1:SE0] takes: [ 81.345731] (&syncp->seq#2){+.?...}, at: [<c054ba3c>] mtk_handle_status_irq.part.6+0x70/0x84 [ 81.354219] {SOFTIRQ-ON-W} state was registered at: [ 81.359062] lock_acquire+0xfc/0x2b0 [ 81.362696] mtk_stats_update_mac+0x60/0x2c0 [ 81.367017] mtk_get_stats64+0x17c/0x18c [ 81.370995] dev_get_stats+0x48/0xbc [ 81.374628] rtnl_fill_stats+0x48/0x128 [ 81.378520] rtnl_fill_ifinfo+0x4ac/0xd1c [ 81.382584] rtmsg_ifinfo_build_skb+0x7c/0xe0 [ 81.386991] rtmsg_ifinfo.part.5+0x24/0x54 [ 81.391139] rtmsg_ifinfo+0x24/0x28 [ 81.394685] __dev_notify_flags+0xa4/0xac [ 81.398749] dev_change_flags+0x50/0x58 [ 81.402640] devinet_ioctl+0x768/0x85c [ 81.406444] inet_ioctl+0x1a4/0x1d0 [ 81.409990] sock_ioctl+0x16c/0x33c [ 81.413538] do_vfs_ioctl+0xb4/0xa34 [ 81.417169] SyS_ioctl+0x44/0x6c [ 81.420458] ret_fast_syscall+0x0/0x1c [ 81.424260] irq event stamp: 3354692 [ 81.427806] hardirqs last enabled at (3354692): [<c0678168>] net_rx_action+0xc0/0x504 [ 81.435660] hardirqs last disabled at (3354691): [<c0678134>] net_rx_action+0x8c/0x504 [ 81.443515] softirqs last enabled at (3354106): [<c0101944>] __do_softirq+0x4b4/0x614 [ 81.451370] softirqs last disabled at (3354109): [<c012f0c4>] run_ksoftirqd+0x44/0x80 [ 81.459134] [ 81.459134] other info that might help us debug this: [ 81.465608] Possible unsafe locking scenario: [ 81.465608] [ 81.471478] CPU0 [ 81.473900] ---- [ 81.476321] lock(&syncp->seq#2); [ 81.479701] <Interrupt> [ 81.482294] lock(&syncp->seq#2); [ 81.485847] [ 81.485847] *** DEADLOCK *** [ 81.485847] [ 81.491720] 1 lock held by ksoftirqd/0/7: [ 81.495693] #0: (&(&mac->hw_stats->stats_lock)->rlock){+.+...}, at: [<c054ba14>] mtk_handle_status_irq.part.6+0x48/0x84 [ 81.506579] [ 81.506579] stack backtrace: [ 81.510904] CPU: 0 PID: 7 Comm: ksoftirqd/0 Not tainted 4.12.0-rc1-00035-gd9dda65 #32 [ 81.518668] Hardware name: Mediatek Cortex-A7 (Device Tree) [ 81.524208] [<c0113dc4>] (unwind_backtrace) from [<c010e3f0>] (show_stack+0x20/0x24) [ 81.531899] [<c010e3f0>] (show_stack) from [<c03f9c64>] (dump_stack+0xb4/0xe0) [ 81.539072] [<c03f9c64>] (dump_stack) from [<c017e970>] (print_usage_bug+0x234/0x2e0) [ 81.546846] [<c017e970>] (print_usage_bug) from [<c017f058>] (mark_lock+0x63c/0x7bc) [ 81.554532] [<c017f058>] (mark_lock) from [<c017fe90>] (__lock_acquire+0x654/0x1bfc) [ 81.562217] [<c017fe90>] (__lock_acquire) from [<c0181d04>] (lock_acquire+0xfc/0x2b0) [ 81.569990] [<c0181d04>] (lock_acquire) from [<c054b76c>] (mtk_stats_update_mac+0x60/0x2c0) [ 81.578283] [<c054b76c>] (mtk_stats_update_mac) from [<c054ba3c>] (mtk_handle_status_irq.part.6+0x70/0x84) [ 81.587865] [<c054ba3c>] (mtk_handle_status_irq.part.6) from [<c054c2b8>] (mtk_napi_tx+0x358/0x37c) [ 81.596845] [<c054c2b8>] (mtk_napi_tx) from [<c06782ec>] (net_rx_action+0x244/0x504) [ 81.604533] [<c06782ec>] (net_rx_action) from [<c01015c4>] (__do_softirq+0x134/0x614) [ 81.612306] [<c01015c4>] (__do_softirq) from [<c012f0c4>] (run_ksoftirqd+0x44/0x80) [ 81.619907] [<c012f0c4>] (run_ksoftirqd) from [<c0154680>] (smpboot_thread_fn+0x14c/0x25c) [ 81.628110] [<c0154680>] (smpboot_thread_fn) from [<c014f8cc>] (kthread+0x150/0x180) [ 81.635798] [<c014f8cc>] (kthread) from [<c0109290>] (ret_from_fork+0x14/0x24) Signed-off-by:Sean Wang <sean.wang@mediatek.com> Signed-off-by:
-
David S. Miller authored
Elena Reshetova says: ==================== v2 ipv4/ipv6 refcount conversions Changes in v2: * rebase on top of net-next * currently by default refcount_t = atomic_t (*) and uses all atomic standard operations unless CONFIG_REFCOUNT_FULL is enabled. This is a compromise for the systems that are critical on performance (such as net) and cannot accept even slight delay on the refcounter operations. This series, for ipv4/ipv6 network components, replaces atomic_t reference counters with the new refcount_t type and API (see include/linux/refcount.h). By doing this we prevent intentional or accidental underflows or overflows that can led to use-after-free vulnerabilities. The patches are fully independent and can be cherry-picked separately. In order to try with refcount functionality enabled in run-time, CONFIG_REFCOUNT_FULL must be enabled. NOTE: automatic kernel builder for some reason doesn't like all my network branches and regularly times out the builds on these branches. Suggestion for "waiting a day for a good coverage" doesn't work, as we have seen with generic network conversions. So please wait for the full report from kernel test rebot before merging further up. This has been compile-tested in 116 configs, but 71 timed out (including all s390-related configs again). I am trying to see if they can fix build coverage for me in meanwhile. * The respective change is currently merged into -next as "locking/refcount: Create unchecked atomic_t implementation". ==================== Signed-off-by: -
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
- 03 Jul, 2017 6 commits
-
-
Michal Kalderon authored
Fix compilation warning qed_iwarp.c:1721:5: warning: ll2_syn_handle may be used uninitialized in this function Signed-off-by:
Michal Kalderon <Michal.Kalderon@cavium.com> Signed-off-by:
Ariel Elior <Ariel.Elior@cavium.com> Signed-off-by:
-
Daniel Axtens authored
I was trying to wrap my head around meaning of mru, and realised that the second line of the comment defining it had somehow ended up after the line defining cutlen, leading to much confusion. Reorder the lines to make sense. Signed-off-by:
Daniel Axtens <dja@axtens.net> Signed-off-by:
-
David S. Miller authored
Merge tag 'wireless-drivers-next-for-davem-2017-07-03' of https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for 4.13 Last minute changes to get new hardware and firmware support for iwlwifi and few other changes I was able to squeeze in. Also two patches for ieee80211.h and nl80211 as Johannes is away. Major changes: iwlwifi * some important fixes for 9000 HW * support for version 30 of the FW API for 8000 and 9000 series * a few new PCI IDs for 9000 series * reorganization of common files brcmfmac * support 4-way handshake offloading for WPA/WPA2-PSK and 802.1X ==================== Signed-off-by:
-
https://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller authored
Some overlapping changes in the mlx5 driver. A merge conflict resolution posted by Stephen Rothwell was used as a guide. Signed-off-by: -
Eric Dumazet authored
sk_ehashfn() is only used from a single file. Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Eric Dumazet authored
We need to use refcount_set() on a newly created rule to avoid following error : [ 64.601749] ------------[ cut here ]------------ [ 64.601757] WARNING: CPU: 0 PID: 6476 at lib/refcount.c:184 refcount_sub_and_test+0x75/0xa0 [ 64.601758] Modules linked in: w1_therm wire cdc_acm ehci_pci ehci_hcd mlx4_en ib_uverbs mlx4_ib ib_core mlx4_core [ 64.601769] CPU: 0 PID: 6476 Comm: ip Tainted: G W 4.12.0-smp-DEV #274 [ 64.601771] task: ffff8837bf482040 task.stack: ffff8837bdc08000 [ 64.601773] RIP: 0010:refcount_sub_and_test+0x75/0xa0 [ 64.601774] RSP: 0018:ffff8837bdc0f5c0 EFLAGS: 00010286 [ 64.601776] RAX: 0000000000000026 RBX: 0000000000000001 RCX: 0000000000000000 [ 64.601777] RDX: 0000000000000026 RSI: 0000000000000096 RDI: ffffed06f7b81eae [ 64.601778] RBP: ffff8837bdc0f5d0 R08: 0000000000000004 R09: fffffbfff4a54c25 [ 64.601779] R10: 00000000cbc500e5 R11: ffffffffa52a6128 R12: ffff881febcf6f24 [ 64.601779] R13: ffff881fbf4eaf00 R14: ffff881febcf6f80 R15: ffff8837d7a4ed00 [ 64.601781] FS: 00007ff5a2f6b700(0000) GS:ffff881fff800000(0000) knlGS:0000000000000000 [ 64.601782] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 64.601783] CR2: 00007ffcdc70d000 CR3: 0000001f9c91e000 CR4: 00000000001406f0 [ 64.601783] Call Trace: [ 64.601786] refcount_dec_and_test+0x11/0x20 [ 64.601790] fib_nl_delrule+0xc39/0x1630 [ 64.601793] ? is_bpf_text_address+0xe/0x20 [ 64.601795] ? fib_nl_newrule+0x25e0/0x25e0 [ 64.601798] ? depot_save_stack+0x133/0x470 [ 64.601801] ? ns_capable+0x13/0x20 [ 64.601803] ? __netlink_ns_capable+0xcc/0x100 [ 64.601806] rtnetlink_rcv_msg+0x23a/0x6a0 [ 64.601808] ? rtnl_newlink+0x1630/0x1630 [ 64.601811] ? memset+0x31/0x40 [ 64.601813] netlink_rcv_skb+0x2d7/0x440 [ 64.601815] ? rtnl_newlink+0x1630/0x1630 [ 64.601816] ? netlink_ack+0xaf0/0xaf0 [ 64.601818] ? kasan_unpoison_shadow+0x35/0x50 [ 64.601820] ? __kmalloc_node_track_caller+0x4c/0x70 [ 64.601821] rtnetlink_rcv+0x28/0x30 [ 64.601823] netlink_unicast+0x422/0x610 [ 64.601824] ? netlink_attachskb+0x650/0x650 [ 64.601826] netlink_sendmsg+0x7b7/0xb60 [ 64.601828] ? netlink_unicast+0x610/0x610 [ 64.601830] ? netlink_unicast+0x610/0x610 [ 64.601832] sock_sendmsg+0xba/0xf0 [ 64.601834] ___sys_sendmsg+0x6a9/0x8c0 [ 64.601835] ? copy_msghdr_from_user+0x520/0x520 [ 64.601837] ? __alloc_pages_nodemask+0x160/0x520 [ 64.601839] ? memcg_write_event_control+0xd60/0xd60 [ 64.601841] ? __alloc_pages_slowpath+0x1d50/0x1d50 [ 64.601843] ? kasan_slab_free+0x71/0xc0 [ 64.601845] ? mem_cgroup_commit_charge+0xb2/0x11d0 [ 64.601847] ? lru_cache_add_active_or_unevictable+0x7d/0x1a0 [ 64.601849] ? __handle_mm_fault+0x1af8/0x2810 [ 64.601851] ? may_open_dev+0xc0/0xc0 [ 64.601852] ? __pmd_alloc+0x2c0/0x2c0 [ 64.601853] ? __fdget+0x13/0x20 [ 64.601855] __sys_sendmsg+0xc6/0x150 [ 64.601856] ? __sys_sendmsg+0xc6/0x150 [ 64.601857] ? SyS_shutdown+0x170/0x170 [ 64.601859] ? handle_mm_fault+0x28a/0x650 [ 64.601861] SyS_sendmsg+0x12/0x20 [ 64.601863] entry_SYSCALL_64_fastpath+0x13/0x94 Fixes: 717d1e99 ("net: convert fib_rule.refcnt from atomic_t to refcount_t") Signed-off-by:
-
