[Bug 173002] [net] data type size problem in if_spppsubr.c

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=173002

--- Comment #7 from [email protected] ---
A commit in branch stable/13 references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=08ec14fecf6a93c0321c31ba1f0b04db6b888f16

commit 08ec14fecf6a93c0321c31ba1f0b04db6b888f16
Author:     Zhenlei Huang <[email protected]>
AuthorDate: 2025-01-14 10:56:49 +0000
Commit:     Zhenlei Huang <[email protected]>
CommitDate: 2025-01-14 10:56:49 +0000

    sppp: Fix getting wrong spppreq cmd from ioctl

    ifr->ifr_data is supposed to point to a struct spppreq. The first member
    cmd of struct spppreq is int type. It was pre-read via `fueword()` before
    a full fetching. Unfortunately an user space `struct spppreq spr` may not
    be zeroed explicitly, on 64bit architectures `fueword()` reads 64bit word
    thus the garbage (extra 4 bytes) may be read into kernel space (subcmd).

    Prior to f9d8181868ee, `subcmd` was declared as int and assigned from
    `fuword()` and was implicitly converted from long to int. On 64bit little
    endian architectures the implicitly conversion overflows (undefined
    bahavior) which happen to trash the garbage (the extra 4 bytes, high
    32 bits) and worked, but no luck on 64bit big endian architectures.

    Since f9d8181868ee `subcmd` was changed to u_long then there is no
    conversion so we end up mismatching `subcmd` with user space's `cmd`.

    It is also a bit hackish to get the value of cmd via `fueword()`, instead
    we refer to it directly from spr->cmd.

    This is a direct commit to stable/13 as sppp(4) no longer exists in main
    and stable/14.

    PR:             173002
    Reviewed by:    glebius (previous version)
    Fixes:  f9d8181868ee Fixed yet more ioctl breakage due to the type of ...
    Differential Revision:  https://reviews.freebsd.org/D47335

 sys/net/if_spppsubr.c | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

-- 
You are receiving this mail because:
You are the assignee for the bug.