CVSS: 9.8EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48716 – ASoC: codecs: wcd938x: fix incorrect used of portid
https://notcve.org/view.php?id=CVE-2022-48716
In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: wcd938x: fix incorrect used of portid Mixer controls have the channel id in mixer->reg, which is not same as port id. port id should be derived from chan_info array. So fix this. Without this, its possible that we could corrupt struct wcd938x_sdw_priv by accessing port_map array out of range with channel id instead of port id. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ASoC: códecs: wcd938x: corrige el uso incorrecto del puerto Los controles del mezclador tienen la identificación del canal en mezclador->reg, que no es la misma que la identificación del puerto. La identificación del puerto debe derivarse de la matriz chan_info. Entonces arregla esto. • https://git.kernel.org/stable/c/e8ba1e05bdc016700c85fad559a812c2e795442f https://git.kernel.org/stable/c/aa7152f9f117b3e66b3c0d4158ca4c6d46ab229f https://git.kernel.org/stable/c/9167f2712dc8c24964840a4d1e2ebf130e846b95 https://git.kernel.org/stable/c/c5c1546a654f613e291a7c5d6f3660fc1eb6d0c7 • CWE-400: Uncontrolled Resource Consumption •
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 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-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 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48712 – ext4: fix error handling in ext4_fc_record_modified_inode()
https://notcve.org/view.php?id=CVE-2022-48712
In the Linux kernel, the following vulnerability has been resolved: ext4: fix error handling in ext4_fc_record_modified_inode() Current code does not fully takes care of krealloc() error case, which could lead to silent memory corruption or a kernel bug. This patch fixes that. Also it cleans up some duplicated error handling logic from various functions in fast_commit.c file. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ext4: corrige el manejo de errores en ext4_fc_record_modified_inode() El código actual no soluciona completamente el caso de error de krealloc(), lo que podría provocar una corrupción silenciosa de la memoria o un error del kernel. Este parche soluciona eso. También limpia alguna lógica de manejo de errores duplicada de varias funciones en el archivo fast_commit.c. • https://git.kernel.org/stable/c/62e46e0ffc02daa8fcfc02f7a932cc8a19601b19 https://git.kernel.org/stable/c/1b6762ecdf3cf12113772427c904aa3c420a1802 https://git.kernel.org/stable/c/14aa3f49c7fc6424763f4323bfbc3a807b0727dc https://git.kernel.org/stable/c/cdce59a1549190b66f8e3fe465c2b2f714b98a94 •