Created attachment 220641 [details] config-4.7.0-rc3 This seems to be a common report but this one is for 4.7.0-rc3 thus : System is a Lenovo G575 which started with Debian 8.5 : vesta$ uname -a Linux vesta 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) x86_64 GNU/Linux vesta$ cat /etc/debian_version 8.5 After a very basic compile and install of 4.7.0-rc3 I see : [ 0.000000] Linux version 4.7.0-rc3 (root@vesta) (gcc version 4.9.2 (Debian 4.9.2-10) ) #1 SMP Sun Jun 19 07:28:02 EDT 2016 [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.7.0-rc3 root=UUID=dd3cc62f-1fda-4084-9b9f-2ed1de3b6a63 ro quiet [ 0.000000] x86/fpu: Legacy x87 FPU detected. [ 0.000000] x86/fpu: Using 'eager' FPU context switches. [ 0.000000] e820: BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable [ 0.000000] BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000dfb3efff] usable [ 0.000000] BIOS-e820: [mem 0x00000000dfb3f000-0x00000000dfbbefff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000dfbbf000-0x00000000dfebefff] ACPI NVS [ 0.000000] BIOS-e820: [mem 0x00000000dfebf000-0x00000000dfef5fff] ACPI data [ 0.000000] BIOS-e820: [mem 0x00000000dfef6000-0x00000000dfefffff] usable [ 0.000000] BIOS-e820: [mem 0x00000000dff00000-0x00000000dfffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fec10000-0x00000000fec10fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000ffe00000-0x00000000ffffffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x0000000186ffffff] usable [ 0.000000] BIOS-e820: [mem 0x0000000187000000-0x000000019effffff] reserved [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] SMBIOS 2.7 present. [ 0.000000] DMI: LENOVO 4383 /Inagua, BIOS 41CN27WW(V2.03) 01/12/2012 [ 0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved [ 0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable [ 0.000000] e820: last_pfn = 0x187000 max_arch_pfn = 0x400000000 [ 0.000000] MTRR default type: uncachable [ 0.000000] MTRR fixed ranges enabled: [ 0.000000] 00000-9FFFF write-back [ 0.000000] A0000-BFFFF uncachable [ 0.000000] C0000-FFFFF write-through [ 0.000000] MTRR variable ranges enabled: [ 0.000000] 0 base 000000000 mask F80000000 write-back [ 0.000000] 1 base 080000000 mask FC0000000 write-back [ 0.000000] 2 base 0C0000000 mask FE0000000 write-back [ 0.000000] 3 base 0DFEBE000 mask FFFFFF000 uncachable [ 0.000000] 4 base 0FFE00000 mask FFFE00000 write-protect [ 0.000000] 5 disabled [ 0.000000] 6 disabled [ 0.000000] 7 disabled . . . [ 62.350785] ip_tables: (C) 2000-2006 Netfilter Core Team [ 62.353848] WARNING: kmemcheck: Caught 64-bit read from uninitialized memory (ffff880037b4bd80) [ 62.353853] 40beb4370088ffffcccccccccccccccc303d8b81ffffffffcccccccccccccccc [ 62.353873] u u u u u u u u u u u u u u u u i i i i i i i i u u u u u u u u [ 62.353891] ^ [ 62.353894] RIP: 0010:[<ffffffff8183f436>] [<ffffffff8183f436>] nf_register_net_hook+0x36/0x180 [ 62.353906] RSP: 0018:ffff880183de7cc8 EFLAGS: 00010282 [ 62.353909] RAX: ffff880037b2d880 RBX: 0000000000000000 RCX: 00000000024000c0 [ 62.353912] RDX: 0000000000000001 RSI: 0000000000000040 RDI: ffff880037b2d880 [ 62.353915] RBP: ffff880183de7ce8 R08: 0000000000000000 R09: ffff880037b2e880 [ 62.353918] R10: ffffffff81855e28 R11: 0000000000000291 R12: ffff880037b4bd80 [ 62.353921] R13: ffffffff820dfd00 R14: ffff880037b2d880 R15: 0000000000000003 [ 62.353924] FS: 0000000000000000(0000) GS:ffff880186200000(0000) knlGS:0000000000000000 [ 62.353927] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 62.353930] CR2: ffff880185812000 CR3: 0000000002007000 CR4: 00000000000006f0 [ 62.353932] [<ffffffff8183f82b>] nf_register_net_hooks+0x3b/0x90 [ 62.353937] [<ffffffff818b305a>] ipt_register_table+0xea/0x120 [ 62.353942] [<ffffffff818b3cc1>] iptable_filter_table_init.part.1+0x51/0x70 [ 62.353946] [<ffffffff818b3d2a>] iptable_filter_net_init+0x2a/0x30 [ 62.353951] [<ffffffff818004b7>] ops_init+0x47/0x120 [ 62.353955] [<ffffffff81800796>] register_pernet_operations+0xe6/0x1a0 [ 62.353959] [<ffffffff81800877>] register_pernet_subsys+0x27/0x40 [ 62.353962] [<ffffffff821baf64>] iptable_filter_init+0x33/0x4b [ 62.353967] [<ffffffff81000444>] do_one_initcall+0x54/0x180 [ 62.353971] [<ffffffff821600dd>] kernel_init_freeable+0x195/0x222 [ 62.353975] [<ffffffff819f6c39>] kernel_init+0x9/0x100 [ 62.353980] [<ffffffff819fd58f>] ret_from_fork+0x1f/0x40 [ 62.353984] [<ffffffffffffffff>] 0xffffffffffffffff . . . I will try to attach the config as well as the full dmesg log that I saw.
Created attachment 220651 [details] output from dmesg seen
Same machine has no issue with 4.6.2
Hi, I'm the regression tracker for Linux 4.7. This bug is unlikely to lead to anything in its current form, as the assigned developer is likely burdened in other stuff and doesn't know much about iptable, where the problem seems to e. You might want to reassign the bug to "networking/iptables" or report the problem to the the mailing list where the networking/iptables developer hang out.
As a follow up I shall go back and perform some more tests to confirm that this is still happening as well as try to get a similar result in some other platform. In addition, I shall go looking for devs that are involved in the "networking/iptables" area such that this bug may be at least given due consideration.
See if this fixes the issue, seems something may have passed a int into a PTR_ERR cast and make a pointer return on error path giving your warning.
Created attachment 224111 [details] Test Patch
That patch is wrong. Misread something.
Can you try this patch after reading over the code and double checking this is probably a good fix.
Created attachment 224161 [details] Regression Test Fix
Did the patch fix the issue or has this already been resolved.
Sorry for the slwo follow up but am trying to reproduce this issue in 4.7.0 and 4.7.2 where the problem seems to be solved. Regardless I will revert back to the 4.7.0-rc3 build and try this patch and report results .. if any. Dennis
Please do not try that patch and ignore any recommendations posted by that user.
Glad you advised me. Thank you.
I can not reproduce this behavior in any recent builds. Am running 4.17.6 fine as well as a few 4.18.x release candidates on various systems with no issues.