CVE-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 •
CVE-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 •
CVE-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 •
CVE-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 •
CVE-2022-48713 – perf/x86/intel/pt: Fix crash with stop filters in single-range mode
https://notcve.org/view.php?id=CVE-2022-48713
In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel/pt: Fix crash with stop filters in single-range mode Add a check for !buf->single before calling pt_buffer_region_size in a place where a missing check can cause a kernel crash. Fixes a bug introduced by commit 670638477aed ("perf/x86/intel/pt: Opportunistically use single range output mode"), which added a support for PT single-range output mode. Since that commit if a PT stop filter range is hit while tracing, the kernel will crash because of a null pointer dereference in pt_handle_status due to calling pt_buffer_region_size without a ToPA configured. The commit which introduced single-range mode guarded almost all uses of the ToPA buffer variables with checks of the buf->single variable, but missed the case where tracing was stopped by the PT hardware, which happens when execution hits a configured stop filter. Tested that hitting a stop filter while PT recording successfully records a trace with this patch but crashes without this patch. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf/x86/intel/pt: soluciona el fallo con filtros de parada en modo de rango único. Añade una marca para ! • https://git.kernel.org/stable/c/670638477aede0d7a355ced04b569214aa3feacd https://git.kernel.org/stable/c/456f041e035913fcedb275aff6f8a71dfebcd394 https://git.kernel.org/stable/c/e83d941fd3445f660d2f43647c580a320cc384f6 https://git.kernel.org/stable/c/feffb6ae2c80b9a8206450cdef90f5943baced99 https://git.kernel.org/stable/c/1d9093457b243061a9bba23543c38726e864a643 •