1. Jun 29, 2011
    • Julian Anastasov's avatar
      netfilter: Fix ip_route_me_harder triggering ip_rt_bug · ed6e4ef8
      Julian Anastasov authored
      
      
      	Avoid creating input routes with ip_route_me_harder.
      It does not work for locally generated packets. Instead,
      restrict sockets to provide valid saddr for output route (or
      unicast saddr for transparent proxy). For other traffic
      allow saddr to be unicast or local but if callers forget
      to check saddr type use 0 for the output route.
      
      	The resulting handling should be:
      
      - REJECT TCP:
      	- in INPUT we can provide addr_type = RTN_LOCAL but
      	better allow rejecting traffic delivered with
      	local route (no IP address => use RTN_UNSPEC to
      	allow also RTN_UNICAST).
      	- FORWARD: RTN_UNSPEC => allow RTN_LOCAL/RTN_UNICAST
      	saddr, add fix to ignore RTN_BROADCAST and RTN_MULTICAST
      	- OUTPUT: RTN_UNSPEC
      
      - NAT, mangle, ip_queue, nf_ip_reroute: RTN_UNSPEC in LOCAL_OUT
      
      - IPVS:
      	- use RTN_LOCAL in LOCAL_OUT and FORWARD after SNAT
      	to restrict saddr to be local
      
      Signed-off-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ed6e4ef8
  2. Jun 28, 2011
  3. Jun 25, 2011
  4. Jun 23, 2011
  5. Jun 22, 2011
    • Xufeng Zhang's avatar
      udp/recvmsg: Clear MSG_TRUNC flag when starting over for a new packet · 9cfaa8de
      Xufeng Zhang authored
      
      
      Consider this scenario: When the size of the first received udp packet
      is bigger than the receive buffer, MSG_TRUNC bit is set in msg->msg_flags.
      However, if checksum error happens and this is a blocking socket, it will
      goto try_again loop to receive the next packet.  But if the size of the
      next udp packet is smaller than receive buffer, MSG_TRUNC flag should not
      be set, but because MSG_TRUNC bit is not cleared in msg->msg_flags before
      receive the next packet, MSG_TRUNC is still set, which is wrong.
      
      Fix this problem by clearing MSG_TRUNC flag when starting over for a
      new packet.
      
      Signed-off-by: default avatarXufeng Zhang <xufeng.zhang@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9cfaa8de
    • Xufeng Zhang's avatar
      ipv6/udp: Use the correct variable to determine non-blocking condition · 32c90254
      Xufeng Zhang authored
      
      
      udpv6_recvmsg() function is not using the correct variable to determine
      whether or not the socket is in non-blocking operation, this will lead
      to unexpected behavior when a UDP checksum error occurs.
      
      Consider a non-blocking udp receive scenario: when udpv6_recvmsg() is
      called by sock_common_recvmsg(), MSG_DONTWAIT bit of flags variable in
      udpv6_recvmsg() is cleared by "flags & ~MSG_DONTWAIT" in this call:
      
          err = sk->sk_prot->recvmsg(iocb, sk, msg, size, flags & MSG_DONTWAIT,
                         flags & ~MSG_DONTWAIT, &addr_len);
      
      i.e. with udpv6_recvmsg() getting these values:
      
      	int noblock = flags & MSG_DONTWAIT
      	int flags = flags & ~MSG_DONTWAIT
      
      So, when udp checksum error occurs, the execution will go to
      csum_copy_err, and then the problem happens:
      
          csum_copy_err:
                  ...............
                  if (flags & MSG_DONTWAIT)
                          return -EAGAIN;
                  goto try_again;
                  ...............
      
      But it will always go to try_again as MSG_DONTWAIT has been cleared
      from flags at call time -- only noblock contains the original value
      of MSG_DONTWAIT, so the test should be:
      
                  if (noblock)
                          return -EAGAIN;
      
      This is also consistent with what the ipv4/udp code does.
      
      Signed-off-by: default avatarXufeng Zhang <xufeng.zhang@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      32c90254
    • Randy Dunlap's avatar
      netconsole: fix build when CONFIG_NETCONSOLE_DYNAMIC is turned on · 58fa4597
      Randy Dunlap authored
      When NETCONSOLE_DYNAMIC=y and CONFIGFS_FS=m, there are build errors
      in netconsole:
      
      drivers/built-in.o: In function `drop_netconsole_target':
      netconsole.c:(.text+0x1a100f): undefined reference to `config_item_put'
      drivers/built-in.o: In function `make_netconsole_target':
      netconsole.c:(.text+0x1a10b9): undefined reference to `config_item_init_type_name'
      drivers/built-in.o: In function `write_msg':
      netconsole.c:(.text+0x1a11a4): undefined reference to `config_item_get'
      netconsole.c:(.text+0x1a1211): undefined reference to `config_item_put'
      drivers/built-in.o: In function `netconsole_netdev_event':
      netconsole.c:(.text+0x1a12cc): undefined reference to `config_item_put'
      netconsole.c:(.text+0x1a12ec): undefined reference to `config_item_get'
      netconsole.c:(.text+0x1a1366): undefined reference to `config_item_put'
      drivers/built-in.o: In function `init_netconsole':
      netconsole.c:(.init.text+0x953a): undefined reference to `config_group_init'
      netconsole.c:(.init.text+0x9560): undefined reference to `configfs_register_subsystem'
      drivers/built-in.o: In function `dynamic_netconsole_exit':
      netconsole.c:(.exit.text+0x809): undefined reference to `configfs_unregister_subsystem'
      
      so fix the NETCONSOLE_DYNAMIC depends clause to prevent this.
      Based on email suggestion from Ben Hutchings.  Thanks.
      
      Fixes https://bugzilla.kernel.org/show_bug.cgi?id=37992
      
      
      
      Reported-by: default avatarDavid Hill <hilld@binarystorm.net>
      Signed-off-by: default avatarRandy Dunlap <randy.dunlap@oracle.com>
      Cc: Ben Hutchings <bhutchings@solarflare.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      58fa4597
  6. Jun 21, 2011
  7. Jun 20, 2011