| Description |
| + |
In the function l2cap_get_conf_opt (l2cap_core.c), which is used to parse configuration elements during an L2cap connection negotiation process. |
| + |
|
| + |
In this function, there is a "dual use" for the output parameter "val". If the length of the data is 1,2 or 4, then the returned value Is a value copied from an input buffer (received over BT) and returned ?by value?. If the length is different, the value is returned as a pointer to the buffer ?by reference?. The buffer is from a kernel SKB. Since the length is taken from the same buffer and the buffer is received via BT, the attacker controls whether the val is returned as a pointer or as a value. |
| + |
|
| + |
The val is later used as a value or as a pointer depending on a different field called ?type?, which is attacker controlled and taken from the same buffer. The ?val? output parameter is assumed to match the "type" and is either used by reference or by value accordingly. This assumption is where the bug is. An attacker can send a response where - for example ? the type is MTU (which uses 2 bytes from "val" by-value), and the length is 3, and so the returned MTU will actually be comprised of the 2 lower bytes of the pointer to the buffer, which will be leaked to the attacker. It is a form of type confusion without having a sophisticated type system. |
|