06 Aug, 2018

1 commit

  • [ Upstream commit c01f6c9b3207e52fc9973a066a856ddf7a0538d8 ]

    There just check the user call ID isn't already in use, hence should
    compare user_call_ID with xcall->user_call_ID, which is current
    node's user_call_ID.

    Fixes: 540b1c48c37a ("rxrpc: Fix deadlock between call creation and sendmsg/recvmsg")
    Suggested-by: David Howells
    Signed-off-by: YueHaibing
    Signed-off-by: David Howells
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    YueHaibing
     

21 Jun, 2018

2 commits

  • [ Upstream commit 93864fc3ffcc4bf70e96cfb5cc6e941630419ad0 ]

    Fix the kernel call initiation to set the minimum security level for kernel
    initiated calls (such as from kAFS) from the sockopt value.

    Fixes: 19ffa01c9c45 ("rxrpc: Use structs to hold connection params and protocol info")
    Signed-off-by: David Howells
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    David Howells
     
  • [ Upstream commit f2aeed3a591ff29a82495eeaa92ac4780bad7487 ]

    AF_RXRPC tries to turn on IP_RECVERR and IP_MTU_DISCOVER on the UDP socket
    it just opened for communications with the outside world, regardless of the
    type of socket. Unfortunately, this doesn't work with an AF_INET6 socket.

    Fix this by turning on IPV6_RECVERR and IPV6_MTU_DISCOVER instead if the
    socket is of the AF_INET6 family.

    Without this, kAFS server and address rotation doesn't work correctly
    because the algorithm doesn't detect received network errors.

    Fixes: 75b54cb57ca3 ("rxrpc: Add IPv6 support")
    Signed-off-by: David Howells
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    David Howells
     

30 May, 2018

3 commits

  • [ Upstream commit 57b0c9d49b94bbeb53649b7fbd264603c1ebd585 ]

    If a call-level abort is received for the previous call to complete on a
    connection channel, then that abort is queued for the connection processor
    to handle. Unfortunately, the connection processor then assumes without
    checking that the abort is connection-level (ie. callNumber is 0) and
    distributes it over all active calls on that connection, thereby
    incorrectly aborting them.

    Fix this by discarding aborts aimed at a completed call.

    Further, discard all packets aimed at a call that's complete if there's
    currently an active call on a channel, since the DATA packets associated
    with the new call automatically terminate the old call.

    Fixes: 18bfeba50dfd ("rxrpc: Perform terminal call ACK/ABORT retransmission from conn processor")
    Reported-by: Marc Dionne
    Signed-off-by: David Howells
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    David Howells
     
  • [ Upstream commit 03877bf6a30cca7d4bc3ffabd3c3e9464a7a1a19 ]

    rxrpc calls have a ring of packets that are awaiting ACK or retransmission
    and a parallel ring of annotations that tracks the state of those packets.
    If the initial transmission of a packet on the underlying UDP socket fails
    then the packet annotation is marked for resend - but the setting of this
    mark accidentally erases the last-packet mark also stored in the same
    annotation slot. If this happens, a call won't switch out of the Tx phase
    when all the packets have been transmitted.

    Fix this by retaining the last-packet mark and only altering the packet
    state.

    Fixes: 248f219cb8bc ("rxrpc: Rewrite the data and ack handling code")
    Signed-off-by: David Howells
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    David Howells
     
  • [ Upstream commit a16b8d0cf2ec1e626d24bc2a7b9e64ace6f7501d ]

    Due to a check recently added to copy_to_user(), it's now not permitted to
    copy from slab-held data to userspace unless the slab is whitelisted. This
    affects rxrpc_recvmsg() when it attempts to place an RXRPC_USER_CALL_ID
    control message in the userspace control message buffer. A warning is
    generated by usercopy_warn() because the source is the copy of the
    user_call_ID retained in the rxrpc_call struct.

    Work around the issue by copying the user_call_ID to a variable on the
    stack and passing that to put_cmsg().

    The warning generated looks like:

    Bad or missing usercopy whitelist? Kernel memory exposure attempt detected from SLUB object 'dmaengine-unmap-128' (offset 680, size 8)!
    WARNING: CPU: 0 PID: 1401 at mm/usercopy.c:81 usercopy_warn+0x7e/0xa0
    ...
    RIP: 0010:usercopy_warn+0x7e/0xa0
    ...
    Call Trace:
    __check_object_size+0x9c/0x1a0
    put_cmsg+0x98/0x120
    rxrpc_recvmsg+0x6fc/0x1010 [rxrpc]
    ? finish_wait+0x80/0x80
    ___sys_recvmsg+0xf8/0x240
    ? __clear_rsb+0x25/0x3d
    ? __clear_rsb+0x15/0x3d
    ? __clear_rsb+0x25/0x3d
    ? __clear_rsb+0x15/0x3d
    ? __clear_rsb+0x25/0x3d
    ? __clear_rsb+0x15/0x3d
    ? __clear_rsb+0x25/0x3d
    ? __clear_rsb+0x15/0x3d
    ? finish_task_switch+0xa6/0x2b0
    ? trace_hardirqs_on_caller+0xed/0x180
    ? _raw_spin_unlock_irq+0x29/0x40
    ? __sys_recvmsg+0x4e/0x90
    __sys_recvmsg+0x4e/0x90
    do_syscall_64+0x7a/0x220
    entry_SYSCALL_64_after_hwframe+0x26/0x9b

    Reported-by: Jonathan Billings
    Signed-off-by: David Howells
    Acked-by: Kees Cook
    Tested-by: Jonathan Billings
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    David Howells
     

26 Apr, 2018

1 commit

  • [ Upstream commit 8c2f826dc36314059ac146c78d3bf8056b626446 ]

    Don't put buffers of data to be handed to crypto on the stack as this may
    cause an assertion failure in the kernel (see below). Fix this by using an
    kmalloc'd buffer instead.

    kernel BUG at ./include/linux/scatterlist.h:147!
    ...
    RIP: 0010:rxkad_encrypt_response.isra.6+0x191/0x1b0 [rxrpc]
    RSP: 0018:ffffbe2fc06cfca8 EFLAGS: 00010246
    RAX: 0000000000000000 RBX: ffff989277d59900 RCX: 0000000000000028
    RDX: 0000259dc06cfd88 RSI: 0000000000000025 RDI: ffffbe30406cfd88
    RBP: ffffbe2fc06cfd60 R08: ffffbe2fc06cfd08 R09: ffffbe2fc06cfd08
    R10: 0000000000000000 R11: 0000000000000000 R12: 1ffff7c5f80d9f95
    R13: ffffbe2fc06cfd88 R14: ffff98927a3f7aa0 R15: ffffbe2fc06cfd08
    FS: 0000000000000000(0000) GS:ffff98927fc00000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 000055b1ff28f0f8 CR3: 000000001b412003 CR4: 00000000003606f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
    rxkad_respond_to_challenge+0x297/0x330 [rxrpc]
    rxrpc_process_connection+0xd1/0x690 [rxrpc]
    ? process_one_work+0x1c3/0x680
    ? __lock_is_held+0x59/0xa0
    process_one_work+0x249/0x680
    worker_thread+0x3a/0x390
    ? process_one_work+0x680/0x680
    kthread+0x121/0x140
    ? kthread_create_worker_on_cpu+0x70/0x70
    ret_from_fork+0x3a/0x50

    Reported-by: Jonathan Billings
    Reported-by: Marc Dionne
    Signed-off-by: David Howells
    Tested-by: Jonathan Billings
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    David Howells
     

09 Mar, 2018

1 commit

  • [ Upstream commit 93c62c45ed5fad1b87e3a45835b251cd68de9c46 ]

    All the kernel_sendmsg() calls in rxrpc_send_data_packet() need to send
    both parts of the iov[] buffer, but one of them does not. Fix it so that
    it does.

    Without this, short IPv6 rxrpc DATA packets may be seen that have the rxrpc
    header included, but no payload.

    Fixes: 5a924b8951f8 ("rxrpc: Don't store the rxrpc header in the Tx queue sk_buffs")
    Reported-by: Marc Dionne
    Signed-off-by: David Howells
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    David Howells
     

04 Feb, 2018

3 commits

  • [ Upstream commit f859ab61875978eeaa539740ff7f7d91f5d60006 ]

    RxRPC service endpoints expire like they're supposed to by the following
    means:

    (1) Mark dead rxrpc_net structs (with ->live) rather than twiddling the
    global service conn timeout, otherwise the first rxrpc_net struct to
    die will cause connections on all others to expire immediately from
    then on.

    (2) Mark local service endpoints for which the socket has been closed
    (->service_closed) so that the expiration timeout can be much
    shortened for service and client connections going through that
    endpoint.

    (3) rxrpc_put_service_conn() needs to schedule the reaper when the usage
    count reaches 1, not 0, as idle conns have a 1 count.

    (4) The accumulator for the earliest time we might want to schedule for
    should be initialised to jiffies + MAX_JIFFY_OFFSET, not ULONG_MAX as
    the comparison functions use signed arithmetic.

    (5) Simplify the expiration handling, adding the expiration value to the
    idle timestamp each time rather than keeping track of the time in the
    past before which the idle timestamp must go to be expired. This is
    much easier to read.

    (6) Ignore the timeouts if the net namespace is dead.

    (7) Restart the service reaper work item rather the client reaper.

    Signed-off-by: David Howells
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    David Howells
     
  • [ Upstream commit 9faaff593404a9c4e5abc6839a641635d7b9d0cd ]

    Provide a different lockdep key for rxrpc_call::user_mutex when the call is
    made on a kernel socket, such as by the AFS filesystem.

    The problem is that lockdep registers a false positive between userspace
    calling the sendmsg syscall on a user socket where call->user_mutex is held
    whilst userspace memory is accessed whereas the AFS filesystem may perform
    operations with mmap_sem held by the caller.

    In such a case, the following warning is produced.

    ======================================================
    WARNING: possible circular locking dependency detected
    4.14.0-fscache+ #243 Tainted: G E
    ------------------------------------------------------
    modpost/16701 is trying to acquire lock:
    (&vnode->io_lock){+.+.}, at: [] afs_begin_vnode_operation+0x33/0x77 [kafs]

    but task is already holding lock:
    (&mm->mmap_sem){++++}, at: [] __do_page_fault+0x1ef/0x486

    which lock already depends on the new lock.

    the existing dependency chain (in reverse order) is:

    -> #3 (&mm->mmap_sem){++++}:
    __might_fault+0x61/0x89
    _copy_from_iter_full+0x40/0x1fa
    rxrpc_send_data+0x8dc/0xff3
    rxrpc_do_sendmsg+0x62f/0x6a1
    rxrpc_sendmsg+0x166/0x1b7
    sock_sendmsg+0x2d/0x39
    ___sys_sendmsg+0x1ad/0x22b
    __sys_sendmsg+0x41/0x62
    do_syscall_64+0x89/0x1be
    return_from_SYSCALL_64+0x0/0x75

    -> #2 (&call->user_mutex){+.+.}:
    __mutex_lock+0x86/0x7d2
    rxrpc_new_client_call+0x378/0x80e
    rxrpc_kernel_begin_call+0xf3/0x154
    afs_make_call+0x195/0x454 [kafs]
    afs_vl_get_capabilities+0x193/0x198 [kafs]
    afs_vl_lookup_vldb+0x5f/0x151 [kafs]
    afs_create_volume+0x2e/0x2f4 [kafs]
    afs_mount+0x56a/0x8d7 [kafs]
    mount_fs+0x6a/0x109
    vfs_kern_mount+0x67/0x135
    do_mount+0x90b/0xb57
    SyS_mount+0x72/0x98
    do_syscall_64+0x89/0x1be
    return_from_SYSCALL_64+0x0/0x75

    -> #1 (k-sk_lock-AF_RXRPC){+.+.}:
    lock_sock_nested+0x74/0x8a
    rxrpc_kernel_begin_call+0x8a/0x154
    afs_make_call+0x195/0x454 [kafs]
    afs_fs_get_capabilities+0x17a/0x17f [kafs]
    afs_probe_fileserver+0xf7/0x2f0 [kafs]
    afs_select_fileserver+0x83f/0x903 [kafs]
    afs_fetch_status+0x89/0x11d [kafs]
    afs_iget+0x16f/0x4f8 [kafs]
    afs_mount+0x6c6/0x8d7 [kafs]
    mount_fs+0x6a/0x109
    vfs_kern_mount+0x67/0x135
    do_mount+0x90b/0xb57
    SyS_mount+0x72/0x98
    do_syscall_64+0x89/0x1be
    return_from_SYSCALL_64+0x0/0x75

    -> #0 (&vnode->io_lock){+.+.}:
    lock_acquire+0x174/0x19f
    __mutex_lock+0x86/0x7d2
    afs_begin_vnode_operation+0x33/0x77 [kafs]
    afs_fetch_data+0x80/0x12a [kafs]
    afs_readpages+0x314/0x405 [kafs]
    __do_page_cache_readahead+0x203/0x2ba
    filemap_fault+0x179/0x54d
    __do_fault+0x17/0x60
    __handle_mm_fault+0x6d7/0x95c
    handle_mm_fault+0x24e/0x2a3
    __do_page_fault+0x301/0x486
    do_page_fault+0x236/0x259
    page_fault+0x22/0x30
    __clear_user+0x3d/0x60
    padzero+0x1c/0x2b
    load_elf_binary+0x785/0xdc7
    search_binary_handler+0x81/0x1ff
    do_execveat_common.isra.14+0x600/0x888
    do_execve+0x1f/0x21
    SyS_execve+0x28/0x2f
    do_syscall_64+0x89/0x1be
    return_from_SYSCALL_64+0x0/0x75

    other info that might help us debug this:

    Chain exists of:
    &vnode->io_lock --> &call->user_mutex --> &mm->mmap_sem

    Possible unsafe locking scenario:

    CPU0 CPU1
    ---- ----
    lock(&mm->mmap_sem);
    lock(&call->user_mutex);
    lock(&mm->mmap_sem);
    lock(&vnode->io_lock);

    *** DEADLOCK ***

    1 lock held by modpost/16701:
    #0: (&mm->mmap_sem){++++}, at: [] __do_page_fault+0x1ef/0x486

    stack backtrace:
    CPU: 0 PID: 16701 Comm: modpost Tainted: G E 4.14.0-fscache+ #243
    Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014
    Call Trace:
    dump_stack+0x67/0x8e
    print_circular_bug+0x341/0x34f
    check_prev_add+0x11f/0x5d4
    ? add_lock_to_list.isra.12+0x8b/0x8b
    ? add_lock_to_list.isra.12+0x8b/0x8b
    ? __lock_acquire+0xf77/0x10b4
    __lock_acquire+0xf77/0x10b4
    lock_acquire+0x174/0x19f
    ? afs_begin_vnode_operation+0x33/0x77 [kafs]
    __mutex_lock+0x86/0x7d2
    ? afs_begin_vnode_operation+0x33/0x77 [kafs]
    ? afs_begin_vnode_operation+0x33/0x77 [kafs]
    ? afs_begin_vnode_operation+0x33/0x77 [kafs]
    afs_begin_vnode_operation+0x33/0x77 [kafs]
    afs_fetch_data+0x80/0x12a [kafs]
    afs_readpages+0x314/0x405 [kafs]
    __do_page_cache_readahead+0x203/0x2ba
    ? filemap_fault+0x179/0x54d
    filemap_fault+0x179/0x54d
    __do_fault+0x17/0x60
    __handle_mm_fault+0x6d7/0x95c
    handle_mm_fault+0x24e/0x2a3
    __do_page_fault+0x301/0x486
    do_page_fault+0x236/0x259
    page_fault+0x22/0x30
    RIP: 0010:__clear_user+0x3d/0x60
    RSP: 0018:ffff880071e93da0 EFLAGS: 00010202
    RAX: 0000000000000000 RBX: 000000000000011c RCX: 000000000000011c
    RDX: 0000000000000000 RSI: 0000000000000008 RDI: 000000000060f720
    RBP: 000000000060f720 R08: 0000000000000001 R09: 0000000000000000
    R10: 0000000000000001 R11: ffff8800b5459b68 R12: ffff8800ce150e00
    R13: 000000000060f720 R14: 00000000006127a8 R15: 0000000000000000
    padzero+0x1c/0x2b
    load_elf_binary+0x785/0xdc7
    search_binary_handler+0x81/0x1ff
    do_execveat_common.isra.14+0x600/0x888
    do_execve+0x1f/0x21
    SyS_execve+0x28/0x2f
    do_syscall_64+0x89/0x1be
    entry_SYSCALL64_slow_path+0x25/0x25
    RIP: 0033:0x7fdb6009ee07
    RSP: 002b:00007fff566d9728 EFLAGS: 00000246 ORIG_RAX: 000000000000003b
    RAX: ffffffffffffffda RBX: 000055ba57280900 RCX: 00007fdb6009ee07
    RDX: 000055ba5727f270 RSI: 000055ba5727cac0 RDI: 000055ba57280900
    RBP: 000055ba57280900 R08: 00007fff566d9700 R09: 0000000000000000
    R10: 000055ba5727cac0 R11: 0000000000000246 R12: 0000000000000000
    R13: 000055ba5727cac0 R14: 000055ba5727f270 R15: 0000000000000000

    Signed-off-by: David Howells
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    David Howells
     
  • [ Upstream commit 03a6c82218b9a87014b2c6c4e178294fdc8ebd8a ]

    The caller of rxrpc_accept_call() must release the lock on call->user_mutex
    returned by that function.

    Signed-off-by: David Howells
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    David Howells
     

02 Nov, 2017

1 commit

  • Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

22 Oct, 2017

1 commit

  • Don't release call mutex at the end of rxrpc_kernel_begin_call() if the
    call pointer actually holds an error value.

    Fixes: 540b1c48c37a ("rxrpc: Fix deadlock between call creation and sendmsg/recvmsg")
    Reported-by: Marc Dionne
    Signed-off-by: David Howells
    Signed-off-by: David S. Miller

    David Howells
     

06 Sep, 2017

1 commit

  • When an RxRPC service packet comes in, the target connection is looked up
    by an rb-tree search under RCU and a read-locked seqlock; the seqlock retry
    check is, however, currently skipped if we got a match, but probably
    shouldn't be in case the connection we found gets replaced whilst we're
    doing a search.

    Make the lookup procedure always go through need_seqretry(), even if the
    lookup was successful. This makes sure we always pick up on a write-lock
    event.

    On the other hand, since we don't take a ref on the object, but rely on RCU
    to prevent its destruction after dropping the seqlock, I'm not sure this is
    necessary.

    Signed-off-by: David Howells
    Signed-off-by: David S. Miller

    David Howells
     

29 Aug, 2017

7 commits

  • Allow a client call that failed on network error to be retried, provided
    that the Tx queue still holds DATA packet 1. This allows an operation to
    be submitted to another server or another address for the same server
    without having to repackage and re-encrypt the data so far processed.

    Two new functions are provided:

    (1) rxrpc_kernel_check_call() - This is used to find out the completion
    state of a call to guess whether it can be retried and whether it
    should be retried.

    (2) rxrpc_kernel_retry_call() - Disconnect the call from its current
    connection, reset the state and submit it as a new client call to a
    new address. The new address need not match the previous address.

    A call may be retried even if all the data hasn't been loaded into it yet;
    a partially constructed will be retained at the same point it was at when
    an error condition was detected. msg_data_left() can be used to find out
    how much data was packaged before the error occurred.

    Signed-off-by: David Howells

    David Howells
     
  • Add a callback to rxrpc_kernel_send_data() so that a kernel service can get
    a notification that the AF_RXRPC call has transitioned out the Tx phase and
    is now waiting for a reply or a final ACK.

    This is called from AF_RXRPC with the call state lock held so the
    notification is guaranteed to come before any reply is passed back.

    Further, modify the AFS filesystem to make use of this so that we don't have
    to change the afs_call state before sending the last bit of data.

    Signed-off-by: David Howells

    David Howells
     
  • Remove indentation from some blank lines.

    Signed-off-by: David Howells

    David Howells
     
  • call->error is stored as 0 or a negative error code. Don't negate this
    value (ie. make it positive) before returning it from a kernel function
    (though it should still be negated before passing to userspace through a
    control message).

    Signed-off-by: David Howells

    David Howells
     
  • Fix IPv6 support in AF_RXRPC in the following ways:

    (1) When extracting the address from a received IPv4 packet, if the local
    transport socket is open for IPv6 then fill out the sockaddr_rxrpc
    struct for an IPv4-mapped-to-IPv6 AF_INET6 transport address instead
    of an AF_INET one.

    (2) When sending CHALLENGE or RESPONSE packets, the transport length needs
    to be set from the sockaddr_rxrpc::transport_len field rather than
    sizeof() on the IPv4 transport address.

    (3) When processing an IPv4 ICMP packet received by an IPv6 socket, set up
    the address correctly before searching for the affected peer.

    Signed-off-by: David Howells

    David Howells
     
  • When an XDR-encoded Kerberos 5 ticket is added as an rxrpc-type key, the
    expiry time should be drawn from the k5 part of the token union (which was
    what was filled in), rather than the kad part of the union.

    Reported-by: Arnd Bergmann
    Signed-off-by: David Howells

    David Howells
     
  • Since the 'expiry' variable of 'struct key_preparsed_payload' has been
    changed to 'time64_t' type, which is year 2038 safe on 32bits system.

    In net/rxrpc subsystem, we need convert 'u32' type to 'time64_t' type
    when copying ticket expires time to 'prep->expiry', then this patch
    introduces two helper functions to help convert 'u32' to 'time64_t'
    type.

    This patch also uses ktime_get_real_seconds() to get current time instead
    of get_seconds() which is not year 2038 safe on 32bits system.

    Signed-off-by: Baolin Wang
    Signed-off-by: David Howells

    Baolin Wang
     

22 Aug, 2017

1 commit


19 Aug, 2017

1 commit

  • rxrpc_service_prealloc_one() doesn't set the socket pointer on any new call
    it preallocates, but does add it to the rxrpc net namespace call list.
    This, however, causes rxrpc_put_call() to oops when the call is discarded
    when the socket is closed. rxrpc_put_call() needs the socket to be able to
    reach the namespace so that it can use a lock held therein.

    Fix this by setting a call's socket pointer immediately before discarding
    it.

    This can be triggered by unloading the kafs module, resulting in an oops
    like the following:

    BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
    IP: rxrpc_put_call+0x1e2/0x32d
    PGD 0
    P4D 0
    Oops: 0000 [#1] SMP
    Modules linked in: kafs(E-)
    CPU: 3 PID: 3037 Comm: rmmod Tainted: G E 4.12.0-fscache+ #213
    Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014
    task: ffff8803fc92e2c0 task.stack: ffff8803fef74000
    RIP: 0010:rxrpc_put_call+0x1e2/0x32d
    RSP: 0018:ffff8803fef77e08 EFLAGS: 00010282
    RAX: 0000000000000000 RBX: ffff8803fab99ac0 RCX: 000000000000000f
    RDX: ffffffff81c50a40 RSI: 000000000000000c RDI: ffff8803fc92ea88
    RBP: ffff8803fef77e30 R08: ffff8803fc87b941 R09: ffffffff82946d20
    R10: ffff8803fef77d10 R11: 00000000000076fc R12: 0000000000000005
    R13: ffff8803fab99c20 R14: 0000000000000001 R15: ffffffff816c6aee
    FS: 00007f915a059700(0000) GS:ffff88041fb80000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000030 CR3: 00000003fef39000 CR4: 00000000001406e0
    Call Trace:
    rxrpc_discard_prealloc+0x325/0x341
    rxrpc_listen+0xf9/0x146
    kernel_listen+0xb/0xd
    afs_close_socket+0x3e/0x173 [kafs]
    afs_exit+0x1f/0x57 [kafs]
    SyS_delete_module+0x10f/0x19a
    do_syscall_64+0x8a/0x149
    entry_SYSCALL64_slow_path+0x25/0x25

    Fixes: 2baec2c3f854 ("rxrpc: Support network namespacing")
    Signed-off-by: David Howells
    Signed-off-by: David S. Miller

    David Howells
     

21 Jul, 2017

1 commit

  • Move the protocol description header file into net/rxrpc/ and rename it to
    protocol.h. It's no longer necessary to expose it as packets are no longer
    exposed to kernel services (such as AFS) that use the facility.

    The abort codes are transferred to the UAPI header instead as we pass these
    back to userspace and also to kernel services.

    Signed-off-by: David Howells

    David Howells
     

01 Jul, 2017

3 commits

  • refcount_t type and corresponding API should be
    used instead of atomic_t when the variable is used as
    a reference counter. This allows to avoid accidental
    refcounter overflows that might lead to use-after-free
    situations.

    This patch uses refcount_inc_not_zero() instead of
    atomic_inc_not_zero_hint() due to absense of a _hint()
    version of refcount API. If the hint() version must
    be used, we might need to revisit API.

    Signed-off-by: Elena Reshetova
    Signed-off-by: Hans Liljestrand
    Signed-off-by: Kees Cook
    Signed-off-by: David Windsor
    Signed-off-by: David S. Miller

    Reshetova, Elena
     
  • refcount_t type and corresponding API should be
    used instead of atomic_t when the variable is used as
    a reference counter. This allows to avoid accidental
    refcounter overflows that might lead to use-after-free
    situations.

    Signed-off-by: Elena Reshetova
    Signed-off-by: Hans Liljestrand
    Signed-off-by: Kees Cook
    Signed-off-by: David Windsor
    Signed-off-by: David S. Miller

    Reshetova, Elena
     
  • refcount_t type and corresponding API should be
    used instead of atomic_t when the variable is used as
    a reference counter. This allows to avoid accidental
    refcounter overflows that might lead to use-after-free
    situations.

    Signed-off-by: Elena Reshetova
    Signed-off-by: Hans Liljestrand
    Signed-off-by: Kees Cook
    Signed-off-by: David Windsor
    Signed-off-by: David S. Miller

    Reshetova, Elena
     

22 Jun, 2017

1 commit


16 Jun, 2017

2 commits

  • There were many places that my previous spatch didn't find,
    as pointed out by yuan linyu in various patches.

    The following spatch found many more and also removes the
    now unnecessary casts:

    @@
    identifier p, p2;
    expression len;
    expression skb;
    type t, t2;
    @@
    (
    -p = skb_put(skb, len);
    +p = skb_put_zero(skb, len);
    |
    -p = (t)skb_put(skb, len);
    +p = skb_put_zero(skb, len);
    )
    ... when != p
    (
    p2 = (t2)p;
    -memset(p2, 0, len);
    |
    -memset(p, 0, len);
    )

    @@
    type t, t2;
    identifier p, p2;
    expression skb;
    @@
    t *p;
    ...
    (
    -p = skb_put(skb, sizeof(t));
    +p = skb_put_zero(skb, sizeof(t));
    |
    -p = (t *)skb_put(skb, sizeof(t));
    +p = skb_put_zero(skb, sizeof(t));
    )
    ... when != p
    (
    p2 = (t2)p;
    -memset(p2, 0, sizeof(*p));
    |
    -memset(p, 0, sizeof(*p));
    )

    @@
    expression skb, len;
    @@
    -memset(skb_put(skb, len), 0, len);
    +skb_put_zero(skb, len);

    Apply it to the tree (with one manual fixup to keep the
    comment in vxlan.c, which spatch removed.)

    Signed-off-by: Johannes Berg
    Signed-off-by: David S. Miller

    Johannes Berg
     
  • This fixes CVE-2017-7482.

    When a kerberos 5 ticket is being decoded so that it can be loaded into an
    rxrpc-type key, there are several places in which the length of a
    variable-length field is checked to make sure that it's not going to
    overrun the available data - but the data is padded to the nearest
    four-byte boundary and the code doesn't check for this extra. This could
    lead to the size-remaining variable wrapping and the data pointer going
    over the end of the buffer.

    Fix this by making the various variable-length data checks use the padded
    length.

    Reported-by: 石磊
    Signed-off-by: David Howells
    Reviewed-by: Marc Dionne
    Reviewed-by: Dan Carpenter
    Signed-off-by: David S. Miller

    David Howells
     

15 Jun, 2017

1 commit

  • Cache the congestion window setting that was determined during a call's
    transmission phase when it finishes so that it can be used by the next call
    to the same peer, thereby shortcutting the slow-start algorithm.

    The value is stored in the rxrpc_peer struct and is accessed without
    locking. Each call takes the value that happens to be there when it starts
    and just overwrites the value when it finishes.

    Signed-off-by: David Howells
    Signed-off-by: David S. Miller

    David Howells
     

08 Jun, 2017

3 commits

  • Provide a control message that can be specified on the first sendmsg() of a
    client call or the first sendmsg() of a service response to indicate the
    total length of the data to be transmitted for that call.

    Currently, because the length of the payload of an encrypted DATA packet is
    encrypted in front of the data, the packet cannot be encrypted until we
    know how much data it will hold.

    By specifying the length at the beginning of the transmit phase, each DATA
    packet length can be set before we start loading data from userspace (where
    several sendmsg() calls may contribute to a particular packet).

    An error will be returned if too little or too much data is presented in
    the Tx phase.

    Signed-off-by: David Howells

    David Howells
     
  • Consolidate the sendmsg control message parameters into a struct rather
    than passing them individually through the argument list of
    rxrpc_sendmsg_cmsg(). This makes it easier to add more parameters.

    Signed-off-by: David Howells

    David Howells
     
  • Provide a getsockopt() call that can query what cmsg types are supported by
    AF_RXRPC.

    David Howells
     

05 Jun, 2017

6 commits

  • Make it possible for a client to use AuriStor's service upgrade facility.

    The client does this by adding an RXRPC_UPGRADE_SERVICE control message to
    the first sendmsg() of a call. This takes no parameters.

    When recvmsg() starts returning data from the call, the service ID field in
    the returned msg_name will reflect the result of the upgrade attempt. If
    the upgrade was ignored, srx_service will match what was set in the
    sendmsg(); if the upgrade happened the srx_service will be altered to
    indicate the service the server upgraded to.

    Note that:

    (1) The choice of upgrade service is up to the server

    (2) Further client calls to the same server that would share a connection
    are blocked if an upgrade probe is in progress.

    (3) This should only be used to probe the service. Clients should then
    use the returned service ID in all subsequent communications with that
    server (and not set the upgrade). Note that the kernel will not
    retain this information should the connection expire from its cache.

    (4) If a server that supports upgrading is replaced by one that doesn't,
    whilst a connection is live, and if the replacement is running, say,
    OpenAFS 1.6.4 or older or an older IBM AFS, then the replacement
    server will not respond to packets sent to the upgraded connection.

    At this point, calls will time out and the server must be reprobed.

    Signed-off-by: David Howells

    David Howells
     
  • Implement AuriStor's service upgrade facility. There are three problems
    that this is meant to deal with:

    (1) Various of the standard AFS RPC calls have IPv4 addresses in their
    requests and/or replies - but there's no room for including IPv6
    addresses.

    (2) Definition of IPv6-specific RPC operations in the standard operation
    sets has not yet been achieved.

    (3) One could envision the creation a new service on the same port that as
    the original service. The new service could implement improved
    operations - and the client could try this first, falling back to the
    original service if it's not there.

    Unfortunately, certain servers ignore packets addressed to a service
    they don't implement and don't respond in any way - not even with an
    ABORT. This means that the client must then wait for the call timeout
    to occur.

    What service upgrade does is to see if the connection is marked as being
    'upgradeable' and if so, change the service ID in the server and thus the
    request and reply formats. Note that the upgrade isn't mandatory - a
    server that supports only the original call set will ignore the upgrade
    request.

    In the protocol, the procedure is then as follows:

    (1) To request an upgrade, the first DATA packet in a new connection must
    have the userStatus set to 1 (this is normally 0). The userStatus
    value is normally ignored by the server.

    (2) If the server doesn't support upgrading, the reply packets will
    contain the same service ID as for the first request packet.

    (3) If the server does support upgrading, all future reply packets on that
    connection will contain the new service ID and the new service ID will
    be applied to *all* further calls on that connection as well.

    (4) The RPC op used to probe the upgrade must take the same request data
    as the shadow call in the upgrade set (but may return a different
    reply). GetCapability RPC ops were added to all standard sets for
    just this purpose. Ops where the request formats differ cannot be
    used for probing.

    (5) The client must wait for completion of the probe before sending any
    further RPC ops to the same destination. It should then use the
    service ID that recvmsg() reported back in all future calls.

    (6) The shadow service must have call definitions for all the operation
    IDs defined by the original service.

    To support service upgrading, a server should:

    (1) Call bind() twice on its AF_RXRPC socket before calling listen().
    Each bind() should supply a different service ID, but the transport
    addresses must be the same. This allows the server to receive
    requests with either service ID.

    (2) Enable automatic upgrading by calling setsockopt(), specifying
    RXRPC_UPGRADEABLE_SERVICE and passing in a two-member array of
    unsigned shorts as the argument:

    unsigned short optval[2];

    This specifies a pair of service IDs. They must be different and must
    match the service IDs bound to the socket. Member 0 is the service ID
    to upgrade from and member 1 is the service ID to upgrade to.

    Signed-off-by: David Howells

    David Howells
     
  • Permit bind() to be called on an AF_RXRPC socket more than once (currently
    maximum twice) to bind multiple listening services to it. There are some
    restrictions:

    (1) All bind() calls involved must have a non-zero service ID.

    (2) The service IDs must all be different.

    (3) The rest of the address (notably the transport part) must be the same
    in all (a single UDP socket is shared).

    (4) This must be done before listen() or sendmsg() is called.

    This allows someone to connect to the service socket with different service
    IDs and lays the foundation for service upgrading.

    The service ID used by an incoming call can be extracted from the msg_name
    returned by recvmsg().

    Signed-off-by: David Howells

    David Howells
     
  • Keep the rxrpc_connection struct's idea of the service ID that is exposed
    in the protocol separate from the service ID that's used as a lookup key.

    This allows the protocol service ID on a client connection to get upgraded
    without making the connection unfindable for other client calls that also
    would like to use the upgraded connection.

    The connection's actual service ID is then returned through recvmsg() by
    way of msg_name.

    Whilst we're at it, we get rid of the last_service_id field from each
    channel. The service ID is per-connection, not per-call and an entire
    connection is upgraded in one go.

    Signed-off-by: David Howells

    David Howells
     
  • Signed-off-by: Jason A. Donenfeld
    Acked-by: David Howells
    Signed-off-by: David S. Miller

    Jason A. Donenfeld
     
  • The proc_remove call is dead code as it occurs after a return and
    hence can never be called. Remove it.

    Detected by CoverityScan, CID#1437743 ("Logically dead code")

    Signed-off-by: Colin Ian King
    Acked-by: David Howells
    Signed-off-by: David S. Miller

    Colin Ian King