CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2022-48721 – net/smc: Forward wakeup to smc socket waitqueue after fallback
https://notcve.org/view.php?id=CVE-2022-48721
In the Linux kernel, the following vulnerability has been resolved: net/smc: Forward wakeup to smc socket waitqueue after fallback When we replace TCP with SMC and a fallback occurs, there may be some socket waitqueue entries remaining in smc socket->wq, such as eppoll_entries inserted by userspace applications. After the fallback, data flows over TCP/IP and only clcsocket->wq will be woken up. Applications can't be notified by the entries which were inserted in smc socket->wq before fallback. So we need a mechanism to wake up smc socket->wq at the same time if some entries remaining in it. The current workaround is to transfer the entries from smc socket->wq to clcsock->wq during the fallback. But this may cause a crash like this: general protection fault, probably for non-canonical address 0xdead000000000100: 0000 [#1] PREEMPT SMP PTI CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Tainted: G E 5.16.0+ #107 RIP: 0010:__wake_up_common+0x65/0x170 Call Trace: <IRQ> __wake_up_common_lock+0x7a/0xc0 sock_def_readable+0x3c/0x70 tcp_data_queue+0x4a7/0xc40 tcp_rcv_established+0x32f/0x660 ? sk_filter_trim_cap+0xcb/0x2e0 tcp_v4_do_rcv+0x10b/0x260 tcp_v4_rcv+0xd2a/0xde0 ip_protocol_deliver_rcu+0x3b/0x1d0 ip_local_deliver_finish+0x54/0x60 ip_local_deliver+0x6a/0x110 ? • https://git.kernel.org/stable/c/fb92e025baa73e99250b79ab64f4e088d2888993 https://git.kernel.org/stable/c/2153bd1e3d3dbf6a3403572084ef6ed31c53c5f0 https://git.kernel.org/stable/c/d6e981ec9491be5ec46d838b1151e7edefe607f5 https://git.kernel.org/stable/c/ff6eeb627898c179aac421af5d6515d3f50b84df https://git.kernel.org/stable/c/0ef6049f664941bc0f75828b3a61877635048b27 https://git.kernel.org/stable/c/504078fbe9dd570d685361b57784a6050bc40aaa https://git.kernel.org/stable/c/341adeec9adad0874f29a0a1af35638207352a39 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48720 – net: macsec: Fix offload support for NETDEV_UNREGISTER event
https://notcve.org/view.php?id=CVE-2022-48720
In the Linux kernel, the following vulnerability has been resolved: net: macsec: Fix offload support for NETDEV_UNREGISTER event Current macsec netdev notify handler handles NETDEV_UNREGISTER event by releasing relevant SW resources only, this causes resources leak in case of macsec HW offload, as the underlay driver was not notified to clean it's macsec offload resources. Fix by calling the underlay driver to clean it's relevant resources by moving offload handling from macsec_dellink() to macsec_common_dellink() when handling NETDEV_UNREGISTER event. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: macsec: se corrigió el soporte de descarga para el evento NETDEV_UNREGISTER. El controlador de notificación netdev de macsec actual maneja el evento NETDEV_UNREGISTER liberando solo recursos SW relevantes, lo que provoca una pérdida de recursos en caso de descarga de HW de macsec, ya que No se notificó al controlador subyacente que limpiara sus recursos de descarga de macsec. Para solucionarlo, llame al controlador subyacente para limpiar sus recursos relevantes moviendo el manejo de descarga de macsec_dellink() a macsec_common_dellink() cuando se maneja el evento NETDEV_UNREGISTER. • https://git.kernel.org/stable/c/3cf3227a21d1fb020fe26128e60321bd2151e922 https://git.kernel.org/stable/c/2e7f5b6ee1a7a2c628253a95b0a95b582901ef1b https://git.kernel.org/stable/c/e7a0b3a0806dae3cc81931f0e83055ca2ac6f455 https://git.kernel.org/stable/c/8299be160aad8548071d080518712dec0df92bd5 https://git.kernel.org/stable/c/9cef24c8b76c1f6effe499d2f131807c90f7ce9a •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2022-48717 – ASoC: max9759: fix underflow in speaker_gain_control_put()
https://notcve.org/view.php?id=CVE-2022-48717
In the Linux kernel, the following vulnerability has been resolved: ASoC: max9759: fix underflow in speaker_gain_control_put() Check for negative values of "priv->gain" to prevent an out of bounds access. The concern is that these might come from the user via: -> snd_ctl_elem_write_user() -> snd_ctl_elem_write() -> kctl->put() En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: max9759: corrige el desbordamiento en altavoz_gain_control_put() Compruebe si hay valores negativos de "priv->gain" para evitar un acceso fuera de los límites. La preocupación es que estos puedan provenir del usuario a través de: -> snd_ctl_elem_write_user() -> snd_ctl_elem_write() -> kctl->put() • https://git.kernel.org/stable/c/fa8d915172b8c10ec0734c4021e99e9705023b07 https://git.kernel.org/stable/c/a0f49d12547d45ea8b0f356a96632dd503941c1e https://git.kernel.org/stable/c/71e60c170105d153e34d01766c1e4db26a4b24cc https://git.kernel.org/stable/c/5a45448ac95b715173edb1cd090ff24b6586d921 https://git.kernel.org/stable/c/baead410e5db49e962a67fffc17ac30e44b50b7c https://git.kernel.org/stable/c/f114fd6165dfb52520755cc4d1c1dfbd447b88b6 https://git.kernel.org/stable/c/4c907bcd9dcd233da6707059d777ab389dcbd964 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48715 – scsi: bnx2fc: Make bnx2fc_recv_frame() mp safe
https://notcve.org/view.php?id=CVE-2022-48715
In the Linux kernel, the following vulnerability has been resolved: scsi: bnx2fc: Make bnx2fc_recv_frame() mp safe Running tests with a debug kernel shows that bnx2fc_recv_frame() is modifying the per_cpu lport stats counters in a non-mpsafe way. Just boot a debug kernel and run the bnx2fc driver with the hardware enabled. [ 1391.699147] BUG: using smp_processor_id() in preemptible [00000000] code: bnx2fc_ [ 1391.699160] caller is bnx2fc_recv_frame+0xbf9/0x1760 [bnx2fc] [ 1391.699174] CPU: 2 PID: 4355 Comm: bnx2fc_l2_threa Kdump: loaded Tainted: G B [ 1391.699180] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013 [ 1391.699183] Call Trace: [ 1391.699188] dump_stack_lvl+0x57/0x7d [ 1391.699198] check_preemption_disabled+0xc8/0xd0 [ 1391.699205] bnx2fc_recv_frame+0xbf9/0x1760 [bnx2fc] [ 1391.699215] ? do_raw_spin_trylock+0xb5/0x180 [ 1391.699221] ? bnx2fc_npiv_create_vports.isra.0+0x4e0/0x4e0 [bnx2fc] [ 1391.699229] ? bnx2fc_l2_rcv_thread+0xb7/0x3a0 [bnx2fc] [ 1391.699240] bnx2fc_l2_rcv_thread+0x1af/0x3a0 [bnx2fc] [ 1391.699250] ? • https://git.kernel.org/stable/c/d576a5e80cd07ea7049f8fd7b303c14df7b5d7d2 https://git.kernel.org/stable/c/3a345198a7c2d1db2526dc60b77052f75de019d3 https://git.kernel.org/stable/c/471085571f926a1fe6b1bed095638994dbf23990 https://git.kernel.org/stable/c/003bcee66a8f0e76157eb3af369c173151901d97 https://git.kernel.org/stable/c/53e4f71763c61a557283eb43301efd671922d1e8 https://git.kernel.org/stable/c/ec4334152dae175dbd8fd5bde1d2139bbe7b42d0 https://git.kernel.org/stable/c/2f5a1ac68bdf2899ce822ab845081922ea8c588e https://git.kernel.org/stable/c/2d24336c7214b281b51860e54783dfc65 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48714 – bpf: Use VM_MAP instead of VM_ALLOC for ringbuf
https://notcve.org/view.php?id=CVE-2022-48714
In the Linux kernel, the following vulnerability has been resolved: bpf: Use VM_MAP instead of VM_ALLOC for ringbuf After commit 2fd3fb0be1d1 ("kasan, vmalloc: unpoison VM_ALLOC pages after mapping"), non-VM_ALLOC mappings will be marked as accessible in __get_vm_area_node() when KASAN is enabled. But now the flag for ringbuf area is VM_ALLOC, so KASAN will complain out-of-bound access after vmap() returns. Because the ringbuf area is created by mapping allocated pages, so use VM_MAP instead. After the change, info in /proc/vmallocinfo also changes from [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmalloc user to [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmap user En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf: use VM_MAP en lugar de VM_ALLOC para ringbuf Después del commit 2fd3fb0be1d1 ("kasan, vmalloc: despoisone las páginas VM_ALLOC después del mapeo"), los mapeos que no sean VM_ALLOC se marcarán como accesibles en __get_vm_area_node( ) cuando KASAN está habilitado. Pero ahora el indicador para el área ringbuf es VM_ALLOC, por lo que KASAN se quejará del acceso fuera de los límites después de que regrese vmap(). Debido a que el área ringbuf se crea asignando páginas asignadas, use VM_MAP en su lugar. • https://git.kernel.org/stable/c/457f44363a8894135c85b7a9afd2bd8196db24ab https://git.kernel.org/stable/c/6304a613a97d6dcd49b93fbad31e9f39d1e138d6 https://git.kernel.org/stable/c/5e457aeab52a5947619e1f18047f4d2f3212b3eb https://git.kernel.org/stable/c/d578933f6226d5419af9306746efa1c693cbaf9c https://git.kernel.org/stable/c/b293dcc473d22a62dc6d78de2b15e4f49515db56 •