Project

General

Profile

Bug #13470

potential crash in in gcm decrypt_update if kmem_alloc fails

Added by Garrett D'Amore 3 months ago.

Status:
New
Priority:
High
Assignee:
-
Category:
kernel
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Bite-size
Tags:
Gerrit CR:

Description

This was found by inspection:

in /illumos-gate/usr/src/common/crypto/modes/gcm.c

```
383 if (length > 0) {
384 new_len = ctx->gcm_pt_buf_len + length;
385#ifdef _KERNEL
386 new = kmem_alloc(new_len, ctx->gcm_kmflag);
387 bcopy(ctx->gcm_pt_buf, new, ctx->gcm_pt_buf_len);
388 kmem_free(ctx->gcm_pt_buf, ctx->gcm_pt_buf_len);
389#else
390 new = malloc(new_len);
391 bcopy(ctx->gcm_pt_buf, new, ctx->gcm_pt_buf_len);
392 free(ctx->gcm_pt_buf);
393#endif
394 if (new == NULL)
395 return (CRYPTO_HOST_MEMORY);
```

At line 387 (and potentially 391) we bcopy over a NULL pointer if the allocation fails. This could have bad ramifications for SMB3, which is the main consumer of this code path at present (though we are looking to fix that by not using partial updates anymore, separate issue). The concern is KM_NOSLEEP is used, then the allocation can fail, leading to a panic. (That will also only happen when doing multipart encryption in multiple steps.)

The fix is to move the check at 394 higher, to just after the allocation.

No data to display

Also available in: Atom PDF