linux.git/net/ceph, branch v4.19

crush: fix using plain integer as NULL warning

2018-08-13T15:55:44+00:00

Fixes the following sparse warnings:

net/ceph/crush/mapper.c:517:76: warning: Using plain integer as NULL pointer
net/ceph/crush/mapper.c:728:68: warning: Using plain integer as NULL pointer

Signed-off-by: YueHaibing 
Reviewed-by: Ilya Dryomov 
Signed-off-by: Ilya Dryomov

libceph: remove unnecessary non NULL check for request_key

2018-08-13T15:55:44+00:00

request_key never return NULL,so no need do non-NULL check.

Signed-off-by: YueHaibing 
Reviewed-by: Ilya Dryomov 
Signed-off-by: Ilya Dryomov

libceph: weaken sizeof check in ceph_x_verify_authorizer_reply()

2018-08-02T19:33:26+00:00

Allow for extending ceph_x_authorize_reply in the future.

Signed-off-by: Ilya Dryomov 
Reviewed-by: Sage Weil

libceph: check authorizer reply/challenge length before reading

2018-08-02T19:33:26+00:00

Avoid scribbling over memory if the received reply/challenge is larger
than the buffer supplied with the authorizer.

Signed-off-by: Ilya Dryomov 
Reviewed-by: Sage Weil

libceph: implement CEPHX_V2 calculation mode

2018-08-02T19:33:25+00:00

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

libceph: add authorizer challenge

2018-08-02T19:33:24+00:00

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

libceph: factor out encrypt_authorizer()

2018-08-02T19:33:24+00:00

Will be used for encrypting both the initial and updated authorizers.

Signed-off-by: Ilya Dryomov 
Reviewed-by: Sage Weil

libceph: factor out __ceph_x_decrypt()

2018-08-02T19:33:23+00:00

Will be used for decrypting the server challenge which is only preceded
by ceph_x_encrypt_header.

Drop struct_v check to allow for extending ceph_x_encrypt_header in the
future.

Signed-off-by: Ilya Dryomov 
Reviewed-by: Sage Weil

libceph: factor out __prepare_write_connect()

2018-08-02T19:33:22+00:00

Will be used for sending ceph_msg_connect with an updated authorizer,
after the server challenges the initial authorizer.

Signed-off-by: Ilya Dryomov 
Reviewed-by: Sage Weil

libceph: store ceph_auth_handshake pointer in ceph_connection

2018-08-02T19:33:22+00:00

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