- 09 Mar, 2019 1 commit
-
-
Guillaume Nault authored
Commit 7716682c ("tcp/dccp: fix another race at listener dismantle") let inet_csk_reqsk_queue_add() fail, and adjusted {tcp,dccp}_check_req() accordingly. However, TFO and syncookies weren't modified, thus leaking allocated resources on error. Contrary to tcp_check_req(), in both syncookies and TFO cases, we need to drop the request socket. Also, since the child socket is created with inet_csk_clone_lock(), we have to unlock it and drop an extra reference (->sk_refcount is initially set to 2 and inet_csk_reqsk_queue_add() drops only one ref). For TFO, we also need to revert the work done by tcp_try_fastopen() (with reqsk_fastopen_remove()). Fixes: 7716682c ("tcp/dccp: fix another race at listener dismantle") Signed-off-by:
Guillaume Nault <gnault@redhat.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 08 Mar, 2019 25 commits
-
-
Nathan Chancellor authored
When building with -Wsometimes-uninitialized, Clang warns: drivers/net/ethernet/sun/niu.c:7466:5: warning: variable 'class' is used uninitialized whenever switch default is taken [-Wsometimes-uninitialized] The default case can never happen because i can only be 0 to 3 (NIU_L3_PROG_CLS is defined as 4). To make this clear to Clang, just zero initialize class in the default case (use the macro CLASS_CODE_UNRECOG to make it clear this shouldn't happen). Link: https://github.com/ClangBuiltLinux/linux/issues/403Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
-
Matthew Whitehead authored
Add PCI vendor and device identifier for U.S. Robotics USR997901A 10/100 Cardbus NIC. Tested on real hardware. Signed-off-by:
Matthew Whitehead <tedheadster@gmail.com> Signed-off-by:
-
Eric Dumazet authored
My prior commit missed the fact that these functions were using udp_hdr() (aka skb_transport_header()) to get access to GUE header. Since pskb_transport_may_pull() does not exist yet, we have to add transport_offset to our pskb_may_pull() calls. BUG: KMSAN: uninit-value in gue_err+0x514/0xfa0 net/ipv4/fou.c:1032 CPU: 1 PID: 10648 Comm: syz-executor.1 Not tainted 5.0.0+ #11 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x173/0x1d0 lib/dump_stack.c:113 kmsan_report+0x12e/0x2a0 mm/kmsan/kmsan.c:600 __msan_warning+0x82/0xf0 mm/kmsan/kmsan_instr.c:313 gue_err+0x514/0xfa0 net/ipv4/fou.c:1032 __udp4_lib_err_encap_no_sk net/ipv4/udp.c:571 [inline] __udp4_lib_err_encap net/ipv4/udp.c:626 [inline] __udp4_lib_err+0x12e6/0x1d40 net/ipv4/udp.c:665 udp_err+0x74/0x90 net/ipv4/udp.c:737 icmp_socket_deliver net/ipv4/icmp.c:767 [inline] icmp_unreach+0xb65/0x1070 net/ipv4/icmp.c:884 icmp_rcv+0x11a1/0x1950 net/ipv4/icmp.c:1066 ip_protocol_deliver_rcu+0x584/0xbb0 net/ipv4/ip_input.c:208 ip_local_deliver_finish net/ipv4/ip_input.c:234 [inline] NF_HOOK include/linux/netfilter.h:289 [inline] ip_local_deliver+0x624/0x7b0 net/ipv4/ip_input.c:255 dst_input include/net/dst.h:450 [inline] ip_rcv_finish net/ipv4/ip_input.c:414 [inline] NF_HOOK include/linux/netfilter.h:289 [inline] ip_rcv+0x6bd/0x740 net/ipv4/ip_input.c:524 __netif_receive_skb_one_core net/core/dev.c:4973 [inline] __netif_receive_skb net/core/dev.c:5083 [inline] process_backlog+0x756/0x10e0 net/core/dev.c:5923 napi_poll net/core/dev.c:6346 [inline] net_rx_action+0x78b/0x1a60 net/core/dev.c:6412 __do_softirq+0x53f/0x93a kernel/softirq.c:293 invoke_softirq kernel/softirq.c:375 [inline] irq_exit+0x214/0x250 kernel/softirq.c:416 exiting_irq+0xe/0x10 arch/x86/include/asm/apic.h:536 smp_apic_timer_interrupt+0x48/0x70 arch/x86/kernel/apic/apic.c:1064 apic_timer_interrupt+0x2e/0x40 arch/x86/entry/entry_64.S:814 </IRQ> RIP: 0010:finish_lock_switch+0x2b/0x40 kernel/sched/core.c:2597 Code: 48 89 e5 53 48 89 fb e8 63 e7 95 00 8b b8 88 0c 00 00 48 8b 00 48 85 c0 75 12 48 89 df e8 dd db 95 00 c6 00 00 c6 03 00 fb 5b <5d> c3 e8 4e e6 95 00 eb e7 66 90 66 2e 0f 1f 84 00 00 00 00 00 55 RSP: 0018:ffff888081a0fc80 EFLAGS: 00000296 ORIG_RAX: ffffffffffffff13 RAX: ffff88821fd6bd80 RBX: ffff888027898000 RCX: ccccccccccccd000 RDX: ffff88821fca8d80 RSI: ffff888000000000 RDI: 00000000000004a0 RBP: ffff888081a0fc80 R08: 0000000000000002 R09: ffff888081a0fb08 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 R13: ffff88811130e388 R14: ffff88811130da00 R15: ffff88812fdb7d80 finish_task_switch+0xfc/0x2d0 kernel/sched/core.c:2698 context_switch kernel/sched/core.c:2851 [inline] __schedule+0x6cc/0x800 kernel/sched/core.c:3491 schedule+0x15b/0x240 kernel/sched/core.c:3535 freezable_schedule include/linux/freezer.h:172 [inline] do_nanosleep+0x2ba/0x980 kernel/time/hrtimer.c:1679 hrtimer_nanosleep kernel/time/hrtimer.c:1733 [inline] __do_sys_nanosleep kernel/time/hrtimer.c:1767 [inline] __se_sys_nanosleep+0x746/0x960 kernel/time/hrtimer.c:1754 __x64_sys_nanosleep+0x3e/0x60 kernel/time/hrtimer.c:1754 do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291 entry_SYSCALL_64_after_hwframe+0x63/0xe7 RIP: 0033:0x4855a0 Code: 00 00 48 c7 c0 d4 ff ff ff 64 c7 00 16 00 00 00 31 c0 eb be 66 0f 1f 44 00 00 83 3d b1 11 5d 00 00 75 14 b8 23 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 04 e2 f8 ff c3 48 83 ec 08 e8 3a 55 fd ff RSP: 002b:0000000000a4fd58 EFLAGS: 00000246 ORIG_RAX: 0000000000000023 RAX: ffffffffffffffda RBX: 0000000000085780 RCX: 00000000004855a0 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000a4fd60 RBP: 00000000000007ec R08: 0000000000000001 R09: 0000000000ceb940 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000008 R13: 0000000000a4fdb0 R14: 0000000000085711 R15: 0000000000a4fdc0 Uninit was created at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:205 [inline] kmsan_internal_poison_shadow+0x92/0x150 mm/kmsan/kmsan.c:159 kmsan_kmalloc+0xa6/0x130 mm/kmsan/kmsan_hooks.c:176 kmsan_slab_alloc+0xe/0x10 mm/kmsan/kmsan_hooks.c:185 slab_post_alloc_hook mm/slab.h:445 [inline] slab_alloc_node mm/slub.c:2773 [inline] __kmalloc_node_track_caller+0xe9e/0xff0 mm/slub.c:4398 __kmalloc_reserve net/core/skbuff.c:140 [inline] __alloc_skb+0x309/0xa20 net/core/skbuff.c:208 alloc_skb include/linux/skbuff.h:1012 [inline] alloc_skb_with_frags+0x186/0xa60 net/core/skbuff.c:5287 sock_alloc_send_pskb+0xafd/0x10a0 net/core/sock.c:2091 sock_alloc_send_skb+0xca/0xe0 net/core/sock.c:2108 __ip_append_data+0x34cd/0x5000 net/ipv4/ip_output.c:998 ip_append_data+0x324/0x480 net/ipv4/ip_output.c:1220 icmp_push_reply+0x23d/0x7e0 net/ipv4/icmp.c:375 __icmp_send+0x2ea3/0x30f0 net/ipv4/icmp.c:737 icmp_send include/net/icmp.h:47 [inline] ipv4_link_failure+0x6d/0x230 net/ipv4/route.c:1190 dst_link_failure include/net/dst.h:427 [inline] arp_error_report+0x106/0x1a0 net/ipv4/arp.c:297 neigh_invalidate+0x359/0x8e0 net/core/neighbour.c:992 neigh_timer_handler+0xdf2/0x1280 net/core/neighbour.c:1078 call_timer_fn+0x285/0x600 kernel/time/timer.c:1325 expire_timers kernel/time/timer.c:1362 [inline] __run_timers+0xdb4/0x11d0 kernel/time/timer.c:1681 run_timer_softirq+0x2e/0x50 kernel/time/timer.c:1694 __do_softirq+0x53f/0x93a kernel/softirq.c:293 Fixes: 26fc181e ("fou, fou6: do not assume linear skbs") Signed-off-by:
syzbot <syzkaller@googlegroups.com> Cc: Stefano Brivio <sbrivio@redhat.com> Cc: Sabrina Dubroca <sd@queasysnail.net> Acked-by:
Stefano Brivio <sbrivio@redhat.com> Signed-off-by:
-
Vlad Buslov authored
When used with unlocked classifier that have filters attached to actions with goto chain, __tcf_chain_put() for last non action reference can race with calls to same function from action cleanup code that releases last action reference. In this case action cleanup handler could free the chain if it executes after all references to chain were released, but before all concurrent users finished using it. Modify __tcf_chain_put() to only access tcf_chain fields when holding block->lock. Remove local variables that were used to cache some tcf_chain fields and are no longer needed because their values can now be obtained directly from chain under block->lock protection. Fixes: 726d0612 ("net: sched: prevent insertion of new classifiers during chain flush") Signed-off-by:
Vlad Buslov <vladbu@mellanox.com> Signed-off-by:
-
Arnd Bergmann authored
On some architectures, the MMU can be disabled, leading to access_ok() becoming an empty macro that does not evaluate its size argument, which in turn produces an unused-variable warning: drivers/vhost/vhost.c:1191:9: error: unused variable 's' [-Werror,-Wunused-variable] size_t s = vhost_has_feature(vq, VIRTIO_RING_F_EVENT_IDX) ? 2 : 0; Mark the variable as __maybe_unused to shut up that warning. Signed-off-by:Arnd Bergmann <arnd@arndb.de> Acked-by:
Jason Wang <jasowang@redhat.com> Signed-off-by:
-
Adalbert Lazăr authored
Previous to commit 22b5c0b6 ("vsock/virtio: fix kernel panic after device hot-unplug"), vsock_core_init() was called from virtio_vsock_probe(). Now, virtio_transport_reset_no_sock() can be called before vsock_core_init() has the chance to run. [Wed Feb 27 14:17:09 2019] BUG: unable to handle kernel NULL pointer dereference at 0000000000000110 [Wed Feb 27 14:17:09 2019] #PF error: [normal kernel read fault] [Wed Feb 27 14:17:09 2019] PGD 0 P4D 0 [Wed Feb 27 14:17:09 2019] Oops: 0000 [#1] SMP PTI [Wed Feb 27 14:17:09 2019] CPU: 3 PID: 59 Comm: kworker/3:1 Not tainted 5.0.0-rc7-390-generic-hvi #390 [Wed Feb 27 14:17:09 2019] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 [Wed Feb 27 14:17:09 2019] Workqueue: virtio_vsock virtio_transport_rx_work [vmw_vsock_virtio_transport] [Wed Feb 27 14:17:09 2019] RIP: 0010:virtio_transport_reset_no_sock+0x8c/0xc0 [vmw_vsock_virtio_transport_common] [Wed Feb 27 14:17:09 2019] Code: 35 8b 4f 14 48 8b 57 08 31 f6 44 8b 4f 10 44 8b 07 48 8d 7d c8 e8 84 f8 ff ff 48 85 c0 48 89 c3 74 2a e8 f7 31 03 00 48 89 df <48> 8b 80 10 01 00 00 e8 68 fb 69 ed 48 8b 75 f0 65 48 33 34 25 28 [Wed Feb 27 14:17:09 2019] RSP: 0018:ffffb42701ab7d40 EFLAGS: 00010282 [Wed Feb 27 14:17:09 2019] RAX: 0000000000000000 RBX: ffff9d79637ee080 RCX: 0000000000000003 [Wed Feb 27 14:17:09 2019] RDX: 0000000000000001 RSI: 0000000000000002 RDI: ffff9d79637ee080 [Wed Feb 27 14:17:09 2019] RBP: ffffb42701ab7d78 R08: ffff9d796fae70e0 R09: ffff9d796f403500 [Wed Feb 27 14:17:09 2019] R10: ffffb42701ab7d90 R11: 0000000000000000 R12: ffff9d7969d09240 [Wed Feb 27 14:17:09 2019] R13: ffff9d79624e6840 R14: ffff9d7969d09318 R15: ffff9d796d48ff80 [Wed Feb 27 14:17:09 2019] FS: 0000000000000000(0000) GS:ffff9d796fac0000(0000) knlGS:0000000000000000 [Wed Feb 27 14:17:09 2019] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [Wed Feb 27 14:17:09 2019] CR2: 0000000000000110 CR3: 0000000427f22000 CR4: 00000000000006e0 [Wed Feb 27 14:17:09 2019] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [Wed Feb 27 14:17:09 2019] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [Wed Feb 27 14:17:09 2019] Call Trace: [Wed Feb 27 14:17:09 2019] virtio_transport_recv_pkt+0x63/0x820 [vmw_vsock_virtio_transport_common] [Wed Feb 27 14:17:09 2019] ? kfree+0x17e/0x190 [Wed Feb 27 14:17:09 2019] ? detach_buf_split+0x145/0x160 [Wed Feb 27 14:17:09 2019] ? __switch_to_asm+0x40/0x70 [Wed Feb 27 14:17:09 2019] virtio_transport_rx_work+0xa0/0x106 [vmw_vsock_virtio_transport] [Wed Feb 27 14:17:09 2019] NET: Registered protocol family 40 [Wed Feb 27 14:17:09 2019] process_one_work+0x167/0x410 [Wed Feb 27 14:17:09 2019] worker_thread+0x4d/0x460 [Wed Feb 27 14:17:09 2019] kthread+0x105/0x140 [Wed Feb 27 14:17:09 2019] ? rescuer_thread+0x360/0x360 [Wed Feb 27 14:17:09 2019] ? kthread_destroy_worker+0x50/0x50 [Wed Feb 27 14:17:09 2019] ret_from_fork+0x35/0x40 [Wed Feb 27 14:17:09 2019] Modules linked in: vmw_vsock_virtio_transport vmw_vsock_virtio_transport_common input_leds vsock serio_raw i2c_piix4 mac_hid qemu_fw_cfg autofs4 cirrus ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops virtio_net psmouse drm net_failover pata_acpi virtio_blk failover floppy Fixes: 22b5c0b6 ("vsock/virtio: fix kernel panic after device hot-unplug") Reported-by:
Alexandru Herghelegiu <aherghelegiu@bitdefender.com> Signed-off-by:
Adalbert Lazăr <alazar@bitdefender.com> Co-developed-by:
Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by:
Stefano Garzarella <sgarzare@redhat.com> Signed-off-by:
-
Li RongQing authored
proc_exit_connector() uses ->real_parent lockless. This is not safe that its parent can go away at any moment, so use RCU to protect it, and ensure that this task is not released. [ 747.624551] ================================================================== [ 747.632946] BUG: KASAN: use-after-free in proc_exit_connector+0x1f7/0x310 [ 747.640686] Read of size 4 at addr ffff88a0276988e0 by task sshd/2882 [ 747.648032] [ 747.649804] CPU: 11 PID: 2882 Comm: sshd Tainted: G E 4.19.26-rc2 #11 [ 747.658629] Hardware name: IBM x3550M4 -[7914OFV]-/00AM544, BIOS -[D7E142BUS-1.71]- 07/31/2014 [ 747.668419] Call Trace: [ 747.671269] dump_stack+0xf0/0x19b [ 747.675186] ? show_regs_print_info+0x5/0x5 [ 747.679988] ? kmsg_dump_rewind_nolock+0x59/0x59 [ 747.685302] print_address_description+0x6a/0x270 [ 747.691162] kasan_report+0x258/0x380 [ 747.695835] ? proc_exit_connector+0x1f7/0x310 [ 747.701402] proc_exit_connector+0x1f7/0x310 [ 747.706767] ? proc_coredump_connector+0x2d0/0x2d0 [ 747.712715] ? _raw_write_unlock_irq+0x29/0x50 [ 747.718270] ? _raw_write_unlock_irq+0x29/0x50 [ 747.723820] ? ___preempt_schedule+0x16/0x18 [ 747.729193] ? ___preempt_schedule+0x16/0x18 [ 747.734574] do_exit+0xa11/0x14f0 [ 747.738880] ? mm_update_next_owner+0x590/0x590 [ 747.744525] ? debug_show_all_locks+0x3c0/0x3c0 [ 747.761448] ? ktime_get_coarse_real_ts64+0xeb/0x1c0 [ 747.767589] ? lockdep_hardirqs_on+0x1a6/0x290 [ 747.773154] ? check_chain_key+0x139/0x1f0 [ 747.778345] ? check_flags.part.35+0x240/0x240 [ 747.783908] ? __lock_acquire+0x2300/0x2300 [ 747.789171] ? _raw_spin_unlock_irqrestore+0x59/0x70 [ 747.795316] ? _raw_spin_unlock_irqrestore+0x59/0x70 [ 747.801457] ? do_raw_spin_unlock+0x10f/0x1e0 [ 747.806914] ? do_raw_spin_trylock+0x120/0x120 [ 747.812481] ? preempt_count_sub+0x14/0xc0 [ 747.817645] ? _raw_spin_unlock+0x2e/0x50 [ 747.822708] ? __handle_mm_fault+0x12db/0x1fa0 [ 747.828367] ? __pmd_alloc+0x2d0/0x2d0 [ 747.833143] ? check_noncircular+0x50/0x50 [ 747.838309] ? match_held_lock+0x7f/0x340 [ 747.843380] ? check_noncircular+0x50/0x50 [ 747.848561] ? handle_mm_fault+0x21a/0x5f0 [ 747.853730] ? check_flags.part.35+0x240/0x240 [ 747.859290] ? check_chain_key+0x139/0x1f0 [ 747.864474] ? __do_page_fault+0x40f/0x760 [ 747.869655] ? __audit_syscall_entry+0x4b/0x1f0 [ 747.875319] ? syscall_trace_enter+0x1d5/0x7b0 [ 747.880877] ? trace_raw_output_preemptirq_template+0x90/0x90 [ 747.887895] ? trace_raw_output_sys_exit+0x80/0x80 [ 747.893860] ? up_read+0x3b/0x90 [ 747.898142] ? stop_critical_timings+0x260/0x260 [ 747.903909] do_group_exit+0xe0/0x1c0 [ 747.908591] ? __x64_sys_exit+0x30/0x30 [ 747.913460] ? trace_raw_output_preemptirq_template+0x90/0x90 [ 747.920485] ? tracer_hardirqs_on+0x270/0x270 [ 747.925956] __x64_sys_exit_group+0x28/0x30 [ 747.931214] do_syscall_64+0x117/0x400 [ 747.935988] ? syscall_return_slowpath+0x2f0/0x2f0 [ 747.941931] ? trace_hardirqs_off_thunk+0x1a/0x1c [ 747.947788] ? trace_hardirqs_on_caller+0x1d0/0x1d0 [ 747.953838] ? lockdep_sys_exit+0x16/0x8e [ 747.958915] ? trace_hardirqs_off_thunk+0x1a/0x1c [ 747.964784] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 747.971021] RIP: 0033:0x7f572f154c68 [ 747.975606] Code: Bad RIP value. [ 747.979791] RSP: 002b:00007ffed2dfaa58 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 [ 747.989324] RAX: ffffffffffffffda RBX: 00007f572f431840 RCX: 00007f572f154c68 [ 747.997910] RDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001 [ 748.006495] RBP: 0000000000000001 R08: 00000000000000e7 R09: fffffffffffffee0 [ 748.015079] R10: 00007f572f4387e8 R11: 0000000000000246 R12: 00007f572f431840 [ 748.023664] R13: 000055a7f90f2c50 R14: 000055a7f96e2310 R15: 000055a7f96e2310 [ 748.032287] [ 748.034509] Allocated by task 2300: [ 748.038982] kasan_kmalloc+0xa0/0xd0 [ 748.043562] kmem_cache_alloc_node+0xf5/0x2e0 [ 748.049018] copy_process+0x1781/0x4790 [ 748.053884] _do_fork+0x166/0x9a0 [ 748.058163] do_syscall_64+0x117/0x400 [ 748.062943] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 748.069180] [ 748.071405] Freed by task 15395: [ 748.075591] __kasan_slab_free+0x130/0x180 [ 748.080752] kmem_cache_free+0xc2/0x310 [ 748.085619] free_task+0xea/0x130 [ 748.089901] __put_task_struct+0x177/0x230 [ 748.095063] finish_task_switch+0x51b/0x5d0 [ 748.100315] __schedule+0x506/0xfa0 [ 748.104791] schedule+0xca/0x260 [ 748.108978] futex_wait_queue_me+0x27e/0x420 [ 748.114333] futex_wait+0x251/0x550 [ 748.118814] do_futex+0x75b/0xf80 [ 748.123097] __x64_sys_futex+0x231/0x2a0 [ 748.128065] do_syscall_64+0x117/0x400 [ 748.132835] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 748.139066] [ 748.141289] The buggy address belongs to the object at ffff88a027698000 [ 748.141289] which belongs to the cache task_struct of size 12160 [ 748.156589] The buggy address is located 2272 bytes inside of [ 748.156589] 12160-byte region [ffff88a027698000, ffff88a02769af80) [ 748.171114] The buggy address belongs to the page: [ 748.177055] page:ffffea00809da600 count:1 mapcount:0 mapping:ffff888107d01e00 index:0x0 compound_mapcount: 0 [ 748.189136] flags: 0x57ffffc0008100(slab|head) [ 748.194688] raw: 0057ffffc0008100 ffffea00809a3200 0000000300000003 ffff888107d01e00 [ 748.204424] raw: 0000000000000000 0000000000020002 00000001ffffffff 0000000000000000 [ 748.214146] page dumped because: kasan: bad access detected [ 748.220976] [ 748.223197] Memory state around the buggy address: [ 748.229128] ffff88a027698780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 748.238271] ffff88a027698800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 748.247414] >ffff88a027698880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 748.256564] ^ [ 748.264267] ffff88a027698900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 748.273493] ffff88a027698980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 748.282630] ================================================================== Fixes: b086ff87 ("connector: add parent pid and tgid to coredump and exit events") Signed-off-by:
Zhang Yu <zhangyu31@baidu.com> Signed-off-by:
Li RongQing <lirongqing@baidu.com> Acked-by:
Evgeniy Polyakov <zbr@ioremap.net> Signed-off-by:
-
Litao Jiao authored
vxlan_cleanup() is a timer callback, it is already and only running in BH context. Signed-off-by:
Litao Jiao <jiaolitao@raisecom.com> Signed-off-by:
-
Jian Shen authored
HW can not guarantee complete write desc->rx.size, even though HNS3_RXD_VLD_B has been set. Driver needs to add dma_rmb() instruction to make sure desc->rx.size is always valid. Fixes: e5597095 ("net: hns3: Add handling of GRO Pkts not fully RX'ed in NAPI poll") Signed-off-by:
Jian Shen <shenjian15@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
-
Pedro Tammela authored
This patch adds missing documentation for some inline functions on linux/skbuff.h. The patch is incomplete and a lot more can be added, just wondering if it's of interest of the netdev developers. Also fixed some whitespaces. Signed-off-by:
Pedro Tammela <pctammela@gmail.com> Signed-off-by:
-
David S. Miller authored
Christophe Roullier says: ==================== stmmac: add some fixes for stm32 For common stmmac: - Add support to set CSR Clock range selection in DT For stm32mpu: - Glue codes to support magic packet - Glue codes to support all PHY config : PHY_MODE (MII,GMII, RMII, RGMII) and in normal, PHY wo crystal (25Mhz), PHY wo crystal (50Mhz), No 125Mhz from PHY config For stm32mcu: - Add Ethernet support for stm32h7 Changes in V3: - Reverse for syscfg management because it is manage by these patches https://lkml.org/lkml/2018/12/12/133 https://lkml.org/lkml/2018/12/12/134 https://lkml.org/lkml/2018/12/12/131 https://lkml.org/lkml/2018/12/12/132 ==================== Signed-off-by:
-
Christophe Roullier authored
Synopsys GMAC 4.10 is used. And Phy mode for eval and disco is RMII with PHY SMSC LAN8742 Signed-off-by:
Christophe Roullier <christophe.roullier@st.com> Signed-off-by:
-
Christophe Roullier authored
Syscfg clock is no more needed. Signed-off-by:
-
Christophe Roullier authored
In Documentation stmmac.txt there is possibility to fixed CSR Clock range selection with property clk_csr. This patch add the management of this property For example to use it, add in your ethernet node DT: clk_csr = <3>; Signed-off-by:
-
Christophe Roullier authored
Add properties to support all Phy config PHY_MODE (MII,GMII, RMII, RGMII) and in normal, PHY wo crystal (25Mhz), PHY wo crystal (50Mhz), No 125Mhz from PHY config. Signed-off-by:
-
Christophe Roullier authored
Update glue codes to support all PHY config on stm32mp157c PHY_MODE (MII,GMII, RMII, RGMII) and in normal, PHY wo crystal (25Mhz), PHY wo crystal (50Mhz), No 125Mhz from PHY config. Signed-off-by:
-
Christophe Roullier authored
Add glue codes to support magic packet on stm32mp157c Signed-off-by:
-
David S. Miller authored
Xin Long says: ==================== sctp: process the error returned from sctp_sock_migrate() This patchset is to process the errs returned by sctp_auth_init_hmacs() and sctp_bind_addr_dup() from sctp_sock_migrate(). And also fix a panic caused by new ep->auth_hmacs was not set due to net->sctp.auth_enable changed by sysctl before accepting an assoc. ==================== Acked-by:
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by:
-
Xin Long authored
New ep's auth_hmacs should be set if old ep's is set, in case that net->sctp.auth_enable has been changed to 0 by users and new ep's auth_hmacs couldn't be set in sctp_endpoint_init(). It can even crash kernel by doing: 1. on server: sysctl -w net.sctp.auth_enable=1, sysctl -w net.sctp.addip_enable=1, sysctl -w net.sctp.addip_noauth_enable=0, listen() on server, sysctl -w net.sctp.auth_enable=0. 2. on client: connect() to server. 3. on server: accept() the asoc, sysctl -w net.sctp.auth_enable=1. 4. on client: send() asconf packet to server. The call trace: [ 245.280251] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 [ 245.286872] RIP: 0010:sctp_auth_calculate_hmac+0xa3/0x140 [sctp] [ 245.304572] Call Trace: [ 245.305091] <IRQ> [ 245.311287] sctp_sf_authenticate+0x110/0x160 [sctp] [ 245.312311] sctp_sf_eat_auth+0xf2/0x230 [sctp] [ 245.313249] sctp_do_sm+0x9a/0x2d0 [sctp] [ 245.321483] sctp_assoc_bh_rcv+0xed/0x1a0 [sctp] [ 245.322495] sctp_rcv+0xa66/0xc70 [sctp] It's because the old ep->auth_hmacs wasn't copied to the new ep while ep->auth_hmacs is used in sctp_auth_calculate_hmac() when processing the incoming auth chunks, and it should have been done when migrating sock. Reported-by:Ying Xu <yinxu@redhat.com> Signed-off-by:
Xin Long <lucien.xin@gmail.com> Acked-by:
Neil Horman <nhorman@redhat.com> Signed-off-by:
-
Xin Long authored
sctp_auth_init_hmacs() is called only when ep->auth_enable is set. It better to move up sctp_auth_init_hmacs() and remove auth_enable check in it and check auth_enable only once in sctp_endpoint_init(). Signed-off-by:
Neil Horman <nhorman@tuxdriver.com> Signed-off-by:
-
Xin Long authored
It should fail to create the new sk if sctp_bind_addr_dup() fails when accepting or peeloff an association. Signed-off-by:
-
Stefano Brivio authored
If we receive a packet while deleting a VXLAN device, there's a chance vxlan_rcv() is called at the same time as vxlan_dellink(). This is fine, except that vxlan_dellink() should never ever touch stuff that's still in use, such as the GRO cells list. Otherwise, vxlan_rcv() crashes while queueing packets via gro_cells_receive(). Move the gro_cells_destroy() to vxlan_uninit(), which runs after the RCU grace period is elapsed and nothing needs the gro_cells anymore. This is now done in the same way as commit 8e816df8 ("geneve: Use GRO cells infrastructure.") originally implemented for GENEVE. Reported-by:
Jianlin Shi <jishi@redhat.com> Fixes: 58ce31cc ("vxlan: GRO support at tunnel layer") Signed-off-by:
Sabrina Dubroca <sd@queasysnail.net> Reviewed-by:
-
David Howells authored
rxrpc_disconnect_client_call() reads the call's connection ID protocol value (call->cid) as part of that function's variable declarations. This is bad because it's not inside the locked section and so may race with someone granting use of the channel to the call. This manifests as an assertion failure (see below) where the call in the presumed channel (0 because call->cid wasn't set when we read it) doesn't match the call attached to the channel we were actually granted (if 1, 2 or 3). Fix this by moving the read and dependent calculations inside of the channel_lock section. Also, only set the channel number and pointer variables if cid is not zero (ie. unset). This problem can be induced by injecting an occasional error in rxrpc_wait_for_channel() before the call to schedule(). Make two further changes also: (1) Add a trace for wait failure in rxrpc_connect_call(). (2) Drop channel_lock before BUG'ing in the case of the assertion failure. The failure causes a trace akin to the following: rxrpc: Assertion failed - 18446612685268945920(0xffff8880beab8c00) == 18446612685268621312(0xffff8880bea69800) is false ------------[ cut here ]------------ kernel BUG at net/rxrpc/conn_client.c:824! ... RIP: 0010:rxrpc_disconnect_client_call+0x2bf/0x99d ... Call Trace: rxrpc_connect_call+0x902/0x9b3 ? wake_up_q+0x54/0x54 rxrpc_new_client_call+0x3a0/0x751 ? rxrpc_kernel_begin_call+0x141/0x1bc ? afs_alloc_call+0x1b5/0x1b5 rxrpc_kernel_begin_call+0x141/0x1bc afs_make_call+0x20c/0x525 ? afs_alloc_call+0x1b5/0x1b5 ? __lock_is_held+0x40/0x71 ? lockdep_init_map+0xaf/0x193 ? lockdep_init_map+0xaf/0x193 ? __lock_is_held+0x40/0x71 ? yfs_fs_fetch_data+0x33b/0x34a yfs_fs_fetch_data+0x33b/0x34a afs_fetch_data+0xdc/0x3b7 afs_read_dir+0x52d/0x97f afs_dir_iterate+0xa0/0x661 ? iterate_dir+0x63/0x141 iterate_dir+0xa2/0x141 ksys_getdents64+0x9f/0x11b ? filldir+0x111/0x111 ? do_syscall_64+0x3e/0x1a0 __x64_sys_getdents64+0x16/0x19 do_syscall_64+0x7d/0x1a0 entry_SYSCALL_64_after_hwframe+0x49/0xbe Fixes: 45025bce ("rxrpc: Improve management and caching of client connection objects") Signed-off-by:
David Howells <dhowells@redhat.com> Reviewed-by:
Marc Dionne <marc.dionne@auristor.com> Signed-off-by:
-
Xin Long authored
syzbot reported a NULL-ptr deref caused by that sched->init() in sctp_stream_init() set stream->rr_next = NULL. kasan: GPF could be caused by NULL-ptr deref or user memory access RIP: 0010:sctp_sched_rr_dequeue+0xd3/0x170 net/sctp/stream_sched_rr.c:141 Call Trace: sctp_outq_dequeue_data net/sctp/outqueue.c:90 [inline] sctp_outq_flush_data net/sctp/outqueue.c:1079 [inline] sctp_outq_flush+0xba2/0x2790 net/sctp/outqueue.c:1205 All sched info is saved in sout->ext now, in sctp_stream_init() sctp_stream_alloc_out() will not change it, there's no need to call sched->init() again, since sctp_outq_init() has already done it. Fixes: 5bbbbe32 ("sctp: introduce stream scheduler foundations") Reported-by: syzbot+4c9934f20522c0efd657@syzkaller.appspotmail.com Signed-off-by: -
Xin Long authored
The race occurs in __mkroute_output() when 2 threads lookup a dst: CPU A CPU B find_exception() find_exception() [fnhe expires] ip_del_fnhe() [fnhe is deleted] rt_bind_exception() In rt_bind_exception() it will bind a deleted fnhe with the new dst, and this dst will get no chance to be freed. It causes a dev defcnt leak and consecutive dmesg warnings: unregister_netdevice: waiting for ethX to become free. Usage count = 1 Especially thanks Jon to identify the issue. This patch fixes it by setting fnhe_daddr to 0 in ip_del_fnhe() to stop binding the deleted fnhe with a new dst when checking fnhe's fnhe_daddr and daddr in rt_bind_exception(). It works as both ip_del_fnhe() and rt_bind_exception() are protected by fnhe_lock and the fhne is freed by kfree_rcu(). Fixes: deed49df ("route: check and remove route cache when we get route") Signed-off-by:Jon Maxwell <jmaxwell37@gmail.com> Signed-off-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
-
- 07 Mar, 2019 12 commits
-
-
Eric Dumazet authored
syzbot found another add_timer() issue, this time in net/hsr [1] Let's use mod_timer() which is safe. [1] kernel BUG at kernel/time/timer.c:1136! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 15909 Comm: syz-executor.3 Not tainted 5.0.0+ #97 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 kobject: 'loop2' (00000000f5629718): kobject_uevent_env RIP: 0010:add_timer kernel/time/timer.c:1136 [inline] RIP: 0010:add_timer+0x654/0xbe0 kernel/time/timer.c:1134 Code: 0f 94 c5 31 ff 44 89 ee e8 09 61 0f 00 45 84 ed 0f 84 77 fd ff ff e8 bb 5f 0f 00 e8 07 10 a0 ff e9 68 fd ff ff e8 ac 5f 0f 00 <0f> 0b e8 a5 5f 0f 00 0f 0b e8 9e 5f 0f 00 4c 89 b5 58 ff ff ff e9 RSP: 0018:ffff8880656eeca0 EFLAGS: 00010246 kobject: 'loop2' (00000000f5629718): fill_kobj_path: path = '/devices/virtual/block/loop2' RAX: 0000000000040000 RBX: 1ffff1100caddd9a RCX: ffffc9000c436000 RDX: 0000000000040000 RSI: ffffffff816056c4 RDI: ffff88806a2f6cc8 RBP: ffff8880656eed58 R08: ffff888067f4a300 R09: ffff888067f4abc8 R10: 0000000000000000 R11: 0000000000000000 R12: ffff88806a2f6cc0 R13: dffffc0000000000 R14: 0000000000000001 R15: ffff8880656eed30 FS: 00007fc2019bf700(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000738000 CR3: 0000000067e8e000 CR4: 00000000001406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: hsr_check_announce net/hsr/hsr_device.c:99 [inline] hsr_check_carrier_and_operstate+0x567/0x6f0 net/hsr/hsr_device.c:120 hsr_netdev_notify+0x297/0xa00 net/hsr/hsr_main.c:51 notifier_call_chain+0xc7/0x240 kernel/notifier.c:93 __raw_notifier_call_chain kernel/notifier.c:394 [inline] raw_notifier_call_chain+0x2e/0x40 kernel/notifier.c:401 call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1739 call_netdevice_notifiers_extack net/core/dev.c:1751 [inline] call_netdevice_notifiers net/core/dev.c:1765 [inline] dev_open net/core/dev.c:1436 [inline] dev_open+0x143/0x160 net/core/dev.c:1424 team_port_add drivers/net/team/team.c:1203 [inline] team_add_slave+0xa07/0x15d0 drivers/net/team/team.c:1933 do_set_master net/core/rtnetlink.c:2358 [inline] do_set_master+0x1d4/0x230 net/core/rtnetlink.c:2332 do_setlink+0x966/0x3510 net/core/rtnetlink.c:2493 rtnl_setlink+0x271/0x3b0 net/core/rtnetlink.c:2747 rtnetlink_rcv_msg+0x465/0xb00 net/core/rtnetlink.c:5192 netlink_rcv_skb+0x17a/0x460 net/netlink/af_netlink.c:2485 rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5210 netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline] netlink_unicast+0x536/0x720 net/netlink/af_netlink.c:1336 netlink_sendmsg+0x8ae/0xd70 net/netlink/af_netlink.c:1925 sock_sendmsg_nosec net/socket.c:622 [inline] sock_sendmsg+0xdd/0x130 net/socket.c:632 sock_write_iter+0x27c/0x3e0 net/socket.c:923 call_write_iter include/linux/fs.h:1869 [inline] do_iter_readv_writev+0x5e0/0x8e0 fs/read_write.c:680 do_iter_write fs/read_write.c:956 [inline] do_iter_write+0x184/0x610 fs/read_write.c:937 vfs_writev+0x1b3/0x2f0 fs/read_write.c:1001 do_writev+0xf6/0x290 fs/read_write.c:1036 __do_sys_writev fs/read_write.c:1109 [inline] __se_sys_writev fs/read_write.c:1106 [inline] __x64_sys_writev+0x75/0xb0 fs/read_write.c:1106 do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457f29 Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007fc2019bec78 EFLAGS: 00000246 ORIG_RAX: 0000000000000014 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457f29 RDX: 0000000000000001 RSI: 00000000200000c0 RDI: 0000000000000003 RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fc2019bf6d4 R13: 00000000004c4a60 R14: 00000000004dd218 R15: 00000000ffffffff Fixes: f421436a ("net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)") Signed-off-by:
-
Dirk van der Merwe authored
The simple vNIC mailbox length should be 12 decimal and not 0x12. Using a decimal also makes it clear this is a length value and not another field within the simple mailbox defines. Found by code inspection, there are no known firmware configurations where this would cause issues. Fixes: 527d7d1b ("nfp: read mailbox address from TLV caps") Signed-off-by:
Dirk van der Merwe <dirk.vandermerwe@netronome.com> Reviewed-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
-
Nathan Chancellor authored
I removed compat's universal assignment to 0, which allows this if statement to fall through when compat is passed with a value other than 0. Fixes: f9d19a74 ("net: atm: Use IS_ENABLED in atm_dev_ioctl") Signed-off-by:
-
Nathan Chancellor authored
When building with -Wsometimes-uninitialized, Clang warns: drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:495:3: warning: variable 'ns' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:495:3: warning: variable 'ns' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized] drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:532:3: warning: variable 'ns' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:532:3: warning: variable 'ns' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized] drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:741:3: warning: variable 'sec_inc' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:741:3: warning: variable 'sec_inc' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized] Clang is concerned with the use of stmmac_do_void_callback (which stmmac_get_timestamp and stmmac_config_sub_second_increment wrap), as it may fail to initialize these values if the if condition was ever false (meaning the callbacks don't exist). It's not wrong because the callbacks (get_timestamp and config_sub_second_increment respectively) are the ones that initialize the variables. While it's unlikely that the callbacks are ever going to disappear and make that condition false, we can easily avoid this warning by zero initialize the variables. Link: https://github.com/ClangBuiltLinux/linux/issues/384Suggested-by:
-
Nathan Chancellor authored
When building with -Wsometimes-uninitialized, Clang warns: net/atm/resources.c:256:6: warning: variable 'number' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized] net/atm/resources.c:212:7: warning: variable 'iobuf_len' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized] Clang won't realize that compat is 0 when CONFIG_COMPAT is not set until the constant folding stage, which happens after this semantic analysis. Use IS_ENABLED instead so that the zero is present at the semantic analysis stage, which eliminates this warning. Link: https://github.com/ClangBuiltLinux/linux/issues/386Signed-off-by:
-
Arnd Bergmann authored
clang inlines the dev_ethtool() more aggressively than gcc does, leading to a larger amount of used stack space: net/core/ethtool.c:2536:24: error: stack frame size of 1216 bytes in function 'dev_ethtool' [-Werror,-Wframe-larger-than=] Marking the sub-functions that require the most stack space as noinline_for_stack gives us reasonable behavior on all compilers. Signed-off-by:
Michal Kubecek <mkubecek@suse.cz> Signed-off-by:
-
Sudarsana Reddy Kalluru authored
Driver uses port-mtu as packet-size for the loopback traffic. This patch limits the max packet size to 1.5K to avoid data being split over multiple buffer descriptors (BDs) in cases where MTU > PAGE_SIZE. Signed-off-by:
Sudarsana Reddy Kalluru <skalluru@marvell.com> Signed-off-by:
Ariel Elior <aelior@marvell.com> Signed-off-by:
-
Arnd Bergmann authored
The enic driver relies on the CONFIG_CPUMASK_OFFSTACK feature to dynamically allocate a struct member, but this is normally intended for local variables. Building with clang, I get a warning for a few locations that check the address of the cpumask_var_t: drivers/net/ethernet/cisco/enic/enic_main.c:122:22: error: address of array 'enic->msix[i].affinity_mask' will always evaluate to 'true' [-Werror,-Wpointer-bool-conversion] As far as I can tell, the code is still correct, as the truth value of the pointer is what we need in this configuration. To get rid of the warning, use cpumask_available() instead of checking the pointer directly. Fixes: 322cf7e3 ("enic: assign affinity hint to interrupts") Signed-off-by:
-
Arnd Bergmann authored
Clang points out undefined behavior when building the pcan_usb_pro driver: drivers/net/can/usb/peak_usb/pcan_usb_pro.c:136:15: error: passing an object that undergoes default argument promotion to 'va_start' has undefined behavior [-Werror,-Wvarargs] Changing the function prototype to avoid argument promotion in the varargs call avoids the warning, and should make this well-defined. Signed-off-by:
-
Masaru Nagai authored
Hardware has the CBS (Credit Based Shaper) which affects only Q3 and Q2. When updating the CBS settings, even if the driver does so after waiting for Tx DMA finished, there is a possibility that frame data still remains in TxFIFO. To avoid this, decrease TxFIFO depth of Q3 and Q2 to one. This patch has been exercised this using netperf TCP_MAERTS, TCP_STREAM and UDP_STREAM tests run on an Ebisu board. No performance change was detected, outside of noise in the tests, both in terms of throughput and CPU utilisation. Fixes: c156633f ("Renesas Ethernet AVB driver proper") Signed-off-by:
Masaru Nagai <masaru.nagai.vx@renesas.com> Signed-off-by:
Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com> [simon: updated changelog] Signed-off-by:
Simon Horman <horms+renesas@verge.net.au> Signed-off-by:
-
Arnd Bergmann authored
clang has spotted an ancient code bug and warns about it with: drivers/isdn/isdnloop/isdnloop.c:573:12: error: address of array 'card->rcard' will always evaluate to 'true' [-Werror,-Wpointer-bool-conversion] This is an array of pointers, so we should check if a specific pointer exists in the array before using it, not whether the array itself exists. Signed-off-by:
-
Arnd Bergmann authored
clang warns about what seems to be an unintended use of an obscure C language feature where a forward declaration of an array remains usable when the final definition is never seen: drivers/net/ethernet/ti/davinci_emac.c:1694:34: error: tentative array definition assumed to have one element [-Werror] static const struct of_device_id davinci_emac_of_match[]; There is no harm in always enabling the device tree matching code here, and it makes the code behave in a more conventional way aside from avoiding the warning. Signed-off-by:
-
- 06 Mar, 2019 2 commits
-
-
Soheil Hassas Yeganeh authored
Returning 0 as inq to userspace indicates there is no more data to read, and the application needs to wait for EPOLLIN. For a connection that has received FIN from the remote peer, however, the application must continue reading until getting EOF (return value of 0 from tcp_recvmsg) or an error, if edge-triggered epoll (EPOLLET) is being used. Otherwise, the application will never receive a new EPOLLIN, since there is no epoll edge after the FIN. Return 1 when there is no data left on the queue but the connection has received FIN, so that the applications continue reading. Fixes: b75eba76 (tcp: send in-queue bytes in cmsg upon read) Signed-off-by:
Soheil Hassas Yeganeh <soheil@google.com> Acked-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
Yuchung Cheng <ycheng@google.com> Signed-off-by:
-
Mao Wenan authored
If hsr_add_port(hsr, hsr_dev, HSR_PT_MASTER) failed to add port, it directly returns res and forgets to free the node that allocated in hsr_create_self_node(), and forgets to delete the node->mac_list linked in hsr->self_node_db. BUG: memory leak unreferenced object 0xffff8881cfa0c780 (size 64): comm "syz-executor.0", pid 2077, jiffies 4294717969 (age 2415.377s) hex dump (first 32 bytes): e0 c7 a0 cf 81 88 ff ff 00 02 00 00 00 00 ad de ................ 00 e6 49 cd 81 88 ff ff c0 9b 87 d0 81 88 ff ff ..I............. backtrace: [<00000000e2ff5070>] hsr_dev_finalize+0x736/0x960 [hsr] [<000000003ed2e597>] hsr_newlink+0x2b2/0x3e0 [hsr] [<000000003fa8c6b6>] __rtnl_newlink+0xf1f/0x1600 net/core/rtnetlink.c:3182 [<000000001247a7ad>] rtnl_newlink+0x66/0x90 net/core/rtnetlink.c:3240 [<00000000e7d1b61d>] rtnetlink_rcv_msg+0x54e/0xb90 net/core/rtnetlink.c:5130 [<000000005556bd3a>] netlink_rcv_skb+0x129/0x340 net/netlink/af_netlink.c:2477 [<00000000741d5ee6>] netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline] [<00000000741d5ee6>] netlink_unicast+0x49a/0x650 net/netlink/af_netlink.c:1336 [<000000009d56f9b7>] netlink_sendmsg+0x88b/0xdf0 net/netlink/af_netlink.c:1917 [<0000000046b35c59>] sock_sendmsg_nosec net/socket.c:621 [inline] [<0000000046b35c59>] sock_sendmsg+0xc3/0x100 net/socket.c:631 [<00000000d208adc9>] __sys_sendto+0x33e/0x560 net/socket.c:1786 [<00000000b582837a>] __do_sys_sendto net/socket.c:1798 [inline] [<00000000b582837a>] __se_sys_sendto net/socket.c:1794 [inline] [<00000000b582837a>] __x64_sys_sendto+0xdd/0x1b0 net/socket.c:1794 [<00000000c866801d>] do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290 [<00000000fea382d9>] entry_SYSCALL_64_after_hwframe+0x49/0xbe [<00000000e01dacb3>] 0xffffffffffffffff Fixes: c5a75911 ("net/hsr: Use list_head (and rcu) instead of array for slave devices.") Reported-by:Hulk Robot <hulkci@huawei.com> Signed-off-by:
Mao Wenan <maowenan@huawei.com> Signed-off-by:
-
