aboutsummaryrefslogtreecommitdiff
path: root/net/ipv4/ping.c
Commit message (Collapse)AuthorAgeFilesLines
* ipv4: fix memory leaks in udp_sendmsg, ping_v4_sendmsgAndrey Ignatov2019-05-031-2/+5
| | | | | | | | | | | | | | | | | | | | | | | commit 1b97013bfb11d66f041de691de6f0fec748ce016 upstream. Fix more memory leaks in ip_cmsg_send() callers. Part of them were fixed earlier in 919483096bfe. * udp_sendmsg one was there since the beginning when linux sources were first added to git; * ping_v4_sendmsg one was copy/pasted in c319b4d76b9e. Whenever return happens in udp_sendmsg() or ping_v4_sendmsg() IP options have to be freed if they were allocated previously. Add label so that future callers (if any) can use it instead of kfree() before return that is easy to forget. Fixes: c319b4d76b9e (net: ipv4: add IPPROTO_ICMP socket kind) Change-Id: I01537e9cbad24816d6fc1baeb6bd6d96bd10990a Signed-off-by: Andrey Ignatov <rdna@fb.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* inet: prevent leakage of uninitialized memory to user in recv syscalls Only ↵Hannes Frederic Sowa2019-05-021-11/+5
| | | | | | | update *addr_len when we actually fill in sockaddr, otherwise we can return uninitialized memory from the stack to the caller in the recvfrom, recvmmsg and recvmsg syscalls. Drop the the (addr_len == NULL) checks because we only get called with a valid addr_len pointer either from sock_common_recvmsg or inet_recvmsg. If a blocking read waits on a socket which is concurrently shut down we now return zero and set msg_msgnamelen to 0.
* seq_file: remove "%n" usage from seq_file usersTetsuo Handa2017-09-231-8/+7
| | | | | | | | | | | | | | | | | | | All seq_printf() users are using "%n" for calculating padding size, convert them to use seq_setwidth() / seq_pad() pair. Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Kees Cook <keescook@chromium.org> Cc: Joe Perches <joe@perches.com> Cc: David Miller <davem@davemloft.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Git-commit: 652586df95e5d76b37d07a11839126dcfede1621 Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git [davidb@codeaurora.org: Resolve merge conflicts with ipv4/6 ping changes in upstream] CRs-fixed: 665291 Change-Id: Ia0416c9dbe3d80ff35f24f9c93c3543d1200a327 Signed-off-by: David Brown <davidb@codeaurora.org>
* ping: implement proper lockingEric Dumazet2017-06-171-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | commit 43a6684519ab0a6c52024b5e25322476cabad893 upstream. We got a report of yet another bug in ping http://www.openwall.com/lists/oss-security/2017/03/24/6 ->disconnect() is not called with socket lock held. Fix this by acquiring ping rwlock earlier. Thanks to Daniel, Alexander and Andrey for letting us know this problem. Fixes: c319b4d76b9e ("net: ipv4: add IPPROTO_ICMP socket kind") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Daniel Jiang <danieljiang0415@gmail.com> Reported-by: Solar Designer <solar@openwall.com> Reported-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> [wt: the function is ping_v4_unhash() in 3.10] Signed-off-by: Willy Tarreau <w@1wt.eu> Conflicts: net/ipv4/ping.c
* ping: fix a null pointer dereferenceWANG Cong2017-06-171-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 73d2c6678e6c3af7e7a42b1e78cd0211782ade32 upstream. Andrey reported a kernel crash: general protection fault: 0000 [#1] SMP KASAN Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 2 PID: 3880 Comm: syz-executor1 Not tainted 4.10.0-rc6+ #124 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 task: ffff880060048040 task.stack: ffff880069be8000 RIP: 0010:ping_v4_push_pending_frames net/ipv4/ping.c:647 [inline] RIP: 0010:ping_v4_sendmsg+0x1acd/0x23f0 net/ipv4/ping.c:837 RSP: 0018:ffff880069bef8b8 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: ffff880069befb90 RCX: 0000000000000000 RDX: 0000000000000018 RSI: ffff880069befa30 RDI: 00000000000000c2 RBP: ffff880069befbb8 R08: 0000000000000008 R09: 0000000000000000 R10: 0000000000000002 R11: 0000000000000000 R12: ffff880069befab0 R13: ffff88006c624a80 R14: ffff880069befa70 R15: 0000000000000000 FS: 00007f6f7c716700(0000) GS:ffff88006de00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000004a6f28 CR3: 000000003a134000 CR4: 00000000000006e0 Call Trace: inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:744 sock_sendmsg_nosec net/socket.c:635 [inline] sock_sendmsg+0xca/0x110 net/socket.c:645 SYSC_sendto+0x660/0x810 net/socket.c:1687 SyS_sendto+0x40/0x50 net/socket.c:1655 entry_SYSCALL_64_fastpath+0x1f/0xc2 This is because we miss a check for NULL pointer for skb_peek() when the queue is empty. Other places already have the same check. Fixes: c319b4d76b9e ("net: ipv4: add IPPROTO_ICMP socket kind") Reported-by: Andrey Konovalov <andreyknvl@google.com> Tested-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Willy Tarreau <w@1wt.eu>
* net: inet: Support UID-based routing in IP protocols.Lorenzo Colitti2017-05-231-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | - Use the UID in routing lookups made by protocol connect() and sendmsg() functions. - Make sure that routing lookups triggered by incoming packets (e.g., Path MTU discovery) take the UID of the socket into account. - For packets not associated with a userspace socket, (e.g., ping replies) use UID 0 inside the user namespace corresponding to the network namespace the socket belongs to. This allows all namespaces to apply routing and iptables rules to kernel-originated traffic in that namespaces by matching UID 0. This is better than using the UID of the kernel socket that is sending the traffic, because the UID of kernel sockets created at namespace creation time (e.g., the per-processor ICMP and TCP sockets) is the UID of the user that created the socket, which might not be mapped in the namespace. [Backport of net-next e2d118a1cb5e60d077131a09db1d81b90a5295fe] Bug: 16355602 Change-Id: I126f8359887b5b5bbac68daf0ded89e899cb7cb0 Tested: compiles allnoconfig, allyesconfig, allmodconfig Tested: https://android-review.googlesource.com/253302 Signed-off-by: Lorenzo Colitti <lorenzo@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
* Revert "net: core: Support UID-based routing."Lorenzo Colitti2017-05-231-2/+1
| | | | | | | | This reverts commit f6f535d3e0d8da2b5bc3c93690c47485d29e4ce6. Bug: 16355602 Change-Id: I5987e276f5ddbe425ea3bd86861cee0ae22212d9 Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
* net: ping: check minimum size on ICMP header lengthKees Cook2017-05-101-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 0eab121ef8750a5c8637d51534d5e9143fb0633f upstream. Prior to commit c0371da6047a ("put iov_iter into msghdr") in v3.19, there was no check that the iovec contained enough bytes for an ICMP header, and the read loop would walk across neighboring stack contents. Since the iov_iter conversion, bad arguments are noticed, but the returned error is EFAULT. Returning EINVAL is a clearer error and also solves the problem prior to v3.19. This was found using trinity with KASAN on v3.18: BUG: KASAN: stack-out-of-bounds in memcpy_fromiovec+0x60/0x114 at addr ffffffc071077da0 Read of size 8 by task trinity-c2/9623 page:ffffffbe034b9a08 count:0 mapcount:0 mapping: (null) index:0x0 flags: 0x0() page dumped because: kasan: bad access detected CPU: 0 PID: 9623 Comm: trinity-c2 Tainted: G BU 3.18.0-dirty #15 Hardware name: Google Tegra210 Smaug Rev 1,3+ (DT) Call trace: [<ffffffc000209c98>] dump_backtrace+0x0/0x1ac arch/arm64/kernel/traps.c:90 [<ffffffc000209e54>] show_stack+0x10/0x1c arch/arm64/kernel/traps.c:171 [< inline >] __dump_stack lib/dump_stack.c:15 [<ffffffc000f18dc4>] dump_stack+0x7c/0xd0 lib/dump_stack.c:50 [< inline >] print_address_description mm/kasan/report.c:147 [< inline >] kasan_report_error mm/kasan/report.c:236 [<ffffffc000373dcc>] kasan_report+0x380/0x4b8 mm/kasan/report.c:259 [< inline >] check_memory_region mm/kasan/kasan.c:264 [<ffffffc00037352c>] __asan_load8+0x20/0x70 mm/kasan/kasan.c:507 [<ffffffc0005b9624>] memcpy_fromiovec+0x5c/0x114 lib/iovec.c:15 [< inline >] memcpy_from_msg include/linux/skbuff.h:2667 [<ffffffc000ddeba0>] ping_common_sendmsg+0x50/0x108 net/ipv4/ping.c:674 [<ffffffc000dded30>] ping_v4_sendmsg+0xd8/0x698 net/ipv4/ping.c:714 [<ffffffc000dc91dc>] inet_sendmsg+0xe0/0x12c net/ipv4/af_inet.c:749 [< inline >] __sock_sendmsg_nosec net/socket.c:624 [< inline >] __sock_sendmsg net/socket.c:632 [<ffffffc000cab61c>] sock_sendmsg+0x124/0x164 net/socket.c:643 [< inline >] SYSC_sendto net/socket.c:1797 [<ffffffc000cad270>] SyS_sendto+0x178/0x1d8 net/socket.c:1761 CVE-2016-8399 Change-Id: I94349a8ff097843782048f9976712ad1c364d127 Reported-by: Qidan He <i@flanker017.me> Fixes: c319b4d76b9e ("net: ipv4: add IPPROTO_ICMP socket kind") Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: David S. Miller <davem@davemloft.net> [bwh: Backported to 3.2: only ICMPv4 is supported] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* Revert "net: ping: Fix stack buffer overflow in ping_common_sendmsg()"Mister Oyster2017-05-101-1/+1
| | | | This reverts commit db613b132bfc21191fc8741c4f201ddc818824f4.
* ping: implement proper lockingEric Dumazet2017-05-101-2/+3
| | | | | | | | | | | | | | | | | | | We got a report of yet another bug in ping http://www.openwall.com/lists/oss-security/2017/03/24/6 ->disconnect() is not called with socket lock held. Fix this by acquiring ping rwlock earlier. Thanks to Daniel, Alexander and Andrey for letting us know this problem. Fixes: c319b4d76b9e ("net: ipv4: add IPPROTO_ICMP socket kind") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Daniel Jiang <danieljiang0415@gmail.com> Reported-by: Solar Designer <solar@openwall.com> Reported-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: ping: Return EAFNOSUPPORT when appropriate.Lorenzo Colitti2017-04-111-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. For an IPv4 ping socket, ping_check_bind_addr does not check the family of the socket address that's passed in. Instead, make it behave like inet_bind, which enforces either that the address family is AF_INET, or that the family is AF_UNSPEC and the address is 0.0.0.0. 2. For an IPv6 ping socket, ping_check_bind_addr returns EINVAL if the socket family is not AF_INET6. Return EAFNOSUPPORT instead, for consistency with inet6_bind. 3. Make ping_v4_sendmsg and ping_v6_sendmsg return EAFNOSUPPORT instead of EINVAL if an incorrect socket address structure is passed in. 4. Make IPv6 ping sockets be IPv6-only. The code does not support IPv4, and it cannot easily be made to support IPv4 because the protocol numbers for ICMP and ICMPv6 are different. This makes connect(::ffff:192.0.2.1) fail with EAFNOSUPPORT instead of making the socket unusable. Among other things, this fixes an oops that can be triggered by: int s = socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP); struct sockaddr_in6 sin6 = { .sin6_family = AF_INET6, .sin6_addr = in6addr_any, }; bind(s, (struct sockaddr *) &sin6, sizeof(sin6)); [backport of net 9145736d4862145684009d6a72a6e61324a9439e] Change-Id: If06ca86d9f1e4593c0d6df174caca3487c57a241 Signed-off-by: Lorenzo Colitti <lorenzo@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: ping: Fix stack buffer overflow in ping_common_sendmsg()Qidan He2017-04-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In ping_common_sendmsg(), when len < icmph_len, memcpy_fromiovec() will access invalid memory because msg->msg_iov only has 1 element and memcpy_fromiovec() attempts to increment it. KASAN report: BUG: KASAN: stack-out-of-bounds in memcpy_fromiovec+0x60/0x114 at addr ffffffc071077da0 Read of size 8 by task trinity-c2/9623 page:ffffffbe034b9a08 count:0 mapcount:0 mapping: (null) index:0x0 flags: 0x0() page dumped because: kasan: bad access detected CPU: 0 PID: 9623 Comm: trinity-c2 Tainted: G BU 3.18.0-dirty #15 Hardware name: Google Tegra210 Smaug Rev 1,3+ (DT) Call trace: [<ffffffc000209c98>] dump_backtrace+0x0/0x1ac arch/arm64/kernel/traps.c:90 [<ffffffc000209e54>] show_stack+0x10/0x1c arch/arm64/kernel/traps.c:171 [< inline >] __dump_stack lib/dump_stack.c:15 [<ffffffc000f18dc4>] dump_stack+0x7c/0xd0 lib/dump_stack.c:50 [< inline >] print_address_description mm/kasan/report.c:147 [< inline >] kasan_report_error mm/kasan/report.c:236 [<ffffffc000373dcc>] kasan_report+0x380/0x4b8 mm/kasan/report.c:259 [< inline >] check_memory_region mm/kasan/kasan.c:264 [<ffffffc00037352c>] __asan_load8+0x20/0x70 mm/kasan/kasan.c:507 [<ffffffc0005b9624>] memcpy_fromiovec+0x5c/0x114 lib/iovec.c:15 [< inline >] memcpy_from_msg include/linux/skbuff.h:2667 [<ffffffc000ddeba0>] ping_common_sendmsg+0x50/0x108 net/ipv4/ping.c:674 [<ffffffc000dded30>] ping_v4_sendmsg+0xd8/0x698 net/ipv4/ping.c:714 [<ffffffc000dc91dc>] inet_sendmsg+0xe0/0x12c net/ipv4/af_inet.c:749 [< inline >] __sock_sendmsg_nosec net/socket.c:624 [< inline >] __sock_sendmsg net/socket.c:632 [<ffffffc000cab61c>] sock_sendmsg+0x124/0x164 net/socket.c:643 [< inline >] SYSC_sendto net/socket.c:1797 [<ffffffc000cad270>] SyS_sendto+0x178/0x1d8 net/socket.c:1761 Memory state around the buggy address: ffffffc071077c80: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 f1 f1 ffffffc071077d00: f1 f1 04 f4 f4 f4 f2 f2 f2 f2 04 f4 f4 f4 f2 f2 >ffffffc071077d80: f2 f2 00 00 f4 f4 f2 f2 f2 f2 00 00 00 00 00 00 ^ ffffffc071077e00: 00 f4 f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 00 ffffffc071077e80: 00 00 00 00 00 00 f3 f3 f3 f3 00 00 00 00 00 00 Bug: 31349935 Change-Id: Ib7385fc26dfe7e07e9bab42a10ff65a37cbaab54 Signed-off-by: Siqi Lin <siqilin@google.com>
* ping: fix null pointer exception (seen in speedtest app)DerTeufel2016-11-071-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [30409.811801]<5> (5)[29555:ping]SELinux: security field of sock is null!! [30409.811808]<5> (5)[29555:ping]SELinux: security field of sock is null!! [30409.811817]<5> (5)[29555:ping]SELinux: security field of sock is null!! [30409.811823]<5> (5)[29555:ping]SELinux: security field of sock is null!! [30409.811833]<5> (5)[29555:ping]SELinux: security field of sock is null!! [30409.811839]<5> (5)[29555:ping]SELinux: security field of sock is null!! [30409.811848]<5> (5)[29555:ping]SELinux: security field of sock is null!! [30409.811855]<5> (5)[29555:ping]SELinux: security field of sock is null!! [30409.811869]<5> (5)[29555:ping]Unable to handle kernel paging request at virtual address 5f37d1ba1e0fb303 [30409.811878]<5> (5)[29555:ping]pgd = ffffffc00fa8c000 [30409.811884][5f37d1ba1e0fb303] *pgd=0000000000000000 [30409.811893]<5> (5)[29555:ping][KERN Warning] ERROR/WARN forces debug_lock off! [30409.811899]<5> (5)[29555:ping][KERN Warning] check backtrace: [30409.811910]<5> (5)[29555:ping]CPU: 5 PID: 29555 Comm: ping Tainted: G W 3.10.90-DragonDevil_Jiayu.de #4 [30409.811918]<5> (5)[29555:ping]Call trace: [30409.811933]<5> (5)[29555:ping][<ffffffc000088aec>] dump_backtrace+0x0/0x16c [30409.811943]<5> (5)[29555:ping][<ffffffc000088c68>] show_stack+0x10/0x1c [30409.811956]<5> (5)[29555:ping][<ffffffc0009bff20>] dump_stack+0x1c/0x28 [30409.811967]<5> (5)[29555:ping][<ffffffc0002fb9f0>] debug_locks_off+0x44/0x5c [30409.811978]<5> (5)[29555:ping][<ffffffc000099f10>] oops_enter+0xc/0x28 [30409.811988]<5> (5)[29555:ping][<ffffffc000088c9c>] die+0x28/0x1d8 [30409.811998]<5> (5)[29555:ping][<ffffffc0009bda84>] __do_kernel_fault.part.5+0x70/0x84 [30409.812009]<5> (5)[29555:ping][<ffffffc0000942c4>] do_bad_area+0x90/0x94 [30409.812019]<5> (5)[29555:ping][<ffffffc000094310>] do_translation_fault+0x30/0x4c [30409.812028]<5> (5)[29555:ping][<ffffffc0000813f8>] do_mem_abort+0x38/0x9c [30409.812036]<5> (5)[29555:ping]Exception stack(0xffffffc0876cf8f0 to 0xffffffc0876cfac4) [30409.812046]<5> (5)[29555:ping]f8e0: 876cfb28 ffffffc0 876cc000 ffffffc0 [30409.812056]<5> (5)[29555:ping]f900: 876cfab0 ffffffc0 002a0018 ffffffc0 00df2008 ffffffc0 00df2008 ffffffc0 [30409.812066]<5> (5)[29555:ping]f920: 876cf930 ffffffc0 009cd040 ffffffc0 876cf940 ffffffc0 000c3cdc ffffffc0 [30409.812076]<5> (5)[29555:ping]f940: 876cf960 ffffffc0 0009b974 ffffffc0 00df2008 ffffffc0 00df1000 ffffffc0 [30409.812086]<5> (5)[29555:ping]f960: 876cf970 ffffffc0 009cd000 ffffffc0 876cf980 ffffffc0 0009c0dc ffffffc0 [30409.812096]<5> (5)[29555:ping]f980: 876cfa20 ffffffc0 009bdd38 ffffffc0 00000000 00000000 8ec6c9c0 ffffffc0 [30409.812106]<5> (5)[29555:ping]f9a0: 00000002 00000000 876cc000 ffffffc0 002a0144 ffffffc0 876cfbc0 ffffffc0 [30409.812116]<5> (5)[29555:ping]f9c0: 876cfd50 ffffffc0 00000000 00000000 000000d4 00000000 00000004 00000000 [30409.812125]<5> (5)[29555:ping]f9e0: 86544000 00000055 000003e8 00000000 0000000a 00000000 000003e8 00000000 [30409.812135]<5> (5)[29555:ping]fa00: 00000001 00000000 000000c0 00000000 00838260 ffffffc0 9c13b0c4 0000007f [30409.812145]<5> (5)[29555:ping]fa20: 00000001 00000000 876cfb28 ffffffc0 1e0fb303 5f37d1ba 00000194 00000000 [30409.812155]<5> (5)[29555:ping]fa40: 00000000 00000000 876cfe88 ffffffc0 876cfd50 ffffffc0 876cfdd0 ffffffc0 [30409.812165]<5> (5)[29555:ping]fa60: ebec47e8 0000007f 000000c0 00000000 876cfe88 ffffffc0 876cfab0 ffffffc0 [30409.812174]<5> (5)[29555:ping]fa80: 002a000c ffffffc0 876cfab0 ffffffc0 002a0018 ffffffc0 60000145 00000000 [30409.812184]<5> (5)[29555:ping]faa0: 876cfb28 ffffffc0 00000001 00000000 876cfb60 ffffffc0 002a0164 ffffffc0 [30409.812191]<5> (5)[29555:ping]fac0: 876cfc38 [30409.812200]<5> (5)[29555:ping][<ffffffc000083c58>] el1_da+0x1c/0x88 [30409.812213]<5> (5)[29555:ping][<ffffffc0002a0160>] selinux_socket_recvmsg+0x1c/0x28 [30409.812225]<5> (5)[29555:ping][<ffffffc00029bfbc>] security_socket_recvmsg+0x14/0x20 [30409.812237]<5> (5)[29555:ping][<ffffffc0008347f0>] sock_recvmsg+0x74/0xf4 [30409.812248]<5> (5)[29555:ping][<ffffffc000834d18>] ___sys_recvmsg+0xcc/0x220 [30409.812259]<5> (5)[29555:ping][<ffffffc000838218>] __sys_recvmsg+0x3c/0x84 [30409.812270]<5> (5)[29555:ping][<ffffffc00083826c>] SyS_recvmsg+0xc/0x20 [30409.812278]<5>-(5)[29555:ping]Internal error: Oops: 96000004 [#1] PREEMPT SMP [30409.812284]disable aee kernel api
* ping: Fix race in free in receive pathsubashab@codeaurora.org2016-11-071-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit fc752f1f43c1c038a2c6ae58cc739ebb5953ccb0 ] An exception is seen in ICMP ping receive path where the skb destructor sock_rfree() tries to access a freed socket. This happens because ping_rcv() releases socket reference with sock_put() and this internally frees up the socket. Later icmp_rcv() will try to free the skb and as part of this, skb destructor is called and which leads to a kernel panic as the socket is freed already in ping_rcv(). -->|exception -007|sk_mem_uncharge -007|sock_rfree -008|skb_release_head_state -009|skb_release_all -009|__kfree_skb -010|kfree_skb -011|icmp_rcv -012|ip_local_deliver_finish Fix this incorrect free by cloning this skb and processing this cloned skb instead. This patch was suggested by Eric Dumazet Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org> Cc: Eric Dumazet <edumazet@google.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* 3.10.77 -> 3.10.78Jan Engelmohr2016-08-261-0/+1
|
* first commitMeizu OpenSource2016-08-151-0/+1216
generated by cgit v1.2.3 (git 2.39.1) at 2026-03-14 19:21:30 +0000