[
https://issues.apache.org/jira/browse/TS-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010652#comment-14010652
]
Leif Hedstrom commented on TS-2618:
-----------------------------------
Maybe
{code}
diff --git a/iocore/eventsystem/P_IOBuffer.h b/iocore/eventsystem/P_IOBuffer.h
index 20e1405..55b8add 100644
--- a/iocore/eventsystem/P_IOBuffer.h
+++ b/iocore/eventsystem/P_IOBuffer.h
@@ -530,10 +530,9 @@ IOBufferBlock::realloc_xmalloc(int64_t buf_size)
TS_INLINE void
IOBufferBlock::realloc(int64_t i)
{
- if (i == data->_size_index)
- return;
- if (i >= (int64_t) sizeof(ioBufAllocator))
+ if ((i == data->_size_index) || (i >= (int64_t)countof(ioBufAllocator))) {
return;
+ }
ink_release_assert(i > data->_size_index && i != BUFFER_SIZE_NOT_ALLOCATED);
void *b = ioBufAllocator[i].alloc_void();
{code}
Now, looking at this, I think this is something I really foobared way back when
(32-bit -> 64-bit migration). There's really no reason for this index to be
64-bit. Should we go through and try fix that? The issue sometimes is that we
overlap sizes and indexes, such that APIs can deal with either (if I recall).
It's wonky....
> IOBufferBlock::realloc()'s bounds check is wrong
> ------------------------------------------------
>
> Key: TS-2618
> URL: https://issues.apache.org/jira/browse/TS-2618
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
> Reporter: William Bardwell
> Assignee: William Bardwell
> Fix For: 5.1.0
>
>
> Presumably this never fires, but:
> {code}
> if (i >= (int64_t) sizeof(ioBufAllocator))
> return;
> {code}
> looks wrong, it looks like i is an index into that array, so it should be
> {code}
> i >= SIZE(ioBufAllocator))
> {code}
> (SIZE() from ink_defs.h)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
