No /proc/sys/net/ipv4/tcp_syncookies present with 2.6.32-61-generic #123 in -proposed

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1326473

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

This issue is unrelated to the SYN cookie check in test-kernel-security.py. It
just so happens that the test caught the bug. Here's two kernel stack dumps
that I see in the logs after booting the 2.6.32-61-generic #123 kernel:

 sysctl table check failed: /net/core/somaxconn .3.1.18 Missing strategy
 Pid: 1, comm: swapper Not tainted 2.6.32-61-generic #123-Ubuntu
 Call Trace:
  [<ffffffff8108f509>] set_fail+0x59/0x60
  [<ffffffff8108f83b>] sysctl_check_table+0x16b/0x4b0
  [<ffffffff8108f84c>] sysctl_check_table+0x17c/0x4b0
  [<ffffffff8108f84c>] sysctl_check_table+0x17c/0x4b0
  [<ffffffff8107235d>] __register_sysctl_paths+0x11d/0x360
  [<ffffffff8108f84c>] ? sysctl_check_table+0x17c/0x4b0
  [<ffffffff81535181>] register_net_sysctl_table+0x61/0x70
  [<ffffffff81462765>] sysctl_core_net_init+0x45/0xb0
  [<ffffffff81461b08>] register_pernet_operations+0x48/0x100
  [<ffffffff8188e882>] ? sysctl_core_init+0x0/0x38
  [<ffffffff81461c6c>] register_pernet_subsys+0x2c/0x50
  [<ffffffff8188e8b8>] sysctl_core_init+0x36/0x38
  [<ffffffff8100a04c>] do_one_initcall+0x3c/0x1a0
  [<ffffffff818576d1>] do_basic_setup+0x54/0x66
  [<ffffffff818577f1>] kernel_init+0x10e/0x162
  [<ffffffff810141ea>] child_rip+0xa/0x20
  [<ffffffff818576e3>] ? kernel_init+0x0/0x162
  [<ffffffff810141e0>] ? child_rip+0x0/0x20

 sysctl table check failed: /net/ipv4/ip_no_pmtu_disc .3.5.39 Missing strategy
 Pid: 1, comm: swapper Not tainted 2.6.32-61-generic #123-Ubuntu
 Call Trace:
  [<ffffffff8108f509>] set_fail+0x59/0x60
  [<ffffffff8108f83b>] sysctl_check_table+0x16b/0x4b0
  [<ffffffff8108f84c>] sysctl_check_table+0x17c/0x4b0
  [<ffffffff8108f84c>] sysctl_check_table+0x17c/0x4b0
  [<ffffffff8107235d>] __register_sysctl_paths+0x11d/0x360
  [<ffffffff811a4808>] ? __proc_create+0xd8/0x130
  [<ffffffff8189029a>] ? sysctl_ipv4_init+0x0/0x4e
  [<ffffffff810725cb>] register_sysctl_paths+0x2b/0x30
  [<ffffffff818902b6>] sysctl_ipv4_init+0x1c/0x4e
  [<ffffffff8100a04c>] do_one_initcall+0x3c/0x1a0
  [<ffffffff818576d1>] do_basic_setup+0x54/0x66
  [<ffffffff818577f1>] kernel_init+0x10e/0x162
  [<ffffffff810141ea>] child_rip+0xa/0x20
  [<ffffffff818576e3>] ? kernel_init+0x0/0x162
  [<ffffffff810141e0>] ? child_rip+0x0/0x20

The first stack dump involves the /net/core/somaxconn sysctl. Looking at the
git log of changes that went into this kernel, I'd say that the following
commit is the likely culprit:

  d77028f net: check net.core.somaxconn sysctl values

This upstream commit, which is not in Lucid, removed the .ctl_name initializer
from netns_core_table:

  f8572d8 sysctl net: Remove unused binary sysctl code

Since Lucid's netns_core_table initializes .ctl_name, sysctl_check_table()
requires the .strategy field to be initialized. Other places using
proc_dointvec_minmax() for the .proc_handler seem to be using sysctl_intvec()
for the .strategy. I suppose the patch below would be the correct fix, but
would like someone from the kernel team to take over from here.

diff --git a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c
index 4b1c570..8bc7541 100644
--- a/net/core/sysctl_net_core.c
+++ b/net/core/sysctl_net_core.c
@@ -132,6 +132,7 @@ static struct ctl_table netns_core_table[] = {
   .extra1 = &zero,
   .extra2 = &ushort_max,
   .proc_handler = proc_dointvec_minmax
+ .strategy = &sysctl_intvec,
  },
  { .ctl_name = 0 }
 };

I've been able to reproduce this issue in Lucid and I can confirm that reverting the following commits actually fixes the problem:

d77028ffe1a3d6eb5f57c5e5ea87cbfc4ee05eb1 "net: check net.core.somaxconn sysctl values"
2dc19ed6338a27a78c7a9d47d311ae4ac5302c83 "sysctl net: Keep tcp_syn_retries inside the boundary"

So, although the fix proposed by Tyler in comment #3 could be the correct fix for this regression, it has been decided to actually revert the offending commits (as usual when a regression is found in an SRU).

This bug was fixed in the package linux - 2.6.32-61.124

---------------
linux (2.6.32-61.124) lucid; urgency=low

  [ Luis Henriques ]

  * Revert "sysctl net: Keep tcp_syn_retries inside the boundary"
    - LP: #1326473
  * Revert "net: check net.core.somaxconn sysctl values"
    - LP: #1326473

  [ Upstream Kernel Changes ]

  * futex-prevent-requeue-pi-on-same-futex.patch futex: Forbid uaddr ==
    uaddr2 in futex_requeue(..., requeue_pi=1)
    - LP: #1326367
    - CVE-2014-3153
  * futex: Validate atomic acquisition in futex_lock_pi_atomic()
    - LP: #1326367
    - CVE-2014-3153
  * futex: Always cleanup owner tid in unlock_pi
    - LP: #1326367
    - CVE-2014-3153
  * futex: Make lookup_pi_state more robust
    - LP: #1326367
    - CVE-2014-3153
 -- Brad Figg <email address hidden> Wed, 04 Jun 2014 07:21:55 -0700

The verification of the Stable Release Update for linux has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.