[MDEV-14945] possible buffer overflow in stack resolver Created: 2018-01-14 Updated: 2020-10-26 Resolved: 2020-10-26 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Server |
| Affects Version/s: | 10.1, 10.2, 10.3, 10.4, 10.5 |
| Fix Version/s: | 10.1.48, 10.2.35, 10.3.26, 10.4.16, 10.5.7 |
| Type: | Bug | Priority: | Blocker |
| Reporter: | Sergei Golubchik | Assignee: | Vicențiu Ciorbaru |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Description |
|
Can be seen in stack traces like in
|
| Comments |
| Comment by Sergei Golubchik [ 2018-01-14 ] |
|
technically, it could've happen that the memory was corrupted before, and only detected in my_addr_resolve(). |
| Comment by Sergei Golubchik [ 2020-09-17 ] |
|
This seems to be it: https://stackoverflow.com/questions/22827510/how-to-avoid-bad-fd-set-buffer-overflow-crash |
| Comment by Sergei Golubchik [ 2020-09-17 ] |
|
supposedly rewriting select to poll should fix it. alternatively, a hack like for (f=10; f < 30; f++) close(f); could, perhaps, alleviate the issue. but only if no cleaner solution would help |
| Comment by Vicențiu Ciorbaru [ 2020-10-26 ] |
|
A tentative fix for this was done by moving stack variables out to global space (code is run single threaded anyway) and switching select to poll. poll can also error out with ENOMEM, which represents Kernel data structures were not allocated due to out-of-memory. There's no way to realistically fix that though. Let's see if this fix is any good as I can't quite reproduce it locally. |