1. 05 10月, 2018 1 次提交
    • D
      dns: Allow the dns resolver to retrieve a server set · bbb4c432
      David Howells 提交于
      Allow the DNS resolver to retrieve a set of servers and their associated
      addresses, ports, preference and weight ratings.
      
      In terms of communication with userspace, "srv=1" is added to the callout
      string (the '1' indicating the maximum data version supported by the
      kernel) to ask the userspace side for this.
      
      If the userspace side doesn't recognise it, it will ignore the option and
      return the usual text address list.
      
      If the userspace side does recognise it, it will return some binary data
      that begins with a zero byte that would cause the string parsers to give an
      error.  The second byte contains the version of the data in the blob (this
      may be between 1 and the version specified in the callout data).  The
      remainder of the payload is version-specific.
      
      In version 1, the payload looks like (note that this is packed):
      
      	u8	Non-string marker (ie. 0)
      	u8	Content (0 => Server list)
      	u8	Version (ie. 1)
      	u8	Source (eg. DNS_RECORD_FROM_DNS_SRV)
      	u8	Status (eg. DNS_LOOKUP_GOOD)
      	u8	Number of servers
      	foreach-server {
      		u16	Name length (LE)
      		u16	Priority (as per SRV record) (LE)
      		u16	Weight (as per SRV record) (LE)
      		u16	Port (LE)
      		u8	Source (eg. DNS_RECORD_FROM_NSS)
      		u8	Status (eg. DNS_LOOKUP_GOT_NOT_FOUND)
      		u8	Protocol (eg. DNS_SERVER_PROTOCOL_UDP)
      		u8	Number of addresses
      		char[]	Name (not NUL-terminated)
      		foreach-address {
      			u8		Family (AF_INET{,6})
      			union {
      				u8[4]	ipv4_addr
      				u8[16]	ipv6_addr
      			}
      		}
      	}
      
      This can then be used to fetch a whole cell's VL-server configuration for
      AFS, for example.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bbb4c432
  2. 04 10月, 2018 4 次提交
  3. 03 10月, 2018 9 次提交
  4. 02 10月, 2018 14 次提交
  5. 30 9月, 2018 2 次提交
  6. 29 9月, 2018 5 次提交
    • M
      Bluetooth: Fix debugfs NULL pointer dereference · 30d65e08
      Matias Karhumaa 提交于
      Fix crash caused by NULL pointer dereference when debugfs functions
      le_max_key_read, le_max_key_size_write, le_min_key_size_read or
      le_min_key_size_write and Bluetooth adapter was powered off.
      
      Fix is to move max_key_size and min_key_size from smp_dev to hci_dev.
      At the same time they were renamed to le_max_key_size and
      le_min_key_size.
      
      BUG: unable to handle kernel NULL pointer dereference at 00000000000002e8
      PGD 0 P4D 0
      Oops: 0000 [#24] SMP PTI
      CPU: 2 PID: 6255 Comm: cat Tainted: G      D    OE     4.18.9-200.fc28.x86_64 #1
      Hardware name: LENOVO 4286CTO/4286CTO, BIOS 8DET76WW (1.46 ) 06/21/2018
      RIP: 0010:le_max_key_size_read+0x45/0xb0 [bluetooth]
      Code: 00 00 00 48 83 ec 10 65 48 8b 04 25 28 00 00 00 48 89 44 24 08 31 c0 48 8b 87 c8 00 00 00 48 8d 7c 24 04 48 8b 80 48 0a 00 00 <48> 8b 80 e8 02 00 00 0f b6 48 52 e8 fb b6 b3 ed be 04 00 00 00 48
      RSP: 0018:ffffab23c3ff3df0 EFLAGS: 00010246
      RAX: 0000000000000000 RBX: 00007f0b4ca2e000 RCX: ffffab23c3ff3f08
      RDX: ffffffffc0ddb033 RSI: 0000000000000004 RDI: ffffab23c3ff3df4
      RBP: 0000000000020000 R08: 0000000000000000 R09: 0000000000000000
      R10: ffffab23c3ff3ed8 R11: 0000000000000000 R12: ffffab23c3ff3f08
      R13: 00007f0b4ca2e000 R14: 0000000000020000 R15: ffffab23c3ff3f08
      FS:  00007f0b4ca0f540(0000) GS:ffff91bd5e280000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000000000002e8 CR3: 00000000629fa006 CR4: 00000000000606e0
      Call Trace:
       full_proxy_read+0x53/0x80
       __vfs_read+0x36/0x180
       vfs_read+0x8a/0x140
       ksys_read+0x4f/0xb0
       do_syscall_64+0x5b/0x160
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      Signed-off-by: NMatias Karhumaa <matias.karhumaa@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      30d65e08
    • J
      netlink: add nested array policy validation · 1501d135
      Johannes Berg 提交于
      Sometimes nested netlink attributes are just used as arrays, with
      the nla_type() of each not being used; we have this in nl80211 and
      e.g. NFTA_SET_ELEM_LIST_ELEMENTS.
      
      Add the ability to validate this type of message directly in the
      policy, by adding the type NLA_NESTED_ARRAY which does exactly
      this: require a first level of nesting but ignore the attribute
      type, and then inside each require a second level of nested and
      validate those attributes against a given policy (if present).
      
      Note that some nested array types actually require that all of
      the entries have the same index, this is possible to express in
      a nested policy already, apart from the validation that only the
      one allowed type is used.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1501d135
    • J
      netlink: allow NLA_NESTED to specify nested policy to validate · 9a659a35
      Johannes Berg 提交于
      Now that we have a validation_data pointer, and the len field in
      the policy is unused for NLA_NESTED, we can allow using them both
      to have nested validation. This can be nice in code, although we
      still have to use nla_parse_nested() or similar which would also
      take a policy; however, it also serves as documentation in the
      policy without requiring a look at the code.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9a659a35
    • J
      netlink: make validation_data const · 48fde90a
      Johannes Berg 提交于
      The validation data is only used within the policy that
      should usually already be const, and isn't changed in any
      code that uses it. Therefore, make the validation_data
      pointer const.
      
      While at it, remove the duplicate variable in the bitfield
      validation that I'd otherwise have to change to const.
      Reviewed-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      48fde90a
    • J
      netlink: remove NLA_NESTED_COMPAT · fe3b30dd
      Johannes Berg 提交于
      This isn't used anywhere, so we might as well get rid of it.
      Reviewed-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fe3b30dd
  7. 28 9月, 2018 2 次提交
    • F
      netfilter: avoid erronous array bounds warning · 421c119f
      Florian Westphal 提交于
      Unfortunately some versions of gcc emit following warning:
        $ make net/xfrm/xfrm_output.o
        linux/compiler.h:252:20: warning: array subscript is above array bounds [-Warray-bounds]
        hook_head = rcu_dereference(net->nf.hooks_arp[hook]);
                                  ^~~~~~~~~~~~~~~~~~~~~
      xfrm_output_resume passes skb_dst(skb)->ops->family as its 'pf' arg so compiler
      can't know that we'll never access hooks_arp[].
      (NFPROTO_IPV4 or NFPROTO_IPV6 are only possible cases).
      
      Avoid this by adding an explicit WARN_ON_ONCE() check.
      
      This patch has no effect if the family is a compile-time constant as gcc
      will remove the switch() construct entirely.
      Reported-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Reviewed-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      421c119f
    • D
      rxrpc: Fix error distribution · f3344303
      David Howells 提交于
      Fix error distribution by immediately delivering the errors to all the
      affected calls rather than deferring them to a worker thread.  The problem
      with the latter is that retries and things can happen in the meantime when we
      want to stop that sooner.
      
      To this end:
      
       (1) Stop the error distributor from removing calls from the error_targets
           list so that peer->lock isn't needed to synchronise against other adds
           and removals.
      
       (2) Require the peer's error_targets list to be accessed with RCU, thereby
           avoiding the need to take peer->lock over distribution.
      
       (3) Don't attempt to affect a call's state if it is already marked complete.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      f3344303
  8. 27 9月, 2018 3 次提交