I would like to report one more current-head `Intra-Object Overflow` in the NTRIP path parser, this time in the optional trailing `:string` component used by `STR_NTRIPSVR`.
The relevant `ntrip_t` layout is:
```c
typedef struct {
int state;
int type;
int nb;
char url[256];
char mntpnt[256];
char user[256];
char passwd[256];
char str[NTRIP_MAXSTR];
unsigned char buff[NTRIP_MAXRSP];
tcpcli_t *tcp;
} ntrip_t;
```
The helper contains:
```c
if ((p = strchr(p, '/'))) {
if ((q = strchr(p + 1, ':'))) {
*q = '\0';
if (str) strcpy(str, q + 1);
}
*p = '\0';
if (mntpnt) strcpy(mntpnt, p + 1);
}
```
And `openntrip()` passes `ntrip->str` directly to this helper:
```c
decodetcppath(path, addr, port, ntrip->user, ntrip->passwd, ntrip->mntpnt,
ntrip->str);
```
Why I believe this is a real current-head bug:
1. The documented server grammar explicitly allows:
```text
STR_NTRIPSVR user[:passwd]@address[:port]/moutpoint[:string]
```
2. There is no validation that the trailing `string` component fits in:
```c
char str[256]
```
3. `str[256]` is immediately followed by the live response buffer:
```c
unsigned char buff[NTRIP_MAXRSP]
```
4. The total path can still remain below `MAXSTRPATH == 1024`, so this is not the previously reported `stream->path` overflow.
I built a reduced source-faithful proof preserving the exact `ntrip_t` member order and the exact parser logic. Its output is:
```text
path_len=327
distance_str_to_buff=256
string_component_len=320
overflow_bytes_into_buff=65
buff_prefix_hex=4343434343434343
buff_corrupted=1
```
This shows:
- the whole path is only `327`
- the trailing `string` component is `320`
- `str[256]` overflows directly into the adjacent live `buff`
I am making a narrow claim:
- this is current-head
- it is reachable from the documented `STR_NTRIPSVR` grammar
- it is a real write-side intra-object overflow
- the concrete overwrite is `ntrip->str[256] -> ntrip->buff`
The straightforward fix is to validate the parsed trailing string against `sizeof(ntrip->str) - 1` and replace the raw `strcpy()` with a bounded copy.
Best regards
Pengpeng Hou
ISCAS
