Page 192 of 2499 results (0.007 seconds)

CVSS: 7.1EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: ipack: ipoctal: fix module reference leak A reference to the carrier module was taken on every open but was only released once when the final reference to the tty struct was dropped. Fix this by taking the module reference and initialising the tty driver data when installing the tty. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipack: ipoctal: reparar fuga de referencia del módulo. Se tomó una referencia al módulo portador en cada apertura, pero solo se publicó una vez cuando se eliminó la referencia final a la estructura tty. Solucione este problema tomando la referencia del módulo e inicializando los datos del controlador tty al instalar el tty. • https://git.kernel.org/stable/c/82a82340bab6c251e0705339f60763718eaa2a22 https://git.kernel.org/stable/c/31398849b84ebae0d43a1cf379cb9895597f221a https://git.kernel.org/stable/c/c0adb5a947dec6cff7050ec56d78ecd3916f9ce6 https://git.kernel.org/stable/c/dde4c1429b97383689f755ce92b4ed1e84a9c92b https://git.kernel.org/stable/c/9c5b77a7ffc983b2429ce158b50497c5d3c86a69 https://git.kernel.org/stable/c/3253c87e1e5bc0107aab773af2f135ebccf38666 https://git.kernel.org/stable/c/7cea848678470daadbfdaa6a112b823c290f900c https://git.kernel.org/stable/c/811178f296b16af30264def74c8d2179a • CWE-200: Exposure of Sensitive Information to an Unauthorized Actor •

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

In the Linux kernel, the following vulnerability has been resolved: net: sched: flower: protect fl_walk() with rcu Patch that refactored fl_walk() to use idr_for_each_entry_continue_ul() also removed rcu protection of individual filters which causes following use-after-free when filter is deleted concurrently. Fix fl_walk() to obtain rcu read lock while iterating and taking the filter reference and temporary release the lock while calling arg->fn() callback that can sleep. KASAN trace: [ 352.773640] ================================================================== [ 352.775041] BUG: KASAN: use-after-free in fl_walk+0x159/0x240 [cls_flower] [ 352.776304] Read of size 4 at addr ffff8881c8251480 by task tc/2987 [ 352.777862] CPU: 3 PID: 2987 Comm: tc Not tainted 5.15.0-rc2+ #2 [ 352.778980] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 352.781022] Call Trace: [ 352.781573] dump_stack_lvl+0x46/0x5a [ 352.782332] print_address_description.constprop.0+0x1f/0x140 [ 352.783400] ? fl_walk+0x159/0x240 [cls_flower] [ 352.784292] ? fl_walk+0x159/0x240 [cls_flower] [ 352.785138] kasan_report.cold+0x83/0xdf [ 352.785851] ? fl_walk+0x159/0x240 [cls_flower] [ 352.786587] kasan_check_range+0x145/0x1a0 [ 352.787337] fl_walk+0x159/0x240 [cls_flower] [ 352.788163] ? • https://git.kernel.org/stable/c/d39d714969cda5cbda291402c8c6b1fb1047f42e https://git.kernel.org/stable/c/694b0cee7f8546b69a80996a29cb3cf4149c0453 https://git.kernel.org/stable/c/d0d520c19e7ea19ed38dc5797b12397b6ccf9f88 https://git.kernel.org/stable/c/dab4677bdbffa5c8270e79e34e51c89efa0728a0 https://git.kernel.org/stable/c/d5ef190693a7d76c5c192d108e8dec48307b46ee •

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

In the Linux kernel, the following vulnerability has been resolved: ipack: ipoctal: fix stack information leak The tty driver name is used also after registering the driver and must specifically not be allocated on the stack to avoid leaking information to user space (or triggering an oops). Drivers should not try to encode topology information in the tty device name but this one snuck in through staging without anyone noticing and another driver has since copied this malpractice. Fixing the ABI is a separate issue, but this at least plugs the security hole. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipack: ipoctal: corrige la fuga de información de la pila. El nombre del controlador tty también se usa después de registrar el controlador y específicamente no debe asignarse en la pila para evitar filtrar información al espacio del usuario (o activar un ups). Los controladores no deberían intentar codificar información de topología en el nombre del dispositivo tty, pero este se coló durante la preparación sin que nadie se diera cuenta y desde entonces otro controlador copió esta mala práctica. Arreglar la ABI es un tema aparte, pero esto al menos tapa el agujero de seguridad. • https://git.kernel.org/stable/c/ba4dc61fe8c545a5d6a68b63616776556b771f51 https://git.kernel.org/stable/c/acb96e782bad427ca4bb1bd94af660acd1462380 https://git.kernel.org/stable/c/741ea2670e021350e54f491106bdaa22dc50e6a0 https://git.kernel.org/stable/c/2725925982dc96a78069cd118ea3d66759bfdad7 https://git.kernel.org/stable/c/829f13d6079cf7a2465522f39acb43033e9b320d https://git.kernel.org/stable/c/8657158a3b68c85234e6da3d8eae33d6183588b7 https://git.kernel.org/stable/c/5f6a309a699675680df15d9b6d389114515b4426 https://git.kernel.org/stable/c/0a9c36a2e06a249acbed64e8e0b84637c •

CVSS: 4.1EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: net: hns3: do not allow call hns3_nic_net_open repeatedly hns3_nic_net_open() is not allowed to called repeatly, but there is no checking for this. When doing device reset and setup tc concurrently, there is a small oppotunity to call hns3_nic_net_open repeatedly, and cause kernel bug by calling napi_enable twice. The calltrace information is like below: [ 3078.222780] ------------[ cut here ]------------ [ 3078.230255] kernel BUG at net/core/dev.c:6991! [ 3078.236224] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 3078.243431] Modules linked in: hns3 hclgevf hclge hnae3 vfio_iommu_type1 vfio_pci vfio_virqfd vfio pv680_mii(O) [ 3078.258880] CPU: 0 PID: 295 Comm: kworker/u8:5 Tainted: G O 5.14.0-rc4+ #1 [ 3078.269102] Hardware name: , BIOS KpxxxFPGA 1P B600 V181 08/12/2021 [ 3078.276801] Workqueue: hclge hclge_service_task [hclge] [ 3078.288774] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--) [ 3078.296168] pc : napi_enable+0x80/0x84 tc qdisc sho[w 3d0e7v8 .e3t0h218 79] lr : hns3_nic_net_open+0x138/0x510 [hns3] [ 3078.314771] sp : ffff8000108abb20 [ 3078.319099] x29: ffff8000108abb20 x28: 0000000000000000 x27: ffff0820a8490300 [ 3078.329121] x26: 0000000000000001 x25: ffff08209cfc6200 x24: 0000000000000000 [ 3078.339044] x23: ffff0820a8490300 x22: ffff08209cd76000 x21: ffff0820abfe3880 [ 3078.349018] x20: 0000000000000000 x19: ffff08209cd76900 x18: 0000000000000000 [ 3078.358620] x17: 0000000000000000 x16: ffffc816e1727a50 x15: 0000ffff8f4ff930 [ 3078.368895] x14: 0000000000000000 x13: 0000000000000000 x12: 0000259e9dbeb6b4 [ 3078.377987] x11: 0096a8f7e764eb40 x10: 634615ad28d3eab5 x9 : ffffc816ad8885b8 [ 3078.387091] x8 : ffff08209cfc6fb8 x7 : ffff0820ac0da058 x6 : ffff0820a8490344 [ 3078.396356] x5 : 0000000000000140 x4 : 0000000000000003 x3 : ffff08209cd76938 [ 3078.405365] x2 : 0000000000000000 x1 : 0000000000000010 x0 : ffff0820abfe38a0 [ 3078.414657] Call trace: [ 3078.418517] napi_enable+0x80/0x84 [ 3078.424626] hns3_reset_notify_up_enet+0x78/0xd0 [hns3] [ 3078.433469] hns3_reset_notify+0x64/0x80 [hns3] [ 3078.441430] hclge_notify_client+0x68/0xb0 [hclge] [ 3078.450511] hclge_reset_rebuild+0x524/0x884 [hclge] [ 3078.458879] hclge_reset_service_task+0x3c4/0x680 [hclge] [ 3078.467470] hclge_service_task+0xb0/0xb54 [hclge] [ 3078.475675] process_one_work+0x1dc/0x48c [ 3078.481888] worker_thread+0x15c/0x464 [ 3078.487104] kthread+0x160/0x170 [ 3078.492479] ret_from_fork+0x10/0x18 [ 3078.498785] Code: c8027c81 35ffffa2 d50323bf d65f03c0 (d4210000) [ 3078.506889] ---[ end trace 8ebe0340a1b0fb44 ]--- Once hns3_nic_net_open() is excute success, the flag HNS3_NIC_STATE_DOWN will be cleared. So add checking for this flag, directly return when HNS3_NIC_STATE_DOWN is no set. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: hns3: no permitir llamadas repetidas a hns3_nic_net_open. • https://git.kernel.org/stable/c/e888402789b9db5de4fcda361331d66dbf0cd9fd https://git.kernel.org/stable/c/5a31d4e73ada8022427b69b10fd1f01a6a8d4b3d https://git.kernel.org/stable/c/f8ba689cb69523144d10606096ef686002dd7285 https://git.kernel.org/stable/c/3dac38bdce7932901b9f0b71c62331852c809e61 https://git.kernel.org/stable/c/5b09e88e1bf7fe86540fab4b5f3eece8abead39e https://access.redhat.com/security/cve/CVE-2021-47400 https://bugzilla.redhat.com/show_bug.cgi?id=2282336 • CWE-664: Improper Control of a Resource Through its Lifetime •

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

In the Linux kernel, the following vulnerability has been resolved: ixgbe: Fix NULL pointer dereference in ixgbe_xdp_setup The ixgbe driver currently generates a NULL pointer dereference with some machine (online cpus < 63). This is due to the fact that the maximum value of num_xdp_queues is nr_cpu_ids. Code is in "ixgbe_set_rss_queues"". Here's how the problem repeats itself: Some machine (online cpus < 63), And user set num_queues to 63 through ethtool. Code is in the "ixgbe_set_channels", adapter->ring_feature[RING_F_FDIR].limit = count; It becomes 63. When user use xdp, "ixgbe_set_rss_queues" will set queues num. adapter->num_rx_queues = rss_i; adapter->num_tx_queues = rss_i; adapter->num_xdp_queues = ixgbe_xdp_queues(adapter); And rss_i's value is from f = &adapter->ring_feature[RING_F_FDIR]; rss_i = f->indices = f->limit; So "num_rx_queues" > "num_xdp_queues", when run to "ixgbe_xdp_setup", for (i = 0; i < adapter->num_rx_queues; i++) if (adapter->xdp_ring[i]->xsk_umem) It leads to panic. Call trace: [exception RIP: ixgbe_xdp+368] RIP: ffffffffc02a76a0 RSP: ffff9fe16202f8d0 RFLAGS: 00010297 RAX: 0000000000000000 RBX: 0000000000000020 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 000000000000001c RDI: ffffffffa94ead90 RBP: ffff92f8f24c0c18 R8: 0000000000000000 R9: 0000000000000000 R10: ffff9fe16202f830 R11: 0000000000000000 R12: ffff92f8f24c0000 R13: ffff9fe16202fc01 R14: 000000000000000a R15: ffffffffc02a7530 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 7 [ffff9fe16202f8f0] dev_xdp_install at ffffffffa89fbbcc 8 [ffff9fe16202f920] dev_change_xdp_fd at ffffffffa8a08808 9 [ffff9fe16202f960] do_setlink at ffffffffa8a20235 10 [ffff9fe16202fa88] rtnl_setlink at ffffffffa8a20384 11 [ffff9fe16202fc78] rtnetlink_rcv_msg at ffffffffa8a1a8dd 12 [ffff9fe16202fcf0] netlink_rcv_skb at ffffffffa8a717eb 13 [ffff9fe16202fd40] netlink_unicast at ffffffffa8a70f88 14 [ffff9fe16202fd80] netlink_sendmsg at ffffffffa8a71319 15 [ffff9fe16202fdf0] sock_sendmsg at ffffffffa89df290 16 [ffff9fe16202fe08] __sys_sendto at ffffffffa89e19c8 17 [ffff9fe16202ff30] __x64_sys_sendto at ffffffffa89e1a64 18 [ffff9fe16202ff38] do_syscall_64 at ffffffffa84042b9 19 [ffff9fe16202ff50] entry_SYSCALL_64_after_hwframe at ffffffffa8c0008c So I fix ixgbe_max_channels so that it will not allow a setting of queues to be higher than the num_online_cpus(). And when run to ixgbe_xdp_setup, take the smaller value of num_rx_queues and num_xdp_queues. • https://git.kernel.org/stable/c/4a9b32f30f805ca596d76605903a48eab58e0b88 https://git.kernel.org/stable/c/20f6c4a31a525edd9ea6243712b868ba0e4e331e https://git.kernel.org/stable/c/2744341dd52e935344ca1b4bf189ba0d182a3e8e https://git.kernel.org/stable/c/513e605d7a9ce136886cb42ebb2c40e9a6eb6333 •