In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Use mlx5_ipsec_rx_status_destroy to correctly delete status rules\n\nrx_create no longer allocates a modify_hdr instance that needs to be\ncleaned up. The mlx5_modify_header_dealloc call will lead to a NULL pointer\ndereference. A leak in the rules also previously occurred since there are\nnow two rules populated related to status.\n\n BUG: kernel NULL pointer dereference, address: 0000000000000000\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 109907067 P4D 109907067 PUD 116890067 PMD 0\n Oops: 0000 [#1] SMP\n CPU: 1 PID: 484 Comm: ip Not tainted 6.9.0-rc2-rrameshbabu+ #254\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Arch Linux 1.16.3-1-1 04/01/2014\n RIP: 0010:mlx5_modify_header_dealloc+0xd/0x70\n <snip>\n Call Trace:\n <TASK>\n ? show_regs+0x60/0x70\n ? __die+0x24/0x70\n ? page_fault_oops+0x15f/0x430\n ? free_to_partial_list.constprop.0+0x79/0x150\n ? do_user_addr_fault+0x2c9/0x5c0\n ? exc_page_fault+0x63/0x110\n ? asm_exc_page_fault+0x27/0x30\n ? mlx5_modify_header_dealloc+0xd/0x70\n rx_create+0x374/0x590\n rx_add_rule+0x3ad/0x500\n ? rx_add_rule+0x3ad/0x500\n ? mlx5_cmd_exec+0x2c/0x40\n ? mlx5_create_ipsec_obj+0xd6/0x200\n mlx5e_accel_ipsec_fs_add_rule+0x31/0xf0\n mlx5e_xfrm_add_state+0x426/0xc00\n <snip>

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: taprio: extend minimum interval restriction to entire cycle too\n\nIt is possible for syzbot to side-step the restriction imposed by the\nblamed commit in the Fixes: tag, because the taprio UAPI permits a\ncycle-time different from (and potentially shorter than) the sum of\nentry intervals.\n\nWe need one more restriction, which is that the cycle time itself must\nbe larger than N * ETH_ZLEN bit times, where N is the number of schedule\nentries. This restriction needs to apply regardless of whether the cycle\ntime came from the user or was the implicit, auto-calculated value, so\nwe move the existing "cycle == 0" check outside the "if "(!new->cycle_time)"\nbranch. This way covers both conditions and scenarios.\n\nAdd a selftest which illustrates the issue triggered by syzbot.

In the Linux kernel, the following vulnerability has been resolved:\n\nmmc: sdhci-msm: pervent access to suspended controller\n\nGeneric sdhci code registers LED device and uses host->runtime_suspended\nflag to protect access to it. The sdhci-msm driver doesn't set this flag,\nwhich causes a crash when LED is accessed while controller is runtime\nsuspended. Fix this by setting the flag correctly.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm/hugetlb: fix DEBUG_LOCKS_WARN_ON(1) when dissolve_free_hugetlb_folio()\n\nWhen I did memory failure tests recently, below warning occurs:\n\nDEBUG_LOCKS_WARN_ON(1)\nWARNING: CPU: 8 PID: 1011 at kernel/locking/lockdep.c:232 __lock_acquire+0xccb/0x1ca0\nModules linked in: mce_inject hwpoison_inject\nCPU: 8 PID: 1011 Comm: bash Kdump: loaded Not tainted 6.9.0-rc3-next-20240410-00012-gdb69f219f4be #3\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014\nRIP: 0010:__lock_acquire+0xccb/0x1ca0\nRSP: 0018:ffffa7a1c7fe3bd0 EFLAGS: 00000082\nRAX: 0000000000000000 RBX: eb851eb853975fcf RCX: ffffa1ce5fc1c9c8\nRDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffffa1ce5fc1c9c0\nRBP: ffffa1c6865d3280 R08: ffffffffb0f570a8 R09: 0000000000009ffb\nR10: 0000000000000286 R11: ffffffffb0f2ad50 R12: ffffa1c6865d3d10\nR13: ffffa1c6865d3c70 R14: 0000000000000000 R15: 0000000000000004\nFS: 00007ff9f32aa740(0000) GS:ffffa1ce5fc00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007ff9f3134ba0 CR3: 00000008484e4000 CR4: 00000000000006f0\nCall Trace:\n <TASK>\n lock_acquire+0xbe/0x2d0\n _raw_spin_lock_irqsave+0x3a/0x60\n hugepage_subpool_put_pages.part.0+0xe/0xc0\n free_huge_folio+0x253/0x3f0\n dissolve_free_huge_page+0x147/0x210\n __page_handle_poison+0x9/0x70\n memory_failure+0x4e6/0x8c0\n hard_offline_page_store+0x55/0xa0\n kernfs_fop_write_iter+0x12c/0x1d0\n vfs_write+0x380/0x540\n ksys_write+0x64/0xe0\n do_syscall_64+0xbc/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7ff9f3114887\nRSP: 002b:00007ffecbacb458 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007ff9f3114887\nRDX: 000000000000000c RSI: 0000564494164e10 RDI: 0000000000000001\nRBP: 0000564494164e10 R08: 00007ff9f31d1460 R09: 000000007fffffff\nR10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c\nR13: 00007ff9f321b780 R14: 00007ff9f3217600 R15: 00007ff9f3216a00\n </TASK>\nKernel panic - not syncing: kernel: panic_on_warn set ...\nCPU: 8 PID: 1011 Comm: bash Kdump: loaded Not tainted 6.9.0-rc3-next-20240410-00012-gdb69f219f4be #3\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014\nCall Trace:\n <TASK>\n panic+0x326/0x350\n check_panic_on_warn+0x4f/0x50\n __warn+0x98/0x190\n report_bug+0x18e/0x1a0\n handle_bug+0x3d/0x70\n exc_invalid_op+0x18/0x70\n asm_exc_invalid_op+0x1a/0x20\nRIP: 0010:__lock_acquire+0xccb/0x1ca0\nRSP: 0018:ffffa7a1c7fe3bd0 EFLAGS: 00000082\nRAX: 0000000000000000 RBX: eb851eb853975fcf RCX: ffffa1ce5fc1c9c8\nRDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffffa1ce5fc1c9c0\nRBP: ffffa1c6865d3280 R08: ffffffffb0f570a8 R09: 0000000000009ffb\nR10: 0000000000000286 R11: ffffffffb0f2ad50 R12: ffffa1c6865d3d10\nR13: ffffa1c6865d3c70 R14: 0000000000000000 R15: 0000000000000004\n lock_acquire+0xbe/0x2d0\n _raw_spin_lock_irqsave+0x3a/0x60\n hugepage_subpool_put_pages.part.0+0xe/0xc0\n free_huge_folio+0x253/0x3f0\n dissolve_free_huge_page+0x147/0x210\n __page_handle_poison+0x9/0x70\n memory_failure+0x4e6/0x8c0\n hard_offline_page_store+0x55/0xa0\n kernfs_fop_write_iter+0x12c/0x1d0\n vfs_write+0x380/0x540\n ksys_write+0x64/0xe0\n do_syscall_64+0xbc/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7ff9f3114887\nRSP: 002b:00007ffecbacb458 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007ff9f3114887\nRDX: 000000000000000c RSI: 0000564494164e10 RDI: 0000000000000001\nRBP: 0000564494164e10 R08: 00007ff9f31d1460 R09: 000000007fffffff\nR10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c\nR13: 00007ff9f321b780 R14: 00007ff9f3217600 R15: 00007ff9f3216a00\n </TASK>\n\nAfter git bisecting and digging into the code, I believe the root cause is\nthat _deferred_list field of folio is unioned with _hugetlb_subpool field.\nIn __update_and_free_hugetlb_folio(), folio->_deferred_list is\ninitialized leading to corrupted folio->_hugetlb_subpool when folio is\nhugetlb. Later free_huge_folio() will use _hugetlb_subpool and above\nwarning happens.\n\nBut it is assumed hugetlb flag must have been cleared when calling\nfolio_put() in update_and_free_hugetlb_folio(). This assumption is broken\ndue to below race:\n\nCPU1 CPU2\ndissolve_free_huge_page update_and_free_pages_bulk\n update_and_free_hugetlb_folio hugetlb_vmemmap_restore_folios\n folio_clear_hugetlb_vmemmap_optimized\n clear_flag = folio_test_hugetlb_vmemmap_optimized\n if (clear_flag) <-- False, it's already cleared.\n __folio_clear_hugetlb(folio) <-- Hugetlb is not cleared.\n folio_put\n free_huge_folio <-- free_the_page is expected.\n list_for_each_entry()\n __folio_clear_hugetlb <-- Too late.\n\nFix this issue by checking whether folio is hugetlb directly instead of\nchecking clear_flag to close the race window.

In the Linux kernel, the following vulnerability has been resolved:\n\nregmap: maple: Fix cache corruption in regcache_maple_drop()\n\nWhen keeping the upper end of a cache block entry, the entry[] array\nmust be indexed by the offset from the base register of the block,\ni.e. max - mas.index.\n\nThe code was indexing entry[] by only the register address, leading\nto an out-of-bounds access that copied some part of the kernel\nmemory over the cache contents.\n\nThis bug was not detected by the regmap KUnit test because it only\ntests with a block of registers starting at 0, so mas.index == 0.

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix slab-use-after-free in l2cap_connect()\n\nExtend a critical section to prevent chan from early freeing.\nAlso make the l2cap_connect() return type void. Nothing is using the\nreturned value but it is ugly to return a potentially freed pointer.\nMaking it void will help with backports because earlier kernels did use\nthe return value. Now the compile will break for kernels where this\npatch is not a complete fix.\n\nCall stack summary:\n\n[use]\nl2cap_bredr_sig_cmd\n l2cap_connect\n ┌ mutex_lock(&conn->chan_lock);\n │ chan = pchan->ops->new_connection(pchan); <- alloc chan\n │ __l2cap_chan_add(conn, chan);\n │ l2cap_chan_hold(chan);\n │ list_add(&chan->list, &conn->chan_l); ... (1)\n └ mutex_unlock(&conn->chan_lock);\n chan->conf_state ... (4) <- use after free\n\n[free]\nl2cap_conn_del\n┌ mutex_lock(&conn->chan_lock);\n│ foreach chan in conn->chan_l: ... (2)\n│ l2cap_chan_put(chan);\n│ l2cap_chan_destroy\n│ kfree(chan) ... (3) <- chan freed\n└ mutex_unlock(&conn->chan_lock);\n\n==================================================================\nBUG: KASAN: slab-use-after-free in instrument_atomic_read\ninclude/linux/instrumented.h:68 [inline]\nBUG: KASAN: slab-use-after-free in _test_bit\ninclude/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]\nBUG: KASAN: slab-use-after-free in l2cap_connect+0xa67/0x11a0\nnet/bluetooth/l2cap_core.c:4260\nRead of size 8 at addr ffff88810bf040a0 by task kworker/u3:1/311

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: msft: fix slab-use-after-free in msft_do_close()\n\nTying the msft->data lifetime to hdev by freeing it in\nhci_release_dev() to fix the following case:\n\n[use]\nmsft_do_close()\n msft = hdev->msft_data;\n if (!msft) ...(1) <- passed.\n return;\n mutex_lock(&msft->filter_lock); ...(4) <- used after freed.\n\n[free]\nmsft_unregister()\n msft = hdev->msft_data;\n hdev->msft_data = NULL; ...(2)\n kfree(msft); ...(3) <- msft is freed.\n\n==================================================================\nBUG: KASAN: slab-use-after-free in __mutex_lock_common\nkernel/locking/mutex.c:587 [inline]\nBUG: KASAN: slab-use-after-free in __mutex_lock+0x8f/0xc30\nkernel/locking/mutex.c:752\nRead of size 8 at addr ffff888106cbbca8 by task kworker/u5:2/309

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: HCI: Fix potential null-ptr-deref\n\nFix potential null-ptr-deref in hci_le_big_sync_established_evt().

In the Linux kernel, the following vulnerability has been resolved:\n\nsched/eevdf: Prevent vlag from going out of bounds in reweight_eevdf()\n\nIt was possible to have pick_eevdf() return NULL, which then causes a\nNULL-deref. This turned out to be due to entity_eligible() returning\nfalsely negative because of a s64 multiplcation overflow.\n\nSpecifically, reweight_eevdf() computes the vlag without considering\nthe limit placed upon vlag as update_entity_lag() does, and then the\nscaling multiplication (remember that weight is 20bit fixed point) can\noverflow. This then leads to the new vruntime being weird which then\ncauses the above entity_eligible() to go side-ways and claim nothing\nis eligible.\n\nThus limit the range of vlag accordingly.\n\nAll this was quite rare, but fatal when it does happen.

In the Linux kernel, the following vulnerability has been resolved:\n\narm64: tlb: Fix TLBI RANGE operand\n\nKVM/arm64 relies on TLBI RANGE feature to flush TLBs when the dirty\npages are collected by VMM and the page table entries become write\nprotected during live migration. Unfortunately, the operand passed\nto the TLBI RANGE instruction isn't correctly sorted out due to the\ncommit 117940aa6e5f ("KVM: arm64: Define kvm_tlb_flush_vmid_range()").\nIt leads to crash on the destination VM after live migration because\nTLBs aren't flushed completely and some of the dirty pages are missed.\n\nFor example, I have a VM where 8GB memory is assigned, starting from\n0x40000000 (1GB). Note that the host has 4KB as the base page size.\nIn the middile of migration, kvm_tlb_flush_vmid_range() is executed\nto flush TLBs. It passes MAX_TLBI_RANGE_PAGES as the argument to\n__kvm_tlb_flush_vmid_range() and __flush_s2_tlb_range_op(). SCALE#3\nand NUM#31, corresponding to MAX_TLBI_RANGE_PAGES, isn't supported\nby __TLBI_RANGE_NUM(). In this specific case, -1 has been returned\nfrom __TLBI_RANGE_NUM() for SCALE#3/2/1/0 and rejected by the loop\nin the __flush_tlb_range_op() until the variable @scale underflows\nand becomes -9, 0xffff708000040000 is set as the operand. The operand\nis wrong since it's sorted out by __TLBI_VADDR_RANGE() according to\ninvalid @scale and @num.\n\nFix it by extending __TLBI_RANGE_NUM() to support the combination of\nSCALE#3 and NUM#31. With the changes, [-1 31] instead of [-1 30] can\nbe returned from the macro, meaning the TLBs for 0x200000 pages in the\nabove example can be flushed in one shoot with SCALE#3 and NUM#31. The\nmacro TLBI_RANGE_MASK is dropped since no one uses it any more. The\ncomments are also adjusted accordingly.

In the Linux kernel, the following vulnerability has been resolved:\n\nraid1: fix use-after-free for original bio in raid1_write_request()\n\nr1_bio->bios[] is used to record new bios that will be issued to\nunderlying disks, however, in raid1_write_request(), r1_bio->bios[]\nwill set to the original bio temporarily. Meanwhile, if blocked rdev\nis set, free_r1bio() will be called causing that all r1_bio->bios[]\nto be freed:\n\nraid1_write_request()\n r1_bio = alloc_r1bio(mddev, bio); -> r1_bio->bios[] is NULL\n for (i = 0; i < disks; i++) -> for each rdev in conf\n // first rdev is normal\n r1_bio->bios[0] = bio; -> set to original bio\n // second rdev is blocked\n if (test_bit(Blocked, &rdev->flags))\n break\n\n if (blocked_rdev)\n free_r1bio()\n put_all_bios()\n bio_put(r1_bio->bios[0]) -> original bio is freed\n\nTest scripts:\n\nmdadm -CR /dev/md0 -l1 -n4 /dev/sd[abcd] --assume-clean\nfio -filename=/dev/md0 -ioengine=libaio -rw=write -bs=4k -numjobs=1 \\\n -iodepth=128 -name=test -direct=1\necho blocked > /sys/block/md0/md/rd2/state\n\nTest result:\n\nBUG bio-264 (Not tainted): Object already free\n-----------------------------------------------------------------------------\n\nAllocated in mempool_alloc_slab+0x24/0x50 age=1 cpu=1 pid=869\n kmem_cache_alloc+0x324/0x480\n mempool_alloc_slab+0x24/0x50\n mempool_alloc+0x6e/0x220\n bio_alloc_bioset+0x1af/0x4d0\n blkdev_direct_IO+0x164/0x8a0\n blkdev_write_iter+0x309/0x440\n aio_write+0x139/0x2f0\n io_submit_one+0x5ca/0xb70\n __do_sys_io_submit+0x86/0x270\n __x64_sys_io_submit+0x22/0x30\n do_syscall_64+0xb1/0x210\n entry_SYSCALL_64_after_hwframe+0x6c/0x74\nFreed in mempool_free_slab+0x1f/0x30 age=1 cpu=1 pid=869\n kmem_cache_free+0x28c/0x550\n mempool_free_slab+0x1f/0x30\n mempool_free+0x40/0x100\n bio_free+0x59/0x80\n bio_put+0xf0/0x220\n free_r1bio+0x74/0xb0\n raid1_make_request+0xadf/0x1150\n md_handle_request+0xc7/0x3b0\n md_submit_bio+0x76/0x130\n __submit_bio+0xd8/0x1d0\n submit_bio_noacct_nocheck+0x1eb/0x5c0\n submit_bio_noacct+0x169/0xd40\n submit_bio+0xee/0x1d0\n blkdev_direct_IO+0x322/0x8a0\n blkdev_write_iter+0x309/0x440\n aio_write+0x139/0x2f0\n\nSince that bios for underlying disks are not allocated yet, fix this\nproblem by using mempool_free() directly to free the r1_bio.

In the Linux kernel, the following vulnerability has been resolved:\n\nbnxt_en: Fix possible memory leak in bnxt_rdma_aux_device_init()\n\nIf ulp = kzalloc() fails, the allocated edev will leak because it is\nnot properly assigned and the cleanup path will not be able to free it.\nFix it by assigning it properly immediately after allocation.

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: qgroup: fix qgroup prealloc rsv leak in subvolume operations\n\nCreate subvolume, create snapshot and delete subvolume all use\nbtrfs_subvolume_reserve_metadata() to reserve metadata for the changes\ndone to the parent subvolume's fs tree, which cannot be mediated in the\nnormal way via start_transaction. When quota groups (squota or qgroups)\nare enabled, this reserves qgroup metadata of type PREALLOC. Once the\noperation is associated to a transaction, we convert PREALLOC to\nPERTRANS, which gets cleared in bulk at the end of the transaction.\n\nHowever, the error paths of these three operations were not implementing\nthis lifecycle correctly. They unconditionally converted the PREALLOC to\nPERTRANS in a generic cleanup step regardless of errors or whether the\noperation was fully associated to a transaction or not. This resulted in\nerror paths occasionally converting this rsv to PERTRANS without calling\nrecord_root_in_trans successfully, which meant that unless that root got\nrecorded in the transaction by some other thread, the end of the\ntransaction would not free that root's PERTRANS, leaking it. Ultimately,\nthis resulted in hitting a WARN in CONFIG_BTRFS_DEBUG builds at unmount\nfor the leaked reservation.\n\nThe fix is to ensure that every qgroup PREALLOC reservation observes the\nfollowing properties:\n\n1. any failure before record_root_in_trans is called successfully\n results in freeing the PREALLOC reservation.\n2. after record_root_in_trans, we convert to PERTRANS, and now the\n transaction owns freeing the reservation.\n\nThis patch enforces those properties on the three operations. Without\nit, generic/269 with squotas enabled at mkfs time would fail in ~5-10\nruns on my system. With this patch, it ran successfully 1000 times in a\nrow.

In the Linux kernel, the following vulnerability has been resolved:\n\nkprobes: Fix possible use-after-free issue on kprobe registration\n\nWhen unloading a module, its state is changing MODULE_STATE_LIVE ->\n MODULE_STATE_GOING -> MODULE_STATE_UNFORMED. Each change will take\na time. `is_module_text_address()` and `__module_text_address()`\nworks with MODULE_STATE_LIVE and MODULE_STATE_GOING.\nIf we use `is_module_text_address()` and `__module_text_address()`\nseparately, there is a chance that the first one is succeeded but the\nnext one is failed because module->state becomes MODULE_STATE_UNFORMED\nbetween those operations.\n\nIn `check_kprobe_address_safe()`, if the second `__module_text_address()`\nis failed, that is ignored because it expected a kernel_text address.\nBut it may have failed simply because module->state has been changed\nto MODULE_STATE_UNFORMED. In this case, arm_kprobe() will try to modify\nnon-exist module text address (use-after-free).\n\nTo fix this problem, we should not use separated `is_module_text_address()`\nand `__module_text_address()`, but use only `__module_text_address()`\nonce and do `try_module_get(module)` which is only available with\nMODULE_STATE_LIVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: sg: Avoid sg device teardown race\n\nsg_remove_sfp_usercontext() must not use sg_device_destroy() after calling\nscsi_device_put().\n\nsg_device_destroy() is accessing the parent scsi_device request_queue which\nwill already be set to NULL when the preceding call to scsi_device_put()\nremoved the last reference to the parent scsi_device.\n\nThe resulting NULL pointer exception will then crash the kernel.

In the Linux kernel, the following vulnerability has been resolved:\n\naccel/ivpu: Fix deadlock in context_xa\n\nivpu_device->context_xa is locked both in kernel thread and IRQ context.\nIt requires XA_FLAGS_LOCK_IRQ flag to be passed during initialization\notherwise the lock could be acquired from a thread and interrupted by\nan IRQ that locks it for the second time causing the deadlock.\n\nThis deadlock was reported by lockdep and observed in internal tests.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr()\n\nSubject: [PATCH] drm/panfrost: Fix the error path in\n panfrost_mmu_map_fault_addr()\n\nIf some the pages or sgt allocation failed, we shouldn't release the\npages ref we got earlier, otherwise we will end up with unbalanced\nget/put_pages() calls. We should instead leave everything in place\nand let the BO release function deal with extra cleanup when the object\nis destroyed, or let the fault handler try again next time it's called.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: phy_device: Prevent nullptr exceptions on ISR\n\nIf phydev->irq is set unconditionally, check\nfor valid interrupt handler or fall back to polling mode to prevent\nnullptr exceptions in interrupt service routine.

In the Linux kernel, the following vulnerability has been resolved:\n\npmdomain: ti: Add a null pointer check to the omap_prm_domain_init\n\ndevm_kasprintf() returns a pointer to dynamically allocated memory\nwhich can be NULL upon failure. Ensure the allocation was successful\nby checking the pointer validity.

In the Linux kernel, the following vulnerability has been resolved:\n\npstore/zone: Add a null pointer check to the psz_kmsg_read\n\nkasprintf() returns a pointer to dynamically allocated memory\nwhich can be NULL upon failure. Ensure the allocation was successful\nby checking the pointer validity.

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: mediatek: vcodec: adding lock to protect encoder context list\n\nAdd a lock for the ctx_list, to avoid accessing a NULL pointer\nwithin the 'vpu_enc_ipi_handler' function when the ctx_list has\nbeen deleted due to an unexpected behavior on the SCP IP block.

In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: Fix error cleanup path in nfsd_rename()\n\nCommit a8b0026847b8 ("rename(): avoid a deadlock in the case of parents\nhaving no common ancestor") added an error bail out path. However this\npath does not drop the remount protection that has been acquired. Fix\nthe cleanup path to properly drop the remount protection.

In the Linux kernel, the following vulnerability has been resolved:\n\nice: fix memory corruption bug with suspend and rebuild\n\nThe ice driver would previously panic after suspend. This is caused\nfrom the driver *only* calling the ice_vsi_free_q_vectors() function by\nitself, when it is suspending. Since commit b3e7b3a6ee92 ("ice: prevent\nNULL pointer deref during reload") the driver has zeroed out\nnum_q_vectors, and only restored it in ice_vsi_cfg_def().\n\nThis further causes the ice_rebuild() function to allocate a zero length\nbuffer, after which num_q_vectors is updated, and then the new value of\nnum_q_vectors is used to index into the zero length buffer, which\ncorrupts memory.\n\nThe fix entails making sure all the code referencing num_q_vectors only\ndoes so after it has been reset via ice_vsi_cfg_def().\n\nI didn't perform a full bisect, but I was able to test against 6.1.77\nkernel and that ice driver works fine for suspend/resume with no panic,\nso sometime since then, this problem was introduced.\n\nAlso clean up an un-needed init of a local variable in the function\nbeing modified.\n\nPANIC from 6.8.0-rc1:\n\n[1026674.915596] PM: suspend exit\n[1026675.664697] ice 0000:17:00.1: PTP reset successful\n[1026675.664707] ice 0000:17:00.1: 2755 msecs passed between update to cached PHC time\n[1026675.667660] ice 0000:b1:00.0: PTP reset successful\n[1026675.675944] ice 0000:b1:00.0: 2832 msecs passed between update to cached PHC time\n[1026677.137733] ixgbe 0000:31:00.0 ens787: NIC Link is Up 1 Gbps, Flow Control: None\n[1026677.190201] BUG: kernel NULL pointer dereference, address: 0000000000000010\n[1026677.192753] ice 0000:17:00.0: PTP reset successful\n[1026677.192764] ice 0000:17:00.0: 4548 msecs passed between update to cached PHC time\n[1026677.197928] #PF: supervisor read access in kernel mode\n[1026677.197933] #PF: error_code(0x0000) - not-present page\n[1026677.197937] PGD 1557a7067 P4D 0\n[1026677.212133] ice 0000:b1:00.1: PTP reset successful\n[1026677.212143] ice 0000:b1:00.1: 4344 msecs passed between update to cached PHC time\n[1026677.212575]\n[1026677.243142] Oops: 0000 [#1] PREEMPT SMP NOPTI\n[1026677.247918] CPU: 23 PID: 42790 Comm: kworker/23:0 Kdump: loaded Tainted: G W 6.8.0-rc1+ #1\n[1026677.257989] Hardware name: Intel Corporation M50CYP2SBSTD/M50CYP2SBSTD, BIOS SE5C620.86B.01.01.0005.2202160810 02/16/2022\n[1026677.269367] Workqueue: ice ice_service_task [ice]\n[1026677.274592] RIP: 0010:ice_vsi_rebuild_set_coalesce+0x130/0x1e0 [ice]\n[1026677.281421] Code: 0f 84 3a ff ff ff 41 0f b7 74 ec 02 66 89 b0 22 02 00 00 81 e6 ff 1f 00 00 e8 ec fd ff ff e9 35 ff ff ff 48 8b 43 30 49 63 ed <41> 0f b7 34 24 41 83 c5 01 48 8b 3c e8 66 89 b7 aa 02 00 00 81 e6\n[1026677.300877] RSP: 0018:ff3be62a6399bcc0 EFLAGS: 00010202\n[1026677.306556] RAX: ff28691e28980828 RBX: ff28691e41099828 RCX: 0000000000188000\n[1026677.314148] RDX: 0000000000000000 RSI: 0000000000000010 RDI: ff28691e41099828\n[1026677.321730] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000\n[1026677.329311] R10: 0000000000000007 R11: ffffffffffffffc0 R12: 0000000000000010\n[1026677.336896] R13: 0000000000000000 R14: 0000000000000000 R15: ff28691e0eaa81a0\n[1026677.344472] FS: 0000000000000000(0000) GS:ff28693cbffc0000(0000) knlGS:0000000000000000\n[1026677.353000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[1026677.359195] CR2: 0000000000000010 CR3: 0000000128df4001 CR4: 0000000000771ef0\n[1026677.366779] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[1026677.374369] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[1026677.381952] PKRU: 55555554\n[1026677.385116] Call Trace:\n[1026677.388023] <TASK>\n[1026677.390589] ? __die+0x20/0x70\n[1026677.394105] ? page_fault_oops+0x82/0x160\n[1026677.398576] ? do_user_addr_fault+0x65/0x6a0\n[1026677.403307] ? exc_page_fault+0x6a/0x150\n[1026677.407694] ? asm_exc_page_fault+0x22/0x30\n[1026677.412349] ? ice_vsi_rebuild_set_coalesce+0x130/0x1e0 [ice]\n[1026677.418614] ice_vsi_rebuild+0x34b/0x3c0 [ice]\n[1026677.423583] ice_vsi_rebuild_by_type+0x76/0x180 [ice]\n[1026677.429147] ice_rebuild+0x18b/0x520 [ice]\n[1026677.433746] ? delay_tsc+0x8f/0xc0\n[1026677.437630] ice_do_reset+0xa3/0x190 [ice]\n[1026677.442231] ice_service_task+0x26/0x440 [ice]\n[1026677.447180] process_one_work+0x174/0x340\n[1026677.451669] worker_thread+0x27e/0x390\n[1026677.455890] ? __pfx_worker_thread+0x10/0x10\n[1026677.460627] kthread+0xee/0x120\n[1026677.464235] ? __pfx_kthread+0x10/0x10\n[1026677.468445] ret_from_fork+0x2d/0x50\n[1026677.472476] ? __pfx_kthread+0x10/0x10\n[1026677.476671] ret_from_fork_asm+0x1b/0x30\n[1026677.481050] </TASK>

In the Linux kernel, the following vulnerability has been resolved:\n\ntls: get psock ref after taking rxlock to avoid leak\n\nAt the start of tls_sw_recvmsg, we take a reference on the psock, and\nthen call tls_rx_reader_lock. If that fails, we return directly\nwithout releasing the reference.\n\nInstead of adding a new label, just take the reference after locking\nhas succeeded, since we don't need it before.

In the Linux kernel, the following vulnerability has been resolved:\n\nx86/bpf: Fix IP after emitting call depth accounting\n\nAdjust the IP passed to `emit_patch` so it calculates the correct offset\nfor the CALL instruction if `x86_call_depth_emit_accounting` emits code.\nOtherwise we will skip some instructions and most likely crash.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: mana: Fix Rx DMA datasize and skb_over_panic\n\nmana_get_rxbuf_cfg() aligns the RX buffer's DMA datasize to be\nmultiple of 64. So a packet slightly bigger than mtu+14, say 1536,\ncan be received and cause skb_over_panic.\n\nSample dmesg:\n[ 5325.237162] skbuff: skb_over_panic: text:ffffffffc043277a len:1536 put:1536 head:ff1100018b517000 data:ff1100018b517100 tail:0x700 end:0x6ea dev:<NULL>\n[ 5325.243689] ------------[ cut here ]------------\n[ 5325.245748] kernel BUG at net/core/skbuff.c:192!\n[ 5325.247838] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\n[ 5325.258374] RIP: 0010:skb_panic+0x4f/0x60\n[ 5325.302941] Call Trace:\n[ 5325.304389] <IRQ>\n[ 5325.315794] ? skb_panic+0x4f/0x60\n[ 5325.317457] ? asm_exc_invalid_op+0x1f/0x30\n[ 5325.319490] ? skb_panic+0x4f/0x60\n[ 5325.321161] skb_put+0x4e/0x50\n[ 5325.322670] mana_poll+0x6fa/0xb50 [mana]\n[ 5325.324578] __napi_poll+0x33/0x1e0\n[ 5325.326328] net_rx_action+0x12e/0x280\n\nAs discussed internally, this alignment is not necessary. To fix\nthis bug, remove it from the code. So oversized packets will be\nmarked as CQE_RX_TRUNCATED by NIC, and dropped.

In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: prevent BPF accessing lowat from a subflow socket.\n\nAlexei reported the following splat:\n\n WARNING: CPU: 32 PID: 3276 at net/mptcp/subflow.c:1430 subflow_data_ready+0x147/0x1c0\n Modules linked in: dummy bpf_testmod(O) [last unloaded: bpf_test_no_cfi(O)]\n CPU: 32 PID: 3276 Comm: test_progs Tainted: GO 6.8.0-12873-g2c43c33bfd23\n Call Trace:\n <TASK>\n mptcp_set_rcvlowat+0x79/0x1d0\n sk_setsockopt+0x6c0/0x1540\n __bpf_setsockopt+0x6f/0x90\n bpf_sock_ops_setsockopt+0x3c/0x90\n bpf_prog_509ce5db2c7f9981_bpf_test_sockopt_int+0xb4/0x11b\n bpf_prog_dce07e362d941d2b_bpf_test_socket_sockopt+0x12b/0x132\n bpf_prog_348c9b5faaf10092_skops_sockopt+0x954/0xe86\n __cgroup_bpf_run_filter_sock_ops+0xbc/0x250\n tcp_connect+0x879/0x1160\n tcp_v6_connect+0x50c/0x870\n mptcp_connect+0x129/0x280\n __inet_stream_connect+0xce/0x370\n inet_stream_connect+0x36/0x50\n bpf_trampoline_6442491565+0x49/0xef\n inet_stream_connect+0x5/0x50\n __sys_connect+0x63/0x90\n __x64_sys_connect+0x14/0x20\n\nThe root cause of the issue is that bpf allows accessing mptcp-level\nproto_ops from a tcp subflow scope.\n\nFix the issue detecting the problematic call and preventing any action.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: fix lockdep splat in qdisc_tree_reduce_backlog()\n\nqdisc_tree_reduce_backlog() is called with the qdisc lock held,\nnot RTNL.\n\nWe must use qdisc_lookup_rcu() instead of qdisc_lookup()\n\nsyzbot reported:\n\nWARNING: suspicious RCU usage\n6.1.74-syzkaller #0 Not tainted\n-----------------------------\nnet/sched/sch_api.c:305 suspicious rcu_dereference_protected() usage!\n\nother info that might help us debug this:\n\nrcu_scheduler_active = 2, debug_locks = 1\n3 locks held by udevd/1142:\n #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:306 [inline]\n #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:747 [inline]\n #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: net_tx_action+0x64a/0x970 net/core/dev.c:5282\n #1: ffff888171861108 (&sch->q.lock){+.-.}-{2:2}, at: spin_lock include/linux/spinlock.h:350 [inline]\n #1: ffff888171861108 (&sch->q.lock){+.-.}-{2:2}, at: net_tx_action+0x754/0x970 net/core/dev.c:5297\n #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:306 [inline]\n #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:747 [inline]\n #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: qdisc_tree_reduce_backlog+0x84/0x580 net/sched/sch_api.c:792\n\nstack backtrace:\nCPU: 1 PID: 1142 Comm: udevd Not tainted 6.1.74-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024\nCall Trace:\n <TASK>\n [<ffffffff85b85f14>] __dump_stack lib/dump_stack.c:88 [inline]\n [<ffffffff85b85f14>] dump_stack_lvl+0x1b1/0x28f lib/dump_stack.c:106\n [<ffffffff85b86007>] dump_stack+0x15/0x1e lib/dump_stack.c:113\n [<ffffffff81802299>] lockdep_rcu_suspicious+0x1b9/0x260 kernel/locking/lockdep.c:6592\n [<ffffffff84f0054c>] qdisc_lookup+0xac/0x6f0 net/sched/sch_api.c:305\n [<ffffffff84f037c3>] qdisc_tree_reduce_backlog+0x243/0x580 net/sched/sch_api.c:811\n [<ffffffff84f5b78c>] pfifo_tail_enqueue+0x32c/0x4b0 net/sched/sch_fifo.c:51\n [<ffffffff84fbcf63>] qdisc_enqueue include/net/sch_generic.h:833 [inline]\n [<ffffffff84fbcf63>] netem_dequeue+0xeb3/0x15d0 net/sched/sch_netem.c:723\n [<ffffffff84eecab9>] dequeue_skb net/sched/sch_generic.c:292 [inline]\n [<ffffffff84eecab9>] qdisc_restart net/sched/sch_generic.c:397 [inline]\n [<ffffffff84eecab9>] __qdisc_run+0x249/0x1e60 net/sched/sch_generic.c:415\n [<ffffffff84d7aa96>] qdisc_run+0xd6/0x260 include/net/pkt_sched.h:125\n [<ffffffff84d85d29>] net_tx_action+0x7c9/0x970 net/core/dev.c:5313\n [<ffffffff85e002bd>] __do_softirq+0x2bd/0x9bd kernel/softirq.c:616\n [<ffffffff81568bca>] invoke_softirq kernel/softirq.c:447 [inline]\n [<ffffffff81568bca>] __irq_exit_rcu+0xca/0x230 kernel/softirq.c:700\n [<ffffffff81568ae9>] irq_exit_rcu+0x9/0x20 kernel/softirq.c:712\n [<ffffffff85b89f52>] sysvec_apic_timer_interrupt+0x42/0x90 arch/x86/kernel/apic/apic.c:1107\n [<ffffffff85c00ccb>] asm_sysvec_apic_timer_interrupt+0x1b/0x20 arch/x86/include/asm/idtentry.h:656

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: micrel: Fix potential null pointer dereference\n\nIn lan8814_get_sig_rx() and lan8814_get_sig_tx() ptp_parse_header() may\nreturn NULL as ptp_header due to abnormal packet type or corrupted packet.\nFix this bug by adding ptp_header check.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: Fix infinite recursion in fib6_dump_done().\n\nsyzkaller reported infinite recursive calls of fib6_dump_done() during\nnetlink socket destruction. [1]\n\n>From the log, syzkaller sent an AF_UNSPEC RTM_GETROUTE message, and then\nthe response was generated. The following recvmmsg() resumed the dump\nfor IPv6, but the first call of inet6_dump_fib() failed at kzalloc() due\nto the fault injection. [0]\n\n 12:01:34 executing program 3:\n r0 = socket$nl_route(0x10, 0x3, 0x0)\n sendmsg$nl_route(r0, ... snip ...)\n recvmmsg(r0, ... snip ...) (fail_nth: 8)\n\nHere, fib6_dump_done() was set to nlk_sk(sk)->cb.done, and the next call\nof inet6_dump_fib() set it to nlk_sk(sk)->cb.args[3]. syzkaller stopped\nreceiving the response halfway through, and finally netlink_sock_destruct()\ncalled nlk_sk(sk)->cb.done().\n\nfib6_dump_done() calls fib6_dump_end() and nlk_sk(sk)->cb.done() if it\nis still not NULL. fib6_dump_end() rewrites nlk_sk(sk)->cb.done() by\nnlk_sk(sk)->cb.args[3], but it has the same function, not NULL, calling\nitself recursively and hitting the stack guard page.\n\nTo avoid the issue, let's set the destructor after kzalloc().\n\n[0]:\nFAULT_INJECTION: forcing a failure.\nname failslab, interval 1, probability 0, space 0, times 0\nCPU: 1 PID: 432110 Comm: syz-executor.3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nCall Trace:\n <TASK>\n dump_stack_lvl (lib/dump_stack.c:117)\n should_fail_ex (lib/fault-inject.c:52 lib/fault-inject.c:153)\n should_failslab (mm/slub.c:3733)\n kmalloc_trace (mm/slub.c:3748 mm/slub.c:3827 mm/slub.c:3992)\n inet6_dump_fib (./include/linux/slab.h:628 ./include/linux/slab.h:749 net/ipv6/ip6_fib.c:662)\n rtnl_dump_all (net/core/rtnetlink.c:4029)\n netlink_dump (net/netlink/af_netlink.c:2269)\n netlink_recvmsg (net/netlink/af_netlink.c:1988)\n ____sys_recvmsg (net/socket.c:1046 net/socket.c:2801)\n ___sys_recvmsg (net/socket.c:2846)\n do_recvmmsg (net/socket.c:2943)\n __x64_sys_recvmmsg (net/socket.c:3041 net/socket.c:3034 net/socket.c:3034)\n\n[1]:\nBUG: TASK stack guard page was hit at 00000000f2fa9af1 (stack is 00000000b7912430..000000009a436beb)\nstack guard page: 0000 [#1] PREEMPT SMP KASAN\nCPU: 1 PID: 223719 Comm: kworker/1:3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nWorkqueue: events netlink_sock_destruct_work\nRIP: 0010:fib6_dump_done (net/ipv6/ip6_fib.c:570)\nCode: 3c 24 e8 f3 e9 51 fd e9 28 fd ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 41 57 41 56 41 55 41 54 55 48 89 fd <53> 48 8d 5d 60 e8 b6 4d 07 fd 48 89 da 48 b8 00 00 00 00 00 fc ff\nRSP: 0018:ffffc9000d980000 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: ffffffff84405990 RCX: ffffffff844059d3\nRDX: ffff8881028e0000 RSI: ffffffff84405ac2 RDI: ffff88810c02f358\nRBP: ffff88810c02f358 R08: 0000000000000007 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000224 R12: 0000000000000000\nR13: ffff888007c82c78 R14: ffff888007c82c68 R15: ffff888007c82c68\nFS: 0000000000000000(0000) GS:ffff88811b100000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffc9000d97fff8 CR3: 0000000102309002 CR4: 0000000000770ef0\nPKRU: 55555554\nCall Trace:\n <#DF>\n </#DF>\n <TASK>\n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n ...\n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n netlink_sock_destruct (net/netlink/af_netlink.c:401)\n __sk_destruct (net/core/sock.c:2177 (discriminator 2))\n sk_destruct (net/core/sock.c:2224)\n __sk_free (net/core/sock.c:2235)\n sk_free (net/core/sock.c:2246)\n process_one_work (kernel/workqueue.c:3259)\n worker_thread (kernel/workqueue.c:3329 kernel/workqueue.c:3416)\n kthread (kernel/kthread.c:388)\n ret_from_fork (arch/x86/kernel/process.c:153)\n ret_from_fork_asm (arch/x86/entry/entry_64.S:256)\nModules linked in:

In the Linux kernel, the following vulnerability has been resolved:\n\nmlxbf_gige: stop interface during shutdown\n\nThe mlxbf_gige driver intermittantly encounters a NULL pointer\nexception while the system is shutting down via "reboot" command.\nThe mlxbf_driver will experience an exception right after executing\nits shutdown() method. One example of this exception is:\n\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000070\nMem abort info:\n ESR = 0x0000000096000004\n EC = 0x25: DABT (current EL), IL = 32 bits\n SET = 0, FnV = 0\n EA = 0, S1PTW = 0\n FSC = 0x04: level 0 translation fault\nData abort info:\n ISV = 0, ISS = 0x00000004\n CM = 0, WnR = 0\nuser pgtable: 4k pages, 48-bit VAs, pgdp=000000011d373000\n[0000000000000070] pgd=0000000000000000, p4d=0000000000000000\nInternal error: Oops: 96000004 [#1] SMP\nCPU: 0 PID: 13 Comm: ksoftirqd/0 Tainted: G S OE 5.15.0-bf.6.gef6992a #1\nHardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS 4.0.2.12669 Apr 21 2023\npstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige]\nlr : mlxbf_gige_poll+0x54/0x160 [mlxbf_gige]\nsp : ffff8000080d3c10\nx29: ffff8000080d3c10 x28: ffffcce72cbb7000 x27: ffff8000080d3d58\nx26: ffff0000814e7340 x25: ffff331cd1a05000 x24: ffffcce72c4ea008\nx23: ffff0000814e4b40 x22: ffff0000814e4d10 x21: ffff0000814e4128\nx20: 0000000000000000 x19: ffff0000814e4a80 x18: ffffffffffffffff\nx17: 000000000000001c x16: ffffcce72b4553f4 x15: ffff80008805b8a7\nx14: 0000000000000000 x13: 0000000000000030 x12: 0101010101010101\nx11: 7f7f7f7f7f7f7f7f x10: c2ac898b17576267 x9 : ffffcce720fa5404\nx8 : ffff000080812138 x7 : 0000000000002e9a x6 : 0000000000000080\nx5 : ffff00008de3b000 x4 : 0000000000000000 x3 : 0000000000000001\nx2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000\nCall trace:\n mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige]\n mlxbf_gige_poll+0x54/0x160 [mlxbf_gige]\n __napi_poll+0x40/0x1c8\n net_rx_action+0x314/0x3a0\n __do_softirq+0x128/0x334\n run_ksoftirqd+0x54/0x6c\n smpboot_thread_fn+0x14c/0x190\n kthread+0x10c/0x110\n ret_from_fork+0x10/0x20\nCode: 8b070000 f9000ea0 f95056c0 f86178a1 (b9407002)\n---[ end trace 7cc3941aa0d8e6a4 ]---\nKernel panic - not syncing: Oops: Fatal exception in interrupt\nKernel Offset: 0x4ce722520000 from 0xffff800008000000\nPHYS_OFFSET: 0x80000000\nCPU features: 0x000005c1,a3330e5a\nMemory Limit: none\n---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---\n\nDuring system shutdown, the mlxbf_gige driver's shutdown() is always executed.\nHowever, the driver's stop() method will only execute if networking interface\nconfiguration logic within the Linux distribution has been setup to do so.\n\nIf shutdown() executes but stop() does not execute, NAPI remains enabled\nand this can lead to an exception if NAPI is scheduled while the hardware\ninterface has only been partially deinitialized.\n\nThe networking interface managed by the mlxbf_gige driver must be properly\nstopped during system shutdown so that IFF_UP is cleared, the hardware\ninterface is put into a clean state, and NAPI is fully deinitialized.

In the Linux kernel, the following vulnerability has been resolved:\n\nspi: mchp-pci1xxx: Fix a possible null pointer dereference in pci1xxx_spi_probe\n\nIn function pci1xxxx_spi_probe, there is a potential null pointer that\nmay be caused by a failed memory allocation by the function devm_kzalloc.\nHence, a null pointer check needs to be added to prevent null pointer\ndereferencing later in the code.\n\nTo fix this issue, spi_bus->spi_int[iter] should be checked. The memory\nallocated by devm_kzalloc will be automatically released, so just directly\nreturn -ENOMEM without worrying about memory leaks.

In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/kbuf: hold io_buffer_list reference over mmap\n\nIf we look up the kbuf, ensure that it doesn't get unregistered until\nafter we're done with it. Since we're inside mmap, we cannot safely use\nthe io_uring lock. Rely on the fact that we can lookup the buffer list\nunder RCU now and grab a reference to it, preventing it from being\nunregistered until we're done with it. The lookup returns the\nio_buffer_list directly with it referenced.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm/secretmem: fix GUP-fast succeeding on secretmem folios\n\nfolio_is_secretmem() currently relies on secretmem folios being LRU\nfolios, to save some cycles.\n\nHowever, folios might reside in a folio batch without the LRU flag set, or\ntemporarily have their LRU flag cleared. Consequently, the LRU flag is\nunreliable for this purpose.\n\nIn particular, this is the case when secretmem_fault() allocates a fresh\npage and calls filemap_add_folio()->folio_add_lru(). The folio might be\nadded to the per-cpu folio batch and won't get the LRU flag set until the\nbatch was drained using e.g., lru_add_drain().\n\nConsequently, folio_is_secretmem() might not detect secretmem folios and\nGUP-fast can succeed in grabbing a secretmem folio, crashing the kernel\nwhen we would later try reading/writing to the folio, because the folio\nhas been unmapped from the directmap.\n\nFix it by removing that unreliable check.

In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: guarantee refcounted children from parent session\n\nAvoid potential use-after-free bugs when walking DFS referrals,\nmounting and performing DFS failover by ensuring that all children\nfrom parent @tcon->ses are also refcounted. They're all needed across\nthe entire DFS mount. Get rid of @tcon->dfs_ses_list while we're at\nit, too.

In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix potential UAF in cifs_dump_full_key()\n\nSkip sessions that are being teared down (status == SES_EXITING) to\navoid UAF.

In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix potential UAF in smb2_is_valid_oplock_break()\n\nSkip sessions that are being teared down (status == SES_EXITING) to\navoid UAF.

In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix potential UAF in smb2_is_valid_lease_break()\n\nSkip sessions that are being teared down (status == SES_EXITING) to\navoid UAF.

In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix potential UAF in is_valid_oplock_break()\n\nSkip sessions that are being teared down (status == SES_EXITING) to\navoid UAF.

In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix potential UAF in smb2_is_network_name_deleted()\n\nSkip sessions that are being teared down (status == SES_EXITING) to\navoid UAF.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: tls, fix WARNIING in __sk_msg_free\n\nA splice with MSG_SPLICE_PAGES will cause tls code to use the\ntls_sw_sendmsg_splice path in the TLS sendmsg code to move the user\nprovided pages from the msg into the msg_pl. This will loop over the\nmsg until msg_pl is full, checked by sk_msg_full(msg_pl). The user\ncan also set the MORE flag to hint stack to delay sending until receiving\nmore pages and ideally a full buffer.\n\nIf the user adds more pages to the msg than can fit in the msg_pl\nscatterlist (MAX_MSG_FRAGS) we should ignore the MORE flag and send\nthe buffer anyways.\n\nWhat actually happens though is we abort the msg to msg_pl scatterlist\nsetup and then because we forget to set 'full record' indicating we\ncan no longer consume data without a send we fallthrough to the 'continue'\npath which will check if msg_data_left(msg) has more bytes to send and\nthen attempts to fit them in the already full msg_pl. Then next\niteration of sender doing send will encounter a full msg_pl and throw\nthe warning in the syzbot report.\n\nTo fix simply check if we have a full_record in splice code path and\nif not send the msg regardless of MORE flag.

In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Mark target gfn of emulated atomic instruction as dirty\n\nWhen emulating an atomic access on behalf of the guest, mark the target\ngfn dirty if the CMPXCHG by KVM is attempted and doesn't fault. This\nfixes a bug where KVM effectively corrupts guest memory during live\nmigration by writing to guest memory without informing userspace that the\npage is dirty.\n\nMarking the page dirty got unintentionally dropped when KVM's emulated\nCMPXCHG was converted to do a user access. Before that, KVM explicitly\nmapped the guest page into kernel memory, and marked the page dirty during\nthe unmap phase.\n\nMark the page dirty even if the CMPXCHG fails, as the old data is written\nback on failure, i.e. the page is still written. The value written is\nguaranteed to be the same because the operation is atomic, but KVM's ABI\nis that all writes are dirty logged regardless of the value written. And\nmore importantly, that's what KVM did before the buggy commit.\n\nHuge kudos to the folks on the Cc list (and many others), who did all the\nactual work of triaging and debugging.\n\nbase-commit: 6769ea8da8a93ed4630f1ce64df6aafcaabfce64

In the Linux kernel, the following vulnerability has been resolved:\n\nefi: fix panic in kdump kernel\n\nCheck if get_next_variable() is actually valid pointer before\ncalling it. In kdump kernel this method is set to NULL that causes\npanic during the kexec-ed kernel boot.\n\nTested with QEMU and OVMF firmware.

In the Linux kernel, the following vulnerability has been resolved:\n\ndma-mapping: benchmark: fix node id validation\n\nWhile validating node ids in map_benchmark_ioctl(), node_possible() may\nbe provided with invalid argument outside of [0,MAX_NUMNODES-1] range\nleading to:\n\nBUG: KASAN: wild-memory-access in map_benchmark_ioctl (kernel/dma/map_benchmark.c:214)\nRead of size 8 at addr 1fffffff8ccb6398 by task dma_map_benchma/971\nCPU: 7 PID: 971 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #37\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996)\nCall Trace:\n <TASK>\ndump_stack_lvl (lib/dump_stack.c:117)\nkasan_report (mm/kasan/report.c:603)\nkasan_check_range (mm/kasan/generic.c:189)\nvariable_test_bit (arch/x86/include/asm/bitops.h:227) [inline]\narch_test_bit (arch/x86/include/asm/bitops.h:239) [inline]\n_test_bit at (include/asm-generic/bitops/instrumented-non-atomic.h:142) [inline]\nnode_state (include/linux/nodemask.h:423) [inline]\nmap_benchmark_ioctl (kernel/dma/map_benchmark.c:214)\nfull_proxy_unlocked_ioctl (fs/debugfs/file.c:333)\n__x64_sys_ioctl (fs/ioctl.c:890)\ndo_syscall_64 (arch/x86/entry/common.c:83)\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n\nCompare node ids with sane bounds first. NUMA_NO_NODE is considered a\nspecial valid case meaning that benchmarking kthreads won't be bound to a\ncpuset of a given node.\n\nFound by Linux Verification Center (linuxtesting.org).

In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: of_property: Return error for int_map allocation failure\n\nReturn -ENOMEM from of_pci_prop_intr_map() if kcalloc() fails to prevent a\nNULL pointer dereference in this case.\n\n[bhelgaas: commit log]

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: ti: j721e-csi2rx: Fix races while restarting DMA\n\nAfter the frame is submitted to DMA, it may happen that the submitted\nlist is not updated soon enough, and the DMA callback is triggered\nbefore that.\n\nThis can lead to kernel crashes, so move everything in a single\nlock/unlock section to prevent such races.

In the Linux kernel, the following vulnerability has been resolved:\n\nclk: mediatek: mt7622-apmixedsys: Fix an error handling path in clk_mt8135_apmixed_probe()\n\n'clk_data' is allocated with mtk_devm_alloc_clk_data(). So calling\nmtk_free_clk_data() explicitly in the remove function would lead to a\ndouble-free.\n\nRemove the redundant call.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ethernet: mtk_eth_soc: fix PPE hanging issue\n\nA patch to resolve an issue was found in MediaTek's GPL-licensed SDK:\nIn the mtk_ppe_stop() function, the PPE scan mode is not disabled before\ndisabling the PPE. This can potentially lead to a hang during the process\nof disabling the PPE.\n\nWithout this patch, the PPE may experience a hang during the reboot test.

In the Linux kernel, the following vulnerability has been resolved:\n\nrtnetlink: fix error logic of IFLA_BRIDGE_FLAGS writing back\n\nIn the commit d73ef2d69c0d ("rtnetlink: let rtnl_bridge_setlink checks\nIFLA_BRIDGE_MODE length"), an adjustment was made to the old loop logic\nin the function `rtnl_bridge_setlink` to enable the loop to also check\nthe length of the IFLA_BRIDGE_MODE attribute. However, this adjustment\nremoved the `break` statement and led to an error logic of the flags\nwriting back at the end of this function.\n\nif (have_flags)\n memcpy(nla_data(attr), &flags, sizeof(flags));\n // attr should point to IFLA_BRIDGE_FLAGS NLA !!!\n\nBefore the mentioned commit, the `attr` is granted to be IFLA_BRIDGE_FLAGS.\nHowever, this is not necessarily true fow now as the updated loop will let\nthe attr point to the last NLA, even an invalid NLA which could cause\noverflow writes.\n\nThis patch introduces a new variable `br_flag` to save the NLA pointer\nthat points to IFLA_BRIDGE_FLAGS and uses it to resolve the mentioned\nerror logic.

In the Linux kernel, the following vulnerability has been resolved:\n\nxen-netfront: Add missing skb_mark_for_recycle\n\nNotice that skb_mark_for_recycle() is introduced later than fixes tag in\ncommit 6a5bcd84e886 ("page_pool: Allow drivers to hint on SKB recycling").\n\nIt is believed that fixes tag were missing a call to page_pool_release_page()\nbetween v5.9 to v5.14, after which is should have used skb_mark_for_recycle().\nSince v6.6 the call page_pool_release_page() were removed (in\ncommit 535b9c61bdef ("net: page_pool: hide page_pool_release_page()")\nand remaining callers converted (in commit 6bfef2ec0172 ("Merge branch\n'net-page_pool-remove-page_pool_release_page'")).\n\nThis leak became visible in v6.8 via commit dba1b8a7ab68 ("mm/page_pool: catch\npage_pool memory leaks").

In the Linux kernel, the following vulnerability has been resolved:\n\nxen/evtchn: avoid WARN() when unbinding an event channel\n\nWhen unbinding a user event channel, the related handler might be\ncalled a last time in case the kernel was built with\nCONFIG_DEBUG_SHIRQ. This might cause a WARN() in the handler.\n\nAvoid that by adding an "unbinding" flag to struct user_event which\nwill short circuit the handler.

In the Linux kernel, the following vulnerability has been resolved:\n\nnouveau: lock the client object tree.\n\nIt appears the client object tree has no locking unless I've missed\nsomething else. Fix races around adding/removing client objects,\nmostly vram bar mappings.\n\n 4562.099306] general protection fault, probably for non-canonical address 0x6677ed422bceb80c: 0000 [#1] PREEMPT SMP PTI\n[ 4562.099314] CPU: 2 PID: 23171 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27\n[ 4562.099324] Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021\n[ 4562.099330] RIP: 0010:nvkm_object_search+0x1d/0x70 [nouveau]\n[ 4562.099503] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 48 89 f8 48 85 f6 74 39 48 8b 87 a0 00 00 00 48 85 c0 74 12 <48> 8b 48 f8 48 39 ce 73 15 48 8b 40 10 48 85 c0 75 ee 48 c7 c0 fe\n[ 4562.099506] RSP: 0000:ffffa94cc420bbf8 EFLAGS: 00010206\n[ 4562.099512] RAX: 6677ed422bceb814 RBX: ffff98108791f400 RCX: ffff9810f26b8f58\n[ 4562.099517] RDX: 0000000000000000 RSI: ffff9810f26b9158 RDI: ffff98108791f400\n[ 4562.099519] RBP: ffff9810f26b9158 R08: 0000000000000000 R09: 0000000000000000\n[ 4562.099521] R10: ffffa94cc420bc48 R11: 0000000000000001 R12: ffff9810f02a7cc0\n[ 4562.099526] R13: 0000000000000000 R14: 00000000000000ff R15: 0000000000000007\n[ 4562.099528] FS: 00007f629c5017c0(0000) GS:ffff98142c700000(0000) knlGS:0000000000000000\n[ 4562.099534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 4562.099536] CR2: 00007f629a882000 CR3: 000000017019e004 CR4: 00000000003706f0\n[ 4562.099541] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 4562.099542] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 4562.099544] Call Trace:\n[ 4562.099555] <TASK>\n[ 4562.099573] ? die_addr+0x36/0x90\n[ 4562.099583] ? exc_general_protection+0x246/0x4a0\n[ 4562.099593] ? asm_exc_general_protection+0x26/0x30\n[ 4562.099600] ? nvkm_object_search+0x1d/0x70 [nouveau]\n[ 4562.099730] nvkm_ioctl+0xa1/0x250 [nouveau]\n[ 4562.099861] nvif_object_map_handle+0xc8/0x180 [nouveau]\n[ 4562.099986] nouveau_ttm_io_mem_reserve+0x122/0x270 [nouveau]\n[ 4562.100156] ? dma_resv_test_signaled+0x26/0xb0\n[ 4562.100163] ttm_bo_vm_fault_reserved+0x97/0x3c0 [ttm]\n[ 4562.100182] ? __mutex_unlock_slowpath+0x2a/0x270\n[ 4562.100189] nouveau_ttm_fault+0x69/0xb0 [nouveau]\n[ 4562.100356] __do_fault+0x32/0x150\n[ 4562.100362] do_fault+0x7c/0x560\n[ 4562.100369] __handle_mm_fault+0x800/0xc10\n[ 4562.100382] handle_mm_fault+0x17c/0x3e0\n[ 4562.100388] do_user_addr_fault+0x208/0x860\n[ 4562.100395] exc_page_fault+0x7f/0x200\n[ 4562.100402] asm_exc_page_fault+0x26/0x30\n[ 4562.100412] RIP: 0033:0x9b9870\n[ 4562.100419] Code: 85 a8 f7 ff ff 8b 8d 80 f7 ff ff 89 08 e9 18 f2 ff ff 0f 1f 84 00 00 00 00 00 44 89 32 e9 90 fa ff ff 0f 1f 84 00 00 00 00 00 <44> 89 32 e9 f8 f1 ff ff 0f 1f 84 00 00 00 00 00 66 44 89 32 e9 e7\n[ 4562.100422] RSP: 002b:00007fff9ba2dc70 EFLAGS: 00010246\n[ 4562.100426] RAX: 0000000000000004 RBX: 000000000dd65e10 RCX: 000000fff0000000\n[ 4562.100428] RDX: 00007f629a882000 RSI: 00007f629a882000 RDI: 0000000000000066\n[ 4562.100432] RBP: 00007fff9ba2e570 R08: 0000000000000000 R09: 0000000123ddf000\n[ 4562.100434] R10: 0000000000000001 R11: 0000000000000246 R12: 000000007fffffff\n[ 4562.100436] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n[ 4562.100446] </TASK>\n[ 4562.100448] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink cmac bnep sunrpc iwlmvm intel_rapl_msr intel_rapl_common snd_sof_pci_intel_cnl x86_pkg_temp_thermal intel_powerclamp snd_sof_intel_hda_common mac80211 coretemp snd_soc_acpi_intel_match kvm_intel snd_soc_acpi snd_soc_hdac_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof_intel_hda_mlink snd_sof_intel_hda snd_sof kvm snd_sof_utils snd_soc_core snd_hda_codec_realtek libarc4 snd_hda_codec_generic snd_compress snd_hda_ext_core vfat fat snd_hda_intel snd_intel_dspcfg irqbypass iwlwifi snd_hda_codec snd_hwdep snd_hda_core btusb btrtl mei_hdcp iTCO_wdt rapl mei_pxp btintel snd_seq iTCO_vendor_support btbcm snd_seq_device intel_cstate bluetooth snd_pcm cfg80211 intel_wmi_thunderbolt wmi_bmof intel_uncore snd_timer mei_me snd ecdh_generic i2c_i801\n[ 4562.100541] ecc mei i2c_smbus soundcore rfkill intel_pch_thermal acpi_pad zram nouveau drm_ttm_helper ttm gpu_sched i2c_algo_bit drm_gpuvm drm_exec mxm_wmi drm_display_helper drm_kms_helper drm crct10dif_pclmul crc32_pclmul nvme e1000e crc32c_intel nvme_core ghash_clmulni_intel video wmi pinctrl_cannonlake ip6_tables ip_tables fuse\n[ 4562.100616] ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:\n\nclk: hisilicon: hi3559a: Fix an erroneous devm_kfree()\n\n'p_clk' is an array allocated just before the for loop for all clk that\nneed to be registered.\nIt is incremented at each loop iteration.\n\nIf a clk_register() call fails, 'p_clk' may point to something different\nfrom what should be freed.\n\nThe best we can do, is to avoid this wrong release of memory.

In the Linux kernel, the following vulnerability has been resolved:\n\nclk: Fix clk_core_get NULL dereference\n\nIt is possible for clk_core_get to dereference a NULL in the following\nsequence:\n\nclk_core_get()\n of_clk_get_hw_from_clkspec()\n __of_clk_get_hw_from_provider()\n __clk_get_hw()\n\n__clk_get_hw() can return NULL which is dereferenced by clk_core_get() at\nhw->core.\n\nPrior to commit dde4eff47c82 ("clk: Look for parents with clkdev based\nclk_lookups") the check IS_ERR_OR_NULL() was performed which would have\ncaught the NULL.\n\nReading the description of this function it talks about returning NULL but\nthat cannot be so at the moment.\n\nUpdate the function to check for hw before dereferencing it and return NULL\nif hw is NULL.

In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Fix writeback data corruption\n\ncifs writeback doesn't correctly handle the case where\ncifs_extend_writeback() hits a point where it is considering an additional\nfolio, but this would overrun the wsize - at which point it drops out of\nthe xarray scanning loop and calls xas_pause(). The problem is that\nxas_pause() advances the loop counter - thereby skipping that page.\n\nWhat needs to happen is for xas_reset() to be called any time we decide we\ndon't want to process the page we're looking at, but rather send the\nrequest we are building and start a new one.\n\nFix this by copying and adapting the netfslib writepages code as a\ntemporary measure, with cifs writeback intending to be offloaded to\nnetfslib in the near future.\n\nThis also fixes the issue with the use of filemap_get_folios_tag() causing\nretry of a bunch of pages which the extender already dealt with.\n\nThis can be tested by creating, say, a 64K file somewhere not on cifs\n(otherwise copy-offload may get underfoot), mounting a cifs share with a\nwsize of 64000, copying the file to it and then comparing the original file\nand the copy:\n\n dd if=/dev/urandom of=/tmp/64K bs=64k count=1\n mount //192.168.6.1/test /mnt -o user=...,pass=...,wsize=64000\n cp /tmp/64K /mnt/64K\n cmp /tmp/64K /mnt/64K\n\nWithout the fix, the cmp fails at position 64000 (or shortly thereafter).

In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: compress: fix to guarantee persisting compressed blocks by CP\n\nIf data block in compressed cluster is not persisted with metadata\nduring checkpoint, after SPOR, the data may be corrupted, let's\nguarantee to write compressed page by checkpoint.

In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: compress: fix to cover normal cluster write with cp_rwsem\n\nWhen we overwrite compressed cluster w/ normal cluster, we should\nnot unlock cp_rwsem during f2fs_write_raw_pages(), otherwise data\nwill be corrupted if partial blocks were persisted before CP & SPOR,\ndue to cluster metadata wasn't updated atomically.

In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to remove unnecessary f2fs_bug_on() to avoid panic\n\nverify_blkaddr() will trigger panic once we inject fault into\nf2fs_is_valid_blkaddr(), fix to remove this unnecessary f2fs_bug_on().

In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to avoid potential panic during recovery\n\nDuring recovery, if FAULT_BLOCK is on, it is possible that\nf2fs_reserve_new_block() will return -ENOSPC during recovery,\nthen it may trigger panic.\n\nAlso, if fault injection rate is 1 and only FAULT_BLOCK fault\ntype is on, it may encounter deadloop in loop of block reservation.\n\nLet's change as below to fix these issues:\n- remove bug_on() to avoid panic.\n- limit the loop count of block reservation to avoid potential\ndeadloop.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: fix mmhub client id out-of-bounds access\n\nProperly handle cid 0x140.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: br_netfilter: skip conntrack input hook for promisc packets\n\nFor historical reasons, when bridge device is in promisc mode, packets\nthat are directed to the taps follow bridge input hook path. This patch\nadds a workaround to reset conntrack for these packets.\n\nJianbo Liu reports warning splats in their test infrastructure where\ncloned packets reach the br_netfilter input hook to confirm the\nconntrack object.\n\nScratch one bit from BR_INPUT_SKB_CB to annotate that this packet has\nreached the input hook because it is passed up to the bridge device to\nreach the taps.\n\n[ 57.571874] WARNING: CPU: 1 PID: 0 at net/bridge/br_netfilter_hooks.c:616 br_nf_local_in+0x157/0x180 [br_netfilter]\n[ 57.572749] Modules linked in: xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat xt_addrtype xt_conntrack nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_isc si ib_umad rdma_cm ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core mlx5ctl mlx5_core\n[ 57.575158] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0+ #19\n[ 57.575700] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n[ 57.576662] RIP: 0010:br_nf_local_in+0x157/0x180 [br_netfilter]\n[ 57.577195] Code: fe ff ff 41 bd 04 00 00 00 be 04 00 00 00 e9 4a ff ff ff be 04 00 00 00 48 89 ef e8 f3 a9 3c e1 66 83 ad b4 00 00 00 04 eb 91 <0f> 0b e9 f1 fe ff ff 0f 0b e9 df fe ff ff 48 89 df e8 b3 53 47 e1\n[ 57.578722] RSP: 0018:ffff88885f845a08 EFLAGS: 00010202\n[ 57.579207] RAX: 0000000000000002 RBX: ffff88812dfe8000 RCX: 0000000000000000\n[ 57.579830] RDX: ffff88885f845a60 RSI: ffff8881022dc300 RDI: 0000000000000000\n[ 57.580454] RBP: ffff88885f845a60 R08: 0000000000000001 R09: 0000000000000003\n[ 57.581076] R10: 00000000ffff1300 R11: 0000000000000002 R12: 0000000000000000\n[ 57.581695] R13: ffff8881047ffe00 R14: ffff888108dbee00 R15: ffff88814519b800\n[ 57.582313] FS: 0000000000000000(0000) GS:ffff88885f840000(0000) knlGS:0000000000000000\n[ 57.583040] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 57.583564] CR2: 000000c4206aa000 CR3: 0000000103847001 CR4: 0000000000370eb0\n[ 57.584194] DR0: 0000000000000000 DR1: 0000000000000000 DR2:\n0000000000000000\n[ 57.584820] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:\n0000000000000400\n[ 57.585440] Call Trace:\n[ 57.585721] <IRQ>\n[ 57.585976] ? __warn+0x7d/0x130\n[ 57.586323] ? br_nf_local_in+0x157/0x180 [br_netfilter]\n[ 57.586811] ? report_bug+0xf1/0x1c0\n[ 57.587177] ? handle_bug+0x3f/0x70\n[ 57.587539] ? exc_invalid_op+0x13/0x60\n[ 57.587929] ? asm_exc_invalid_op+0x16/0x20\n[ 57.588336] ? br_nf_local_in+0x157/0x180 [br_netfilter]\n[ 57.588825] nf_hook_slow+0x3d/0xd0\n[ 57.589188] ? br_handle_vlan+0x4b/0x110\n[ 57.589579] br_pass_frame_up+0xfc/0x150\n[ 57.589970] ? br_port_flags_change+0x40/0x40\n[ 57.590396] br_handle_frame_finish+0x346/0x5e0\n[ 57.590837] ? ipt_do_table+0x32e/0x430\n[ 57.591221] ? br_handle_local_finish+0x20/0x20\n[ 57.591656] br_nf_hook_thresh+0x4b/0xf0 [br_netfilter]\n[ 57.592286] ? br_handle_local_finish+0x20/0x20\n[ 57.592802] br_nf_pre_routing_finish+0x178/0x480 [br_netfilter]\n[ 57.593348] ? br_handle_local_finish+0x20/0x20\n[ 57.593782] ? nf_nat_ipv4_pre_routing+0x25/0x60 [nf_nat]\n[ 57.594279] br_nf_pre_routing+0x24c/0x550 [br_netfilter]\n[ 57.594780] ? br_nf_hook_thresh+0xf0/0xf0 [br_netfilter]\n[ 57.595280] br_handle_frame+0x1f3/0x3d0\n[ 57.595676] ? br_handle_local_finish+0x20/0x20\n[ 57.596118] ? br_handle_frame_finish+0x5e0/0x5e0\n[ 57.596566] __netif_receive_skb_core+0x25b/0xfc0\n[ 57.597017] ? __napi_build_skb+0x37/0x40\n[ 57.597418] __netif_receive_skb_list_core+0xfb/0x220

In the Linux kernel, the following vulnerability has been resolved:\n\ns390/cio: fix race condition during online processing\n\nA race condition exists in ccw_device_set_online() that can cause the\nonline process to fail, leaving the affected device in an inconsistent\nstate. As a result, subsequent attempts to set that device online fail\nwith return code ENODEV.\n\nThe problem occurs when a path verification request arrives after\na wait for final device state completed, but before the result state\nis evaluated.\n\nFix this by ensuring that the CCW-device lock is held between\ndetermining final state and checking result state.\n\nNote that since:\n\ncommit 2297791c92d0 ("s390/cio: dont unregister subchannel from child-drivers")\n\npath verification requests are much more likely to occur during boot,\nresulting in an increased chance of this race condition occurring.

In the Linux kernel, the following vulnerability has been resolved:\n\nuserfaultfd: change src_folio after ensuring it's unpinned in UFFDIO_MOVE\n\nCommit d7a08838ab74 ("mm: userfaultfd: fix unexpected change to src_folio\nwhen UFFDIO_MOVE fails") moved the src_folio->{mapping, index} changing to\nafter clearing the page-table and ensuring that it's not pinned. This\navoids failure of swapout+migration and possibly memory corruption.\n\nHowever, the commit missed fixing it in the huge-page case.

In the Linux kernel, the following vulnerability has been resolved:\n\nclk: qcom: gcc-ipq5018: fix terminating of frequency table arrays\n\nThe frequency table arrays are supposed to be terminated with an\nempty element. Add such entry to the end of the arrays where it\nis missing in order to avoid possible out-of-bound access when\nthe table is traversed by functions like qcom_find_freq() or\nqcom_find_freq_floor().

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: btnxpuart: Fix btnxpuart_close\n\nFix scheduling while atomic BUG in btnxpuart_close(), properly\npurge the transmit queue and free the receive skb.\n\n[ 10.973809] BUG: scheduling while atomic: kworker/u9:0/80/0x00000002\n...\n[ 10.980740] CPU: 3 PID: 80 Comm: kworker/u9:0 Not tainted 6.8.0-rc7-0.0.0-devel-00005-g61fdfceacf09 #1\n[ 10.980751] Hardware name: Toradex Verdin AM62 WB on Dahlia Board (DT)\n[ 10.980760] Workqueue: hci0 hci_power_off [bluetooth]\n[ 10.981169] Call trace:\n...\n[ 10.981363] uart_update_mctrl+0x58/0x78\n[ 10.981373] uart_dtr_rts+0x104/0x114\n[ 10.981381] tty_port_shutdown+0xd4/0xdc\n[ 10.981396] tty_port_close+0x40/0xbc\n[ 10.981407] uart_close+0x34/0x9c\n[ 10.981414] ttyport_close+0x50/0x94\n[ 10.981430] serdev_device_close+0x40/0x50\n[ 10.981442] btnxpuart_close+0x24/0x98 [btnxpuart]\n[ 10.981469] hci_dev_close_sync+0x2d8/0x718 [bluetooth]\n[ 10.981728] hci_dev_do_close+0x2c/0x70 [bluetooth]\n[ 10.981862] hci_power_off+0x20/0x64 [bluetooth]

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu/pm: Fix NULL pointer dereference when get power limit\n\nBecause powerplay_table initialization is skipped under\nsriov case, We check and set default lower and upper OD\nvalue if powerplay_table is NULL.

In the Linux kernel, the following vulnerability has been resolved:\n\nARM: 9359/1: flush: check if the folio is reserved for no-mapping addresses\n\nSince commit a4d5613c4dc6 ("arm: extend pfn_valid to take into account\nfreed memory map alignment") changes the semantics of pfn_valid() to check\npresence of the memory map for a PFN. A valid page for an address which\nis reserved but not mapped by the kernel[1], the system crashed during\nsome uio test with the following memory layout:\n\n node 0: [mem 0x00000000c0a00000-0x00000000cc8fffff]\n node 0: [mem 0x00000000d0000000-0x00000000da1fffff]\n the uio layout is：0xc0900000, 0x100000\n\nthe crash backtrace like:\n\n Unable to handle kernel paging request at virtual address bff00000\n [...]\n CPU: 1 PID: 465 Comm: startapp.bin Tainted: G O 5.10.0 #1\n Hardware name: Generic DT based system\n PC is at b15_flush_kern_dcache_area+0x24/0x3c\n LR is at __sync_icache_dcache+0x6c/0x98\n [...]\n (b15_flush_kern_dcache_area) from (__sync_icache_dcache+0x6c/0x98)\n (__sync_icache_dcache) from (set_pte_at+0x28/0x54)\n (set_pte_at) from (remap_pfn_range+0x1a0/0x274)\n (remap_pfn_range) from (uio_mmap+0x184/0x1b8 [uio])\n (uio_mmap [uio]) from (__mmap_region+0x264/0x5f4)\n (__mmap_region) from (__do_mmap_mm+0x3ec/0x440)\n (__do_mmap_mm) from (do_mmap+0x50/0x58)\n (do_mmap) from (vm_mmap_pgoff+0xfc/0x188)\n (vm_mmap_pgoff) from (ksys_mmap_pgoff+0xac/0xc4)\n (ksys_mmap_pgoff) from (ret_fast_syscall+0x0/0x5c)\n Code: e0801001 e2423001 e1c00003 f57ff04f (ee070f3e)\n ---[ end trace 09cf0734c3805d52 ]---\n Kernel panic - not syncing: Fatal exception\n\nSo check if PG_reserved was set to solve this issue.\n\n[1]: https://lore.kernel.org/lkml/Zbtdue57RO0QScJM@linux.ibm.com/

In the Linux kernel, the following vulnerability has been resolved:\n\nkprobes/x86: Use copy_from_kernel_nofault() to read from unsafe address\n\nRead from an unsafe address with copy_from_kernel_nofault() in\narch_adjust_kprobe_addr() because this function is used before checking\nthe address is in text or not. Syzcaller bot found a bug and reported\nthe case if user specifies inaccessible data area,\narch_adjust_kprobe_addr() will cause a kernel panic.\n\n[ mingo: Clarified the comment. ]

In the Linux kernel, the following vulnerability has been resolved:\n\nnouveau/dmem: handle kcalloc() allocation failure\n\nThe kcalloc() in nouveau_dmem_evict_chunk() will return null if\nthe physical memory has run out. As a result, if we dereference\nsrc_pfns, dst_pfns or dma_addrs, the null pointer dereference bugs\nwill happen.\n\nMoreover, the GPU is going away. If the kcalloc() fails, we could not\nevict all pages mapping a chunk. So this patch adds a __GFP_NOFAIL\nflag in kcalloc().\n\nFinally, as there is no need to have physically contiguous memory,\nthis patch switches kcalloc() to kvcalloc() in order to avoid\nfailing allocations.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/dp: Fix divide-by-zero regression on DP MST unplug with nouveau\n\nFix a regression when using nouveau and unplugging a StarTech MSTDP122DP\nDisplayPort 1.2 MST hub (the same regression does not appear when using\na Cable Matters DisplayPort 1.4 MST hub). Trace:\n\n divide error: 0000 [#1] PREEMPT SMP PTI\n CPU: 7 PID: 2962 Comm: Xorg Not tainted 6.8.0-rc3+ #744\n Hardware name: Razer Blade/DANA_MB, BIOS 01.01 08/31/2018\n RIP: 0010:drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]\n Code: c6 b8 01 00 00 00 75 61 01 c6 41 0f af f3 41 0f af f1 c1 e1 04 48 63 c7 31 d2 89 ff 48 8b 5d f8 c9 48 0f af f1 48 8d 44 06 ff <48> f7 f7 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 45 31\n RSP: 0018:ffffb2c5c211fa30 EFLAGS: 00010206\n RAX: ffffffffffffffff RBX: 0000000000000000 RCX: 0000000000f59b00\n RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\n RBP: ffffb2c5c211fa48 R08: 0000000000000001 R09: 0000000000000020\n R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000023b4a\n R13: ffff91d37d165800 R14: ffff91d36fac6d80 R15: ffff91d34a764010\n FS: 00007f4a1ca3fa80(0000) GS:ffff91d6edbc0000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000559491d49000 CR3: 000000011d180002 CR4: 00000000003706f0\n Call Trace:\n <TASK>\n ? show_regs+0x6d/0x80\n ? die+0x37/0xa0\n ? do_trap+0xd4/0xf0\n ? do_error_trap+0x71/0xb0\n ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]\n ? exc_divide_error+0x3a/0x70\n ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]\n ? asm_exc_divide_error+0x1b/0x20\n ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]\n ? drm_dp_calc_pbn_mode+0x2e/0x70 [drm_display_helper]\n nv50_msto_atomic_check+0xda/0x120 [nouveau]\n drm_atomic_helper_check_modeset+0xa87/0xdf0 [drm_kms_helper]\n drm_atomic_helper_check+0x19/0xa0 [drm_kms_helper]\n nv50_disp_atomic_check+0x13f/0x2f0 [nouveau]\n drm_atomic_check_only+0x668/0xb20 [drm]\n ? drm_connector_list_iter_next+0x86/0xc0 [drm]\n drm_atomic_commit+0x58/0xd0 [drm]\n ? __pfx___drm_printfn_info+0x10/0x10 [drm]\n drm_atomic_connector_commit_dpms+0xd7/0x100 [drm]\n drm_mode_obj_set_property_ioctl+0x1c5/0x450 [drm]\n ? __pfx_drm_connector_property_set_ioctl+0x10/0x10 [drm]\n drm_connector_property_set_ioctl+0x3b/0x60 [drm]\n drm_ioctl_kernel+0xb9/0x120 [drm]\n drm_ioctl+0x2d0/0x550 [drm]\n ? __pfx_drm_connector_property_set_ioctl+0x10/0x10 [drm]\n nouveau_drm_ioctl+0x61/0xc0 [nouveau]\n __x64_sys_ioctl+0xa0/0xf0\n do_syscall_64+0x76/0x140\n ? do_syscall_64+0x85/0x140\n ? do_syscall_64+0x85/0x140\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\n RIP: 0033:0x7f4a1cd1a94f\n Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 ff ff 77 1f 48 8b 44 24 18 64 48 2b 04 25 28 00\n RSP: 002b:00007ffd2f1df520 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\n RAX: ffffffffffffffda RBX: 00007ffd2f1df5b0 RCX: 00007f4a1cd1a94f\n RDX: 00007ffd2f1df5b0 RSI: 00000000c01064ab RDI: 000000000000000f\n RBP: 00000000c01064ab R08: 000056347932deb8 R09: 000056347a7d99c0\n R10: 0000000000000000 R11: 0000000000000246 R12: 000056347938a220\n R13: 000000000000000f R14: 0000563479d9f3f0 R15: 0000000000000000\n </TASK>\n Modules linked in: rfcomm xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat nf_tables nfnetlink br_netfilter bridge stp llc ccm cmac algif_hash overlay algif_skcipher af_alg bnep binfmt_misc snd_sof_pci_intel_cnl snd_sof_intel_hda_common snd_soc_hdac_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof_intel_hda snd_sof snd_sof_utils snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core snd_compress snd_sof_intel_hda_mlink snd_hda_ext_core iwlmvm intel_rapl_msr intel_rapl_common intel_tcc_cooling x86_pkg_temp_thermal intel_powerclamp mac80211 coretemp kvm_intel snd_hda_codec_hdmi kvm snd_hda_codec_realtek snd_hda_codec_generic uvcvideo libarc4 snd_hda_intel snd_intel_dspcfg snd_hda_codec iwlwifi videobuf2_vmalloc videobuf2_memops uvc irqbypass btusb videobuf2_v4l2 snd_seq_midi crct10dif_pclmul hid_multitouch crc32_pclmul snd_seq_midi_event btrtl snd_hwdep videodev polyval_clmulni polyval_generic snd_rawmidi\n ghash_clmulni_intel aesni_intel btintel crypto_simd snd_hda_core cryptd snd_seq btbcm ee1004 8250_dw videobuf2_common btmtk rapl nls_iso8859_1 mei_hdcp thunderbolt bluetooth intel_cstate wmi_bmof intel_wmi_thunderbolt cfg80211 snd_pcm mc snd_seq_device i2c_i801 r8169 ecdh_generic snd_timer i2c_smbus ecc snd mei_me intel_lpss_pci mei ahci intel_lpss soundcore realtek libahci idma64 intel_pch_thermal i2c_hid_acpi i2c_hid acpi_pad sch_fq_codel msr parport_pc ppdev lp parport efi_pstore ip_tables x_tables autofs4 dm_crypt raid10 raid456 libcrc32c async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq raid1 raid0 joydev input_leds hid_generic usbhid hid nouveau i915 drm_ttm_helper gpu_sched drm_gpuvm drm_exec i2c_algo_bit drm_buddy ttm drm_display_helper drm_kms_helper cec rc_core drm nvme nvme_core mxm_wmi xhci_pci xhci_pci_renesas video wmi pinctrl_cannonlake mac_hid\n ---[ end trace 0000000000000000 ]---\n\nFix this by avoiding the divide if bpp is 0.

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: tcpm: fix double-free issue in tcpm_port_unregister_pd()\n\nWhen unregister pd capabilitie in tcpm, KASAN will capture below double\n-free issue. The root cause is the same capabilitiy will be kfreed twice,\nthe first time is kfreed by pd_capabilities_release() and the second time\nis explicitly kfreed by tcpm_port_unregister_pd().\n\n[ 3.988059] BUG: KASAN: double-free in tcpm_port_unregister_pd+0x1a4/0x3dc\n[ 3.995001] Free of addr ffff0008164d3000 by task kworker/u16:0/10\n[ 4.001206]\n[ 4.002712] CPU: 2 PID: 10 Comm: kworker/u16:0 Not tainted 6.8.0-rc5-next-20240220-05616-g52728c567a55 #53\n[ 4.012402] Hardware name: Freescale i.MX8QXP MEK (DT)\n[ 4.017569] Workqueue: events_unbound deferred_probe_work_func\n[ 4.023456] Call trace:\n[ 4.025920] dump_backtrace+0x94/0xec\n[ 4.029629] show_stack+0x18/0x24\n[ 4.032974] dump_stack_lvl+0x78/0x90\n[ 4.036675] print_report+0xfc/0x5c0\n[ 4.040289] kasan_report_invalid_free+0xa0/0xc0\n[ 4.044937] __kasan_slab_free+0x124/0x154\n[ 4.049072] kfree+0xb4/0x1e8\n[ 4.052069] tcpm_port_unregister_pd+0x1a4/0x3dc\n[ 4.056725] tcpm_register_port+0x1dd0/0x2558\n[ 4.061121] tcpci_register_port+0x420/0x71c\n[ 4.065430] tcpci_probe+0x118/0x2e0\n\nTo fix the issue, this will remove kree() from tcpm_port_unregister_pd().

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Fix double free of the ha->vp_map pointer\n\nCoverity scan reported potential risk of double free of the pointer\nha->vp_map. ha->vp_map was freed in qla2x00_mem_alloc(), and again freed\nin function qla2x00_mem_free(ha).\n\nAssign NULL to vp_map and kfree take care of NULL.

In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: Fix active state requirement in PME polling\n\nThe commit noted in fixes added a bogus requirement that runtime PM managed\ndevices need to be in the RPM_ACTIVE state for PME polling. In fact, only\ndevices in low power states should be polled.\n\nHowever there's still a requirement that the device config space must be\naccessible, which has implications for both the current state of the polled\ndevice and the parent bridge, when present. It's not sufficient to assume\nthe bridge remains in D0 and cases have been observed where the bridge\npasses the D0 test, but the PM state indicates RPM_SUSPENDING and config\nspace of the polled device becomes inaccessible during pci_pme_wakeup().\n\nTherefore, since the bridge is already effectively required to be in the\nRPM_ACTIVE state, formalize this in the code and elevate the PM usage count\nto maintain the state while polling the subordinate device.\n\nThis resolves a regression reported in the bugzilla below where a\nThunderbolt/USB4 hierarchy fails to scan for an attached NVMe endpoint\ndownstream of a bridge in a D3hot power state.

In the Linux kernel, the following vulnerability has been resolved:\n\nRevert "drm/amd: flush any delayed gfxoff on suspend entry"\n\ncommit ab4750332dbe ("drm/amdgpu/sdma5.2: add begin/end_use ring\ncallbacks") caused GFXOFF control to be used more heavily and the\ncodepath that was removed from commit 0dee72639533 ("drm/amd: flush any\ndelayed gfxoff on suspend entry") now can be exercised at suspend again.\n\nUsers report that by using GNOME to suspend the lockscreen trigger will\ncause SDMA traffic and the system can deadlock.\n\nThis reverts commit 0dee726395333fea833eaaf838bc80962df886c8.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Fixed bug on error when unloading amdgpu\n\nFixed bug on error when unloading amdgpu.\n\nThe error message is as follows:\n[ 377.706202] kernel BUG at drivers/gpu/drm/drm_buddy.c:278!\n[ 377.706215] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\n[ 377.706222] CPU: 4 PID: 8610 Comm: modprobe Tainted: G IOE 6.0.0-thomas #1\n[ 377.706231] Hardware name: ASUS System Product Name/PRIME Z390-A, BIOS 2004 11/02/2021\n[ 377.706238] RIP: 0010:drm_buddy_free_block+0x26/0x30 [drm_buddy]\n[ 377.706264] Code: 00 00 00 90 0f 1f 44 00 00 48 8b 0e 89 c8 25 00 0c 00 00 3d 00 04 00 00 75 10 48 8b 47 18 48 d3 e0 48 01 47 28 e9 fa fe ff ff <0f> 0b 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 54 55 48 89 f5 53\n[ 377.706282] RSP: 0018:ffffad2dc4683cb8 EFLAGS: 00010287\n[ 377.706289] RAX: 0000000000000000 RBX: ffff8b1743bd5138 RCX: 0000000000000000\n[ 377.706297] RDX: ffff8b1743bd5160 RSI: ffff8b1743bd5c78 RDI: ffff8b16d1b25f70\n[ 377.706304] RBP: ffff8b1743bd59e0 R08: 0000000000000001 R09: 0000000000000001\n[ 377.706311] R10: ffff8b16c8572400 R11: ffffad2dc4683cf0 R12: ffff8b16d1b25f70\n[ 377.706318] R13: ffff8b16d1b25fd0 R14: ffff8b1743bd59c0 R15: ffff8b16d1b25f70\n[ 377.706325] FS: 00007fec56c72c40(0000) GS:ffff8b1836500000(0000) knlGS:0000000000000000\n[ 377.706334] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 377.706340] CR2: 00007f9b88c1ba50 CR3: 0000000110450004 CR4: 00000000003706e0\n[ 377.706347] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 377.706354] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 377.706361] Call Trace:\n[ 377.706365] \n[ 377.706369] drm_buddy_free_list+0x2a/0x60 [drm_buddy]\n[ 377.706376] amdgpu_vram_mgr_fini+0xea/0x180 [amdgpu]\n[ 377.706572] amdgpu_ttm_fini+0x12e/0x1a0 [amdgpu]\n[ 377.706650] amdgpu_bo_fini+0x22/0x90 [amdgpu]\n[ 377.706727] gmc_v11_0_sw_fini+0x26/0x30 [amdgpu]\n[ 377.706821] amdgpu_device_fini_sw+0xa1/0x3c0 [amdgpu]\n[ 377.706897] amdgpu_driver_release_kms+0x12/0x30 [amdgpu]\n[ 377.706975] drm_dev_release+0x20/0x40 [drm]\n[ 377.707006] release_nodes+0x35/0xb0\n[ 377.707014] devres_release_all+0x8b/0xc0\n[ 377.707020] device_unbind_cleanup+0xe/0x70\n[ 377.707027] device_release_driver_internal+0xee/0x160\n[ 377.707033] driver_detach+0x44/0x90\n[ 377.707039] bus_remove_driver+0x55/0xe0\n[ 377.707045] pci_unregister_driver+0x3b/0x90\n[ 377.707052] amdgpu_exit+0x11/0x6c [amdgpu]\n[ 377.707194] __x64_sys_delete_module+0x142/0x2b0\n[ 377.707201] ? fpregs_assert_state_consistent+0x22/0x50\n[ 377.707208] ? exit_to_user_mode_prepare+0x3e/0x190\n[ 377.707215] do_syscall_64+0x38/0x90\n[ 377.707221] entry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: mediatek: vcodec: Only free buffer VA that is not NULL\n\nIn the MediaTek vcodec driver, while mtk_vcodec_mem_free() is mostly\ncalled only when the buffer to free exists, there are some instances\nthat didn't do the check and triggered warnings in practice.\n\nWe believe those checks were forgotten unintentionally. Add the checks\nback to fix the warnings.

In the Linux kernel, the following vulnerability has been resolved:\n\nInput: cyapa - add missing input core locking to suspend/resume functions\n\nGrab input->mutex during suspend/resume functions like it is done in\nother input drivers. This fixes the following warning during system\nsuspend/resume cycle on Samsung Exynos5250-based Snow Chromebook:\n\n------------[ cut here ]------------\nWARNING: CPU: 1 PID: 1680 at drivers/input/input.c:2291 input_device_enabled+0x68/0x6c\nModules linked in: ...\nCPU: 1 PID: 1680 Comm: kworker/u4:12 Tainted: G W 6.6.0-rc5-next-20231009 #14109\nHardware name: Samsung Exynos (Flattened Device Tree)\nWorkqueue: events_unbound async_run_entry_fn\n unwind_backtrace from show_stack+0x10/0x14\n show_stack from dump_stack_lvl+0x58/0x70\n dump_stack_lvl from __warn+0x1a8/0x1cc\n __warn from warn_slowpath_fmt+0x18c/0x1b4\n warn_slowpath_fmt from input_device_enabled+0x68/0x6c\n input_device_enabled from cyapa_gen3_set_power_mode+0x13c/0x1dc\n cyapa_gen3_set_power_mode from cyapa_reinitialize+0x10c/0x15c\n cyapa_reinitialize from cyapa_resume+0x48/0x98\n cyapa_resume from dpm_run_callback+0x90/0x298\n dpm_run_callback from device_resume+0xb4/0x258\n device_resume from async_resume+0x20/0x64\n async_resume from async_run_entry_fn+0x40/0x15c\n async_run_entry_fn from process_scheduled_works+0xbc/0x6a8\n process_scheduled_works from worker_thread+0x188/0x454\n worker_thread from kthread+0x108/0x140\n kthread from ret_from_fork+0x14/0x28\nException stack(0xf1625fb0 to 0xf1625ff8)\n...\n---[ end trace 0000000000000000 ]---\n...\n------------[ cut here ]------------\nWARNING: CPU: 1 PID: 1680 at drivers/input/input.c:2291 input_device_enabled+0x68/0x6c\nModules linked in: ...\nCPU: 1 PID: 1680 Comm: kworker/u4:12 Tainted: G W 6.6.0-rc5-next-20231009 #14109\nHardware name: Samsung Exynos (Flattened Device Tree)\nWorkqueue: events_unbound async_run_entry_fn\n unwind_backtrace from show_stack+0x10/0x14\n show_stack from dump_stack_lvl+0x58/0x70\n dump_stack_lvl from __warn+0x1a8/0x1cc\n __warn from warn_slowpath_fmt+0x18c/0x1b4\n warn_slowpath_fmt from input_device_enabled+0x68/0x6c\n input_device_enabled from cyapa_gen3_set_power_mode+0x13c/0x1dc\n cyapa_gen3_set_power_mode from cyapa_reinitialize+0x10c/0x15c\n cyapa_reinitialize from cyapa_resume+0x48/0x98\n cyapa_resume from dpm_run_callback+0x90/0x298\n dpm_run_callback from device_resume+0xb4/0x258\n device_resume from async_resume+0x20/0x64\n async_resume from async_run_entry_fn+0x40/0x15c\n async_run_entry_fn from process_scheduled_works+0xbc/0x6a8\n process_scheduled_works from worker_thread+0x188/0x454\n worker_thread from kthread+0x108/0x140\n kthread from ret_from_fork+0x14/0x28\nException stack(0xf1625fb0 to 0xf1625ff8)\n...\n---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Fix possible null pointer dereference\n\nabo->tbo.resource may be NULL in amdgpu_vm_bo_update.

In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Have trace_event_file have ref counters\n\nThe following can crash the kernel:\n\n # cd /sys/kernel/tracing\n # echo 'p:sched schedule' > kprobe_events\n # exec 5>>events/kprobes/sched/enable\n # > kprobe_events\n # exec 5>&-\n\nThe above commands:\n\n 1. Change directory to the tracefs directory\n 2. Create a kprobe event (doesn't matter what one)\n 3. Open bash file descriptor 5 on the enable file of the kprobe event\n 4. Delete the kprobe event (removes the files too)\n 5. Close the bash file descriptor 5\n\nThe above causes a crash!\n\n BUG: kernel NULL pointer dereference, address: 0000000000000028\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 [#1] PREEMPT SMP PTI\n CPU: 6 PID: 877 Comm: bash Not tainted 6.5.0-rc4-test-00008-g2c6b6b1029d4-dirty #186\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\n RIP: 0010:tracing_release_file_tr+0xc/0x50\n\nWhat happens here is that the kprobe event creates a trace_event_file\n"file" descriptor that represents the file in tracefs to the event. It\nmaintains state of the event (is it enabled for the given instance?).\nOpening the "enable" file gets a reference to the event "file" descriptor\nvia the open file descriptor. When the kprobe event is deleted, the file is\nalso deleted from the tracefs system which also frees the event "file"\ndescriptor.\n\nBut as the tracefs file is still opened by user space, it will not be\ntotally removed until the final dput() is called on it. But this is not\ntrue with the event "file" descriptor that is already freed. If the user\ndoes a write to or simply closes the file descriptor it will reference the\nevent "file" descriptor that was just freed, causing a use-after-free bug.\n\nTo solve this, add a ref count to the event "file" descriptor as well as a\nnew flag called "FREED". The "file" will not be freed until the last\nreference is released. But the FREE flag will be set when the event is\nremoved to prevent any more modifications to that event from happening,\neven if there's still a reference to the event "file" descriptor.

In the Linux kernel, the following vulnerability has been resolved:\n\nthermal: core: prevent potential string overflow\n\nThe dev->id value comes from ida_alloc() so it's a number between zero\nand INT_MAX. If it's too high then these sprintf()s will overflow.

In the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: Fix slab-use-after-free in gfs2_qd_dealloc\n\nIn gfs2_put_super(), whether withdrawn or not, the quota should\nbe cleaned up by gfs2_quota_cleanup().\n\nOtherwise, struct gfs2_sbd will be freed before gfs2_qd_dealloc (rcu\ncallback) has run for all gfs2_quota_data objects, resulting in\nuse-after-free.\n\nAlso, gfs2_destroy_threads() and gfs2_quota_cleanup() is already called\nby gfs2_make_fs_ro(), so in gfs2_put_super(), after calling\ngfs2_make_fs_ro(), there is no need to call them again.

In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix potential deadlock when releasing mids\n\nAll release_mid() callers seem to hold a reference of @mid so there is\nno need to call kref_put(&mid->refcount, __release_mid) under\n@server->mid_lock spinlock. If they don't, then an use-after-free bug\nwould have occurred anyways.\n\nBy getting rid of such spinlock also fixes a potential deadlock as\nshown below\n\nCPU 0 CPU 1\n------------------------------------------------------------------\ncifs_demultiplex_thread() cifs_debug_data_proc_show()\n release_mid()\n spin_lock(&server->mid_lock);\n spin_lock(&cifs_tcp_ses_lock)\n spin_lock(&server->mid_lock)\n __release_mid()\n smb2_find_smb_tcon()\n spin_lock(&cifs_tcp_ses_lock) *deadlock*

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Don't let sock_map_{close,destroy,unhash} call itself\n\nsock_map proto callbacks should never call themselves by design. Protect\nagainst bugs like [1] and break out of the recursive loop to avoid a stack\noverflow in favor of a resource leak.\n\n[1] https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/

In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: Intel: sof_sdw_rt_sdca_jack_common: ctx->headset_codec_dev = NULL\n\nsof_sdw_rt_sdca_jack_exit() are used by different codecs, and some of\nthem use the same dai name.\nFor example, rt712 and rt713 both use "rt712-sdca-aif1" and\nsof_sdw_rt_sdca_jack_exit().\nAs a result, sof_sdw_rt_sdca_jack_exit() will be called twice by\nmc_dailink_exit_loop(). Set ctx->headset_codec_dev = NULL; after\nput_device(ctx->headset_codec_dev); to avoid ctx->headset_codec_dev\nbeing put twice.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath12k: fix the error handler of rfkill config\n\nWhen the core rfkill config throws error, it should free the\nallocated resources. Currently it is not freeing the core pdev\ncreate resources. Avoid this issue by calling the core pdev\ndestroy in the error handler of core rfkill config.\n\nFound this issue in the code review and it is compile tested only.

In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: scarlett2: Add clamp() in scarlett2_mixer_ctl_put()\n\nEnsure the value passed to scarlett2_mixer_ctl_put() is between 0 and\nSCARLETT2_MIXER_MAX_VALUE so we don't attempt to access outside\nscarlett2_mixer_values[].

In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: SOF: amd: Fix memory leak in amd_sof_acp_probe()\n\nDriver uses kasprintf() to initialize fw_{code,data}_bin members of\nstruct acp_dev_data, but kfree() is never called to deallocate the\nmemory, which results in a memory leak.\n\nFix the issue by switching to devm_kasprintf(). Additionally, ensure the\nallocation was successful by checking the pointer validity.

In the Linux kernel, the following vulnerability has been resolved:\n\nNTB: fix possible name leak in ntb_register_device()\n\nIf device_register() fails in ntb_register_device(), the device name\nallocated by dev_set_name() should be freed. As per the comment in\ndevice_register(), callers should use put_device() to give up the\nreference in the error path. So fix this by calling put_device() in the\nerror path so that the name can be freed in kobject_cleanup().\n\nAs a result of this, put_device() in the error path of\nntb_register_device() is removed and the actual error is returned.\n\n[mani: reworded commit message]

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: prevent copying too big compressed lzo segment\n\nCompressed length can be corrupted to be a lot larger than memory\nwe have allocated for buffer.\nThis will cause memcpy in copy_compressed_segment to write outside\nof allocated memory.\n\nThis mostly results in stuck read syscall but sometimes when using\nbtrfs send can get #GP\n\n kernel: general protection fault, probably for non-canonical address 0x841551d5c1000: 0000 [#1] PREEMPT SMP NOPTI\n kernel: CPU: 17 PID: 264 Comm: kworker/u256:7 Tainted: P OE 5.17.0-rc2-1 #12\n kernel: Workqueue: btrfs-endio btrfs_work_helper [btrfs]\n kernel: RIP: 0010:lzo_decompress_bio (./include/linux/fortify-string.h:225 fs/btrfs/lzo.c:322 fs/btrfs/lzo.c:394) btrfs\n Code starting with the faulting instruction\n ===========================================\n 0:* 48 8b 06 mov (%rsi),%rax <-- trapping instruction\n 3: 48 8d 79 08 lea 0x8(%rcx),%rdi\n 7: 48 83 e7 f8 and $0xfffffffffffffff8,%rdi\n b: 48 89 01 mov %rax,(%rcx)\n e: 44 89 f0 mov %r14d,%eax\n 11: 48 8b 54 06 f8 mov -0x8(%rsi,%rax,1),%rdx\n kernel: RSP: 0018:ffffb110812efd50 EFLAGS: 00010212\n kernel: RAX: 0000000000001000 RBX: 000000009ca264c8 RCX: ffff98996e6d8ff8\n kernel: RDX: 0000000000000064 RSI: 000841551d5c1000 RDI: ffffffff9500435d\n kernel: RBP: ffff989a3be856c0 R08: 0000000000000000 R09: 0000000000000000\n kernel: R10: 0000000000000000 R11: 0000000000001000 R12: ffff98996e6d8000\n kernel: R13: 0000000000000008 R14: 0000000000001000 R15: 000841551d5c1000\n kernel: FS: 0000000000000000(0000) GS:ffff98a09d640000(0000) knlGS:0000000000000000\n kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n kernel: CR2: 00001e9f984d9ea8 CR3: 000000014971a000 CR4: 00000000003506e0\n kernel: Call Trace:\n kernel: \n kernel: end_compressed_bio_read (fs/btrfs/compression.c:104 fs/btrfs/compression.c:1363 fs/btrfs/compression.c:323) btrfs\n kernel: end_workqueue_fn (fs/btrfs/disk-io.c:1923) btrfs\n kernel: btrfs_work_helper (fs/btrfs/async-thread.c:326) btrfs\n kernel: process_one_work (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:212 ./include/trace/events/workqueue.h:108 kernel/workqueue.c:2312)\n kernel: worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2455)\n kernel: ? process_one_work (kernel/workqueue.c:2397)\n kernel: kthread (kernel/kthread.c:377)\n kernel: ? kthread_complete_and_exit (kernel/kthread.c:332)\n kernel: ret_from_fork (arch/x86/entry/entry_64.S:301)\n kernel:

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: get rid of warning on transaction commit when using flushoncommit\n\nWhen using the flushoncommit mount option, during almost every transaction\ncommit we trigger a warning from __writeback_inodes_sb_nr():\n\n $ cat fs/fs-writeback.c:\n (...)\n static void __writeback_inodes_sb_nr(struct super_block *sb, ...\n {\n (...)\n WARN_ON(!rwsem_is_locked(&sb->s_umount));\n (...)\n }\n (...)\n\nThe trace produced in dmesg looks like the following:\n\n [947.473890] WARNING: CPU: 5 PID: 930 at fs/fs-writeback.c:2610 __writeback_inodes_sb_nr+0x7e/0xb3\n [947.481623] Modules linked in: nfsd nls_cp437 cifs asn1_decoder cifs_arc4 fscache cifs_md4 ipmi_ssif\n [947.489571] CPU: 5 PID: 930 Comm: btrfs-transacti Not tainted 95.16.3-srb-asrock-00001-g36437ad63879 #186\n [947.497969] RIP: 0010:__writeback_inodes_sb_nr+0x7e/0xb3\n [947.502097] Code: 24 10 4c 89 44 24 18 c6 (...)\n [947.519760] RSP: 0018:ffffc90000777e10 EFLAGS: 00010246\n [947.523818] RAX: 0000000000000000 RBX: 0000000000963300 RCX: 0000000000000000\n [947.529765] RDX: 0000000000000000 RSI: 000000000000fa51 RDI: ffffc90000777e50\n [947.535740] RBP: ffff888101628a90 R08: ffff888100955800 R09: ffff888100956000\n [947.541701] R10: 0000000000000002 R11: 0000000000000001 R12: ffff888100963488\n [947.547645] R13: ffff888100963000 R14: ffff888112fb7200 R15: ffff888100963460\n [947.553621] FS: 0000000000000000(0000) GS:ffff88841fd40000(0000) knlGS:0000000000000000\n [947.560537] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n [947.565122] CR2: 0000000008be50c4 CR3: 000000000220c000 CR4: 00000000001006e0\n [947.571072] Call Trace:\n [947.572354] \n [947.573266] btrfs_commit_transaction+0x1f1/0x998\n [947.576785] ? start_transaction+0x3ab/0x44e\n [947.579867] ? schedule_timeout+0x8a/0xdd\n [947.582716] transaction_kthread+0xe9/0x156\n [947.585721] ? btrfs_cleanup_transaction.isra.0+0x407/0x407\n [947.590104] kthread+0x131/0x139\n [947.592168] ? set_kthread_struct+0x32/0x32\n [947.595174] ret_from_fork+0x22/0x30\n [947.597561] \n [947.598553] ---[ end trace 644721052755541c ]---\n\nThis is because we started using writeback_inodes_sb() to flush delalloc\nwhen committing a transaction (when using -o flushoncommit), in order to\navoid deadlocks with filesystem freeze operations. This change was made\nby commit ce8ea7cc6eb313 ("btrfs: don't call btrfs_start_delalloc_roots\nin flushoncommit"). After that change we started producing that warning,\nand every now and then a user reports this since the warning happens too\noften, it spams dmesg/syslog, and a user is unsure if this reflects any\nproblem that might compromise the filesystem's reliability.\n\nWe can not just lock the sb->s_umount semaphore before calling\nwriteback_inodes_sb(), because that would at least deadlock with\nfilesystem freezing, since at fs/super.c:freeze_super() sync_filesystem()\nis called while we are holding that semaphore in write mode, and that can\ntrigger a transaction commit, resulting in a deadlock. It would also\ntrigger the same type of deadlock in the unmount path. Possibly, it could\nalso introduce some other locking dependencies that lockdep would report.\n\nTo fix this call try_to_writeback_inodes_sb() instead of\nwriteback_inodes_sb(), because that will try to read lock sb->s_umount\nand then will only call writeback_inodes_sb() if it was able to lock it.\nThis is fine because the cases where it can't read lock sb->s_umount\nare during a filesystem unmount or during a filesystem freeze - in those\ncases sb->s_umount is write locked and sync_filesystem() is called, which\ncalls writeback_inodes_sb(). In other words, in all cases where we can't\ntake a read lock on sb->s_umount, writeback is already being triggered\nelsewhere.\n\nAn alternative would be to call btrfs_start_delalloc_roots() with a\nnumber of pages different from LONG_MAX, for example matching the number\nof delalloc bytes we currently have, in \n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: do not WARN_ON() if we have PageError set\n\nWhenever we do any extent buffer operations we call\nassert_eb_page_uptodate() to complain loudly if we're operating on an\nnon-uptodate page. Our overnight tests caught this warning earlier this\nweek\n\n WARNING: CPU: 1 PID: 553508 at fs/btrfs/extent_io.c:6849 assert_eb_page_uptodate+0x3f/0x50\n CPU: 1 PID: 553508 Comm: kworker/u4:13 Tainted: G W 5.17.0-rc3+ #564\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014\n Workqueue: btrfs-cache btrfs_work_helper\n RIP: 0010:assert_eb_page_uptodate+0x3f/0x50\n RSP: 0018:ffffa961440a7c68 EFLAGS: 00010246\n RAX: 0017ffffc0002112 RBX: ffffe6e74453f9c0 RCX: 0000000000001000\n RDX: ffffe6e74467c887 RSI: ffffe6e74453f9c0 RDI: ffff8d4c5efc2fc0\n RBP: 0000000000000d56 R08: ffff8d4d4a224000 R09: 0000000000000000\n R10: 00015817fa9d1ef0 R11: 000000000000000c R12: 00000000000007b1\n R13: ffff8d4c5efc2fc0 R14: 0000000001500000 R15: 0000000001cb1000\n FS: 0000000000000000(0000) GS:ffff8d4dbbd00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007ff31d3448d8 CR3: 0000000118be8004 CR4: 0000000000370ee0\n Call Trace:\n\n extent_buffer_test_bit+0x3f/0x70\n free_space_test_bit+0xa6/0xc0\n load_free_space_tree+0x1f6/0x470\n caching_thread+0x454/0x630\n ? rcu_read_lock_sched_held+0x12/0x60\n ? rcu_read_lock_sched_held+0x12/0x60\n ? rcu_read_lock_sched_held+0x12/0x60\n ? lock_release+0x1f0/0x2d0\n btrfs_work_helper+0xf2/0x3e0\n ? lock_release+0x1f0/0x2d0\n ? finish_task_switch.isra.0+0xf9/0x3a0\n process_one_work+0x26d/0x580\n ? process_one_work+0x580/0x580\n worker_thread+0x55/0x3b0\n ? process_one_work+0x580/0x580\n kthread+0xf0/0x120\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork+0x1f/0x30\n\nThis was partially fixed by c2e39305299f01 ("btrfs: clear extent buffer\nuptodate when we fail to write it"), however all that fix did was keep\nus from finding extent buffers after a failed writeout. It didn't keep\nus from continuing to use a buffer that we already had found.\n\nIn this case we're searching the commit root to cache the block group,\nso we can start committing the transaction and switch the commit root\nand then start writing. After the switch we can look up an extent\nbuffer that hasn't been written yet and start processing that block\ngroup. Then we fail to write that block out and clear Uptodate on the\npage, and then we start spewing these errors.\n\nNormally we're protected by the tree lock to a certain degree here. If\nwe read a block we have that block read locked, and we block the writer\nfrom locking the block before we submit it for the write. However this\nisn't necessarily fool proof because the read could happen before we do\nthe submit_bio and after we locked and unlocked the extent buffer.\n\nAlso in this particular case we have path->skip_locking set, so that\nwon't save us here. We'll simply get a block that was valid when we\nread it, but became invalid while we were using it.\n\nWhat we really want is to catch the case where we've "read" a block but\nit's not marked Uptodate. On read we ClearPageError(), so if we're\n!Uptodate and !Error we know we didn't do the right thing for reading\nthe page.\n\nFix this by checking !Uptodate && !Error, this way we will not complain\nif our buffer gets invalidated while we're using it, and we'll maintain\nthe spirit of the check which is to make sure we have a fully in-cache\nblock while we're messing with it.

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: do not start relocation until in progress drops are done\n\nWe hit a bug with a recovering relocation on mount for one of our file\nsystems in production. I reproduced this locally by injecting errors\ninto snapshot delete with balance running at the same time. This\npresented as an error while looking up an extent item\n\n WARNING: CPU: 5 PID: 1501 at fs/btrfs/extent-tree.c:866 lookup_inline_extent_backref+0x647/0x680\n CPU: 5 PID: 1501 Comm: btrfs-balance Not tainted 5.16.0-rc8+ #8\n RIP: 0010:lookup_inline_extent_backref+0x647/0x680\n RSP: 0018:ffffae0a023ab960 EFLAGS: 00010202\n RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000000\n RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000000000\n RBP: ffff943fd2a39b60 R08: 0000000000000000 R09: 0000000000000001\n R10: 0001434088152de0 R11: 0000000000000000 R12: 0000000001d05000\n R13: ffff943fd2a39b60 R14: ffff943fdb96f2a0 R15: ffff9442fc923000\n FS: 0000000000000000(0000) GS:ffff944e9eb40000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f1157b1fca8 CR3: 000000010f092000 CR4: 0000000000350ee0\n Call Trace:\n \n insert_inline_extent_backref+0x46/0xd0\n __btrfs_inc_extent_ref.isra.0+0x5f/0x200\n ? btrfs_merge_delayed_refs+0x164/0x190\n __btrfs_run_delayed_refs+0x561/0xfa0\n ? btrfs_search_slot+0x7b4/0xb30\n ? btrfs_update_root+0x1a9/0x2c0\n btrfs_run_delayed_refs+0x73/0x1f0\n ? btrfs_update_root+0x1a9/0x2c0\n btrfs_commit_transaction+0x50/0xa50\n ? btrfs_update_reloc_root+0x122/0x220\n prepare_to_merge+0x29f/0x320\n relocate_block_group+0x2b8/0x550\n btrfs_relocate_block_group+0x1a6/0x350\n btrfs_relocate_chunk+0x27/0xe0\n btrfs_balance+0x777/0xe60\n balance_kthread+0x35/0x50\n ? btrfs_balance+0xe60/0xe60\n kthread+0x16b/0x190\n ? set_kthread_struct+0x40/0x40\n ret_from_fork+0x22/0x30\n \n\nNormally snapshot deletion and relocation are excluded from running at\nthe same time by the fs_info->cleaner_mutex. However if we had a\npending balance waiting to get the ->cleaner_mutex, and a snapshot\ndeletion was running, and then the box crashed, we would come up in a\nstate where we have a half deleted snapshot.\n\nAgain, in the normal case the snapshot deletion needs to complete before\nrelocation can start, but in this case relocation could very well start\nbefore the snapshot deletion completes, as we simply add the root to the\ndead roots list and wait for the next time the cleaner runs to clean up\nthe snapshot.\n\nFix this by setting a bit on the fs_info if we have any DEAD_ROOT's that\nhad a pending drop_progress key. If they do then we know we were in the\nmiddle of the drop operation and set a flag on the fs_info. Then\nbalance can wait until this flag is cleared to start up again.\n\nIf there are DEAD_ROOT's that don't have a drop_progress set then we're\nsafe to start balance right away as we'll be properly protected by the\ncleaner_mutex.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/gt: Cleanup partial engine discovery failures\n\nIf we abort driver initialisation in the middle of gt/engine discovery,\nsome engines will be fully setup and some not. Those incompletely setup\nengines only have 'engine->release == NULL' and so will leak any of the\ncommon objects allocated.\n\nv2:\n - Drop the destroy_pinned_context() helper for now. It's not really\n worth it with just a single callsite at the moment. (Janusz)

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vc4: hdmi: Unregister codec device on unbind\n\nOn bind we will register the HDMI codec device but we don't unregister\nit on unbind, leading to a device leakage. Unregister our device at\nunbind.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: bypass tiling flag check in virtual display case (v2)\n\nvkms leverages common amdgpu framebuffer creation, and\nalso as it does not support FB modifier, there is no need\nto check tiling flags when initing framebuffer when virtual\ndisplay is enabled.\n\nThis can fix below calltrace:\n\namdgpu 0000:00:08.0: GFX9+ requires FB check based on format modifier\nWARNING: CPU: 0 PID: 1023 at drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:1150 amdgpu_display_framebuffer_init+0x8e7/0xb40 [amdgpu]\n\nv2: check adev->enable_virtual_display instead as vkms can be\n enabled in bare metal as well.

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_core: Fix leaking sent_cmd skb\n\nsent_cmd memory is not freed before freeing hci_dev causing it to leak\nit contents.