Switch System Flaws: Difference between revisions
| Line 1,145: | Line 1,145: | ||
| June 3, 2024 (possibly eariler(?)) | | June 3, 2024 (possibly eariler(?)) | ||
| November 14, 2025 | | November 14, 2025 | ||
| [[User:Yellows8|yellows8]] | |||
|- | |||
| [[Bluetooth_Driver_services|bluetooth]] BSA allowed ATT MTU is too large | |||
| GATT-handler stack buffer overflows with a large input size are only possible if the payload_size (MTU) field in state is large enough. gatt_client_handle_server_rsp/gatt_server_handle_client_req will drop messages where the size is >= payload_size (though unless the request opcode matches certain values it will also send an error-response for invalid-PDU). Both of these handle updating this field when needed, however that's handled properly. | |||
With bluetooth-classic via L2CAP, a hard-coded MTU of 0x205 is sent in the configure request. However the code handling received configure requests will set payload_size to 0x2A0 if no MTU is specified, or the input MTU if it's within range 0x30..0x2A0. Hence, sending data large enough for buffer overflows requires bluetooth-classic via L2CAP + manually sending large ACL data. | |||
[15.0.0+] gatt_l2cif_config_ind_cback which handles the received configure-requests with bluetooth-classic mentioned above, now uses MTU range 0x30..0x205 with the default MTU being 0x205. It is therefore no longer possible to trigger the previously mentioned buffer-overflows with bluetooth-classic. | |||
| Stack buffer overflows in bluetooth-sysmodule due to the allowed MTU for ATT being larger than the stack data. | |||
| [[15.0.0]] | |||
| [[20.0.0]] | |||
| November 2021? | |||
| November 26, 2025 | |||
| [[User:Yellows8|yellows8]] | | [[User:Yellows8|yellows8]] | ||
|} | |} | ||