SNACC ExpBuf bugs
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
snacc (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
Thought I ought to make you aware of some problems with SNACC's (C-lib) ExpBufs, since finding them in our company's own branch of SNACC. (I've checked, and they're still present in yours.)
The basic idea of ExpBufs is that there’s a chain of 1024-byte blocks of memory. The thing the original author failed to consider is that there’s a difference between leaving the “current” pointer at the end of one block at the end of an operation, and leaving it at the beginning of the next – they leave it on different sides after reading and after writing. So a write then a write (or a read then a read) will always be fine, but doing one then the other will fail if the first ends on a 1024-byte boundary. (I’ve only fixed this one way round in our codebase, since we only ever write then read everything back.)
The effect of this to the outside world is that when you try to compose an ASN.1 message that should be a multiple of 1024 bytes, you'll get back something that has the correct length but not necessarily the correct contents.
The right fix is probably to make sure that the "current" pointer ends up in a consistent place after all operations that end on a boundary. My fix for our codebase is less right and more quick, so I won't include it here!