[ 
https://issues.apache.org/jira/browse/IGNITE-28854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitry Werner updated IGNITE-28854:
-----------------------------------
       Epic Link: IGNITE-25881
    Ignite Flags:   (was: Docs Required,Release Notes Required)
          Labels: IEP-132 ise  (was: )

> CompressedMessageSerializer.readFrom() spins forever on a null chunk from a 
> corrupted or incompatible peer
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: IGNITE-28854
>                 URL: https://issues.apache.org/jira/browse/IGNITE-28854
>             Project: Ignite
>          Issue Type: Task
>            Reporter: Anton Vinogradov
>            Assignee: Dmitry Werner
>            Priority: Major
>              Labels: IEP-132, ise
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> In CompressedMessageSerializer.readFrom(), state 2 reads the next compressed 
> chunk:
>     msg.chunk = reader.readByteArray();
>     if (!reader.isLastRead())
>         return false;
>     if (msg.chunk != null) \{ ... reader.decrementState(); ... }
> DirectByteBufferStream.readByteArray() returns null (with lastFinished == 
> true) when the wire contains the null-array marker (length == -1). A 
> well-behaved sender never writes null at this position (writeTo() only enters 
> state 2 with a non-null chunk), but a corrupted stream or a 
> malicious/incompatible peer can produce it: the -1 length is accepted, the 
> null branch does not advance the reader state, and the while(true) loop 
> re-executes state 2 forever - the grid-nio worker thread spins at 100% CPU 
> and its stripe stops processing messages, effectively degrading the whole 
> node.
> The defect predates IGNITE-28853 (the master version with the direct-buffer 
> accumulator has the identical structure).
> Fix: treat a null chunk at this protocol position as a protocol violation - 
> throw IgniteException with a descriptive message instead of silently looping. 
> The exception propagates out of message decoding and the connection is 
> closed, which is the correct outcome for a corrupted stream.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to