Page 133 of 2598 results (0.037 seconds)

CVSS: -EPSS: 0%CPEs: 5EXPL: 0

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: 0

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: 0

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-&gt;gain" para evitar un acceso fuera de los límites. La preocupación es que estos puedan provenir del usuario a través de: -&gt; snd_ctl_elem_write_user() -&gt; snd_ctl_elem_write() -&gt; kctl-&gt;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: 0

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: 0

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 •