CVE-2022-49456

In the Linux kernel, the following vulnerability has been resolved: bonding: fix missed rcu protection When removing the rcu_read_lock in bond_ethtool_get_ts_info() as discussed [1], I didn't notice it could be called via setsockopt, which doesn't hold rcu lock, as syzbot pointed: stack backtrace: CPU: 0 PID: 3599 Comm: syz-executor317 Not tainted 5.18.0-rc5-syzkaller-01392-g01f4685797a5 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 bond_option_active_slave_get_rcu include/net/bonding.h:353 [inline] bond_ethtool_get_ts_info+0x32c/0x3a0 drivers/net/bonding/bond_main.c:5595 __ethtool_get_ts_info+0x173/0x240 net/ethtool/common.c:554 ethtool_get_phc_vclocks+0x99/0x110 net/ethtool/common.c:568 sock_timestamping_bind_phc net/core/sock.c:869 [inline] sock_set_timestamping+0x3a3/0x7e0 net/core/sock.c:916 sock_setsockopt+0x543/0x2ec0 net/core/sock.c:1221 __sys_setsockopt+0x55e/0x6a0 net/socket.c:2223 __do_sys_setsockopt net/socket.c:2238 [inline] __se_sys_setsockopt net/socket.c:2235 [inline] __x64_sys_setsockopt+0xba/0x150 net/socket.c:2235 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f8902c8eb39 Fix it by adding rcu_read_lock and take a ref on the real_dev. Since dev_hold() and dev_put() can take NULL these days, we can skip checking if real_dev exist. [1] https://lore.kernel.org/netdev/27565.1642742439@famine/
Configurations

Configuration 1 (hide)

OR cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:5.17:-:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:5.17:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:5.17:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:5.17:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:5.17:rc5:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:5.17:rc6:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:5.17:rc7:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:5.17:rc8:*:*:*:*:*:*

History

22 Oct 2025, 17:24

Type Values Removed Values Added
References () https://git.kernel.org/stable/c/1b66a533c47d29b38af8e05fbb53b609a5ba3a4e - () https://git.kernel.org/stable/c/1b66a533c47d29b38af8e05fbb53b609a5ba3a4e - Patch
References () https://git.kernel.org/stable/c/85eed460681da71b359ed906bce4d800081db854 - () https://git.kernel.org/stable/c/85eed460681da71b359ed906bce4d800081db854 - Patch
References () https://git.kernel.org/stable/c/9b80ccda233fa6c59de411bf889cc4d0e028f2c7 - () https://git.kernel.org/stable/c/9b80ccda233fa6c59de411bf889cc4d0e028f2c7 - Patch
CVSS v2 : unknown
v3 : unknown
v2 : unknown
v3 : 5.5
First Time Linux linux Kernel
Linux
Summary
  • (es) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bonding: se corrige la protección rcu faltante Al eliminar rcu_read_lock en bond_ethtool_get_ts_info() como se discutió [1], no noté que se podía llamar a través de setsockopt, que no mantiene el bloqueo rcu, como señaló syzbot: seguimiento de pila: CPU: 0 PID: 3599 Comm: syz-executor317 Not tainted 5.18.0-rc5-syzkaller-01392-g01f4685797a5 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 bond_option_active_slave_get_rcu include/net/bonding.h:353 [inline] bond_ethtool_get_ts_info+0x32c/0x3a0 drivers/net/bonding/bond_main.c:5595 __ethtool_get_ts_info+0x173/0x240 net/ethtool/common.c:554 ethtool_get_phc_vclocks+0x99/0x110 net/ethtool/common.c:568 sock_timestamping_bind_phc net/core/sock.c:869 [inline] sock_set_timestamping+0x3a3/0x7e0 net/core/sock.c:916 sock_setsockopt+0x543/0x2ec0 net/core/sock.c:1221 __sys_setsockopt+0x55e/0x6a0 net/socket.c:2223 __do_sys_setsockopt net/socket.c:2238 [inline] __se_sys_setsockopt net/socket.c:2235 [inline] __x64_sys_setsockopt+0xba/0x150 net/socket.c:2235 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f8902c8eb39 Fix it by adding rcu_read_lock and take a ref on the real_dev. Since dev_hold() and dev_put() can take NULL these days, we can skip checking if real_dev exist. [1] https://lore.kernel.org/netdev/27565.1642742439@famine/
CPE cpe:2.3:o:linux:linux_kernel:5.17:-:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:5.17:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:5.17:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:5.17:rc5:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:5.17:rc6:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:5.17:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:5.17:rc8:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:5.17:rc7:*:*:*:*:*:*
CWE NVD-CWE-noinfo

26 Feb 2025, 07:01

Type Values Removed Values Added
New CVE

Information

Published : 2025-02-26 07:01

Updated : 2025-10-22 17:24


NVD link : CVE-2022-49456

Mitre link : CVE-2022-49456

CVE.ORG link : CVE-2022-49456


JSON object : View

Products Affected

linux

  • linux_kernel