BBS:      TELESC.NET.BR
Assunto:  src/sftp/sftp_pkt.c
De:       Deuc¨
Data:     Fri, 1 May 2026 07:59:47 -0700
-----------------------------------------------------------
https://gitlab.synchro.net/main/sbbs/-/commit/16319af40a18856276aea0fa
Modified Files:
	src/sftp/sftp_pkt.c
Log Message:
sftp: fix tx and rx buffer round-up bugs at 4 KiB boundaries

Two parallel undersizing bugs in the shared SFTP packet library
caused both peers to corrupt their own buffers near
SFTP_MIN_PACKET_ALLOC (4 KiB) boundaries.

rx_pkt_append used

	new_sz = new_sz / SFTP_MIN_PACKET_ALLOC + SFTP_MIN_PACKET_ALLOC

 a divide where there should have been a `+= (BLOCK - remain)`.
For any inbound chunk whose total exceeded the first 4 KiB boundary
the formula collapsed back to roughly 4 KiB, the realloc undersized
the buffer, and the subsequent memcpy walked past the heap
allocation.

grow_tx had a structurally different but related bug: in the
existing-packet branch it computed

	newsz = pkt->used + need;

omitting the offsetof(struct sftp_tx_pkt, type) header that pkt->sz
already accounts for.  The realloc rounded `pkt->used + need` up to
the next 4 KiB boundary, but the actual write target lands at
`pkt->used + offsetof(type) + need`, so when (used + need) lands on
a 4 KiB boundary the new allocation undershoots by up to
offsetof(type) bytes.  The fresh-allocation branch and the trailing
asserts both already used the offsetof-inclusive form; bring the
existing-packet branch in line.

The library is shared, so each bug corrupted both peers: rx_pkt for
large inbound packets (uploads, large readdir replies, file data),
grow_tx for outbound packets that crossed a 4 KiB boundary.
Symptom in the wild was a SyncTERM SFTP browser failing to list a
25-entry filebase directory with garbled fattr / filename strings
near entry 23-24.

Co-Authored-By: Claude Opus 4.7 (1M context) 
n
---
  mSynchronetn  hgVertrauen n hHome of Synchronet n gh[vert/cvs/bbs].synchro.net

-----------------------------------------------------------
[Voltar]