Commit 45f066a
committed
fix: prevent OOM on malformed APK with crafted string table
Two allocation vulnerabilities in string table parsing allow a crafted
resources.arsc to cause multi-GiB heap allocations:
parseStringTable — res.data = make([]byte, r.N)
r.N is derived from the chunk's totalLen field, a raw uint32 that a
malformed APK can set to ~4 GiB. make() commits the memory immediately;
io.ReadFull then fails (if the file is smaller), but only after the 4 GiB
block is live on the heap. The existing stringCnt >= 2M guard does not
bound the data section size. Guard with a 50 MiB limit before the make.
parseString16 — buf = make([]uint16, strCharacters)
The extended 31-bit length encoding (high bit of the first uint16 set)
allows strCharacters up to 0x7FFF_FFFF (4 GiB as []uint16) per call.
r is bytes.NewReader(t.data[offset:]), so binary.Read fails immediately
when the actual data is smaller -- but only after the allocation lands.
Fix with two guards in order:
1. Validate strCharacters against br.Len(): a correctly-formed string
cannot claim more chars than remaining_bytes/2. Catches both crafted
fields and any future decoding misalignment.
2. Secondary cap at 64 KiB: no legitimate resource string exceeds this.
Also fix &buf -> buf in binary.Read calls (parseString16, parseString8):
Passing *[]uint16 / *[]uint8 instead of the slice value itself bypasses
binary.Read's intDataSize fast-path switch (which handles []uint16 /
[]uint8 but not pointer-to-slice). The fallback reflection path allocates
an extra []byte temp buffer of the same size and calls reflect.New per
element -- visible as ~3 GiB flat in encoding/binary.Read and ~378 MB
in reflect.New in heap profiles of affected servers. Passing the slice
directly uses the fast path, is functionally identical, and is zero-
reflection.1 parent 7294e27 commit 45f066a
1 file changed
Lines changed: 36 additions & 4 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
101 | 101 | | |
102 | 102 | | |
103 | 103 | | |
| 104 | + | |
| 105 | + | |
| 106 | + | |
| 107 | + | |
| 108 | + | |
| 109 | + | |
| 110 | + | |
| 111 | + | |
| 112 | + | |
104 | 113 | | |
105 | 114 | | |
106 | 115 | | |
| |||
128 | 137 | | |
129 | 138 | | |
130 | 139 | | |
131 | | - | |
132 | | - | |
133 | | - | |
| 140 | + | |
| 141 | + | |
| 142 | + | |
| 143 | + | |
| 144 | + | |
| 145 | + | |
| 146 | + | |
| 147 | + | |
| 148 | + | |
| 149 | + | |
| 150 | + | |
| 151 | + | |
| 152 | + | |
| 153 | + | |
| 154 | + | |
| 155 | + | |
| 156 | + | |
| 157 | + | |
| 158 | + | |
| 159 | + | |
| 160 | + | |
| 161 | + | |
| 162 | + | |
| 163 | + | |
| 164 | + | |
| 165 | + | |
134 | 166 | | |
135 | 167 | | |
136 | 168 | | |
| |||
173 | 205 | | |
174 | 206 | | |
175 | 207 | | |
176 | | - | |
| 208 | + | |
177 | 209 | | |
178 | 210 | | |
179 | 211 | | |
| |||
0 commit comments