Describe the bug
Bluetooth Mesh Protocol 1.1.1 Section 6.9.1 defines the Solicitation PDU as a Network PDU with CTL=1, TTL=0, an empty TransportPDU and an 8-octet NetMIC, yielding a fixed 17-octet encrypted payload carried inside a 22-octet Service Data AD structure.
The mesh scan callback in adv.c restores the advertising buffer to span the remainder of the payload before dispatching to bt_mesh_sol_recv(), so buf->len may still cover subsequent AD structures after the Solicitation Service Data element. In that case sol_pdu_decrypt() would copy more than 17 octets into its 17-octet working buffer.
Regression
Steps to reproduce
No response
Relevant log output
Impact
Functional Limitation – Some features not working as expected, but system usable.
Environment
The issue has been introduced in the Zephyr code since v3.4.0 in commit d099554 (dated 2022-10-19, "Bluetooth: Mesh: add implementation for Proxy Solicitation")
Additional Context
No response
Describe the bug
Bluetooth Mesh Protocol 1.1.1 Section 6.9.1 defines the Solicitation PDU as a Network PDU with CTL=1, TTL=0, an empty TransportPDU and an 8-octet NetMIC, yielding a fixed 17-octet encrypted payload carried inside a 22-octet Service Data AD structure.
The mesh scan callback in adv.c restores the advertising buffer to span the remainder of the payload before dispatching to bt_mesh_sol_recv(), so buf->len may still cover subsequent AD structures after the Solicitation Service Data element. In that case sol_pdu_decrypt() would copy more than 17 octets into its 17-octet working buffer.
Regression
Steps to reproduce
No response
Relevant log output
Impact
Functional Limitation – Some features not working as expected, but system usable.
Environment
The issue has been introduced in the Zephyr code since v3.4.0 in commit d099554 (dated 2022-10-19, "Bluetooth: Mesh: add implementation for Proxy Solicitation")
Additional Context
No response