In the Linux kernel, the following vulnerability has been resolved:
ieee802154: fix kernel-infoleak in dgram_recvmsg()
KMSAN reported a kernel-infoleak in move_addr_to_user():
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:131 [inline] BUG: KMSAN: kernel-infoleak in _inline_copy_to_user include/linux/uaccess.h:205 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xcc/0x120 lib/usercopy.c:26 instrument_copy_to_user include/linux/instrumented.h:131 [inline] _inline_copy_to_user include/linux/uaccess.h:205 [inline] _copy_to_user+0xcc/0x120 lib/usercopy.c:26 copy_to_user include/linux/uaccess.h:236 [inline] move_addr_to_user+0x2e7/0x440 net/socket.c:302 ____sys_recvmsg+0x232/0x610 net/socket.c:2925 ... Uninit was stored to memory at: ieee802154_addr_to_sa include/net/ieee802154_netdev.h:369 [inline] dgram_recvmsg+0xa09/0xbe0 net/ieee802154/socket.c:739
The issue occurs because the pan_id field of struct ieee802154_addr
is left uninitialized when the address mode is IEEE802154_ADDR_NONE.
The execution flow is as follows:
__ieee802154_rx_handle_packet()declares a localstruct
ieee802154_hdr_pull()callsieee802154_hdr_get_addr()to parse
- If the address mode is
IEEE802154_ADDR_NONE,
ieee802154_hdr_get_addr() previously only set the mode field,
leaving the pan_id field containing uninitialized stack memory.
- This uninitialized
pan_idis later copied into astruct
dgram_recvmsg() via ieee802154_addr_to_sa().
- Finally,
move_addr_to_user()copies the socket address structure to
Fix this by using memset to zero out the address structure in
ieee802154_hdr_get_addr() when the mode is IEEE802154_ADDR_NONE.