May 2024 - Kernel - mailweb.openeuler.org

[PATCH openEuler-1.0-LTS] tty: serial: 8250: serial_cs: Fix a memory leak in error handling path
by Cai Xinchen 31 May '24

31 May '24

From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> stable inclusion from stable-v4.19.198 commit cddee5c287e26f6b2ba5c0ffdfc3a846f2f10461 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9S6TL CVE: CVE-2021-47330 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit fad92b11047a748c996ebd6cfb164a63814eeb2e ] In the probe function, if the final 'serial_config()' fails, 'info' is leaking. Add a resource handling path to free this memory. Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Link: https://lore.kernel.org/r/dc25f96b7faebf42e60fe8d02963c941cf4d8124.16219717… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Cai Xinchen <caixinchen1(a)huawei.com> --- drivers/tty/serial/8250/serial_cs.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/tty/serial/8250/serial_cs.c b/drivers/tty/serial/8250/serial_cs.c index c8186a05a453..271c0388e00d 100644 --- a/drivers/tty/serial/8250/serial_cs.c +++ b/drivers/tty/serial/8250/serial_cs.c @@ -306,6 +306,7 @@ static int serial_resume(struct pcmcia_device *link) static int serial_probe(struct pcmcia_device *link) { struct serial_info *info; + int ret; dev_dbg(&link->dev, "serial_attach()\n"); @@ -320,7 +321,15 @@ static int serial_probe(struct pcmcia_device *link) if (do_sound) link->config_flags |= CONF_ENABLE_SPKR; - return serial_config(link); + ret = serial_config(link); + if (ret) + goto free_info; + + return 0; + +free_info: + kfree(info); + return ret; } static void serial_detach(struct pcmcia_device *link) -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] can: j1939: j1939_netdev_start(): fix UAF for rx_kref of j1939_priv
by Ziyang Xuan 31 May '24

31 May '24

mainline inclusion from mainline-v5.15-rc7 commit d9d52a3ebd284882f5562c88e55991add5d01586 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9RB24 CVE: CVE-2021-47459 -------------------------------- It will trigger UAF for rx_kref of j1939_priv as following. cpu0 cpu1 j1939_sk_bind(socket0, ndev0, ...) j1939_netdev_start j1939_sk_bind(socket1, ndev0, ...) j1939_netdev_start j1939_priv_set j1939_priv_get_by_ndev_locked j1939_jsk_add ..... j1939_netdev_stop kref_put_lock(&priv->rx_kref, ...) kref_get(&priv->rx_kref, ...) REFCOUNT_WARN("addition on 0;...") ==================================================== refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 20874 at lib/refcount.c:25 refcount_warn_saturate+0x169/0x1e0 RIP: 0010:refcount_warn_saturate+0x169/0x1e0 Call Trace: j1939_netdev_start+0x68b/0x920 j1939_sk_bind+0x426/0xeb0 ? security_socket_bind+0x83/0xb0 The rx_kref's kref_get() and kref_put() should use j1939_netdev_lock to protect. Fixes: 9d71dd0c70099 ("can: add support of SAE J1939 protocol") Link: https://lore.kernel.org/all/20210926104757.2021540-1-william.xuanziyang@hua… Cc: stable(a)vger.kernel.org Reported-by: syzbot+85d9878b19c94f9019ad(a)syzkaller.appspotmail.com Signed-off-by: Ziyang Xuan <william.xuanziyang(a)huawei.com> Acked-by: Oleksij Rempel <o.rempel(a)pengutronix.de> Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> Signed-off-by: Ziyang Xuan <william.xuanziyang(a)huawei.com> --- net/can/j1939/main.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/net/can/j1939/main.c b/net/can/j1939/main.c index fed1de256827..ac5169891811 100644 --- a/net/can/j1939/main.c +++ b/net/can/j1939/main.c @@ -251,11 +251,14 @@ struct j1939_priv *j1939_netdev_start(struct net_device *ndev) struct j1939_priv *priv, *priv_new; int ret; - priv = j1939_priv_get_by_ndev(ndev); + spin_lock(&j1939_netdev_lock); + priv = j1939_priv_get_by_ndev_locked(ndev); if (priv) { kref_get(&priv->rx_kref); + spin_unlock(&j1939_netdev_lock); return priv; } + spin_unlock(&j1939_netdev_lock); priv = j1939_priv_create(ndev); if (!priv) @@ -271,10 +274,10 @@ struct j1939_priv *j1939_netdev_start(struct net_device *ndev) /* Someone was faster than us, use their priv and roll * back our's. */ + kref_get(&priv_new->rx_kref); spin_unlock(&j1939_netdev_lock); dev_put(ndev); kfree(priv); - kref_get(&priv_new->rx_kref); return priv_new; } j1939_priv_set(ndev, priv); -- 2.25.1

2 2

[PATCH openEuler-1.0-LTS] i40e: Fix freeing of uninitialized misc IRQ vector
by Cui GaoSheng 31 May '24

31 May '24

From: Sylwester Dziedziuch <sylwesterx.dziedziuch(a)intel.com> stable inclusion from stable-v5.10.73 commit 97aeed72af4f83ae51534f0a2473ff52f8d66236 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9R4ON CVE: CVE-2021-47424 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 2e5a20573a926302b233b0c2e1077f5debc7ab2e ] When VSI set up failed in i40e_probe() as part of PF switch set up driver was trying to free misc IRQ vectors in i40e_clear_interrupt_scheme and produced a kernel Oops: Trying to free already-free IRQ 266 WARNING: CPU: 0 PID: 5 at kernel/irq/manage.c:1731 __free_irq+0x9a/0x300 Workqueue: events work_for_cpu_fn RIP: 0010:__free_irq+0x9a/0x300 Call Trace: ? synchronize_irq+0x3a/0xa0 free_irq+0x2e/0x60 i40e_clear_interrupt_scheme+0x53/0x190 [i40e] i40e_probe.part.108+0x134b/0x1a40 [i40e] ? kmem_cache_alloc+0x158/0x1c0 ? acpi_ut_update_ref_count.part.1+0x8e/0x345 ? acpi_ut_update_object_reference+0x15e/0x1e2 ? strstr+0x21/0x70 ? irq_get_irq_data+0xa/0x20 ? mp_check_pin_attr+0x13/0xc0 ? irq_get_irq_data+0xa/0x20 ? mp_map_pin_to_irq+0xd3/0x2f0 ? acpi_register_gsi_ioapic+0x93/0x170 ? pci_conf1_read+0xa4/0x100 ? pci_bus_read_config_word+0x49/0x70 ? do_pci_enable_device+0xcc/0x100 local_pci_probe+0x41/0x90 work_for_cpu_fn+0x16/0x20 process_one_work+0x1a7/0x360 worker_thread+0x1cf/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x112/0x130 ? kthread_flush_work_fn+0x10/0x10 ret_from_fork+0x1f/0x40 The problem is that at that point misc IRQ vectors were not allocated yet and we get a call trace that driver is trying to free already free IRQ vectors. Add a check in i40e_clear_interrupt_scheme for __I40E_MISC_IRQ_REQUESTED PF state before calling i40e_free_misc_vector. This state is set only if misc IRQ vectors were properly initialized. Fixes: c17401a1dd21 ("i40e: use separate state bit for miscellaneous IRQ setup") Reported-by: PJ Waskiewicz <pwaskiewicz(a)jumptrading.com> Signed-off-by: Sylwester Dziedziuch <sylwesterx.dziedziuch(a)intel.com> Signed-off-by: Mateusz Palczewski <mateusz.palczewski(a)intel.com> Tested-by: Dave Switzer <david.switzer(a)intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Cui GaoSheng <cuigaosheng1(a)huawei.com> --- drivers/net/ethernet/intel/i40e/i40e_main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c index fc6550979118..84bb3ef9f638 100644 --- a/drivers/net/ethernet/intel/i40e/i40e_main.c +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c @@ -4716,7 +4716,8 @@ static void i40e_clear_interrupt_scheme(struct i40e_pf *pf) { int i; - i40e_free_misc_vector(pf); + if (test_bit(__I40E_MISC_IRQ_REQUESTED, pf->state)) + i40e_free_misc_vector(pf); i40e_put_lump(pf->irq_pile, pf->iwarp_base_vector, I40E_IWARP_IRQ_PILE_ID); -- 2.34.1

2 1

[PATCH OLK-5.10] x86/sgx: Break up long non-preemptible delays in sgx_vepc_release()
by Xiang Yang 31 May '24

31 May '24

From: Jack Wang <jinpu.wang(a)ionos.com> mainline inclusion from mainline-v6.6-rc1 commit 3d7d72a34e05b23e21bafc8bfb861e73c86b31f3 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9TZZB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- On large enclaves we hit the softlockup warning with following call trace: xa_erase() sgx_vepc_release() __fput() task_work_run() do_exit() The latency issue is similar to the one fixed in: 8795359e35bc ("x86/sgx: Silence softlockup detection when releasing large enclaves") The test system has 64GB of enclave memory, and all is assigned to a single VM. Release of 'vepc' takes a longer time and causes long latencies, which triggers the softlockup warning. Add cond_resched() to give other tasks a chance to run and reduce latencies, which also avoids the softlockup detector. [ mingo: Rewrote the changelog. ] Fixes: 540745ddbc70 ("x86/sgx: Introduce virtual EPC for use by KVM guests") Reported-by: Yu Zhang <yu.zhang(a)ionos.com> Signed-off-by: Jack Wang <jinpu.wang(a)ionos.com> Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Tested-by: Yu Zhang <yu.zhang(a)ionos.com> Reviewed-by: Jarkko Sakkinen <jarkko(a)kernel.org> Reviewed-by: Kai Huang <kai.huang(a)intel.com> Acked-by: Haitao Huang <haitao.huang(a)linux.intel.com> Cc: stable(a)vger.kernel.org Signed-off-by: Xiang Yang <xiangyang3(a)huawei.com> --- arch/x86/kernel/cpu/sgx/virt.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/kernel/cpu/sgx/virt.c b/arch/x86/kernel/cpu/sgx/virt.c index b4f9a50de776..6d0531f8b087 100644 --- a/arch/x86/kernel/cpu/sgx/virt.c +++ b/arch/x86/kernel/cpu/sgx/virt.c @@ -204,6 +204,7 @@ static int sgx_vepc_release(struct inode *inode, struct file *file) continue; xa_erase(&vepc->page_array, index); + cond_resched(); } /* @@ -222,6 +223,7 @@ static int sgx_vepc_release(struct inode *inode, struct file *file) list_add_tail(&epc_page->list, &secs_pages); xa_erase(&vepc->page_array, index); + cond_resched(); } /* @@ -243,6 +245,7 @@ static int sgx_vepc_release(struct inode *inode, struct file *file) if (sgx_vepc_free_page(epc_page)) list_add_tail(&epc_page->list, &secs_pages); + cond_resched(); } if (!list_empty(&secs_pages)) -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] comedi: ni_usb6501: fix NULL-deref in command paths
by Cui GaoSheng 31 May '24

31 May '24

From: Johan Hovold <johan(a)kernel.org> stable inclusion from stable-v5.10.79 commit ef143dc0c3defe56730ecd3a9de7b3e1d7e557c1 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9RD2V CVE: CVE-2021-47476 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 907767da8f3a925b060c740e0b5c92ea7dbec440 upstream. The driver uses endpoint-sized USB transfer buffers but had no sanity checks on the sizes. This can lead to zero-size-pointer dereferences or overflowed transfer buffers in ni6501_port_command() and ni6501_counter_command() if a (malicious) device has smaller max-packet sizes than expected (or when doing descriptor fuzz testing). Add the missing sanity checks to probe(). Fixes: a03bb00e50ab ("staging: comedi: add NI USB-6501 support") Cc: stable(a)vger.kernel.org # 3.18 Cc: Luca Ellero <luca.ellero(a)brickedbrain.com> Reviewed-by: Ian Abbott <abbotti(a)mev.co.uk> Signed-off-by: Johan Hovold <johan(a)kernel.org> Link: https://lore.kernel.org/r/20211027093529.30896-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Cui GaoSheng <cuigaosheng1(a)huawei.com> --- drivers/staging/comedi/drivers/ni_usb6501.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/staging/comedi/drivers/ni_usb6501.c b/drivers/staging/comedi/drivers/ni_usb6501.c index 1bb1cb651349..75e5b57ae0d7 100644 --- a/drivers/staging/comedi/drivers/ni_usb6501.c +++ b/drivers/staging/comedi/drivers/ni_usb6501.c @@ -144,6 +144,10 @@ static const u8 READ_COUNTER_RESPONSE[] = {0x00, 0x01, 0x00, 0x10, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00}; +/* Largest supported packets */ +static const size_t TX_MAX_SIZE = sizeof(SET_PORT_DIR_REQUEST); +static const size_t RX_MAX_SIZE = sizeof(READ_PORT_RESPONSE); + enum commands { READ_PORT, WRITE_PORT, @@ -501,6 +505,12 @@ static int ni6501_find_endpoints(struct comedi_device *dev) if (!devpriv->ep_rx || !devpriv->ep_tx) return -ENODEV; + if (usb_endpoint_maxp(devpriv->ep_rx) < RX_MAX_SIZE) + return -ENODEV; + + if (usb_endpoint_maxp(devpriv->ep_tx) < TX_MAX_SIZE) + return -ENODEV; + return 0; } -- 2.34.1

2 2

[PATCH OLK-5.10] mm/hugetlb: fix missing hugetlb_lock for resv uncharge
by Jinjiang Tu 31 May '24

31 May '24

From: Peter Xu <peterx(a)redhat.com> mainline inclusion from mainline-v6.9-rc6 commit b76b46902c2d0395488c8412e1116c2486cdfcb2 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9QR5M CVE: CVE-2024-36000 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- There is a recent report on UFFDIO_COPY over hugetlb: https://lore.kernel.org/all/000000000000ee06de0616177560@google.com/ 350: lockdep_assert_held(&hugetlb_lock); Should be an issue in hugetlb but triggered in an userfault context, where it goes into the unlikely path where two threads modifying the resv map together. Mike has a fix in that path for resv uncharge but it looks like the locking criteria was overlooked: hugetlb_cgroup_uncharge_folio_rsvd() will update the cgroup pointer, so it requires to be called with the lock held. Link: https://lkml.kernel.org/r/20240417211836.2742593-3-peterx@redhat.com Fixes: 79aa925bf239 ("hugetlb_cgroup: fix reservation accounting") Signed-off-by: Peter Xu <peterx(a)redhat.com> Reported-by: syzbot+4b8077a5fccc61c385a1(a)syzkaller.appspotmail.com Reviewed-by: Mina Almasry <almasrymina(a)google.com> Cc: David Hildenbrand <david(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Conflicts: mm/hugetlb.c [Conflicts due to page converts to folio.] Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- mm/hugetlb.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index e04c21f735ad..e3746bcfc827 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -2709,9 +2709,12 @@ struct page *alloc_huge_page(struct vm_area_struct *vma, rsv_adjust = hugepage_subpool_put_pages(spool, 1, info); hugetlb_acct_memory(h, -rsv_adjust, info); - if (deferred_reserve) + if (deferred_reserve) { + spin_lock_irq(&hugetlb_lock); hugetlb_cgroup_uncharge_page_rsvd(hstate_index(h), pages_per_huge_page(h), page); + spin_unlock_irq(&hugetlb_lock); + } } return page; -- 2.25.1

2 1

[openeuler:OLK-6.6 9623/9796] arch/x86/kernel/zhaoxin_kh40000.c:322:26: sparse: sparse: symbol 'kh40000_dma_iommu_ops' was not declared. Should it be static?
by kernel test robot 31 May '24

31 May '24

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: a4c1bb6d259c5f07d1cf526fcb8c10d67c43a825 commit: ef20808db09987137fba30519fb94a6b12b63ee7 [9623/9796] Add kh40000_iommu_dma_ops for KH-40000 platform config: x86_64-randconfig-123-20240531 (https://download.01.org/0day-ci/archive/20240531/202405311417.Uc6n3wMh-lkp@…) compiler: gcc-12 (Ubuntu 12.3.0-9ubuntu2) 12.3.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240531/202405311417.Uc6n3wMh-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202405311417.Uc6n3wMh-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) arch/x86/kernel/zhaoxin_kh40000.c:35:15: sparse: sparse: symbol 'zhaoxin_patch_code' was not declared. Should it be static? >> arch/x86/kernel/zhaoxin_kh40000.c:322:26: sparse: sparse: symbol 'kh40000_dma_iommu_ops' was not declared. Should it be static? vim +/kh40000_dma_iommu_ops +322 arch/x86/kernel/zhaoxin_kh40000.c 321 > 322 const struct dma_map_ops kh40000_dma_iommu_ops = { 323 .flags = DMA_F_PCI_P2PDMA_SUPPORTED, 324 .alloc = kh40000_iommu_dma_alloc, 325 .free = kh40000_iommu_dma_free, 326 .unmap_page = kh40000_iommu_dma_unmap_page, 327 .alloc_pages = kh40000_dma_common_alloc_pages, 328 .free_pages = kh40000_dma_common_free_pages, 329 .alloc_noncontiguous = kh40000_iommu_dma_alloc_noncontiguous, 330 .free_noncontiguous = kh40000_iommu_dma_free_noncontiguous, 331 .mmap = kh40000_iommu_dma_mmap, 332 .get_sgtable = kh40000_iommu_dma_get_sgtable, 333 .map_page = kh40000_iommu_dma_map_page, 334 .map_sg = kh40000_iommu_dma_map_sg, 335 .unmap_sg = kh40000_iommu_dma_unmap_sg, 336 .sync_single_for_cpu = kh40000_iommu_dma_sync_single_for_cpu, 337 .sync_single_for_device = kh40000_iommu_dma_sync_single_for_device, 338 .sync_sg_for_cpu = kh40000_iommu_dma_sync_sg_for_cpu, 339 .sync_sg_for_device = kh40000_iommu_dma_sync_sg_for_device, 340 .map_resource = kh40000_iommu_dma_map_resource, 341 .unmap_resource = kh40000_iommu_dma_unmap_resource, 342 .get_merge_boundary = kh40000_iommu_dma_get_merge_boundary, 343 .opt_mapping_size = kh40000_iommu_dma_opt_mapping_size, 344 }; 345 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-5.10 0/1] 5.10: fix CVE-2024-35978
by Wupeng Ma 31 May '24

31 May '24

From: Ma Wupeng <mawupeng1(a)huawei.com> fix CVE-2024-35978. Dmitry Antipov (1): Bluetooth: Fix memory leak in hci_req_sync_complete() net/bluetooth/hci_request.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- 2.25.1

2 2

[PATCH openEuler-1.0-LTS] hugetlbfs: fix hugetlbfs_statfs() locking
by Jinjiang Tu 31 May '24

31 May '24

From: Mina Almasry <almasrymina(a)google.com> mainline inclusion from mainline-v5.19-rc1 commit 4b25f030ae69ba710eff587cabb4c57cb7e7a8a1 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9SZXR CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ------------------------------------------- After commit db71ef79b59b ("hugetlb: make free_huge_page irq safe"), the subpool lock should be locked with spin_lock_irq() and all call sites was modified as such, except for the ones in hugetlbfs_statfs(). Link: https://lkml.kernel.org/r/20220429202207.3045-1-almasrymina@google.com Fixes: db71ef79b59b ("hugetlb: make free_huge_page irq safe") Signed-off-by: Mina Almasry <almasrymina(a)google.com> Reviewed-by: Mike Kravetz <mike.kravetz(a)oracle.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- fs/hugetlbfs/inode.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c index 92077383f320..58e879f089c4 100644 --- a/fs/hugetlbfs/inode.c +++ b/fs/hugetlbfs/inode.c @@ -1099,12 +1099,12 @@ static int hugetlbfs_statfs(struct dentry *dentry, struct kstatfs *buf) if (sbinfo->spool) { long free_pages; - spin_lock(&sbinfo->spool->lock); + spin_lock_irq(&sbinfo->spool->lock); buf->f_blocks = sbinfo->spool->max_hpages; free_pages = sbinfo->spool->max_hpages - sbinfo->spool->used_hpages; buf->f_bavail = buf->f_bfree = free_pages; - spin_unlock(&sbinfo->spool->lock); + spin_unlock_irq(&sbinfo->spool->lock); buf->f_files = sbinfo->max_inodes; buf->f_ffree = sbinfo->free_inodes; } -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS 0/1] 4.19: fix CVE-2024-35978
by Wupeng Ma 31 May '24

31 May '24

From: Ma Wupeng <mawupeng1(a)huawei.com> fix CVE-2024-35978. Dmitry Antipov (1): Bluetooth: Fix memory leak in hci_req_sync_complete() net/bluetooth/hci_request.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- 2.25.1

2 2

2024

2023

2022

2021

2020

2019

Kernel May 2024