sahvx655-wq opened a new pull request, #3335: URL: https://github.com/apache/brpc/pull/3335
### What problem does this PR solve? Issue Number: Problem Summary: While tracing how a brpc redis server handles RESP command names, I saw the command name lowercased with `tolower` over a raw `char`. Those bytes come straight off the socket through `RedisCommandParser::Consume`, so any byte in 0x80-0xFF reaches the loop as a negative `char`. Passing a negative value other than `EOF` to a `<ctype.h>` function is undefined behaviour, because the argument has to be representable as `unsigned char`; on some libc builds the ctype macro indexes before the lookup table, which is exactly the kind of thing a fuzzer or a hardened build will flag. The same shape sits in both parser paths (the inline-command path and the bulk-string path) and in `Str2HttpMethod`, which hands the first byte of an attacker-supplied HTTP/2 `:method` pseudo-header to `toupper`. The root cause is just the missing cast, and the codebase already knows the correct idiom: the array-size guard a few lines up uses `std::isalpha(static_cast<unsigned char>(*pfc))`, and `uri.cpp` casts before its ctype calls too. Left unfixed this is latent UB on every redis server and h2 endpoint, harmless on glibc today but not portable and noisy under UBSan, so I have brought the three sites in line with the existing idiom. ### What is changed and the side effects? Changed: Cast each untrusted byte to `unsigned char` before the ctype call in `src/brpc/redis_command.cpp` (both command-name paths) and `src/brpc/http_method.cpp`. Valid ASCII commands and methods behave exactly as before, so there is no observable behaviour change to test against. Side effects: - Performance effects: none. - Breaking backward compatibility: none. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
