aboutsummaryrefslogtreecommitdiff
path: root/gdb/tracectf.c
diff options
context:
space:
mode:
authorAndrew Burgess <aburgess@redhat.com>2023-05-31 21:41:48 +0100
committerAndrew Burgess <aburgess@redhat.com>2023-07-07 15:20:28 +0100
commit13f5f57e0d2fb3e06e15c57d67a40499a5910ba6 (patch)
tree619d370da08a14a8ad4b289c8c61bcf9c7e6565c /gdb/tracectf.c
parent7d8708653dc05075b926a61303abd96c3f746e25 (diff)
downloadgdb-13f5f57e0d2fb3e06e15c57d67a40499a5910ba6.zip
gdb-13f5f57e0d2fb3e06e15c57d67a40499a5910ba6.tar.gz
gdb-13f5f57e0d2fb3e06e15c57d67a40499a5910ba6.tar.bz2
gdb: check max-value-size when reading strings for printf
I noticed that the printf code for strings, printf_c_string and printf_wide_c_string, don't take max-value-size into account, but do load a complete string from the inferior into a GDB buffer. As such it would be possible for an badly behaved inferior to cause GDB to try and allocate an excessively large buffer, potentially crashing GDB, or at least causing GDB to swap lots, which isn't great. We already have a setting to protect against this sort of thing, the 'max-value-size'. So this commit updates the two function mentioned above to check the max-value-size and give an error if the max-value-size is exceeded. If the max-value-size is exceeded, I chose to continue reading inferior memory to figure out how long the string actually is, we just don't store the results. The benefit of this is that when we give the user an error we can tell the user how big the string actually is, which would allow them to correctly adjust max-value-size, if that's what they choose to do. The default for max-value-size is 64k so there should be no user visible changes after this commit, unless the user was previously printing very large strings. If that is the case then the user will now need to increase max-value-size.
Diffstat (limited to 'gdb/tracectf.c')
0 files changed, 0 insertions, 0 deletions