aboutsummaryrefslogtreecommitdiffhomepage
path: root/src
diff options
context:
space:
mode:
authorGravatar Alex Chernyakhovsky <alex@achernya.com>2022-05-30 20:39:09 -0400
committerGravatar Alex Chernyakhovsky <achernya@mit.edu>2022-05-30 20:55:21 -0400
commit2f90addb7c3ff22401df339a9d7219e6769a09bf (patch)
tree0e63329a14bb9394bfe8064b97aea5e77ea3a287 /src
parentadb62e97ffe10d00be1f6fa0744d568cbda631c9 (diff)
Revert "Remove redundant malloc/free"
This reverts commit 6321b1d9c50b202e1823ba62ea8e47f6b08bdb2e. The original commit 6321b1d9c50b202e1823ba62ea8e47f6b08bdb2e switched from a malloc call of a 22400 byte buffer to a stack-allocated 22400 byte buffer, in addition to the fairly large buffers already allocated in the functions. Some systems have fairly small stack frames, making this 22K allocation potentially dangerous. On my stock Debian bullseye system, I have 200809 bytes (from `getconf _POSIX_THREAD_ATTR_STACKSIZE`); a 22400 byte buffer already represents about 10% of the available stacksize. Other systems, such as those with musl libc, may have either 80KiB or 128KiB [1], making this allocation represent between 18% to 28% of the available stack space. [1] https://wiki.musl-libc.org/functional-differences-from-glibc.html#Thread-stack-size
Diffstat (limited to 'src')
-rw-r--r--src/crypto/ocb.cc6
1 files changed, 4 insertions, 2 deletions
diff --git a/src/crypto/ocb.cc b/src/crypto/ocb.cc
index 9efc8cd..307734f 100644
--- a/src/crypto/ocb.cc
+++ b/src/crypto/ocb.cc
@@ -1449,11 +1449,13 @@ static void validate()
ALIGN(16) uint8_t key[32] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
ALIGN(16) uint8_t valid[] = {0xB2,0xB4,0x1C,0xBF,0x9B,0x05,0x03,0x7D,
0xA7,0xF1,0x6C,0x24,0xA3,0x5C,0x1C,0x94};
- ALIGN(16) uint8_t val_buf[22400];
ae_ctx ctx;
- uint8_t *next = val_buf;
+ uint8_t *val_buf, *next;
int i, len;
+ val_buf = (uint8_t *)malloc(22400 + 16);
+ next = val_buf = (uint8_t *)(((size_t)val_buf + 16) & ~((size_t)15));
+
if (0) {
ae_init(&ctx, key, 16, 12, 16);
/* pbuf(&ctx, sizeof(ctx), "CTX: "); */