user/sven/linux.git/include/linux/ceph, branch v4.9.188

libceph: wait for latest osdmap in ceph_monc_blacklist_add()

2019-03-27T05:13:02Z

commit bb229bbb3bf63d23128e851a1f3b85c083178fa1 upstream. Because map updates are distributed lazily, an OSD may not know about the new blacklist for quite some time after "osd blacklist add" command is completed. This makes it possible for a blacklisted but still alive client to overwrite a post-blacklist update, resulting in data corruption. Waiting for latest osdmap in ceph_monc_blacklist_add() and thus using the post-blacklist epoch for all post-blacklist requests ensures that all such requests "wait" for the blacklist to come into force on their respective OSDs. Cc: stable@vger.kernel.org Fixes: 6305a3b41515 ("libceph: support for blacklisting clients") Signed-off-by: Ilya Dryomov Reviewed-by: Jason Dillaman Signed-off-by: Greg Kroah-Hartman

libceph: implement CEPHX_V2 calculation mode

2018-12-08T12:05:10Z

commit cc255c76c70f7a87d97939621eae04b600d9f4a1 upstream. Derive the signature from the entire buffer (both AES cipher blocks) instead of using just the first half of the first block, leaving out data_crc entirely. This addresses CVE-2018-1129. Link: http://tracker.ceph.com/issues/24837 Signed-off-by: Ilya Dryomov Reviewed-by: Sage Weil [bwh: Backported to 4.9: - Define and test the feature bit in the old way - Don't change any other feature bits in ceph_features.h] Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman

libceph: add authorizer challenge

2018-12-08T12:05:10Z

commit 6daca13d2e72bedaaacfc08f873114c9307d5aea upstream. When a client authenticates with a service, an authorizer is sent with a nonce to the service (ceph_x_authorize_[ab]) and the service responds with a mutation of that nonce (ceph_x_authorize_reply). This lets the client verify the service is who it says it is but it doesn't protect against a replay: someone can trivially capture the exchange and reuse the same authorizer to authenticate themselves. Allow the service to reject an initial authorizer with a random challenge (ceph_x_authorize_challenge). The client then has to respond with an updated authorizer proving they are able to decrypt the service's challenge and that the new authorizer was produced for this specific connection instance. The accepting side requires this challenge and response unconditionally if the client side advertises they have CEPHX_V2 feature bit. This addresses CVE-2018-1128. Link: http://tracker.ceph.com/issues/24836 Signed-off-by: Ilya Dryomov Reviewed-by: Sage Weil Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman

libceph: store ceph_auth_handshake pointer in ceph_connection

2018-12-08T12:05:09Z

commit 262614c4294d33b1f19e0d18c0091d9c329b544a upstream. We already copy authorizer_reply_buf and authorizer_reply_buf_len into ceph_connection. Factoring out __prepare_write_connect() requires two more: authorizer_buf and authorizer_buf_len. Store the pointer to the handshake in con->auth rather than piling on. Signed-off-by: Ilya Dryomov Reviewed-by: Sage Weil Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman

libceph: drop len argument of *verify_authorizer_reply()

2018-12-08T12:05:09Z

commit 0dde584882ade13dc9708d611fbf69b0ae8a9e48 upstream. The length of the reply is protocol-dependent - for cephx it's ceph_x_authorize_reply. Nothing sensible can be passed from the messenger layer anyway. Signed-off-by: Ilya Dryomov Reviewed-by: Sage Weil Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman

libceph: bump CEPH_MSG_MAX_DATA_LEN

2018-11-21T08:25:59Z

commit 94e6992bb560be8bffb47f287194adf070b57695 upstream. If the read is large enough, we end up spinning in the messenger: libceph: osd0 192.168.122.1:6801 io error libceph: osd0 192.168.122.1:6801 io error libceph: osd0 192.168.122.1:6801 io error This is a receive side limit, so only reads were affected. Cc: stable@vger.kernel.org Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman

libceph: use BUG() instead of BUG_ON(1)

2017-03-15T02:02:51Z

commit d24cdcd3e40a6825135498e11c20c7976b9bf545 upstream. I ran into this compile warning, which is the result of BUG_ON(1) not always leading to the compiler treating the code path as unreachable: include/linux/ceph/osdmap.h: In function 'ceph_can_shift_osds': include/linux/ceph/osdmap.h:62:1: error: control reaches end of non-void function [-Werror=return-type] Using BUG() here avoids the warning. Signed-off-by: Arnd Bergmann Signed-off-by: Ilya Dryomov Cc: Heinrich Schuchardt Signed-off-by: Greg Kroah-Hartman

libceph: initialize last_linger_id with a large integer

2016-11-10T19:13:08Z

osdc->last_linger_id is a counter for lreq->linger_id, which is used for watch cookies. Starting with a large integer should ease the task of telling apart kernel and userspace clients. Signed-off-by: Ilya Dryomov

ceph: handle CEPH_SESSION_REJECT message

2016-10-03T14:13:50Z

Signed-off-by: Yan, Zheng

rbd: add 'client_addr' sysfs rbd device attribute

2016-08-24T21:49:16Z

Export client addr/nonce, so userspace can check if a image is being blacklisted. Signed-off-by: Mike Christie [idryomov@gmail.com: ceph_client_addr(), endianess fix] Signed-off-by: Ilya Dryomov