In the Linux kernel, the following vulnerability has been resolved:\n\ntpm: tpm_crb: Add the missed acpi_put_table() to fix memory leak\n\nIn crb_acpi_add(), we get the TPM2 table to retrieve information\nlike start method, and then assign them to the priv data, so the\nTPM2 table is not used after the init, should be freed, call\nacpi_put_table() to fix the memory leak.

In the Linux kernel, the following vulnerability has been resolved:\n\nnvme: fix multipath crash caused by flush request when blktrace is enabled\n\nThe flush request initialized by blk_kick_flush has NULL bio,\nand it may be dealt with nvme_end_req during io completion.\nWhen blktrace is enabled, nvme_trace_bio_complete with multipath\nactivated trying to access NULL pointer bio from flush request\nresults in the following crash:\n\n[ 2517.831677] BUG: kernel NULL pointer dereference, address: 000000000000001a\n[ 2517.835213] #PF: supervisor read access in kernel mode\n[ 2517.838724] #PF: error_code(0x0000) - not-present page\n[ 2517.842222] PGD 7b2d51067 P4D 0\n[ 2517.845684] Oops: 0000 [#1] SMP NOPTI\n[ 2517.849125] CPU: 2 PID: 732 Comm: kworker/2:1H Kdump: loaded Tainted: G S 5.15.67-0.cl9.x86_64 #1\n[ 2517.852723] Hardware name: XFUSION 2288H V6/BC13MBSBC, BIOS 1.13 07/27/2022\n[ 2517.856358] Workqueue: nvme_tcp_wq nvme_tcp_io_work [nvme_tcp]\n[ 2517.859993] RIP: 0010:blk_add_trace_bio_complete+0x6/0x30\n[ 2517.863628] Code: 1f 44 00 00 48 8b 46 08 31 c9 ba 04 00 10 00 48 8b 80 50 03 00 00 48 8b 78 50 e9 e5 fe ff ff 0f 1f 44 00 00 41 54 49 89 f4 55 <0f> b6 7a 1a 48 89 d5 e8 3e 1c 2b 00 48 89 ee 4c 89 e7 5d 89 c1 ba\n[ 2517.871269] RSP: 0018:ff7f6a008d9dbcd0 EFLAGS: 00010286\n[ 2517.875081] RAX: ff3d5b4be00b1d50 RBX: 0000000002040002 RCX: ff3d5b0a270f2000\n[ 2517.878966] RDX: 0000000000000000 RSI: ff3d5b0b021fb9f8 RDI: 0000000000000000\n[ 2517.882849] RBP: ff3d5b0b96a6fa00 R08: 0000000000000001 R09: 0000000000000000\n[ 2517.886718] R10: 000000000000000c R11: 000000000000000c R12: ff3d5b0b021fb9f8\n[ 2517.890575] R13: 0000000002000000 R14: ff3d5b0b021fb1b0 R15: 0000000000000018\n[ 2517.894434] FS: 0000000000000000(0000) GS:ff3d5b42bfc80000(0000) knlGS:0000000000000000\n[ 2517.898299] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 2517.902157] CR2: 000000000000001a CR3: 00000004f023e005 CR4: 0000000000771ee0\n[ 2517.906053] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 2517.909930] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 2517.913761] PKRU: 55555554\n[ 2517.917558] Call Trace:\n[ 2517.921294] \n[ 2517.924982] nvme_complete_rq+0x1c3/0x1e0 [nvme_core]\n[ 2517.928715] nvme_tcp_recv_pdu+0x4d7/0x540 [nvme_tcp]\n[ 2517.932442] nvme_tcp_recv_skb+0x4f/0x240 [nvme_tcp]\n[ 2517.936137] ? nvme_tcp_recv_pdu+0x540/0x540 [nvme_tcp]\n[ 2517.939830] tcp_read_sock+0x9c/0x260\n[ 2517.943486] nvme_tcp_try_recv+0x65/0xa0 [nvme_tcp]\n[ 2517.947173] nvme_tcp_io_work+0x64/0x90 [nvme_tcp]\n[ 2517.950834] process_one_work+0x1e8/0x390\n[ 2517.954473] worker_thread+0x53/0x3c0\n[ 2517.958069] ? process_one_work+0x390/0x390\n[ 2517.961655] kthread+0x10c/0x130\n[ 2517.965211] ? set_kthread_struct+0x40/0x40\n[ 2517.968760] ret_from_fork+0x1f/0x30\n[ 2517.972285] \n\nTo avoid this situation, add a NULL check for req->bio before\ncalling trace_block_bio_complete.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: hinic: fix the issue of CMDQ memory leaks\n\nWhen hinic_set_cmdq_depth() fails in hinic_init_cmdqs(), the cmdq memory is\nnot released correctly. Fix it.

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix user-after-free\n\nThis uses l2cap_chan_hold_unless_zero() after calling\n__l2cap_get_chan_blah() to prevent the following trace:\n\nBluetooth: l2cap_core.c:static void l2cap_chan_destroy(struct kref\n*kref)\nBluetooth: chan 0000000023c4974d\nBluetooth: parent 00000000ae861c08\n==================================================================\nBUG: KASAN: use-after-free in __mutex_waiter_is_first\nkernel/locking/mutex.c:191 [inline]\nBUG: KASAN: use-after-free in __mutex_lock_common\nkernel/locking/mutex.c:671 [inline]\nBUG: KASAN: use-after-free in __mutex_lock+0x278/0x400\nkernel/locking/mutex.c:729\nRead of size 8 at addr ffff888006a49b08 by task kworker/u3:2/389

In the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Fix an Oops in nfs_d_automount()\n\nWhen mounting from a NFSv4 referral, path->dentry can end up being a\nnegative dentry, so derive the struct nfs_server from the dentry\nitself instead.

In the Linux kernel, the following vulnerability has been resolved:\n\nstaging: vme_user: Fix possible UAF in tsi148_dma_list_add\n\nSmatch report warning as follows:\n\ndrivers/staging/vme_user/vme_tsi148.c:1757 tsi148_dma_list_add() warn:\n '&entry->list' not removed from list\n\nIn tsi148_dma_list_add(), the error path "goto err_dma" will not\nremove entry->list from list->entries, but entry will be freed,\nthen list traversal may cause UAF.\n\nFix by removeing it from list->entries before free().

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: mediatek: vcodec: Can't set dst buffer to done when lat decode error\n\nCore thread will call v4l2_m2m_buf_done to set dst buffer done for\nlat architecture. If lat call v4l2_m2m_buf_done_and_job_finish to\nfree dst buffer when lat decode error, core thread will access kernel\nNULL pointer dereference, then crash.

In the Linux kernel, the following vulnerability has been resolved:\n\npadata: Always leave BHs disabled when running ->parallel()\n\nA deadlock can happen when an overloaded system runs ->parallel() in the\ncontext of the current task:\n\n padata_do_parallel\n ->parallel()\n pcrypt_aead_enc/dec\n padata_do_serial\n spin_lock(&reorder->lock) // BHs still enabled\n \n ...\n __do_softirq\n ...\n padata_do_serial\n spin_lock(&reorder->lock)\n\nIt's a bug for BHs to be on in _do_serial as Steffen points out, so\nensure they're off in the "current task" case like they are in\npadata_parallel_worker to avoid this situation.

In the Linux kernel, the following vulnerability has been resolved:\n\nmd: fix a crash in mempool_free\n\nThere's a crash in mempool_free when running the lvm test\nshell/lvchange-rebuild-raid.sh.\n\nThe reason for the crash is this:\n* super_written calls atomic_dec_and_test(&mddev->pending_writes) and\n wake_up(&mddev->sb_wait). Then it calls rdev_dec_pending(rdev, mddev)\n and bio_put(bio).\n* so, the process that waited on sb_wait and that is woken up is racing\n with bio_put(bio).\n* if the process wins the race, it calls bioset_exit before bio_put(bio)\n is executed.\n* bio_put(bio) attempts to free a bio into a destroyed bio set - causing\n a crash in mempool_free.\n\nWe fix this bug by moving bio_put before atomic_dec_and_test.\n\nWe also move rdev_dec_pending before atomic_dec_and_test as suggested by\nNeil Brown.\n\nThe function md_end_flush has a similar bug - we must call bio_put before\nwe decrement the number of in-progress bios.\n\n BUG: kernel NULL pointer dereference, address: 0000000000000000\n #PF: supervisor write access in kernel mode\n #PF: error_code(0x0002) - not-present page\n PGD 11557f0067 P4D 11557f0067 PUD 0\n Oops: 0002 [#1] PREEMPT SMP\n CPU: 0 PID: 73 Comm: kworker/0:1 Not tainted 6.1.0-rc3 #5\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014\n Workqueue: kdelayd flush_expired_bios [dm_delay]\n RIP: 0010:mempool_free+0x47/0x80\n Code: 48 89 ef 5b 5d ff e0 f3 c3 48 89 f7 e8 32 45 3f 00 48 63 53 08 48 89 c6 3b 53 04 7d 2d 48 8b 43 10 8d 4a 01 48 89 df 89 4b 08 <48> 89 2c d0 e8 b0 45 3f 00 48 8d 7b 30 5b 5d 31 c9 ba 01 00 00 00\n RSP: 0018:ffff88910036bda8 EFLAGS: 00010093\n RAX: 0000000000000000 RBX: ffff8891037b65d8 RCX: 0000000000000001\n RDX: 0000000000000000 RSI: 0000000000000202 RDI: ffff8891037b65d8\n RBP: ffff8891447ba240 R08: 0000000000012908 R09: 00000000003d0900\n R10: 0000000000000000 R11: 0000000000173544 R12: ffff889101a14000\n R13: ffff8891562ac300 R14: ffff889102b41440 R15: ffffe8ffffa00d05\n FS: 0000000000000000(0000) GS:ffff88942fa00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000000 CR3: 0000001102e99000 CR4: 00000000000006b0\n Call Trace:\n \n clone_endio+0xf4/0x1c0 [dm_mod]\n clone_endio+0xf4/0x1c0 [dm_mod]\n __submit_bio+0x76/0x120\n submit_bio_noacct_nocheck+0xb6/0x2a0\n flush_expired_bios+0x28/0x2f [dm_delay]\n process_one_work+0x1b4/0x300\n worker_thread+0x45/0x3e0\n ? rescuer_thread+0x380/0x380\n kthread+0xc2/0x100\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork+0x1f/0x30\n \n Modules linked in: brd dm_delay dm_raid dm_mod af_packet uvesafb cfbfillrect cfbimgblt cn cfbcopyarea fb font fbdev tun autofs4 binfmt_misc configfs ipv6 virtio_rng virtio_balloon rng_core virtio_net pcspkr net_failover failover qemu_fw_cfg button mousedev raid10 raid456 libcrc32c async_raid6_recov async_memcpy async_pq raid6_pq async_xor xor async_tx raid1 raid0 md_mod sd_mod t10_pi crc64_rocksoft crc64 virtio_scsi scsi_mod evdev psmouse bsg scsi_common [last unloaded: brd]\n CR2: 0000000000000000\n ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:\n\nmm: /proc/pid/smaps_rollup: fix no vma's null-deref\n\nCommit 258f669e7e88 ("mm: /proc/pid/smaps_rollup: convert to single value\nseq_file") introduced a null-deref if there are no vma's in the task in\nshow_smaps_rollup.

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix race between quota enable and quota rescan ioctl\n\nWhen enabling quotas, at btrfs_quota_enable(), after committing the\ntransaction, we change fs_info->quota_root to point to the quota root we\ncreated and set BTRFS_FS_QUOTA_ENABLED at fs_info->flags. Then we try\nto start the qgroup rescan worker, first by initializing it with a call\nto qgroup_rescan_init() - however if that fails we end up freeing the\nquota root but we leave fs_info->quota_root still pointing to it, this\ncan later result in a use-after-free somewhere else.\n\nWe have previously set the flags BTRFS_FS_QUOTA_ENABLED and\nBTRFS_QGROUP_STATUS_FLAG_ON, so we can only fail with -EINPROGRESS at\nbtrfs_quota_enable(), which is possible if someone already called the\nquota rescan ioctl, and therefore started the rescan worker.\n\nSo fix this by ignoring an -EINPROGRESS and asserting we can't get any\nother error.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/meson: reorder driver deinit sequence to fix use-after-free bug\n\nUnloading the driver triggers the following KASAN warning:\n\n[ +0.006275] =============================================================\n[ +0.000029] BUG: KASAN: use-after-free in __list_del_entry_valid+0xe0/0x1a0\n[ +0.000026] Read of size 8 at addr ffff000020c395e0 by task rmmod/2695\n\n[ +0.000019] CPU: 5 PID: 2695 Comm: rmmod Tainted: G C O 5.19.0-rc6-lrmbkasan+ #1\n[ +0.000013] Hardware name: Hardkernel ODROID-N2Plus (DT)\n[ +0.000008] Call trace:\n[ +0.000007] dump_backtrace+0x1ec/0x280\n[ +0.000013] show_stack+0x24/0x80\n[ +0.000008] dump_stack_lvl+0x98/0xd4\n[ +0.000011] print_address_description.constprop.0+0x80/0x520\n[ +0.000011] print_report+0x128/0x260\n[ +0.000007] kasan_report+0xb8/0xfc\n[ +0.000008] __asan_report_load8_noabort+0x3c/0x50\n[ +0.000010] __list_del_entry_valid+0xe0/0x1a0\n[ +0.000009] drm_atomic_private_obj_fini+0x30/0x200 [drm]\n[ +0.000172] drm_bridge_detach+0x94/0x260 [drm]\n[ +0.000145] drm_encoder_cleanup+0xa4/0x290 [drm]\n[ +0.000144] drm_mode_config_cleanup+0x118/0x740 [drm]\n[ +0.000143] drm_mode_config_init_release+0x1c/0x2c [drm]\n[ +0.000144] drm_managed_release+0x170/0x414 [drm]\n[ +0.000142] drm_dev_put.part.0+0xc0/0x124 [drm]\n[ +0.000143] drm_dev_put+0x20/0x30 [drm]\n[ +0.000142] meson_drv_unbind+0x1d8/0x2ac [meson_drm]\n[ +0.000028] take_down_aggregate_device+0xb0/0x160\n[ +0.000016] component_del+0x18c/0x360\n[ +0.000009] meson_dw_hdmi_remove+0x28/0x40 [meson_dw_hdmi]\n[ +0.000015] platform_remove+0x64/0xb0\n[ +0.000009] device_remove+0xb8/0x154\n[ +0.000009] device_release_driver_internal+0x398/0x5b0\n[ +0.000009] driver_detach+0xac/0x1b0\n[ +0.000009] bus_remove_driver+0x158/0x29c\n[ +0.000009] driver_unregister+0x70/0xb0\n[ +0.000008] platform_driver_unregister+0x20/0x2c\n[ +0.000008] meson_dw_hdmi_platform_driver_exit+0x1c/0x30 [meson_dw_hdmi]\n[ +0.000012] __do_sys_delete_module+0x288/0x400\n[ +0.000011] __arm64_sys_delete_module+0x5c/0x80\n[ +0.000009] invoke_syscall+0x74/0x260\n[ +0.000009] el0_svc_common.constprop.0+0xcc/0x260\n[ +0.000009] do_el0_svc+0x50/0x70\n[ +0.000007] el0_svc+0x68/0x1a0\n[ +0.000012] el0t_64_sync_handler+0x11c/0x150\n[ +0.000008] el0t_64_sync+0x18c/0x190\n\n[ +0.000018] Allocated by task 0:\n[ +0.000007] (stack is not available)\n\n[ +0.000011] Freed by task 2695:\n[ +0.000008] kasan_save_stack+0x2c/0x5c\n[ +0.000011] kasan_set_track+0x2c/0x40\n[ +0.000008] kasan_set_free_info+0x28/0x50\n[ +0.000009] ____kasan_slab_free+0x128/0x1d4\n[ +0.000008] __kasan_slab_free+0x18/0x24\n[ +0.000007] slab_free_freelist_hook+0x108/0x230\n[ +0.000011] kfree+0x110/0x35c\n[ +0.000008] release_nodes+0xf0/0x16c\n[ +0.000009] devres_release_group+0x180/0x270\n[ +0.000008] component_unbind+0x128/0x1e0\n[ +0.000010] component_unbind_all+0x1b8/0x264\n[ +0.000009] meson_drv_unbind+0x1a0/0x2ac [meson_drm]\n[ +0.000025] take_down_aggregate_device+0xb0/0x160\n[ +0.000009] component_del+0x18c/0x360\n[ +0.000009] meson_dw_hdmi_remove+0x28/0x40 [meson_dw_hdmi]\n[ +0.000012] platform_remove+0x64/0xb0\n[ +0.000008] device_remove+0xb8/0x154\n[ +0.000009] device_release_driver_internal+0x398/0x5b0\n[ +0.000009] driver_detach+0xac/0x1b0\n[ +0.000009] bus_remove_driver+0x158/0x29c\n[ +0.000008] driver_unregister+0x70/0xb0\n[ +0.000008] platform_driver_unregister+0x20/0x2c\n[ +0.000008] meson_dw_hdmi_platform_driver_exit+0x1c/0x30 [meson_dw_hdmi]\n[ +0.000011] __do_sys_delete_module+0x288/0x400\n[ +0.000010] __arm64_sys_delete_module+0x5c/0x80\n[ +0.000008] invoke_syscall+0x74/0x260\n[ +0.000008] el0_svc_common.constprop.0+0xcc/0x260\n[ +0.000008] do_el0_svc+0x50/0x70\n[ +0.000007] el0_svc+0x68/0x1a0\n[ +0.000009] el0t_64_sync_handler+0x11c/0x150\n[ +0.000009] el0t_64_sync+0x18c/0x190\n\n[ +0.000014] The buggy address belongs to the object at ffff000020c39000\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\norangefs: Fix kmemleak in orangefs_{kernel,client}_debug_init()\n\nWhen insert and remove the orangefs module, there are memory leaked\nas below:\n\nunreferenced object 0xffff88816b0cc000 (size 2048):\n comm "insmod", pid 783, jiffies 4294813439 (age 65.512s)\n hex dump (first 32 bytes):\n 6e 6f 6e 65 0a 00 00 00 00 00 00 00 00 00 00 00 none............\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace:\n [<0000000031ab7788>] kmalloc_trace+0x27/0xa0\n [<000000005b405fee>] orangefs_debugfs_init.cold+0xaf/0x17f\n [<00000000e5a0085b>] 0xffffffffa02780f9\n [<000000004232d9f7>] do_one_initcall+0x87/0x2a0\n [<0000000054f22384>] do_init_module+0xdf/0x320\n [<000000003263bdea>] load_module+0x2f98/0x3330\n [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0\n [<00000000250ae02b>] do_syscall_64+0x35/0x80\n [<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nUse the golbal variable as the buffer rather than dynamic allocate to\nslove the problem.

In the Linux kernel, the following vulnerability has been resolved:\n\ntty: serial: fsl_lpuart: disable dma rx/tx use flags in lpuart_dma_shutdown\n\nlpuart_dma_shutdown tears down lpuart dma, but lpuart_flush_buffer can\nstill occur which in turn tries to access dma apis if lpuart_dma_tx_use\nflag is true. At this point since dma is torn down, these dma apis can\nabort. Set lpuart_dma_tx_use and the corresponding rx flag\nlpuart_dma_rx_use to false in lpuart_dma_shutdown so that dmas are not\naccessed after they are relinquished.\n\nOtherwise, when try to kill btattach, kernel may panic. This patch may\nfix this issue.\nroot@imx8ulpevk:~# btattach -B /dev/ttyLP2 -S 115200\n^C[ 90.182296] Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP\n[ 90.189806] Modules linked in: moal(O) mlan(O)\n[ 90.194258] CPU: 0 PID: 503 Comm: btattach Tainted: G O 5.15.32-06136-g34eecdf2f9e4 #37\n[ 90.203554] Hardware name: NXP i.MX8ULP 9X9 EVK (DT)\n[ 90.208513] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 90.215470] pc : fsl_edma3_disable_request+0x8/0x60\n[ 90.220358] lr : fsl_edma3_terminate_all+0x34/0x20c\n[ 90.225237] sp : ffff800013f0bac0\n[ 90.228548] x29: ffff800013f0bac0 x28: 0000000000000001 x27: ffff000008404800\n[ 90.235681] x26: ffff000008404960 x25: ffff000008404a08 x24: ffff000008404a00\n[ 90.242813] x23: ffff000008404a60 x22: 0000000000000002 x21: 0000000000000000\n[ 90.249946] x20: ffff800013f0baf8 x19: ffff00000559c800 x18: 0000000000000000\n[ 90.257078] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\n[ 90.264211] x14: 0000000000000003 x13: 0000000000000000 x12: 0000000000000040\n[ 90.271344] x11: ffff00000600c248 x10: ffff800013f0bb10 x9 : ffff000057bcb090\n[ 90.278477] x8 : fffffc0000241a08 x7 : ffff00000534ee00 x6 : ffff000008404804\n[ 90.285609] x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff0000055b3480\n[ 90.292742] x2 : ffff8000135c0000 x1 : ffff00000534ee00 x0 : ffff00000559c800\n[ 90.299876] Call trace:\n[ 90.302321] fsl_edma3_disable_request+0x8/0x60\n[ 90.306851] lpuart_flush_buffer+0x40/0x160\n[ 90.311037] uart_flush_buffer+0x88/0x120\n[ 90.315050] tty_driver_flush_buffer+0x20/0x30\n[ 90.319496] hci_uart_flush+0x44/0x90\n[ 90.323162] +0x34/0x12c\n[ 90.327253] tty_ldisc_close+0x38/0x70\n[ 90.331005] tty_ldisc_release+0xa8/0x190\n[ 90.335018] tty_release_struct+0x24/0x8c\n[ 90.339022] tty_release+0x3ec/0x4c0\n[ 90.342593] __fput+0x70/0x234\n[ 90.345652] ____fput+0x14/0x20\n[ 90.348790] task_work_run+0x84/0x17c\n[ 90.352455] do_exit+0x310/0x96c\n[ 90.355688] do_group_exit+0x3c/0xa0\n[ 90.359259] __arm64_sys_exit_group+0x1c/0x20\n[ 90.363609] invoke_syscall+0x48/0x114\n[ 90.367362] el0_svc_common.constprop.0+0xd4/0xfc\n[ 90.372068] do_el0_svc+0x2c/0x94\n[ 90.375379] el0_svc+0x28/0x80\n[ 90.378438] el0t_64_sync_handler+0xa8/0x130\n[ 90.382711] el0t_64_sync+0x1a0/0x1a4\n[ 90.386376] Code: 17ffffda d503201f d503233f f9409802 (b9400041)\n[ 90.392467] ---[ end trace 2f60524b4a43f1f6 ]---\n[ 90.397073] note: btattach[503] exited with preempt_count 1\n[ 90.402636] Fixing recursive fault but reboot is needed!

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix race issue between cpu buffer write and swap\n\nWarning happened in rb_end_commit() at code:\n\tif (RB_WARN_ON(cpu_buffer, !local_read(&cpu_buffer->committing)))\n\n WARNING: CPU: 0 PID: 139 at kernel/trace/ring_buffer.c:3142\n\trb_commit+0x402/0x4a0\n Call Trace:\n ring_buffer_unlock_commit+0x42/0x250\n trace_buffer_unlock_commit_regs+0x3b/0x250\n trace_event_buffer_commit+0xe5/0x440\n trace_event_buffer_reserve+0x11c/0x150\n trace_event_raw_event_sched_switch+0x23c/0x2c0\n __traceiter_sched_switch+0x59/0x80\n __schedule+0x72b/0x1580\n schedule+0x92/0x120\n worker_thread+0xa0/0x6f0\n\nIt is because the race between writing event into cpu buffer and swapping\ncpu buffer through file per_cpu/cpu0/snapshot:\n\n Write on CPU 0 Swap buffer by per_cpu/cpu0/snapshot on CPU 1\n -------- --------\n tracing_snapshot_write()\n [...]\n\n ring_buffer_lock_reserve()\n cpu_buffer = buffer->buffers[cpu]; // 1. Suppose find 'cpu_buffer_a';\n [...]\n rb_reserve_next_event()\n [...]\n\n ring_buffer_swap_cpu()\n if (local_read(&cpu_buffer_a->committing))\n goto out_dec;\n if (local_read(&cpu_buffer_b->committing))\n goto out_dec;\n buffer_a->buffers[cpu] = cpu_buffer_b;\n buffer_b->buffers[cpu] = cpu_buffer_a;\n // 2. cpu_buffer has swapped here.\n\n rb_start_commit(cpu_buffer);\n if (unlikely(READ_ONCE(cpu_buffer->buffer)\n != buffer)) { // 3. This check passed due to 'cpu_buffer->buffer'\n [...] // has not changed here.\n return NULL;\n }\n cpu_buffer_b->buffer = buffer_a;\n cpu_buffer_a->buffer = buffer_b;\n [...]\n\n // 4. Reserve event from 'cpu_buffer_a'.\n\n ring_buffer_unlock_commit()\n [...]\n cpu_buffer = buffer->buffers[cpu]; // 5. Now find 'cpu_buffer_b' !!!\n rb_commit(cpu_buffer)\n rb_end_commit() // 6. WARN for the wrong 'committing' state !!!\n\nBased on above analysis, we can easily reproduce by following testcase:\n ``` bash\n #!/bin/bash\n\n dmesg -n 7\n sysctl -w kernel.panic_on_warn=1\n TR=/sys/kernel/tracing\n echo 7 > ${TR}/buffer_size_kb\n echo "sched:sched_switch" > ${TR}/set_event\n while [ true ]; do\n echo 1 > ${TR}/per_cpu/cpu0/snapshot\n done &\n while [ true ]; do\n echo 1 > ${TR}/per_cpu/cpu0/snapshot\n done &\n while [ true ]; do\n echo 1 > ${TR}/per_cpu/cpu0/snapshot\n done &\n ```\n\nTo fix it, IIUC, we can use smp_call_function_single() to do the swap on\nthe target cpu where the buffer is located, so that above race would be\navoided.

In the Linux kernel, the following vulnerability has been resolved:\n\naccel/habanalabs: fix mem leak in capture user mappings\n\nThis commit fixes a memory leak caused when clearing the user_mappings\ninfo when a new context is opened immediately after user_mapping is\ncaptured and a hard reset is performed.

In the Linux kernel, the following vulnerability has been resolved:\n\nblock: be a bit more careful in checking for NULL bdev while polling\n\nWei reports a crash with an application using polled IO:\n\nPGD 14265e067 P4D 14265e067 PUD 47ec50067 PMD 0\nOops: 0000 [#1] SMP\nCPU: 0 PID: 21915 Comm: iocore_0 Kdump: loaded Tainted: G S 5.12.0-0_fbk12_clang_7346_g1bb6f2e7058f #1\nHardware name: Wiwynn Delta Lake MP T8/Delta Lake-Class2, BIOS Y3DLM08 04/10/2022\nRIP: 0010:bio_poll+0x25/0x200\nCode: 0f 1f 44 00 00 0f 1f 44 00 00 55 41 57 41 56 41 55 41 54 53 48 83 ec 28 65 48 8b 04 25 28 00 00 00 48 89 44 24 20 48 8b 47 08 <48> 8b 80 70 02 00 00 4c 8b 70 50 8b 6f 34 31 db 83 fd ff 75 25 65\nRSP: 0018:ffffc90005fafdf8 EFLAGS: 00010292\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: 74b43cd65dd66600\nRDX: 0000000000000003 RSI: ffffc90005fafe78 RDI: ffff8884b614e140\nRBP: ffff88849964df78 R08: 0000000000000000 R09: 0000000000000008\nR10: 0000000000000000 R11: 0000000000000000 R12: ffff88849964df00\nR13: ffffc90005fafe78 R14: ffff888137d3c378 R15: 0000000000000001\nFS: 00007fd195000640(0000) GS:ffff88903f400000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000270 CR3: 0000000466121001 CR4: 00000000007706f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n iocb_bio_iopoll+0x1d/0x30\n io_do_iopoll+0xac/0x250\n __se_sys_io_uring_enter+0x3c5/0x5a0\n ? __x64_sys_write+0x89/0xd0\n do_syscall_64+0x2d/0x40\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x94f225d\nCode: 24 cc 00 00 00 41 8b 84 24 d0 00 00 00 c1 e0 04 83 e0 10 41 09 c2 8b 33 8b 53 04 4c 8b 43 18 4c 63 4b 0c b8 aa 01 00 00 0f 05 <85> c0 0f 88 85 00 00 00 29 03 45 84 f6 0f 84 88 00 00 00 41 f6 c7\nRSP: 002b:00007fd194ffcd88 EFLAGS: 00000202 ORIG_RAX: 00000000000001aa\nRAX: ffffffffffffffda RBX: 00007fd194ffcdc0 RCX: 00000000094f225d\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000007\nRBP: 00007fd194ffcdb0 R08: 0000000000000000 R09: 0000000000000008\nR10: 0000000000000001 R11: 0000000000000202 R12: 00007fd269d68030\nR13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000000\n\nwhich is due to bio->bi_bdev being NULL. This can happen if we have two\ntasks doing polled IO, and task B ends up completing IO from task A if\nthey are sharing a poll queue. If task B completes the IO and puts the\nbio into our cache, then it can allocate that bio again before task A\nis done polling for it. As that would necessitate a preempt between the\ntwo tasks, it's enough to just be a bit more careful in checking for\nwhether or not bio->bi_bdev is NULL.

In the Linux kernel, the following vulnerability has been resolved:\n\nip6mr: Fix skb_under_panic in ip6mr_cache_report()\n\nskbuff: skb_under_panic: text:ffffffff88771f69 len:56 put:-4\n head:ffff88805f86a800 data:ffff887f5f86a850 tail:0x88 end:0x2c0 dev:pim6reg\n ------------[ cut here ]------------\n kernel BUG at net/core/skbuff.c:192!\n invalid opcode: 0000 [#1] PREEMPT SMP KASAN\n CPU: 2 PID: 22968 Comm: kworker/2:11 Not tainted 6.5.0-rc3-00044-g0a8db05b571a #236\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n Workqueue: ipv6_addrconf addrconf_dad_work\n RIP: 0010:skb_panic+0x152/0x1d0\n Call Trace:\n \n skb_push+0xc4/0xe0\n ip6mr_cache_report+0xd69/0x19b0\n reg_vif_xmit+0x406/0x690\n dev_hard_start_xmit+0x17e/0x6e0\n __dev_queue_xmit+0x2d6a/0x3d20\n vlan_dev_hard_start_xmit+0x3ab/0x5c0\n dev_hard_start_xmit+0x17e/0x6e0\n __dev_queue_xmit+0x2d6a/0x3d20\n neigh_connected_output+0x3ed/0x570\n ip6_finish_output2+0x5b5/0x1950\n ip6_finish_output+0x693/0x11c0\n ip6_output+0x24b/0x880\n NF_HOOK.constprop.0+0xfd/0x530\n ndisc_send_skb+0x9db/0x1400\n ndisc_send_rs+0x12a/0x6c0\n addrconf_dad_completed+0x3c9/0xea0\n addrconf_dad_work+0x849/0x1420\n process_one_work+0xa22/0x16e0\n worker_thread+0x679/0x10c0\n ret_from_fork+0x28/0x60\n ret_from_fork_asm+0x11/0x20\n\nWhen setup a vlan device on dev pim6reg, DAD ns packet may sent on reg_vif_xmit().\nreg_vif_xmit()\n ip6mr_cache_report()\n skb_push(skb, -skb_network_offset(pkt));//skb_network_offset(pkt) is 4\nAnd skb_push declared as:\n void *skb_push(struct sk_buff *skb, unsigned int len);\n skb->data -= len;\n //0xffff88805f86a84c - 0xfffffffc = 0xffff887f5f86a850\nskb->data is set to 0xffff887f5f86a850, which is invalid mem addr, lead to skb_push() fails.

In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: Fix use-after-free in pci_bus_release_domain_nr()\n\nCommit c14f7ccc9f5d ("PCI: Assign PCI domain IDs by ida_alloc()")\nintroduced a use-after-free bug in the bus removal cleanup. The issue was\nfound with kfence:\n\n [ 19.293351] BUG: KFENCE: use-after-free read in pci_bus_release_domain_nr+0x10/0x70\n\n [ 19.302817] Use-after-free read at 0x000000007f3b80eb (in kfence-#115):\n [ 19.309677] pci_bus_release_domain_nr+0x10/0x70\n [ 19.309691] dw_pcie_host_deinit+0x28/0x78\n [ 19.309702] tegra_pcie_deinit_controller+0x1c/0x38 [pcie_tegra194]\n [ 19.309734] tegra_pcie_dw_probe+0x648/0xb28 [pcie_tegra194]\n [ 19.309752] platform_probe+0x90/0xd8\n ...\n\n [ 19.311457] kfence-#115: 0x00000000063a155a-0x00000000ba698da8, size=1072, cache=kmalloc-2k\n\n [ 19.311469] allocated by task 96 on cpu 10 at 19.279323s:\n [ 19.311562] __kmem_cache_alloc_node+0x260/0x278\n [ 19.311571] kmalloc_trace+0x24/0x30\n [ 19.311580] pci_alloc_bus+0x24/0xa0\n [ 19.311590] pci_register_host_bridge+0x48/0x4b8\n [ 19.311601] pci_scan_root_bus_bridge+0xc0/0xe8\n [ 19.311613] pci_host_probe+0x18/0xc0\n [ 19.311623] dw_pcie_host_init+0x2c0/0x568\n [ 19.311630] tegra_pcie_dw_probe+0x610/0xb28 [pcie_tegra194]\n [ 19.311647] platform_probe+0x90/0xd8\n ...\n\n [ 19.311782] freed by task 96 on cpu 10 at 19.285833s:\n [ 19.311799] release_pcibus_dev+0x30/0x40\n [ 19.311808] device_release+0x30/0x90\n [ 19.311814] kobject_put+0xa8/0x120\n [ 19.311832] device_unregister+0x20/0x30\n [ 19.311839] pci_remove_bus+0x78/0x88\n [ 19.311850] pci_remove_root_bus+0x5c/0x98\n [ 19.311860] dw_pcie_host_deinit+0x28/0x78\n [ 19.311866] tegra_pcie_deinit_controller+0x1c/0x38 [pcie_tegra194]\n [ 19.311883] tegra_pcie_dw_probe+0x648/0xb28 [pcie_tegra194]\n [ 19.311900] platform_probe+0x90/0xd8\n ...\n\n [ 19.313579] CPU: 10 PID: 96 Comm: kworker/u24:2 Not tainted 6.2.0 #4\n [ 19.320171] Hardware name: /, BIOS 1.0-d7fb19b 08/10/2022\n [ 19.325852] Workqueue: events_unbound deferred_probe_work_func\n\nThe stack trace is a bit misleading as dw_pcie_host_deinit() doesn't\ndirectly call pci_bus_release_domain_nr(). The issue turns out to be in\npci_remove_root_bus() which first calls pci_remove_bus() which frees the\nstruct pci_bus when its struct device is released. Then\npci_bus_release_domain_nr() is called and accesses the freed struct\npci_bus. Reordering these fixes the issue.

In the Linux kernel, the following vulnerability has been resolved:\n\nbus: fsl-mc: don't assume child devices are all fsl-mc devices\n\nChanges in VFIO caused a pseudo-device to be created as child of\nfsl-mc devices causing a crash [1] when trying to bind a fsl-mc\ndevice to VFIO. Fix this by checking the device type when enumerating\nfsl-mc child devices.\n\n[1]\nModules linked in:\nInternal error: Oops: 0000000096000004 [#1] PREEMPT SMP\nCPU: 6 PID: 1289 Comm: sh Not tainted 6.2.0-rc5-00047-g7c46948a6e9c #2\nHardware name: NXP Layerscape LX2160ARDB (DT)\npstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : mc_send_command+0x24/0x1f0\nlr : dprc_get_obj_region+0xfc/0x1c0\nsp : ffff80000a88b900\nx29: ffff80000a88b900 x28: ffff48a9429e1400 x27: 00000000000002b2\nx26: ffff48a9429e1718 x25: 0000000000000000 x24: 0000000000000000\nx23: ffffd59331ba3918 x22: ffffd59331ba3000 x21: 0000000000000000\nx20: ffff80000a88b9b8 x19: 0000000000000000 x18: 0000000000000001\nx17: 7270642f636d2d6c x16: 73662e3030303030 x15: ffffffffffffffff\nx14: ffffd59330f1d668 x13: ffff48a8727dc389 x12: ffff48a8727dc386\nx11: 0000000000000002 x10: 00008ceaf02f35d4 x9 : 0000000000000012\nx8 : 0000000000000000 x7 : 0000000000000006 x6 : ffff80000a88bab0\nx5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff80000a88b9e8\nx2 : ffff80000a88b9e8 x1 : 0000000000000000 x0 : ffff48a945142b80\nCall trace:\n mc_send_command+0x24/0x1f0\n dprc_get_obj_region+0xfc/0x1c0\n fsl_mc_device_add+0x340/0x590\n fsl_mc_obj_device_add+0xd0/0xf8\n dprc_scan_objects+0x1c4/0x340\n dprc_scan_container+0x38/0x60\n vfio_fsl_mc_probe+0x9c/0xf8\n fsl_mc_driver_probe+0x24/0x70\n really_probe+0xbc/0x2a8\n __driver_probe_device+0x78/0xe0\n device_driver_attach+0x30/0x68\n bind_store+0xa8/0x130\n drv_attr_store+0x24/0x38\n sysfs_kf_write+0x44/0x60\n kernfs_fop_write_iter+0x128/0x1b8\n vfs_write+0x334/0x448\n ksys_write+0x68/0xf0\n __arm64_sys_write+0x1c/0x28\n invoke_syscall+0x44/0x108\n el0_svc_common.constprop.1+0x94/0xf8\n do_el0_svc+0x38/0xb0\n el0_svc+0x20/0x50\n el0t_64_sync_handler+0x98/0xc0\n el0t_64_sync+0x174/0x178\nCode: aa0103f4 a9025bf5 d5384100 b9400801 (79401260)\n---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: mm: Add p?d_leaf() definitions\n\nWhen I do LTP test, LTP test case ksm06 caused panic at\n break_ksm_pmd_entry\n -> pmd_leaf (Huge page table but False)\n -> pte_present (panic)\n\nThe reason is pmd_leaf() is not defined, So like commit 501b81046701\n("mips: mm: add p?d_leaf() definitions") add p?d_leaf() definition for\nLoongArch.

In the Linux kernel, the following vulnerability has been resolved:\n\nNFSv4.2: Rework scratch handling for READ_PLUS (again)\n\nI found that the read code might send multiple requests using the same\nnfs_pgio_header, but nfs4_proc_read_setup() is only called once. This is\nhow we ended up occasionally double-freeing the scratch buffer, but also\nmeans we set a NULL pointer but non-zero length to the xdr scratch\nbuffer. This results in an oops the first time decoding needs to copy\nsomething to scratch, which frequently happens when decoding READ_PLUS\nhole segments.\n\nI fix this by moving scratch handling into the pageio read code. I\nprovide a function to allocate scratch space for decoding read replies,\nand free the scratch buffer when the nfs_pgio_header is freed.

In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: fix memory leak with using debugfs_lookup()\n\nWhen calling debugfs_lookup() the result must have dput() called on it,\notherwise the memory will leak over time. To make things simpler, just\ncall debugfs_lookup_and_remove() instead which handles all of the logic at\nonce.

In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix racy issue under cocurrent smb2 tree disconnect\n\nThere is UAF issue under cocurrent smb2 tree disconnect.\nThis patch introduce TREE_CONN_EXPIRE flags for tcon to avoid cocurrent\naccess.

In the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid10: check slab-out-of-bounds in md_bitmap_get_counter\n\nIf we write a large number to md/bitmap_set_bits, md_bitmap_checkpage()\nwill return -EINVAL because 'page >= bitmap->pages', but the return value\nwas not checked immediately in md_bitmap_get_counter() in order to set\n*blocks value and slab-out-of-bounds occurs.\n\nMove check of 'page >= bitmap->pages' to md_bitmap_get_counter() and\nreturn directly if true.

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: u_serial: Add null pointer check in gserial_suspend\n\nConsider a case where gserial_disconnect has already cleared\ngser->ioport. And if gserial_suspend gets called afterwards,\nit will lead to accessing of gser->ioport and thus causing\nnull pointer dereference.\n\nAvoid this by adding a null pointer check. Added a static\nspinlock to prevent gser->ioport from becoming null after\nthe newly added null pointer check.

In the Linux kernel, the following vulnerability has been resolved:\n\nstaging: pi433: fix memory leak with using debugfs_lookup()\n\nWhen calling debugfs_lookup() the result must have dput() called on it,\notherwise the memory will leak over time. To make things simpler, just\ncall debugfs_lookup_and_remove() instead which handles all of the logic\nat once. This requires saving off the root directory dentry to make\ncreation of individual device subdirectories easier.

In the Linux kernel, the following vulnerability has been resolved:\n\nskbuff: skb_segment, Call zero copy functions before using skbuff frags\n\nCommit bf5c25d60861 ("skbuff: in skb_segment, call zerocopy functions\nonce per nskb") added the call to zero copy functions in skb_segment().\nThe change introduced a bug in skb_segment() because skb_orphan_frags()\nmay possibly change the number of fragments or allocate new fragments\naltogether leaving nrfrags and frag to point to the old values. This can\ncause a panic with stacktrace like the one below.\n\n[ 193.894380] BUG: kernel NULL pointer dereference, address: 00000000000000bc\n[ 193.895273] CPU: 13 PID: 18164 Comm: vh-net-17428 Kdump: loaded Tainted: G O 5.15.123+ #26\n[ 193.903919] RIP: 0010:skb_segment+0xb0e/0x12f0\n[ 194.021892] Call Trace:\n[ 194.027422] \n[ 194.072861] tcp_gso_segment+0x107/0x540\n[ 194.082031] inet_gso_segment+0x15c/0x3d0\n[ 194.090783] skb_mac_gso_segment+0x9f/0x110\n[ 194.095016] __skb_gso_segment+0xc1/0x190\n[ 194.103131] netem_enqueue+0x290/0xb10 [sch_netem]\n[ 194.107071] dev_qdisc_enqueue+0x16/0x70\n[ 194.110884] __dev_queue_xmit+0x63b/0xb30\n[ 194.121670] bond_start_xmit+0x159/0x380 [bonding]\n[ 194.128506] dev_hard_start_xmit+0xc3/0x1e0\n[ 194.131787] __dev_queue_xmit+0x8a0/0xb30\n[ 194.138225] macvlan_start_xmit+0x4f/0x100 [macvlan]\n[ 194.141477] dev_hard_start_xmit+0xc3/0x1e0\n[ 194.144622] sch_direct_xmit+0xe3/0x280\n[ 194.147748] __dev_queue_xmit+0x54a/0xb30\n[ 194.154131] tap_get_user+0x2a8/0x9c0 [tap]\n[ 194.157358] tap_sendmsg+0x52/0x8e0 [tap]\n[ 194.167049] handle_tx_zerocopy+0x14e/0x4c0 [vhost_net]\n[ 194.173631] handle_tx+0xcd/0xe0 [vhost_net]\n[ 194.176959] vhost_worker+0x76/0xb0 [vhost]\n[ 194.183667] kthread+0x118/0x140\n[ 194.190358] ret_from_fork+0x1f/0x30\n[ 194.193670] \n\nIn this case calling skb_orphan_frags() updated nr_frags leaving nrfrags\nlocal variable in skb_segment() stale. This resulted in the code hitting\ni >= nrfrags prematurely and trying to move to next frag_skb using\nlist_skb pointer, which was NULL, and caused kernel panic. Move the call\nto zero copy functions before using frags and nr_frags.

In the Linux kernel, the following vulnerability has been resolved:\n\naccel/habanalabs: postpone mem_mgr IDR destruction to hpriv_release()\n\nThe memory manager IDR is currently destroyed when user releases the\nfile descriptor.\nHowever, at this point the user context might be still held, and memory\nbuffers might be still in use.\nLater on, calls to release those buffers will fail due to not finding\ntheir handles in the IDR, leading to a memory leak.\nTo avoid this leak, split the IDR destruction from the memory manager\nfini, and postpone it to hpriv_release() when there is no user context\nand no buffers are used.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/sched: Check scheduler work queue before calling timeout handling\n\nDuring an IGT GPU reset test we see again oops despite of\ncommit 0c8c901aaaebc9 (drm/sched: Check scheduler ready before calling\ntimeout handling).\n\nIt uses ready condition whether to call drm_sched_fault which unwind\nthe TDR leads to GPU reset.\nHowever it looks the ready condition is overloaded with other meanings,\nfor example, for the following stack is related GPU reset :\n\n0 gfx_v9_0_cp_gfx_start\n1 gfx_v9_0_cp_gfx_resume\n2 gfx_v9_0_cp_resume\n3 gfx_v9_0_hw_init\n4 gfx_v9_0_resume\n5 amdgpu_device_ip_resume_phase2\n\ndoes the following:\n /* start the ring */\n gfx_v9_0_cp_gfx_start(adev);\n ring->sched.ready = true;\n\nThe same approach is for other ASICs as well :\ngfx_v8_0_cp_gfx_resume\ngfx_v10_0_kiq_resume, etc...\n\nAs a result, our GPU reset test causes GPU fault which calls unconditionally gfx_v9_0_fault\nand then drm_sched_fault. However now it depends on whether the interrupt service routine\ndrm_sched_fault is executed after gfx_v9_0_cp_gfx_start is completed which sets the ready\nfield of the scheduler to true even for uninitialized schedulers and causes oops vs\nno fault or when ISR drm_sched_fault is completed prior gfx_v9_0_cp_gfx_start and\nNULL pointer dereference does not occur.\n\nUse the field timeout_wq to prevent oops for uninitialized schedulers.\nThe field could be initialized by the work queue of resetting the domain.\n\nv1: Corrections to commit message (Luben)

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwl4965: Add missing check for create_singlethread_workqueue()\n\nAdd the check for the return value of the create_singlethread_workqueue()\nin order to avoid NULL pointer dereference.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: hisilicon: Add multi-thread support for a DMA channel\n\nWhen we get a DMA channel and try to use it in multiple threads it\nwill cause oops and hanging the system.\n\n% echo 100 > /sys/module/dmatest/parameters/threads_per_chan\n% echo 100 > /sys/module/dmatest/parameters/iterations\n% echo 1 > /sys/module/dmatest/parameters/run\n[383493.327077] Unable to handle kernel paging request at virtual\n address dead000000000108\n[383493.335103] Mem abort info:\n[383493.335103] ESR = 0x96000044\n[383493.335105] EC = 0x25: DABT (current EL), IL = 32 bits\n[383493.335107] SET = 0, FnV = 0\n[383493.335108] EA = 0, S1PTW = 0\n[383493.335109] FSC = 0x04: level 0 translation fault\n[383493.335110] Data abort info:\n[383493.335111] ISV = 0, ISS = 0x00000044\n[383493.364739] CM = 0, WnR = 1\n[383493.367793] [dead000000000108] address between user and kernel\n address ranges\n[383493.375021] Internal error: Oops: 96000044 [#1] PREEMPT SMP\n[383493.437574] CPU: 63 PID: 27895 Comm: dma0chan0-copy2 Kdump:\n loaded Tainted: GO 5.17.0-rc4+ #2\n[383493.457851] pstate: 204000c9 (nzCv daIF +PAN -UAO -TCO -DIT\n -SSBS BTYPE=--)\n[383493.465331] pc : vchan_tx_submit+0x64/0xa0\n[383493.469957] lr : vchan_tx_submit+0x34/0xa0\n\nThis occurs because the transmission timed out, and that's due\nto data race. Each thread rewrite channels's descriptor as soon as\ndevice_issue_pending is called. It leads to the situation that\nthe driver thinks that it uses the right descriptor in interrupt\nhandler while channels's descriptor has been changed by other\nthread. The descriptor which in fact reported interrupt will not\nbe handled any more, as well as its tx->callback.\nThat's why timeout reports.\n\nWith current fixes channels' descriptor changes it's value only\nwhen it has been used. A new descriptor is acquired from\nvc->desc_issued queue that is already filled with descriptors\nthat are ready to be sent. Threads have no direct access to DMA\nchannel descriptor. In case of channel's descriptor is busy, try\nto submit to HW again when a descriptor is completed. In this case,\nvc->desc_issued may be empty when hisi_dma_start_transfer is called,\nso delete error reporting on this. Now it is just possible to queue\na descriptor for further processing.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: wilc1000: add missing unregister_netdev() in wilc_netdev_ifc_init()\n\nFault injection test reports this issue:\n\nkernel BUG at net/core/dev.c:10731!\ninvalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI\nCall Trace:\n \n wilc_netdev_ifc_init+0x19f/0x220 [wilc1000 884bf126e9e98af6a708f266a8dffd53f99e4bf5]\n wilc_cfg80211_init+0x30c/0x380 [wilc1000 884bf126e9e98af6a708f266a8dffd53f99e4bf5]\n wilc_bus_probe+0xad/0x2b0 [wilc1000_spi 1520a7539b6589cc6cde2ae826a523a33f8bacff]\n spi_probe+0xe4/0x140\n really_probe+0x17e/0x3f0\n __driver_probe_device+0xe3/0x170\n driver_probe_device+0x49/0x120\n\nThe root case here is alloc_ordered_workqueue() fails, but\ncfg80211_unregister_netdevice() or unregister_netdev() not be called in\nerror handling path. To fix add unregister_netdev goto lable to add the\nunregister operation in error handling path.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/dp: fix aux-bus EP lifetime\n\nDevice-managed resources allocated post component bind must be tied to\nthe lifetime of the aggregate DRM device or they will not necessarily be\nreleased when binding of the aggregate device is deferred.\n\nThis can lead resource leaks or failure to bind the aggregate device\nwhen binding is later retried and a second attempt to allocate the\nresources is made.\n\nFor the DP aux-bus, an attempt to populate the bus a second time will\nsimply fail ("DP AUX EP device already populated").\n\nFix this by tying the lifetime of the EP device to the DRM device rather\nthan DP controller platform device.\n\nPatchwork: https://patchwork.freedesktop.org/patch/502672/

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: cx88: Fix a null-ptr-deref bug in buffer_prepare()\n\nWhen the driver calls cx88_risc_buffer() to prepare the buffer, the\nfunction call may fail, resulting in a empty buffer and null-ptr-deref\nlater in buffer_queue().\n\nThe following log can reveal it:\n\n[ 41.822762] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI\n[ 41.824488] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\n[ 41.828027] RIP: 0010:buffer_queue+0xc2/0x500\n[ 41.836311] Call Trace:\n[ 41.836945] __enqueue_in_driver+0x141/0x360\n[ 41.837262] vb2_start_streaming+0x62/0x4a0\n[ 41.838216] vb2_core_streamon+0x1da/0x2c0\n[ 41.838516] __vb2_init_fileio+0x981/0xbc0\n[ 41.839141] __vb2_perform_fileio+0xbf9/0x1120\n[ 41.840072] vb2_fop_read+0x20e/0x400\n[ 41.840346] v4l2_read+0x215/0x290\n[ 41.840603] vfs_read+0x162/0x4c0\n\nFix this by checking the return value of cx88_risc_buffer()\n\n[hverkuil: fix coding style issues]

In the Linux kernel, the following vulnerability has been resolved:\n\nbrcmfmac: return error when getting invalid max_flowrings from dongle\n\nWhen firmware hit trap at initialization, host will read abnormal\nmax_flowrings number from dongle, and it will cause kernel panic when\ndoing iowrite to initialize dongle ring.\nTo detect this error at early stage, we directly return error when getting\ninvalid max_flowrings(>256).

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\next4: init quota for 'old.inode' in 'ext4_rename'\n\nSyzbot found the following issue:\next4_parse_param: s_want_extra_isize=128\next4_inode_info_init: s_want_extra_isize=32\next4_rename: old.inode=ffff88823869a2c8 old.dir=ffff888238699828 new.inode=ffff88823869d7e8 new.dir=ffff888238699828\n__ext4_mark_inode_dirty: inode=ffff888238699828 ea_isize=32 want_ea_size=128\n__ext4_mark_inode_dirty: inode=ffff88823869a2c8 ea_isize=32 want_ea_size=128\next4_xattr_block_set: inode=ffff88823869a2c8\n------------[ cut here ]------------\nWARNING: CPU: 13 PID: 2234 at fs/ext4/xattr.c:2070 ext4_xattr_block_set.cold+0x22/0x980\nModules linked in:\nRIP: 0010:ext4_xattr_block_set.cold+0x22/0x980\nRSP: 0018:ffff888227d3f3b0 EFLAGS: 00010202\nRAX: 0000000000000001 RBX: ffff88823007a000 RCX: 0000000000000000\nRDX: 0000000000000a03 RSI: 0000000000000040 RDI: ffff888230078178\nRBP: 0000000000000000 R08: 000000000000002c R09: ffffed1075c7df8e\nR10: ffff8883ae3efc6b R11: ffffed1075c7df8d R12: 0000000000000000\nR13: ffff88823869a2c8 R14: ffff8881012e0460 R15: dffffc0000000000\nFS: 00007f350ac1f740(0000) GS:ffff8883ae200000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f350a6ed6a0 CR3: 0000000237456000 CR4: 00000000000006e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \n ? ext4_xattr_set_entry+0x3b7/0x2320\n ? ext4_xattr_block_set+0x0/0x2020\n ? ext4_xattr_set_entry+0x0/0x2320\n ? ext4_xattr_check_entries+0x77/0x310\n ? ext4_xattr_ibody_set+0x23b/0x340\n ext4_xattr_move_to_block+0x594/0x720\n ext4_expand_extra_isize_ea+0x59a/0x10f0\n __ext4_expand_extra_isize+0x278/0x3f0\n __ext4_mark_inode_dirty.cold+0x347/0x410\n ext4_rename+0xed3/0x174f\n vfs_rename+0x13a7/0x2510\n do_renameat2+0x55d/0x920\n __x64_sys_rename+0x7d/0xb0\n do_syscall_64+0x3b/0xa0\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\n\nAs 'ext4_rename' will modify 'old.inode' ctime and mark inode dirty,\nwhich may trigger expand 'extra_isize' and allocate block. If inode\ndidn't init quota will lead to warning. To solve above issue, init\n'old.inode' firstly in 'ext4_rename'.

A memory amplification vulnerability in libexpat allows attackers to trigger excessive dynamic memory allocations by submitting specially crafted XML input. A small input (~250 KiB) can cause the parser to allocate hundreds of megabytes, leading to denial-of-service (DoS) through memory exhaustion.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: lapbether: ignore ops-locked netdevs\n\nSyzkaller managed to trigger lock dependency in xsk_notify via\nregister_netdevice. As discussed in [0], using register_netdevice\nin the notifiers is problematic so skip adding lapbeth for ops-locked\ndevices.\n\n xsk_notifier+0xa4/0x280 net/xdp/xsk.c:1645\n notifier_call_chain+0xbc/0x410 kernel/notifier.c:85\n call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:2230\n call_netdevice_notifiers_extack net/core/dev.c:2268 [inline]\n call_netdevice_notifiers net/core/dev.c:2282 [inline]\n unregister_netdevice_many_notify+0xf9d/0x2700 net/core/dev.c:12077\n unregister_netdevice_many net/core/dev.c:12140 [inline]\n unregister_netdevice_queue+0x305/0x3f0 net/core/dev.c:11984\n register_netdevice+0x18f1/0x2270 net/core/dev.c:11149\n lapbeth_new_device drivers/net/wan/lapbether.c:420 [inline]\n lapbeth_device_event+0x5b1/0xbe0 drivers/net/wan/lapbether.c:462\n notifier_call_chain+0xbc/0x410 kernel/notifier.c:85\n call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:2230\n call_netdevice_notifiers_extack net/core/dev.c:2268 [inline]\n call_netdevice_notifiers net/core/dev.c:2282 [inline]\n __dev_notify_flags+0x12c/0x2e0 net/core/dev.c:9497\n netif_change_flags+0x108/0x160 net/core/dev.c:9526\n dev_change_flags+0xba/0x250 net/core/dev_api.c:68\n devinet_ioctl+0x11d5/0x1f50 net/ipv4/devinet.c:1200\n inet_ioctl+0x3a7/0x3f0 net/ipv4/af_inet.c:1001\n\n0: https://lore.kernel.org/netdev/20250625140357.6203d0af@kernel.org/

In the Linux kernel, the following vulnerability has been resolved:\n\nARM: tegra: Use I/O memcpy to write to IRAM\n\nKasan crashes the kernel trying to check boundaries when using the\nnormal memcpy.