oss-sec mailing list archives
Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution
From: Ruihan Li <lrh2000 () pku edu cn>
Date: Wed, 19 Apr 2023 02:37:35 +0800
Hi, On Tue, Apr 18, 2023 at 08:13:24PM +0300, 0xef967c36 () gmail com wrote:
No, there's no clash. That was a bug in strace (fortunately fixed in newer versions). Those values macros are different; and they were ALWAYS different.
A quick search shows that it is fixed in df7aa2 ("ioctl: take all 32 bits of ioctl commands into account") [1]. The commit message says
Historically, only 16 bits (8-bit number and 8-bit type) of 32-bit ioctl commands were used for decoding, which was the source for numerous annoying collisions like this: ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = > 0 ioctl(0, MGSL_IOCGPARAMS or MMTIMER_GETRES or MTIOCTOP or SNDCTL_MIDI_MPUMODE, 0x7fffd47f7338) = -1 ENOTTY (Inappropriate ioctl for device)
Here the first example is exactly the case we are discussing. [1]: https://github.com/strace/strace/commit/df7aa2b19e6f69c19fbe09180bf1ec4fb52e2615 It appears that SNDCTL_TMR_TIMEBASE and TCGETS do have the same command code, which sits in the lower 16 bits. But SNDCTL_TMR_TIMEBASE uses a newer command encoding scheme [2] that includes the direction and argument size in the higher 16 bits. TCGETS, on the other hand, contains only the command code, so its higher bits are set to zero (TCGETS should have a really long history, just longer than that of the new ioctl command encoding scheme). [2]: https://elixir.bootlin.com/linux/v6.3-rc7/source/include/uapi/asm-generic/ioctl.h#L5 This means we haven't had any collisions yet. Also, since new ioctl commands will certainly be encoded using the new encoding scheme, which TCGETS does not use, it is very unlikely that new collisions will occur in the future, unless the command code is exactly the same and the higher bits under the new encoding scheme are also occasionally zeros. Thanks, Ruihan Li
Current thread:
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution, (continued)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution Solar Designer (Apr 17)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution Ruihan Li (Apr 18)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution Todd C. Miller (Apr 18)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution Ruihan Li (Apr 18)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution Todd C. Miller (Apr 18)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution Steffen Nurpmeso (Apr 18)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution Solar Designer (Apr 17)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution nightmare . yeah27 (Apr 19)
- Re: Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution Steffen Nurpmeso (Apr 20)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution 0xef967c36 (Apr 18)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution Ruihan Li (Apr 18)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution 0xef967c36 (Apr 18)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution Solar Designer (Apr 18)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution 0xef967c36 (Apr 18)
- Re: CVE-2023-2002: Linux Bluetooth: Unauthorized management command execution Steffen Nurpmeso (Apr 18)