linux-kernel - missing capability check in __rfcomm_release

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20dc58ee.bf74.18cccf32c62.Coremail.mengjingzi@iie.ac.cn>
Date: Wed, 3 Jan 2024 09:32:17 +0800 (GMT+08:00)
From: 孟敬姿 <mengjingzi@....ac.cn>
To: marcel@...tmann.org, johan.hedberg@...il.com, luiz.dentz@...il.com
Cc: linux-bluetooth@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: missing capability check in __rfcomm_release_dev()

Hi!

We observed a potential enhancement in the __rfcomm_release_dev() function. Currently, the function checks CAP_NET_ADMIN at line 452, primarily safeguarding rfcomm_dlc_close() for closing a data link connection.
We consider an extra CAP_SYS_TTY_CONFIG maybe needed for hanging up a tty at line 469(tty_vhangup()). 

On the one hand, the definition of CAP_SYS_TTY_CONFIG includes "employ various privileged ioctl operations on virtual terminals"(check capability manual page https://www.man7.org/linux/man-pages/man7/capabilities.7.html); on the other hand, the similar functionality is already protected by CAP_SYS_TTY_CONFIG in fs/open.c.

The callpath in net/bluetooth/rfcomm/tty.c is:
rfcomm_dev_ioctl() -&gt; rfcomm_release_dev() -&gt; __rfcomm_release_dev() -&gt; tty_vhangup()

The callpath in fs/open.c is: 
SYSCALL_DEFINE0(vhangup) -&gt; capable(CAP_SYS_TTY_CONFIG)-&gt; tty_vhangup_self() -&gt; tty_vhangup().

This issue exists in several kernel versions and we have checked it on the latest stable release(Linux 6.6.9). 

We would like to promote the proper use of capability to enhance the protection of kernel resources. Your insights and feedback on this proposed adjustment would be invaluable. Thank you for taking the time to consider this request.

Best regards,
Jingzi