CVSS: 4.4EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52798 – wifi: ath11k: fix dfs radar event locking
https://notcve.org/view.php?id=CVE-2023-52798
In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix dfs radar event locking The ath11k active pdevs are protected by RCU but the DFS radar event handling code calling ath11k_mac_get_ar_by_pdev_id() was not marked as a read-side critical section. Mark the code in question as an RCU read-side critical section to avoid any potential use-after-free issues. Compile tested only. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: ath11k: corrige el bloqueo de eventos de radar dfs. Los pdevs activos de ath11k están protegidos por RCU, pero el código de manejo de eventos de radar DFS que llama a ath11k_mac_get_ar_by_pdev_id() no se marcó como una sección crítica del lado de lectura . Marque el código en cuestión como una sección crítica del lado de lectura de RCU para evitar posibles problemas de use after free. Compilación probada únicamente. • https://git.kernel.org/stable/c/d5c65159f2895379e11ca13f62feabe93278985d https://git.kernel.org/stable/c/f882f51905517575c9f793a3dff567af90ef9a10 https://git.kernel.org/stable/c/426e718ce9ba60013364a54233feee309356cb82 https://git.kernel.org/stable/c/ca420ac4f9451f22347bae44b18ab47ba2c267ec https://git.kernel.org/stable/c/1fd878e1750190a612b5de2af357cca422ec0822 https://git.kernel.org/stable/c/21ebb0aba580d347e12f01ce5f6e75044427b3d5 https://git.kernel.org/stable/c/3b6c14833165f689cc5928574ebafe52bbce5f1e https://access.redhat.com/security/cve/CVE-2023-52798 • CWE-416: Use After Free •
CVSS: 4.4EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52796 – ipvlan: add ipvlan_route_v6_outbound() helper
https://notcve.org/view.php?id=CVE-2023-52796
In the Linux kernel, the following vulnerability has been resolved: ipvlan: add ipvlan_route_v6_outbound() helper Inspired by syzbot reports using a stack of multiple ipvlan devices. Reduce stack size needed in ipvlan_process_v6_outbound() by moving the flowi6 struct used for the route lookup in an non inlined helper. ipvlan_route_v6_outbound() needs 120 bytes on the stack, immediately reclaimed. Also make sure ipvlan_process_v4_outbound() is not inlined. We might also have to lower MAX_NEST_DEV, because only syzbot uses setups with more than four stacked devices. BUG: TASK stack guard page was hit at ffffc9000e803ff8 (stack is ffffc9000e804000..ffffc9000e808000) stack guard page: 0000 [#1] SMP KASAN CPU: 0 PID: 13442 Comm: syz-executor.4 Not tainted 6.1.52-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023 RIP: 0010:kasan_check_range+0x4/0x2a0 mm/kasan/generic.c:188 Code: 48 01 c6 48 89 c7 e8 db 4e c1 03 31 c0 5d c3 cc 0f 0b eb 02 0f 0b b8 ea ff ff ff 5d c3 cc 00 00 cc cc 00 00 cc cc 55 48 89 e5 <41> 57 41 56 41 55 41 54 53 b0 01 48 85 f6 0f 84 a4 01 00 00 48 89 RSP: 0018:ffffc9000e804000 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817e5bf2 RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff887c6568 RBP: ffffc9000e804000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff92001d0080c R13: dffffc0000000000 R14: ffffffff87e6b100 R15: 0000000000000000 FS: 00007fd0c55826c0(0000) GS:ffff8881f6800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc9000e803ff8 CR3: 0000000170ef7000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <#DF> </#DF> <TASK> [<ffffffff81f281d1>] __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31 [<ffffffff817e5bf2>] instrument_atomic_read include/linux/instrumented.h:72 [inline] [<ffffffff817e5bf2>] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] [<ffffffff817e5bf2>] cpumask_test_cpu include/linux/cpumask.h:506 [inline] [<ffffffff817e5bf2>] cpu_online include/linux/cpumask.h:1092 [inline] [<ffffffff817e5bf2>] trace_lock_acquire include/trace/events/lock.h:24 [inline] [<ffffffff817e5bf2>] lock_acquire+0xe2/0x590 kernel/locking/lockdep.c:5632 [<ffffffff8563221e>] rcu_lock_acquire+0x2e/0x40 include/linux/rcupdate.h:306 [<ffffffff8561464d>] rcu_read_lock include/linux/rcupdate.h:747 [inline] [<ffffffff8561464d>] ip6_pol_route+0x15d/0x1440 net/ipv6/route.c:2221 [<ffffffff85618120>] ip6_pol_route_output+0x50/0x80 net/ipv6/route.c:2606 [<ffffffff856f65b5>] pol_lookup_func include/net/ip6_fib.h:584 [inline] [<ffffffff856f65b5>] fib6_rule_lookup+0x265/0x620 net/ipv6/fib6_rules.c:116 [<ffffffff85618009>] ip6_route_output_flags_noref+0x2d9/0x3a0 net/ipv6/route.c:2638 [<ffffffff8561821a>] ip6_route_output_flags+0xca/0x340 net/ipv6/route.c:2651 [<ffffffff838bd5a3>] ip6_route_output include/net/ip6_route.h:100 [inline] [<ffffffff838bd5a3>] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:473 [inline] [<ffffffff838bd5a3>] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline] [<ffffffff838bd5a3>] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] [<ffffffff838bd5a3>] ipvlan_queue_xmit+0xc33/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677 [<ffffffff838c2909>] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229 [<ffffffff84d03900>] netdev_start_xmit include/linux/netdevice.h:4966 [inline] [<ffffffff84d03900>] xmit_one net/core/dev.c:3644 [inline] [<ffffffff84d03900>] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660 [<ffffffff84d080e2>] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324 [<ffffffff855ce4cd>] dev_queue_xmit include/linux/netdevice.h:3067 [inline] [<ffffffff855ce4cd>] neigh_hh_output include/net/neighbour.h:529 [inline] [<f ---truncated--- En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipvlan: agregue el asistente ipvlan_route_v6_outbound(). Inspirado en los informes de syzbot que utilizan una pila de múltiples dispositivos ipvlan. Reduzca el tamaño de pila necesario en ipvlan_process_v6_outbound() moviendo la estructura flowi6 utilizada para la búsqueda de rutas en un asistente no integrado. ipvlan_route_v6_outbound() necesita 120 bytes en la pila, que se recuperan inmediatamente. También asegúrese de que ipvlan_process_v4_outbound() no esté incluido. Es posible que también tengamos que reducir MAX_NEST_DEV, porque solo syzbot usa configuraciones con más de cuatro dispositivos apilados. • https://git.kernel.org/stable/c/2ad7bf3638411cb547f2823df08166c13ab04269 https://git.kernel.org/stable/c/4f7f850611aa27aaaf1bf5687702ad2240ae442a https://git.kernel.org/stable/c/4d2d30f0792b47908af64c4d02ed1ee25ff50542 https://git.kernel.org/stable/c/43b781e7cb5cd0b435de276111953bf2bacd1f02 https://git.kernel.org/stable/c/1f64cad3ac38ac5978b53c40e6c5e6fd3477c68f https://git.kernel.org/stable/c/732a67ca436887b594ebc43bb5a04ffb0971a760 https://git.kernel.org/stable/c/8872dc638c24bb774cd2224a69d72a7f661a4d56 https://git.kernel.org/stable/c/03cddc4df8c6be47fd27c8f8b87e5f9a9 • CWE-121: Stack-based Buffer Overflow •
CVSS: 4.4EPSS: 0%CPEs: 7EXPL: 0CVE-2023-52791 – i2c: core: Run atomic i2c xfer when !preemptible
https://notcve.org/view.php?id=CVE-2023-52791
In the Linux kernel, the following vulnerability has been resolved: i2c: core: Run atomic i2c xfer when !preemptible Since bae1d3a05a8b, i2c transfers are non-atomic if preemption is disabled. However, non-atomic i2c transfers require preemption (e.g. in wait_for_completion() while waiting for the DMA). panic() calls preempt_disable_notrace() before calling emergency_restart(). Therefore, if an i2c device is used for the restart, the xfer should be atomic. This avoids warnings like: [ 12.667612] WARNING: CPU: 1 PID: 1 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x33c/0x6b0 [ 12.676926] Voluntary context switch within RCU read-side critical section! • https://git.kernel.org/stable/c/bae1d3a05a8b99bd748168bbf8155a1d047c562e https://git.kernel.org/stable/c/25eb381a736e7ae39a4245ef5c96484eb1073809 https://git.kernel.org/stable/c/25284c46b657f48c0f3880a2e0706c70d81182c0 https://git.kernel.org/stable/c/f6237afabc349c1c7909db00e15d2816519e0d2b https://git.kernel.org/stable/c/185f3617adc8fe45e40489b458f03911f0dec46c https://git.kernel.org/stable/c/8c3fa52a46ff4d208cefb1a462ec94e0043a91e1 https://git.kernel.org/stable/c/3473cf43b9068b9dfef2f545f833f33c6a544b91 https://git.kernel.org/stable/c/aa49c90894d06e18a1ee7c095edbd2f37 • CWE-459: Incomplete Cleanup •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2023-52789 – tty: vcc: Add check for kstrdup() in vcc_probe()
https://notcve.org/view.php?id=CVE-2023-52789
In the Linux kernel, the following vulnerability has been resolved: tty: vcc: Add check for kstrdup() in vcc_probe() Add check for the return value of kstrdup() and return the error, if it fails in order to avoid NULL pointer dereference. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tty: vcc: Agregar verificación para kstrdup() en vcc_probe(). Agregar verificación para el valor de retorno de kstrdup() y devolver el error, si falla, para evitar la desreferencia de puntero NULL . • https://git.kernel.org/stable/c/38cd56fc9de78bf3c878790785e8c231116ef9d3 https://git.kernel.org/stable/c/909963e0c16778cec28efb1affc21558825f4200 https://git.kernel.org/stable/c/460284dfb10b207980c6f3f7046e33446ceb38ac https://git.kernel.org/stable/c/4ef41a7f33ffe1a335e7db7e1564ddc6afad47cc https://git.kernel.org/stable/c/6c80f48912b5bd4965352d1a9a989e21743a4a06 https://git.kernel.org/stable/c/7cebc86481bf16049e266f6774d90f2fd4f8d5d2 https://git.kernel.org/stable/c/4a24a31826246b15477399febd13292b0c9f0ee9 https://git.kernel.org/stable/c/8f8771757b130383732195497e47fba2a •
CVSS: 4.4EPSS: 0%CPEs: 7EXPL: 0CVE-2023-52784 – bonding: stop the device in bond_setup_by_slave()
https://notcve.org/view.php?id=CVE-2023-52784
In the Linux kernel, the following vulnerability has been resolved: bonding: stop the device in bond_setup_by_slave() Commit 9eed321cde22 ("net: lapbether: only support ethernet devices") has been able to keep syzbot away from net/lapb, until today. In the following splat [1], the issue is that a lapbether device has been created on a bonding device without members. Then adding a non ARPHRD_ETHER member forced the bonding master to change its type. The fix is to make sure we call dev_close() in bond_setup_by_slave() so that the potential linked lapbether devices (or any other devices having assumptions on the physical device) are removed. A similar bug has been addressed in commit 40baec225765 ("bonding: fix panic on non-ARPHRD_ETHER enslave failure") [1] skbuff: skb_under_panic: text:ffff800089508810 len:44 put:40 head:ffff0000c78e7c00 data:ffff0000c78e7bea tail:0x16 end:0x140 dev:bond0 kernel BUG at net/core/skbuff.c:192 ! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 6007 Comm: syz-executor383 Not tainted 6.6.0-rc3-syzkaller-gbf6547d8715b #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_panic net/core/skbuff.c:188 [inline] pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:202 lr : skb_panic net/core/skbuff.c:188 [inline] lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:202 sp : ffff800096a06aa0 x29: ffff800096a06ab0 x28: ffff800096a06ba0 x27: dfff800000000000 x26: ffff0000ce9b9b50 x25: 0000000000000016 x24: ffff0000c78e7bea x23: ffff0000c78e7c00 x22: 000000000000002c x21: 0000000000000140 x20: 0000000000000028 x19: ffff800089508810 x18: ffff800096a06100 x17: 0000000000000000 x16: ffff80008a629a3c x15: 0000000000000001 x14: 1fffe00036837a32 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000201 x10: 0000000000000000 x9 : cb50b496c519aa00 x8 : cb50b496c519aa00 x7 : 0000000000000001 x6 : 0000000000000001 x5 : ffff800096a063b8 x4 : ffff80008e280f80 x3 : ffff8000805ad11c x2 : 0000000000000001 x1 : 0000000100000201 x0 : 0000000000000086 Call trace: skb_panic net/core/skbuff.c:188 [inline] skb_under_panic+0x13c/0x140 net/core/skbuff.c:202 skb_push+0xf0/0x108 net/core/skbuff.c:2446 ip6gre_header+0xbc/0x738 net/ipv6/ip6_gre.c:1384 dev_hard_header include/linux/netdevice.h:3136 [inline] lapbeth_data_transmit+0x1c4/0x298 drivers/net/wan/lapbether.c:257 lapb_data_transmit+0x8c/0xb0 net/lapb/lapb_iface.c:447 lapb_transmit_buffer+0x178/0x204 net/lapb/lapb_out.c:149 lapb_send_control+0x220/0x320 net/lapb/lapb_subr.c:251 __lapb_disconnect_request+0x9c/0x17c net/lapb/lapb_iface.c:326 lapb_device_event+0x288/0x4e0 net/lapb/lapb_iface.c:492 notifier_call_chain+0x1a4/0x510 kernel/notifier.c:93 raw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461 call_netdevice_notifiers_info net/core/dev.c:1970 [inline] call_netdevice_notifiers_extack net/core/dev.c:2008 [inline] call_netdevice_notifiers net/core/dev.c:2022 [inline] __dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508 dev_close_many+0x1e0/0x470 net/core/dev.c:1559 dev_close+0x174/0x250 net/core/dev.c:1585 lapbeth_device_event+0x2e4/0x958 drivers/net/wan/lapbether.c:466 notifier_call_chain+0x1a4/0x510 kernel/notifier.c:93 raw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461 call_netdevice_notifiers_info net/core/dev.c:1970 [inline] call_netdevice_notifiers_extack net/core/dev.c:2008 [inline] call_netdevice_notifiers net/core/dev.c:2022 [inline] __dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508 dev_close_many+0x1e0/0x470 net/core/dev.c:1559 dev_close+0x174/0x250 net/core/dev.c:1585 bond_enslave+0x2298/0x30cc drivers/net/bonding/bond_main.c:2332 bond_do_ioctl+0x268/0xc64 drivers/net/bonding/bond_main.c:4539 dev_ifsioc+0x754/0x9ac dev_ioctl+0x4d8/0xd34 net/core/dev_ioctl.c:786 sock_do_ioctl+0x1d4/0x2d0 net/socket.c:1217 sock_ioctl+0x4e8/0x834 net/socket.c:1322 vfs_ioctl fs/ioctl.c:51 [inline] __do_ ---truncated--- En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bonding: detener el dispositivo en bond_setup_by_slave(). El compromiso 9eed321cde22 ("net: lapbether: solo admite dispositivos ethernet") ha podido mantener a syzbot alejado de net/lapb, hasta hoy. En el siguiente símbolo [1], el problema es que se ha creado un dispositivo lapbether sobre un dispositivo de unión sin miembros. • https://git.kernel.org/stable/c/872254dd6b1f80cb95ee9e2e22980888533fc293 https://git.kernel.org/stable/c/b4f0e605a508f6d7cda6df2f03a0c676b778b1fe https://git.kernel.org/stable/c/396baca6683f415b5bc2b380289387bef1406edc https://git.kernel.org/stable/c/53064e8239dd2ecfefc5634e991f1025abc2ee0c https://git.kernel.org/stable/c/19554aa901b5833787df4417a05ccdebf351b7f4 https://git.kernel.org/stable/c/87c49806a37f88eddde3f537c162fd0c2834170c https://git.kernel.org/stable/c/d98c91215a5748a0f536e7ccea26027005196859 https://git.kernel.org/stable/c/3cffa2ddc4d3fcf70cde361236f5a614f • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •