In the Linux kernel, the following vulnerability has been resolved:\n\nSUNRPC: Fix a slow server-side memory leak with RPC-over-TCP\n\nJan Schunk reports that his small NFS servers suffer from memory\nexhaustion after just a few days. A bisect shows that commit\ne18e157bb5c8 ("SUNRPC: Send RPC message on TCP with a single\nsock_sendmsg() call") is the first bad commit.\n\nThat commit assumed that sock_sendmsg() releases all the pages in\nthe underlying bio_vec array, but the reality is that it doesn't.\nsvc_xprt_release() releases the rqst's response pages, but the\nrecord marker page fragment isn't one of those, so it is never\nreleased.\n\nThis is a narrow fix that can be applied to stable kernels. A\nmore extensive fix is in the works.

In the Linux kernel, the following vulnerability has been resolved:\n\naio: Fix null ptr deref in aio_complete() wakeup\n\nlist_del_init_careful() needs to be the last access to the wait queue\nentry - it effectively unlocks access.\n\nPreviously, finish_wait() would see the empty list head and skip taking\nthe lock, and then we'd return - but the completion path would still\nattempt to do the wakeup after the task_struct pointer had been\noverwritten.

In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: Fix vector state restore in rt_sigreturn()\n\nThe RISC-V Vector specification states in "Appendix D: Calling\nConvention for Vector State" [1] that "Executing a system call causes\nall caller-saved vector registers (v0-v31, vl, vtype) and vstart to\nbecome unspecified.". In the RISC-V kernel this is called "discarding\nthe vstate".\n\nReturning from a signal handler via the rt_sigreturn() syscall, vector\ndiscard is also performed. However, this is not an issue since the\nvector state should be restored from the sigcontext, and therefore not\ncare about the vector discard.\n\nThe "live state" is the actual vector register in the running context,\nand the "vstate" is the vector state of the task. A dirty live state,\nmeans that the vstate and live state are not in synch.\n\nWhen vectorized user_from_copy() was introduced, an bug sneaked in at\nthe restoration code, related to the discard of the live state.\n\nAn example when this go wrong:\n\n 1. A userland application is executing vector code\n 2. The application receives a signal, and the signal handler is\n entered.\n 3. The application returns from the signal handler, using the\n rt_sigreturn() syscall.\n 4. The live vector state is discarded upon entering the\n rt_sigreturn(), and the live state is marked as "dirty", indicating\n that the live state need to be synchronized with the current\n vstate.\n 5. rt_sigreturn() restores the vstate, except the Vector registers,\n from the sigcontext\n 6. rt_sigreturn() restores the Vector registers, from the sigcontext,\n and now the vectorized user_from_copy() is used. The dirty live\n state from the discard is saved to the vstate, making the vstate\n corrupt.\n 7. rt_sigreturn() returns to the application, which crashes due to\n corrupted vstate.\n\nNote that the vectorized user_from_copy() is invoked depending on the\nvalue of CONFIG_RISCV_ISA_V_UCOPY_THRESHOLD. Default is 768, which\nmeans that vlen has to be larger than 128b for this bug to trigger.\n\nThe fix is simply to mark the live state as non-dirty/clean prior\nperforming the vstate restore.

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: support deferring bpf_link dealloc to after RCU grace period\n\nBPF link for some program types is passed as a "context" which can be\nused by those BPF programs to look up additional information. E.g., for\nmulti-kprobes and multi-uprobes, link is used to fetch BPF cookie values.\n\nBecause of this runtime dependency, when bpf_link refcnt drops to zero\nthere could still be active BPF programs running accessing link data.\n\nThis patch adds generic support to defer bpf_link dealloc callback to\nafter RCU GP, if requested. This is done by exposing two different\ndeallocation callbacks, one synchronous and one deferred. If deferred\none is provided, bpf_link_free() will schedule dealloc_deferred()\ncallback to happen after RCU GP.\n\nBPF is using two flavors of RCU: "classic" non-sleepable one and RCU\ntasks trace one. The latter is used when sleepable BPF programs are\nused. bpf_link_free() accommodates that by checking underlying BPF\nprogram's sleepable flag, and goes either through normal RCU GP only for\nnon-sleepable, or through RCU tasks trace GP *and* then normal RCU GP\n(taking into account rcu_trace_implies_rcu_gp() optimization), if BPF\nprogram is sleepable.\n\nWe use this for multi-kprobe and multi-uprobe links, which dereference\nlink during program run. We also preventively switch raw_tp link to use\ndeferred dealloc callback, as upcoming changes in bpf-next tree expose\nraw_tp link data (specifically, cookie value) to BPF program at runtime\nas well.

In the Linux kernel, the following vulnerability has been resolved:\n\nblock: fix module reference leakage from bdev_open_by_dev error path\n\nAt the time bdev_may_open() is called, module reference is grabbed\nalready, hence module reference should be released if bdev_may_open()\nfailed.\n\nThis problem is found by code review.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: bcmasp: fix memory leak when bringing down interface\n\nWhen bringing down the TX rings we flush the rings but forget to\nreclaimed the flushed packets. This leads to a memory leak since we\ndo not free the dma mapped buffers. This also leads to tx control\nblock corruption when bringing down the interface for power\nmanagement.

In the Linux kernel, the following vulnerability has been resolved:\n\nicmp: prevent possible NULL dereferences from icmp_build_probe()\n\nFirst problem is a double call to __in_dev_get_rcu(), because\nthe second one could return NULL.\n\nif (__in_dev_get_rcu(dev) && __in_dev_get_rcu(dev)->ifa_list)\n\nSecond problem is a read from dev->ip6_ptr with no NULL check:\n\nif (!list_empty(&rcu_dereference(dev->ip6_ptr)->addr_list))\n\nUse the correct RCU API to fix these.\n\nv2: add missing include <net/addrconf.h>

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: btusb: mediatek: Fix double free of skb in coredump\n\nhci_devcd_append() would free the skb on error so the caller don't\nhave to free it again otherwise it would cause the double free of skb.\n\nReported-by : Dan Carpenter <dan.carpenter@linaro.org>

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: qca: fix NULL-deref on non-serdev suspend\n\nQualcomm ROME controllers can be registered from the Bluetooth line\ndiscipline and in this case the HCI UART serdev pointer is NULL.\n\nAdd the missing sanity check to prevent a NULL-pointer dereference when\nwakeup() is called for a non-serdev controller during suspend.\n\nJust return true for now to restore the original behaviour and address\nthe crash with pre-6.2 kernels, which do not have commit e9b3e5b8c657\n("Bluetooth: hci_qca: only assign wakeup with serial port support") that\ncauses the crash to happen already at setup() time.

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: qca: fix NULL-deref on non-serdev setup\n\nQualcomm ROME controllers can be registered from the Bluetooth line\ndiscipline and in this case the HCI UART serdev pointer is NULL.\n\nAdd the missing sanity check to prevent a NULL-pointer dereference when\nsetup() is called for a non-serdev controller.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm: zswap: fix shrinker NULL crash with cgroup_disable=memory\n\nChristian reports a NULL deref in zswap that he bisected down to the zswap\nshrinker. The issue also cropped up in the bug trackers of libguestfs [1]\nand the Red Hat bugzilla [2].\n\nThe problem is that when memcg is disabled with the boot time flag, the\nzswap shrinker might get called with sc->memcg == NULL. This is okay in\nmany places, like the lruvec operations. But it crashes in\nmemcg_page_state() - which is only used due to the non-node accounting of\ncgroup's the zswap memory to begin with.\n\nNhat spotted that the memcg can be NULL in the memcg-disabled case, and I\nwas then able to reproduce the crash locally as well.\n\n[1] https://github.com/libguestfs/libguestfs/issues/139\n[2] https://bugzilla.redhat.com/show_bug.cgi?id=2275252

In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: mediatek: sof-common: Add NULL check for normal_link string\n\nIt's not granted that all entries of struct sof_conn_stream declare\na `normal_link` (a non-SOF, direct link) string, and this is the case\nfor SoCs that support only SOF paths (hence do not support both direct\nand SOF usecases).\n\nFor example, in the case of MT8188 there is no normal_link string in\nany of the sof_conn_stream entries and there will be more drivers\ndoing that in the future.\n\nTo avoid possible NULL pointer KPs, add a NULL check for `normal_link`.

In the Linux kernel, the following vulnerability has been resolved:\n\ndpll: fix pin dump crash for rebound module\n\nWhen a kernel module is unbound but the pin resources were not entirely\nfreed (other kernel module instance of the same PCI device have had kept\nthe reference to that pin), and kernel module is again bound, the pin\nproperties would not be updated (the properties are only assigned when\nmemory for the pin is allocated), prop pointer still points to the\nkernel module memory of the kernel module which was deallocated on the\nunbind.\n\nIf the pin dump is invoked in this state, the result is a kernel crash.\nPrevent the crash by storing persistent pin properties in dpll subsystem,\ncopy the content from the kernel module when pin is allocated, instead of\nusing memory of the kernel module.

In the Linux kernel, the following vulnerability has been resolved:\n\nxsk: recycle buffer in case Rx queue was full\n\nAdd missing xsk_buff_free() call when __xsk_rcv_zc() failed to produce\ndescriptor to XSK Rx queue.

In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: Fix release of pinned pages when __io_uaddr_map fails\n\nLooking at the error path of __io_uaddr_map, if we fail after pinning\nthe pages for any reasons, ret will be set to -EINVAL and the error\nhandler won't properly release the pinned pages.\n\nI didn't manage to trigger it without forcing a failure, but it can\nhappen in real life when memory is heavily fragmented.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer()\n\nIn the for statement of lbs_allocate_cmd_buffer(), if the allocation of\ncmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to\nbe freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer().

In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/net: fix overflow check in io_recvmsg_mshot_prep()\n\nThe "controllen" variable is type size_t (unsigned long). Casting it\nto int could lead to an integer underflow.\n\nThe check_add_overflow() function considers the type of the destination\nwhich is type int. If we add two positive values and the result cannot\nfit in an integer then that's counted as an overflow.\n\nHowever, if we cast "controllen" to an int and it turns negative, then\nnegative values *can* fit into an int type so there is no overflow.\n\nGood: 100 + (unsigned long)-4 = 96 <-- overflow\n Bad: 100 + (int)-4 = 96 <-- no overflow\n\nI deleted the cast of the sizeof() as well. That's not a bug but the\ncast is unnecessary.

In the Linux kernel, the following vulnerability has been resolved:\n\nubifs: Set page uptodate in the correct place\n\nPage cache reads are lockless, so setting the freshly allocated page\nuptodate before we've overwritten it with the data it's supposed to have\nin it will allow a simultaneous reader to see old data. Move the call\nto SetPageUptodate into ubifs_write_end(), which is after we copied the\nnew data into the page.

In the Linux kernel, the following vulnerability has been resolved:\n\nfirewire: ohci: prevent leak of left-over IRQ on unbind\n\nCommit 5a95f1ded28691e6 ("firewire: ohci: use devres for requested IRQ")\nalso removed the call to free_irq() in pci_remove(), leading to a\nleftover irq of devm_request_irq() at pci_disable_msi() in pci_remove()\nwhen unbinding the driver from the device\n\nremove_proc_entry: removing non-empty directory 'irq/136', leaking at\nleast 'firewire_ohci'\nCall Trace:\n ? remove_proc_entry+0x19c/0x1c0\n ? __warn+0x81/0x130\n ? remove_proc_entry+0x19c/0x1c0\n ? report_bug+0x171/0x1a0\n ? console_unlock+0x78/0x120\n ? handle_bug+0x3c/0x80\n ? exc_invalid_op+0x17/0x70\n ? asm_exc_invalid_op+0x1a/0x20\n ? remove_proc_entry+0x19c/0x1c0\n unregister_irq_proc+0xf4/0x120\n free_desc+0x3d/0xe0\n ? kfree+0x29f/0x2f0\n irq_free_descs+0x47/0x70\n msi_domain_free_locked.part.0+0x19d/0x1d0\n msi_domain_free_irqs_all_locked+0x81/0xc0\n pci_free_msi_irqs+0x12/0x40\n pci_disable_msi+0x4c/0x60\n pci_remove+0x9d/0xc0 [firewire_ohci\n 01b483699bebf9cb07a3d69df0aa2bee71db1b26]\n pci_device_remove+0x37/0xa0\n device_release_driver_internal+0x19f/0x200\n unbind_store+0xa1/0xb0\n\nremove irq with devm_free_irq() before pci_disable_msi()\nalso remove it in fail_msi: of pci_probe() as this would lead to\nan identical leak

In the Linux kernel, the following vulnerability has been resolved:\n\nfs/aio: Check IOCB_AIO_RW before the struct aio_kiocb conversion\n\nThe first kiocb_set_cancel_fn() argument may point at a struct kiocb\nthat is not embedded inside struct aio_kiocb. With the current code,\ndepending on the compiler, the req->ki_ctx read happens either before\nthe IOCB_AIO_RW test or after that test. Move the req->ki_ctx read such\nthat it is guaranteed that the IOCB_AIO_RW test happens first.

In the Linux kernel, the following vulnerability has been resolved:\n\nmmc: core: Avoid negative index with array access\n\nCommit 4d0c8d0aef63 ("mmc: core: Use mrq.sbc in close-ended ffu") assigns\nprev_idata = idatas[i - 1], but doesn't check that the iterator i is\ngreater than zero. Let's fix this by adding a check.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: fix deadlock while reading mqd from debugfs\n\nAn errant disk backup on my desktop got into debugfs and triggered the\nfollowing deadlock scenario in the amdgpu debugfs files. The machine\nalso hard-resets immediately after those lines are printed (although I\nwasn't able to reproduce that part when reading by hand):\n\n[ 1318.016074][ T1082] ======================================================\n[ 1318.016607][ T1082] WARNING: possible circular locking dependency detected\n[ 1318.017107][ T1082] 6.8.0-rc7-00015-ge0c8221b72c0 #17 Not tainted\n[ 1318.017598][ T1082] ------------------------------------------------------\n[ 1318.018096][ T1082] tar/1082 is trying to acquire lock:\n[ 1318.018585][ T1082] ffff98c44175d6a0 (&mm->mmap_lock){++++}-{3:3}, at: __might_fault+0x40/0x80\n[ 1318.019084][ T1082]\n[ 1318.019084][ T1082] but task is already holding lock:\n[ 1318.020052][ T1082] ffff98c4c13f55f8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: amdgpu_debugfs_mqd_read+0x6a/0x250 [amdgpu]\n[ 1318.020607][ T1082]\n[ 1318.020607][ T1082] which lock already depends on the new lock.\n[ 1318.020607][ T1082]\n[ 1318.022081][ T1082]\n[ 1318.022081][ T1082] the existing dependency chain (in reverse order) is:\n[ 1318.023083][ T1082]\n[ 1318.023083][ T1082] -> #2 (reservation_ww_class_mutex){+.+.}-{3:3}:\n[ 1318.024114][ T1082] __ww_mutex_lock.constprop.0+0xe0/0x12f0\n[ 1318.024639][ T1082] ww_mutex_lock+0x32/0x90\n[ 1318.025161][ T1082] dma_resv_lockdep+0x18a/0x330\n[ 1318.025683][ T1082] do_one_initcall+0x6a/0x350\n[ 1318.026210][ T1082] kernel_init_freeable+0x1a3/0x310\n[ 1318.026728][ T1082] kernel_init+0x15/0x1a0\n[ 1318.027242][ T1082] ret_from_fork+0x2c/0x40\n[ 1318.027759][ T1082] ret_from_fork_asm+0x11/0x20\n[ 1318.028281][ T1082]\n[ 1318.028281][ T1082] -> #1 (reservation_ww_class_acquire){+.+.}-{0:0}:\n[ 1318.029297][ T1082] dma_resv_lockdep+0x16c/0x330\n[ 1318.029790][ T1082] do_one_initcall+0x6a/0x350\n[ 1318.030263][ T1082] kernel_init_freeable+0x1a3/0x310\n[ 1318.030722][ T1082] kernel_init+0x15/0x1a0\n[ 1318.031168][ T1082] ret_from_fork+0x2c/0x40\n[ 1318.031598][ T1082] ret_from_fork_asm+0x11/0x20\n[ 1318.032011][ T1082]\n[ 1318.032011][ T1082] -> #0 (&mm->mmap_lock){++++}-{3:3}:\n[ 1318.032778][ T1082] __lock_acquire+0x14bf/0x2680\n[ 1318.033141][ T1082] lock_acquire+0xcd/0x2c0\n[ 1318.033487][ T1082] __might_fault+0x58/0x80\n[ 1318.033814][ T1082] amdgpu_debugfs_mqd_read+0x103/0x250 [amdgpu]\n[ 1318.034181][ T1082] full_proxy_read+0x55/0x80\n[ 1318.034487][ T1082] vfs_read+0xa7/0x360\n[ 1318.034788][ T1082] ksys_read+0x70/0xf0\n[ 1318.035085][ T1082] do_syscall_64+0x94/0x180\n[ 1318.035375][ T1082] entry_SYSCALL_64_after_hwframe+0x46/0x4e\n[ 1318.035664][ T1082]\n[ 1318.035664][ T1082] other info that might help us debug this:\n[ 1318.035664][ T1082]\n[ 1318.036487][ T1082] Chain exists of:\n[ 1318.036487][ T1082] &mm->mmap_lock --> reservation_ww_class_acquire --> reservation_ww_class_mutex\n[ 1318.036487][ T1082]\n[ 1318.037310][ T1082] Possible unsafe locking scenario:\n[ 1318.037310][ T1082]\n[ 1318.037838][ T1082] CPU0 CPU1\n[ 1318.038101][ T1082] ---- ----\n[ 1318.038350][ T1082] lock(reservation_ww_class_mutex);\n[ 1318.038590][ T1082] lock(reservation_ww_class_acquire);\n[ 1318.038839][ T1082] lock(reservation_ww_class_mutex);\n[ 1318.039083][ T1082] rlock(&mm->mmap_lock);\n[ 1318.039328][ T1082]\n[ 1318.039328][ T1082] *** DEADLOCK ***\n[ 1318.039328][ T1082]\n[ 1318.040029][ T1082] 1 lock held by tar/1082:\n[ 1318.040259][ T1082] #0: ffff98c4c13f55f8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: amdgpu_debugfs_mqd_read+0x6a/0x250 [amdgpu]\n[ 1318.040560][ T1082]\n[ 1318.040560][ T1082] stack backtrace:\n[ 1318.041053][ T1082] CPU: 22 PID: 1082 Comm: tar Not tainted 6.8.0-rc7-00015-ge0c8221b72c0 #17 3316c85d50e282c5643b075d1f01a4f6365e39c2\n[ 1318.041329][ T1082] Hardware name: Gigabyte Technology Co., Ltd. B650 AORUS PRO AX/B650 AORUS PRO AX, BIOS F20 12/14/2023\n[ 1318.041614][ T1082] Call Trace:\n[ 1318.041895][ T1082] <TASK>\n[ 1318.042175][ T1082] dump_stack_lvl+0x4a/0x80\n[ 1318.042460][ T1082] check_noncircular+0x145/0x160\n[ 1318.042743][ T1082] __lock_acquire+0x14bf/0x2680\n[ 1318.043022][ T1082] lock_acquire+0xcd/0x2c0\n[ 1318.043301][ T1082] ? __might_fault+0x40/0x80\n[ 1318.043580][ T1082] ? __might_fault+0x40/0x80\n[ 1318.043856][ T1082] __might_fault+0x58/0x80\n[ 1318.044131][ T1082] ? __might_fault+0x40/0x80\n[ 1318.044408][ T1082] amdgpu_debugfs_mqd_read+0x103/0x250 [amdgpu 8fe2afaa910cbd7654c8cab23563a94d6caebaab]\n[ 1318.044749][ T1082] full_proxy_read+0x55/0x80\n[ 1318.045042][ T1082] vfs_read+0xa7/0x360\n[ 1318.045333][ T1082] ksys_read+0x70/0xf0\n[ 1318.045623][ T1082] do_syscall_64+0x94/0x180\n[ 1318.045913][ T1082] ? do_syscall_64+0xa0/0x180\n[ 1318.046201][ T1082] ? lockdep_hardirqs_on+0x7d/0x100\n[ 1318.046487][ T1082] ? do_syscall_64+0xa0/0x180\n[ 1318.046773][ T1082] ? do_syscall_64+0xa0/0x180\n[ 1318.047057][ T1082] ? do_syscall_64+0xa0/0x180\n[ 1318.047337][ T1082] ? do_syscall_64+0xa0/0x180\n[ 1318.047611][ T1082] entry_SYSCALL_64_after_hwframe+0x46/0x4e\n[ 1318.047887][ T1082] RIP: 0033:0x7f480b70a39d\n[ 1318.048162][ T1082] Code: 91 ba 0d 00 f7 d8 64 89 02 b8 ff ff ff ff eb b2 e8 18 a3 01 00 0f 1f 84 00 00 00 00 00 80 3d a9 3c 0e 00 00 74 17 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 5b c3 66 2e 0f 1f 84 00 00 00 00 00 53 48 83\n[ 1318.048769][ T1082] RSP: 002b:00007ffde77f5c68 EFLAGS: 00000246 ORIG_RAX: 0000000000000000\n[ 1318.049083][ T1082] RAX: ffffffffffffffda RBX: 0000000000000800 RCX: 00007f480b70a39d\n[ 1318.049392][ T1082] RDX: 0000000000000800 RSI: 000055c9f2120c00 RDI: 0000000000000008\n[ 1318.049703][ T1082] RBP: 0000000000000800 R08: 000055c9f2120a94 R09: 0000000000000007\n[ 1318.050011][ T1082] R10: 0000000000000000 R11: 0000000000000246 R12: 000055c9f2120c00\n[ 1318.050324][ T1082] R13: 0000000000000008 R14: 0000000000000008 R15: 0000000000000800\n[ 1318.050638][ T1082] </TASK>\n\namdgpu_debugfs_mqd_read() holds a reservation when it calls\nput_user(), which may fault and acquire the mmap_sem. This violates\nthe established locking order.\n\nBounce the mqd data through a kernel buffer to get put_user() out of\nthe illegal section.

In the Linux kernel, the following vulnerability has been resolved:\n\ndebugfs: fix wait/cancellation handling during remove\n\nBen Greear further reports deadlocks during concurrent debugfs\nremove while files are being accessed, even though the code in\nquestion now uses debugfs cancellations. Turns out that despite\nall the review on the locking, we missed completely that the\nlogic is wrong: if the refcount hits zero we can finish (and\nneed not wait for the completion), but if it doesn't we have\nto trigger all the cancellations. As written, we can _never_\nget into the loop triggering the cancellations. Fix this, and\nexplain it better while at it.

In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: rk3288 - Fix use after free in unprepare\n\nThe unprepare call must be carried out before the finalize call\nas the latter can free the request.

In the Linux kernel, the following vulnerability has been resolved:\n\nmd/md-bitmap: fix incorrect usage for sb_index\n\nCommit d7038f951828 ("md-bitmap: don't use ->index for pages backing the\nbitmap file") removed page->index from bitmap code, but left wrong code\nlogic for clustered-md. current code never set slot offset for cluster\nnodes, will sometimes cause crash in clustered env.\n\nCall trace (partly):\n md_bitmap_file_set_bit+0x110/0x1d8 [md_mod]\n md_bitmap_startwrite+0x13c/0x240 [md_mod]\n raid1_make_request+0x6b0/0x1c08 [raid1]\n md_handle_request+0x1dc/0x368 [md_mod]\n md_submit_bio+0x80/0xf8 [md_mod]\n __submit_bio+0x178/0x300\n submit_bio_noacct_nocheck+0x11c/0x338\n submit_bio_noacct+0x134/0x614\n submit_bio+0x28/0xdc\n submit_bh_wbc+0x130/0x1cc\n submit_bh+0x1c/0x28

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau: fix stale locked mutex in nouveau_gem_ioctl_pushbuf\n\nIf VM_BIND is enabled on the client the legacy submission ioctl can't be\nused, however if a client tries to do so regardless it will return an\nerror. In this case the clients mutex remained unlocked leading to a\ndeadlock inside nouveau_drm_postclose or any other nouveau ioctl call.

In the Linux kernel, the following vulnerability has been resolved:\n\ntee: optee: Fix kernel panic caused by incorrect error handling\n\nThe error path while failing to register devices on the TEE bus has a\nbug leading to kernel panic as follows:\n\n[ 15.398930] Unable to handle kernel paging request at virtual address ffff07ed00626d7c\n[ 15.406913] Mem abort info:\n[ 15.409722] ESR = 0x0000000096000005\n[ 15.413490] EC = 0x25: DABT (current EL), IL = 32 bits\n[ 15.418814] SET = 0, FnV = 0\n[ 15.421878] EA = 0, S1PTW = 0\n[ 15.425031] FSC = 0x05: level 1 translation fault\n[ 15.429922] Data abort info:\n[ 15.432813] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000\n[ 15.438310] CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[ 15.443372] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[ 15.448697] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000d9e3e000\n[ 15.455413] [ffff07ed00626d7c] pgd=1800000bffdf9003, p4d=1800000bffdf9003, pud=0000000000000000\n[ 15.464146] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP\n\nCommit 7269cba53d90 ("tee: optee: Fix supplicant based device enumeration")\nlead to the introduction of this bug. So fix it appropriately.

In the Linux kernel, the following vulnerability has been resolved:\n\nnvme: fix reconnection fail due to reserved tag allocation\n\nWe found a issue on production environment while using NVMe over RDMA,\nadmin_q reconnect failed forever while remote target and network is ok.\nAfter dig into it, we found it may caused by a ABBA deadlock due to tag\nallocation. In my case, the tag was hold by a keep alive request\nwaiting inside admin_q, as we quiesced admin_q while reset ctrl, so the\nrequest maked as idle and will not process before reset success. As\nfabric_q shares tagset with admin_q, while reconnect remote target, we\nneed a tag for connect command, but the only one reserved tag was held\nby keep alive command which waiting inside admin_q. As a result, we\nfailed to reconnect admin_q forever. In order to fix this issue, I\nthink we should keep two reserved tags for admin queue.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: mctp: take ownership of skb in mctp_local_output\n\nCurrently, mctp_local_output only takes ownership of skb on success, and\nwe may leak an skb if mctp_local_output fails in specific states; the\nskb ownership isn't transferred until the actual output routing occurs.\n\nInstead, make mctp_local_output free the skb on all error paths up to\nthe route action, so it always consumes the passed skb.

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_event: Fix handling of HCI_EV_IO_CAPA_REQUEST\n\nIf we received HCI_EV_IO_CAPA_REQUEST while\nHCI_OP_READ_REMOTE_EXT_FEATURES is yet to be responded assume the remote\ndoes support SSP since otherwise this event shouldn't be generated.

In the Linux kernel, the following vulnerability has been resolved:\n\npower: supply: bq27xxx-i2c: Do not free non existing IRQ\n\nThe bq27xxx i2c-client may not have an IRQ, in which case\nclient->irq will be 0. bq27xxx_battery_i2c_probe() already has\nan if (client->irq) check wrapping the request_threaded_irq().\n\nBut bq27xxx_battery_i2c_remove() unconditionally calls\nfree_irq(client->irq) leading to:\n\n[ 190.310742] ------------[ cut here ]------------\n[ 190.310843] Trying to free already-free IRQ 0\n[ 190.310861] WARNING: CPU: 2 PID: 1304 at kernel/irq/manage.c:1893 free_irq+0x1b8/0x310\n\nFollowed by a backtrace when unbinding the driver. Add\nan if (client->irq) to bq27xxx_battery_i2c_remove() mirroring\nprobe() to fix this.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau: keep DMA buffers required for suspend/resume\n\nNouveau deallocates a few buffers post GPU init which are required for GPU suspend/resume to function correctly.\nThis is likely not as big an issue on systems where the NVGPU is the only GPU, but on multi-GPU set ups it leads to a regression where the kernel module errors and results in a system-wide rendering freeze.\n\nThis commit addresses that regression by moving the two buffers required for suspend and resume to be deallocated at driver unload instead of post init.

In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: dw-edma: HDMA: Add sync read before starting the DMA transfer in remote setup\n\nThe Linked list element and pointer are not stored in the same memory as\nthe HDMA controller register. If the doorbell register is toggled before\nthe full write of the linked list a race condition error will occur.\nIn remote setup we can only use a readl to the memory to assure the full\nwrite has occurred.

In the Linux kernel, the following vulnerability has been resolved:\n\nlib/Kconfig.debug: TEST_IOV_ITER depends on MMU\n\nTrying to run the iov_iter unit test on a nommu system such as the qemu\nkc705-nommu emulation results in a crash.\n\n KTAP version 1\n # Subtest: iov_iter\n # module: kunit_iov_iter\n 1..9\nBUG: failure at mm/nommu.c:318/vmap()!\nKernel panic - not syncing: BUG!\n\nThe test calls vmap() directly, but vmap() is not supported on nommu\nsystems, causing the crash. TEST_IOV_ITER therefore needs to depend on\nMMU.

In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix data races on remote_id\n\nSimilar to the previous patch, address the data race on\nremote_id, adding the suitable ONCE annotations.

In the Linux kernel, the following vulnerability has been resolved:\n\nphonet/pep: fix racy skb_queue_empty() use\n\nThe receive queues are protected by their respective spin-lock, not\nthe socket lock. This could lead to skb_peek() unexpectedly\nreturning NULL or a pointer to an already dequeued socket buffer.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: once more fix the call oder in amdgpu_ttm_move() v2\n\nThis reverts drm/amdgpu: fix ftrace event amdgpu_bo_move always move\non same heap. The basic problem here is that after the move the old\nlocation is simply not available any more.\n\nSome fixes were suggested, but essentially we should call the move\nnotification before actually moving things because only this way we have\nthe correct order for DMA-buf and VM move notifications as well.\n\nAlso rework the statistic handling so that we don't update the eviction\ncounter before the move.\n\nv2: add missing NULL check

In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: Fix Use-After-Free in tcp_ao_connect_init\n\nSince call_rcu, which is called in the hlist_for_each_entry_rcu traversal\nof tcp_ao_connect_init, is not part of the RCU read critical section, it\nis possible that the RCU grace period will pass during the traversal and\nthe key will be free.\n\nTo prevent this, it should be changed to hlist_for_each_entry_safe.

In the Linux kernel, the following vulnerability has been resolved:\n\nnvme: host: fix double-free of struct nvme_id_ns in ns_update_nuse()\n\nWhen nvme_identify_ns() fails, it frees the pointer to the struct\nnvme_id_ns before it returns. However, ns_update_nuse() calls kfree()\nfor the pointer even when nvme_identify_ns() fails. This results in\nKASAN double-free, which was observed with blktests nvme/045 with\nproposed patches [1] on the kernel v6.8-rc7. Fix the double-free by\nskipping kfree() when nvme_identify_ns() fails.

In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: mcast: remove one synchronize_net() barrier in ipv6_mc_down()\n\nAs discussed in the past (commit 2d3916f31891 ("ipv6: fix skb drops\nin igmp6_event_query() and igmp6_event_report()")) I think the\nsynchronize_net() call in ipv6_mc_down() is not needed.\n\nUnder load, synchronize_net() can last between 200 usec and 5 ms.\n\nKASAN seems to agree as well.

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix race when detecting delalloc ranges during fiemap\n\nFor fiemap we recently stopped locking the target extent range for the\nwhole duration of the fiemap call, in order to avoid a deadlock in a\nscenario where the fiemap buffer happens to be a memory mapped range of\nthe same file. This use case is very unlikely to be useful in practice but\nit may be triggered by fuzz testing (syzbot, etc).\n\nThis however introduced a race that makes us miss delalloc ranges for\nfile regions that are currently holes, so the caller of fiemap will not\nbe aware that there's data for some file regions. This can be quite\nserious for some use cases - for example in coreutils versions before 9.0,\nthe cp program used fiemap to detect holes and data in the source file,\ncopying only regions with data (extents or delalloc) from the source file\nto the destination file in order to preserve holes (see the documentation\nfor its --sparse command line option). This means that if cp was used\nwith a source file that had delalloc in a hole, the destination file could\nend up without that data, which is effectively a data loss issue, if it\nhappened to hit the race described below.\n\nThe race happens like this:\n\n1) Fiemap is called, without the FIEMAP_FLAG_SYNC flag, for a file that\n has delalloc in the file range [64M, 65M[, which is currently a hole;\n\n2) Fiemap locks the inode in shared mode, then starts iterating the\n inode's subvolume tree searching for file extent items, without having\n the whole fiemap target range locked in the inode's io tree - the\n change introduced recently by commit b0ad381fa769 ("btrfs: fix\n deadlock with fiemap and extent locking"). It only locks ranges in\n the io tree when it finds a hole or prealloc extent since that\n commit;\n\n3) Note that fiemap clones each leaf before using it, and this is to\n avoid deadlocks when locking a file range in the inode's io tree and\n the fiemap buffer is memory mapped to some file, because writing\n to the page with btrfs_page_mkwrite() will wait on any ordered extent\n for the page's range and the ordered extent needs to lock the range\n and may need to modify the same leaf, therefore leading to a deadlock\n on the leaf;\n\n4) While iterating the file extent items in the cloned leaf before\n finding the hole in the range [64M, 65M[, the delalloc in that range\n is flushed and its ordered extent completes - meaning the corresponding\n file extent item is in the inode's subvolume tree, but not present in\n the cloned leaf that fiemap is iterating over;\n\n5) When fiemap finds the hole in the [64M, 65M[ range by seeing the gap in\n the cloned leaf (or a file extent item with disk_bytenr == 0 in case\n the NO_HOLES feature is not enabled), it will lock that file range in\n the inode's io tree and then search for delalloc by checking for the\n EXTENT_DELALLOC bit in the io tree for that range and ordered extents\n (with btrfs_find_delalloc_in_range()). But it finds nothing since the\n delalloc in that range was already flushed and the ordered extent\n completed and is gone - as a result fiemap will not report that there's\n delalloc or an extent for the range [64M, 65M[, so user space will be\n mislead into thinking that there's a hole in that range.\n\nThis could actually be sporadically triggered with test case generic/094\nfrom fstests, which reports a missing extent/delalloc range like this:\n\n generic/094 2s ... - output mismatch (see /home/fdmanana/git/hub/xfstests/results//generic/094.out.bad)\n --- tests/generic/094.out 2020-06-10 19:29:03.830519425 +0100\n +++ /home/fdmanana/git/hub/xfstests/results//generic/094.out.bad 2024-02-28 11:00:00.381071525 +0000\n @@ -1,3 +1,9 @@\n QA output created by 094\n fiemap run with sync\n fiemap run without sync\n +ERROR: couldn't find extent at 7\n +map is 'HHDDHPPDPHPH'\n +logical: [ 5.. 6] phys: 301517.. 301518 flags: 0x800 tot: 2\n +logical: [ 8.. 8] phys: 301520.. 301520 flags: 0x800 tot: 1\n ...\n (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/generic/094.out /home/fdmanana/git/hub/xfstests/results//generic/094.out.bad' to see the entire diff)\n\nSo in order to fix this, while still avoiding deadlocks in the case where\nthe fiemap buffer is memory mapped to the same file, change fiemap to work\nlike the following:\n\n1) Always lock the whole range in the inode's io tree before starting to\n iterate the inode's subvolume tree searching for file extent items,\n just like we did before commit b0ad381fa769 ("btrfs: fix deadlock with\n fiemap and extent locking");\n\n2) Now instead of writing to the fiemap buffer every time we have an extent\n to report, write instead to a temporary buffer (1 page), and when that\n buffer becomes full, stop iterating the file extent items, unlock the\n range in the io tree, release the search path, submit all the entries\n kept in that buffer to the fiemap buffer, and then resume the search\n for file extent items after locking again the remainder of the range in\n the io tree.\n\n The buffer having a size of a page, allows for 146 entries in a system\n with 4K pages. This is a large enough value to have a good performance\n by avoiding too many restarts of the search for file extent items.\n In other words this preserves the huge performance gains made in the\n last two years to fiemap, while avoiding the deadlocks in case the\n fiemap buffer is memory mapped to the same file (useless in practice,\n but possible and exercised by fuzz testing and syzbot).

In the Linux kernel, the following vulnerability has been resolved:\n\nbacklight: hx8357: Fix potential NULL pointer dereference\n\nThe "im" pins are optional. Add missing check in the hx8357_probe().

In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to avoid use-after-free issue in f2fs_filemap_fault\n\nsyzbot reports a f2fs bug as below:\n\nBUG: KASAN: slab-use-after-free in f2fs_filemap_fault+0xd1/0x2c0 fs/f2fs/file.c:49\nRead of size 8 at addr ffff88807bb22680 by task syz-executor184/5058\n\nCPU: 0 PID: 5058 Comm: syz-executor184 Not tainted 6.7.0-syzkaller-09928-g052d534373b7 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x163/0x540 mm/kasan/report.c:488\n kasan_report+0x142/0x170 mm/kasan/report.c:601\n f2fs_filemap_fault+0xd1/0x2c0 fs/f2fs/file.c:49\n __do_fault+0x131/0x450 mm/memory.c:4376\n do_shared_fault mm/memory.c:4798 [inline]\n do_fault mm/memory.c:4872 [inline]\n do_pte_missing mm/memory.c:3745 [inline]\n handle_pte_fault mm/memory.c:5144 [inline]\n __handle_mm_fault+0x23b7/0x72b0 mm/memory.c:5285\n handle_mm_fault+0x27e/0x770 mm/memory.c:5450\n do_user_addr_fault arch/x86/mm/fault.c:1364 [inline]\n handle_page_fault arch/x86/mm/fault.c:1507 [inline]\n exc_page_fault+0x456/0x870 arch/x86/mm/fault.c:1563\n asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:570\n\nThe root cause is: in f2fs_filemap_fault(), vmf->vma may be not alive after\nfilemap_fault(), so it may cause use-after-free issue when accessing\nvmf->vma->vm_flags in trace_f2fs_filemap_fault(). So it needs to keep vm_flags\nin separated temporary variable for tracepoint use.

In the Linux kernel, the following vulnerability has been resolved:\n\novl: relax WARN_ON in ovl_verify_area()\n\nsyzbot hit an assertion in copy up data loop which looks like it is\nthe result of a lower file whose size is being changed underneath\noverlayfs.\n\nThis type of use case is documented to cause undefined behavior, so\nreturning EIO error for the copy up makes sense, but it should not be\ncausing a WARN_ON assertion.

In the Linux kernel, the following vulnerability has been resolved:\n\nthermal/drivers/mediatek/lvts_thermal: Fix a memory leak in an error handling path\n\nIf devm_krealloc() fails, then 'efuse' is leaking.\nSo free it to avoid a leak.

In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio: packed: fix unmap leak for indirect desc table\n\nWhen use_dma_api and premapped are true, then the do_unmap is false.\n\nBecause the do_unmap is false, vring_unmap_extra_packed is not called by\ndetach_buf_packed.\n\n if (unlikely(vq->do_unmap)) {\n curr = id;\n for (i = 0; i < state->num; i++) {\n vring_unmap_extra_packed(vq,\n &vq->packed.desc_extra[curr]);\n curr = vq->packed.desc_extra[curr].next;\n }\n }\n\nSo the indirect desc table is not unmapped. This causes the unmap leak.\n\nSo here, we check vq->use_dma_api instead. Synchronously, dma info is\nupdated based on use_dma_api judgment\n\nThis bug does not occur, because no driver use the premapped with\nindirect.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: Fix a memory leak in nf_tables_updchain\n\nIf nft_netdev_register_hooks() fails, the memory associated with\nnft_stats is not freed, causing a memory leak.\n\nThis patch fixes it by moving nft_stats_alloc() down after\nnft_netdev_register_hooks() succeeds.

In the Linux kernel, the following vulnerability has been resolved:\n\nleds: trigger: netdev: Fix kernel panic on interface rename trig notify\n\nCommit d5e01266e7f5 ("leds: trigger: netdev: add additional specific link\nspeed mode") in the various changes, reworked the way to set the LINKUP\nmode in commit cee4bd16c319 ("leds: trigger: netdev: Recheck\nNETDEV_LED_MODE_LINKUP on dev rename") and moved it to a generic function.\n\nThis changed the logic where, in the previous implementation the dev\nfrom the trigger event was used to check if the carrier was ok, but in\nthe new implementation with the generic function, the dev in\ntrigger_data is used instead.\n\nThis is problematic and cause a possible kernel panic due to the fact\nthat the dev in the trigger_data still reference the old one as the\nnew one (passed from the trigger event) still has to be hold and saved\nin the trigger_data struct (done in the NETDEV_REGISTER case).\n\nOn calling of get_device_state(), an invalid net_dev is used and this\ncause a kernel panic.\n\nTo handle this correctly, move the call to get_device_state() after the\nnew net_dev is correctly set in trigger_data (in the NETDEV_REGISTER\ncase) and correctly parse the new dev.

In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: sun8i-ce - Fix use after free in unprepare\n\nsun8i_ce_cipher_unprepare should be called before\ncrypto_finalize_skcipher_request, because client callbacks may\nimmediately free memory, that isn't needed anymore. But it will be\nused by unprepare after free. Before removing prepare/unprepare\ncallbacks it was handled by crypto engine in crypto_finalize_request.\n\nUsually that results in a pointer dereference problem during a in\ncrypto selftest.\n Unable to handle kernel NULL pointer dereference at\n virtual address 0000000000000030\n Mem 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\n Data abort info:\n ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n user pgtable: 4k pages, 48-bit VAs, pgdp=000000004716d000\n [0000000000000030] pgd=0000000000000000, p4d=0000000000000000\n Internal error: Oops: 0000000096000004 [#1] SMP\n\nThis problem is detected by KASAN as well.\n ==================================================================\n BUG: KASAN: slab-use-after-free in sun8i_ce_cipher_do_one+0x6e8/0xf80 [sun8i_ce]\n Read of size 8 at addr ffff00000dcdc040 by task 1c15000.crypto-/373\n\n Hardware name: Pine64 PinePhone (1.2) (DT)\n Call trace:\n dump_backtrace+0x9c/0x128\n show_stack+0x20/0x38\n dump_stack_lvl+0x48/0x60\n print_report+0xf8/0x5d8\n kasan_report+0x90/0xd0\n __asan_load8+0x9c/0xc0\n sun8i_ce_cipher_do_one+0x6e8/0xf80 [sun8i_ce]\n crypto_pump_work+0x354/0x620 [crypto_engine]\n kthread_worker_fn+0x244/0x498\n kthread+0x168/0x178\n ret_from_fork+0x10/0x20\n\n Allocated by task 379:\n kasan_save_stack+0x3c/0x68\n kasan_set_track+0x2c/0x40\n kasan_save_alloc_info+0x24/0x38\n __kasan_kmalloc+0xd4/0xd8\n __kmalloc+0x74/0x1d0\n alg_test_skcipher+0x90/0x1f0\n alg_test+0x24c/0x830\n cryptomgr_test+0x38/0x60\n kthread+0x168/0x178\n ret_from_fork+0x10/0x20\n\n Freed by task 379:\n kasan_save_stack+0x3c/0x68\n kasan_set_track+0x2c/0x40\n kasan_save_free_info+0x38/0x60\n __kasan_slab_free+0x100/0x170\n slab_free_freelist_hook+0xd4/0x1e8\n __kmem_cache_free+0x15c/0x290\n kfree+0x74/0x100\n kfree_sensitive+0x80/0xb0\n alg_test_skcipher+0x12c/0x1f0\n alg_test+0x24c/0x830\n cryptomgr_test+0x38/0x60\n kthread+0x168/0x178\n ret_from_fork+0x10/0x20\n\n The buggy address belongs to the object at ffff00000dcdc000\n which belongs to the cache kmalloc-256 of size 256\n The buggy address is located 64 bytes inside of\n freed 256-byte region [ffff00000dcdc000, ffff00000dcdc100)

In the Linux kernel, the following vulnerability has been resolved:\n\nthunderbolt: Fix NULL pointer dereference in tb_port_update_credits()\n\nOlliver reported that his system crashes when plugging in Thunderbolt 1\ndevice:\n\n BUG: kernel NULL pointer dereference, address: 0000000000000020\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 NOPTI\n RIP: 0010:tb_port_do_update_credits+0x1b/0x130 [thunderbolt]\n Call Trace:\n <TASK>\n ? __die+0x23/0x70\n ? page_fault_oops+0x171/0x4e0\n ? exc_page_fault+0x7f/0x180\n ? asm_exc_page_fault+0x26/0x30\n ? tb_port_do_update_credits+0x1b/0x130\n ? tb_switch_update_link_attributes+0x83/0xd0\n tb_switch_add+0x7a2/0xfe0\n tb_scan_port+0x236/0x6f0\n tb_handle_hotplug+0x6db/0x900\n process_one_work+0x171/0x340\n worker_thread+0x27b/0x3a0\n ? __pfx_worker_thread+0x10/0x10\n kthread+0xe5/0x120\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x31/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1b/0x30\n </TASK>\n\nThis is due the fact that some Thunderbolt 1 devices only have one lane\nadapter. Fix this by checking for the lane 1 before we read its credits.

In the Linux kernel, the following vulnerability has been resolved:\n\ntmpfs: fix race on handling dquot rbtree\n\nA syzkaller reproducer found a race while attempting to remove dquot\ninformation from the rb tree.\n\nFetching the rb_tree root node must also be protected by the\ndqopt->dqio_sem, otherwise, giving the right timing, shmem_release_dquot()\nwill trigger a warning because it couldn't find a node in the tree, when\nthe real reason was the root node changing before the search starts:\n\nThread 1 Thread 2\n- shmem_release_dquot() - shmem_{acquire,release}_dquot()\n\n- fetch ROOT - Fetch ROOT\n\n - acquire dqio_sem\n- wait dqio_sem\n\n - do something, triger a tree rebalance\n - release dqio_sem\n\n- acquire dqio_sem\n- start searching for the node, but\n from the wrong location, missing\n the node, and triggering a warning.

In the Linux kernel, the following vulnerability has been resolved:\n\nlibbpf: Use OPTS_SET() macro in bpf_xdp_query()\n\nWhen the feature_flags and xdp_zc_max_segs fields were added to the libbpf\nbpf_xdp_query_opts, the code writing them did not use the OPTS_SET() macro.\nThis causes libbpf to write to those fields unconditionally, which means\nthat programs compiled against an older version of libbpf (with a smaller\nsize of the bpf_xdp_query_opts struct) will have its stack corrupted by\nlibbpf writing out of bounds.\n\nThe patch adding the feature_flags field has an early bail out if the\nfeature_flags field is not part of the opts struct (via the OPTS_HAS)\nmacro, but the patch adding xdp_zc_max_segs does not. For consistency, this\nfix just changes the assignments to both fields to use the OPTS_SET()\nmacro.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mt76: mt7925e: fix use-after-free in free_irq()\n\n>From commit a304e1b82808 ("[PATCH] Debug shared irqs"), there is a test\nto make sure the shared irq handler should be able to handle the unexpected\nevent after deregistration. For this case, let's apply MT76_REMOVED flag to\nindicate the device was removed and do not run into the resource access\nanymore.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: fix phy_get_internal_delay accessing an empty array\n\nThe phy_get_internal_delay function could try to access to an empty\narray in the case that the driver is calling phy_get_internal_delay\nwithout defining delay_values and rx-internal-delay-ps or\ntx-internal-delay-ps is defined to 0 in the device-tree.\nThis will lead to "unable to handle kernel NULL pointer dereference at\nvirtual address 0". To avoid this kernel oops, the test should be delay\n>= 0. As there is already delay < 0 test just before, the test could\nonly be size == 0.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: fix NULL checks for adev->dm.dc in amdgpu_dm_fini()\n\nSince 'adev->dm.dc' in amdgpu_dm_fini() might turn out to be NULL\nbefore the call to dc_enable_dmub_notifications(), check\nbeforehand to ensure there will not be a possible NULL-ptr-deref\nthere.\n\nAlso, since commit 1e88eb1b2c25 ("drm/amd/display: Drop\nCONFIG_DRM_AMD_DC_HDCP") there are two separate checks for NULL in\n'adev->dm.dc' before dc_deinit_callbacks() and dc_dmub_srv_destroy().\nClean up by combining them all under one 'if'.\n\nFound by Linux Verification Center (linuxtesting.org) with static\nanalysis tool SVACE.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Add 'replay' NULL check in 'edp_set_replay_allow_active()'\n\nIn the first if statement, we're checking if 'replay' is NULL. But in\nthe second if statement, we're not checking if 'replay' is NULL again\nbefore calling replay->funcs->replay_set_power_opt().\n\nif (replay == NULL && force_static)\n return false;\n\n...\n\nif (link->replay_settings.replay_feature_enabled &&\n replay->funcs->replay_set_power_opt) {\n replay->funcs->replay_set_power_opt(replay, *power_opts, panel_inst);\n link->replay_settings.replay_power_opt_active = *power_opts;\n}\n\nIf 'replay' is NULL, this will cause a null pointer dereference.\n\nFixes the below found by smatch:\ndrivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_edp_panel_control.c:895 edp_set_replay_allow_active() error: we previously assumed 'replay' could be null (see line 887)

In the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Fix nfs_netfs_issue_read() xarray locking for writeback interrupt\n\nThe loop inside nfs_netfs_issue_read() currently does not disable\ninterrupts while iterating through pages in the xarray to submit\nfor NFS read. This is not safe though since after taking xa_lock,\nanother page in the mapping could be processed for writeback inside\nan interrupt, and deadlock can occur. The fix is simple and clean\nif we use xa_for_each_range(), which handles the iteration with RCU\nwhile reducing code complexity.\n\nThe problem is easily reproduced with the following test:\n mount -o vers=3,fsc 127.0.0.1:/export /mnt/nfs\n dd if=/dev/zero of=/mnt/nfs/file1.bin bs=4096 count=1\n echo 3 > /proc/sys/vm/drop_caches\n dd if=/mnt/nfs/file1.bin of=/dev/null\n umount /mnt/nfs\n\nOn the console with a lockdep-enabled kernel a message similar to\nthe following will be seen:\n\n ================================\n WARNING: inconsistent lock state\n 6.7.0-lockdbg+ #10 Not tainted\n --------------------------------\n inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.\n test5/1708 [HC0[0]:SC0[0]:HE1:SE1] takes:\n ffff888127baa598 (&xa->xa_lock#4){+.?.}-{3:3}, at:\nnfs_netfs_issue_read+0x1b2/0x4b0 [nfs]\n {IN-SOFTIRQ-W} state was registered at:\n lock_acquire+0x144/0x380\n _raw_spin_lock_irqsave+0x4e/0xa0\n __folio_end_writeback+0x17e/0x5c0\n folio_end_writeback+0x93/0x1b0\n iomap_finish_ioend+0xeb/0x6a0\n blk_update_request+0x204/0x7f0\n blk_mq_end_request+0x30/0x1c0\n blk_complete_reqs+0x7e/0xa0\n __do_softirq+0x113/0x544\n __irq_exit_rcu+0xfe/0x120\n irq_exit_rcu+0xe/0x20\n sysvec_call_function_single+0x6f/0x90\n asm_sysvec_call_function_single+0x1a/0x20\n pv_native_safe_halt+0xf/0x20\n default_idle+0x9/0x20\n default_idle_call+0x67/0xa0\n do_idle+0x2b5/0x300\n cpu_startup_entry+0x34/0x40\n start_secondary+0x19d/0x1c0\n secondary_startup_64_no_verify+0x18f/0x19b\n irq event stamp: 176891\n hardirqs last enabled at (176891): [<ffffffffa67a0be4>]\n_raw_spin_unlock_irqrestore+0x44/0x60\n hardirqs last disabled at (176890): [<ffffffffa67a0899>]\n_raw_spin_lock_irqsave+0x79/0xa0\n softirqs last enabled at (176646): [<ffffffffa515d91e>]\n__irq_exit_rcu+0xfe/0x120\n softirqs last disabled at (176633): [<ffffffffa515d91e>]\n__irq_exit_rcu+0xfe/0x120\n\n other info that might help us debug this:\n Possible unsafe locking scenario:\n\n CPU0\n ----\n lock(&xa->xa_lock#4);\n <Interrupt>\n lock(&xa->xa_lock#4);\n\n *** DEADLOCK ***\n\n 2 locks held by test5/1708:\n #0: ffff888127baa498 (&sb->s_type->i_mutex_key#22){++++}-{4:4}, at:\n nfs_start_io_read+0x28/0x90 [nfs]\n #1: ffff888127baa650 (mapping.invalidate_lock#3){.+.+}-{4:4}, at:\n page_cache_ra_unbounded+0xa4/0x280\n\n stack backtrace:\n CPU: 6 PID: 1708 Comm: test5 Kdump: loaded Not tainted 6.7.0-lockdbg+\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39\n04/01/2014\n Call Trace:\n dump_stack_lvl+0x5b/0x90\n mark_lock+0xb3f/0xd20\n __lock_acquire+0x77b/0x3360\n _raw_spin_lock+0x34/0x80\n nfs_netfs_issue_read+0x1b2/0x4b0 [nfs]\n netfs_begin_read+0x77f/0x980 [netfs]\n nfs_netfs_readahead+0x45/0x60 [nfs]\n nfs_readahead+0x323/0x5a0 [nfs]\n read_pages+0xf3/0x5c0\n page_cache_ra_unbounded+0x1c8/0x280\n filemap_get_pages+0x38c/0xae0\n filemap_read+0x206/0x5e0\n nfs_file_read+0xb7/0x140 [nfs]\n vfs_read+0x2a9/0x460\n ksys_read+0xb7/0x140

In the Linux kernel, the following vulnerability has been resolved:\n\ndpll: fix dpll_xa_ref_*_del() for multiple registrations\n\nCurrently, if there are multiple registrations of the same pin on the\nsame dpll device, following warnings are observed:\nWARNING: CPU: 5 PID: 2212 at drivers/dpll/dpll_core.c:143 dpll_xa_ref_pin_del.isra.0+0x21e/0x230\nWARNING: CPU: 5 PID: 2212 at drivers/dpll/dpll_core.c:223 __dpll_pin_unregister+0x2b3/0x2c0\n\nThe problem is, that in both dpll_xa_ref_dpll_del() and\ndpll_xa_ref_pin_del() registration is only removed from list in case the\nreference count drops to zero. That is wrong, the registration has to\nbe removed always.\n\nTo fix this, remove the registration from the list and free\nit unconditionally, instead of doing it only when the ref reference\ncounter reaches zero.

In the Linux kernel, the following vulnerability has been resolved:\n\nvmxnet3: Fix missing reserved tailroom\n\nUse rbi->len instead of rcd->len for non-dataring packet.\n\nFound issue:\n XDP_WARN: xdp_update_frame_from_buff(line:278): Driver BUG: missing reserved tailroom\n WARNING: CPU: 0 PID: 0 at net/core/xdp.c:586 xdp_warn+0xf/0x20\n CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W O 6.5.1 #1\n RIP: 0010:xdp_warn+0xf/0x20\n ...\n ? xdp_warn+0xf/0x20\n xdp_do_redirect+0x15f/0x1c0\n vmxnet3_run_xdp+0x17a/0x400 [vmxnet3]\n vmxnet3_process_xdp+0xe4/0x760 [vmxnet3]\n ? vmxnet3_tq_tx_complete.isra.0+0x21e/0x2c0 [vmxnet3]\n vmxnet3_rq_rx_complete+0x7ad/0x1120 [vmxnet3]\n vmxnet3_poll_rx_only+0x2d/0xa0 [vmxnet3]\n __napi_poll+0x20/0x180\n net_rx_action+0x177/0x390

In the Linux kernel, the following vulnerability has been resolved:\n\nmd: Fix missing release of 'active_io' for flush\n\nsubmit_flushes\n atomic_set(&mddev->flush_pending, 1);\n rdev_for_each_rcu(rdev, mddev)\n atomic_inc(&mddev->flush_pending);\n bi->bi_end_io = md_end_flush\n submit_bio(bi);\n /* flush io is done first */\n md_end_flush\n if (atomic_dec_and_test(&mddev->flush_pending))\n percpu_ref_put(&mddev->active_io)\n -> active_io is not released\n\n if (atomic_dec_and_test(&mddev->flush_pending))\n -> missing release of active_io\n\nFor consequence, mddev_suspend() will wait for 'active_io' to be zero\nforever.\n\nFix this problem by releasing 'active_io' in submit_flushes() if\n'flush_pending' is decreased to zero.

In the Linux kernel, the following vulnerability has been resolved:\n\nr8169: fix LED-related deadlock on module removal\n\nBinding devm_led_classdev_register() to the netdev is problematic\nbecause on module removal we get a RTNL-related deadlock. Fix this\nby avoiding the device-managed LED functions.\n\nNote: We can safely call led_classdev_unregister() for a LED even\nif registering it failed, because led_classdev_unregister() detects\nthis and is a no-op in this case.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: flowtable: validate pppoe header\n\nEnsure there is sufficient room to access the protocol field of the\nPPPoe header. Validate it once before the flowtable lookup, then use a\nhelper function to access protocol field.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: flowtable: incorrect pppoe tuple\n\npppoe traffic reaching ingress path does not match the flowtable entry\nbecause the pppoe header is expected to be at the network header offset.\nThis bug causes a mismatch in the flow table lookup, so pppoe packets\nenter the classical forwarding path.

In the Linux kernel, the following vulnerability has been resolved:\n\nthermal/debugfs: Add missing count increment to thermal_debug_tz_trip_up()\n\nThe count field in struct trip_stats, representing the number of times\nthe zone temperature was above the trip point, needs to be incremented\nin thermal_debug_tz_trip_up(), for two reasons.\n\nFirst, if a trip point is crossed on the way up for the first time,\nthermal_debug_update_temp() called from update_temperature() does\nnot see it because it has not been added to trips_crossed[] array\nin the thermal zone's struct tz_debugfs object yet. Therefore, when\nthermal_debug_tz_trip_up() is called after that, the trip point's\ncount value is 0, and the attempt to divide by it during the average\ntemperature computation leads to a divide error which causes the kernel\nto crash. Setting the count to 1 before the division by incrementing it\nfixes this problem.\n\nSecond, if a trip point is crossed on the way up, but it has been\ncrossed on the way up already before, its count value needs to be\nincremented to make a record of the fact that the zone temperature is\nabove the trip now. Without doing that, if the mitigations applied\nafter crossing the trip cause the zone temperature to drop below its\nthreshold, the count will not be updated for this episode at all and\nthe average temperature in the trip statistics record will be somewhat\nhigher than it should be.\n\nCc :6.8+ <stable@vger.kernel.org> # 6.8+

In the Linux kernel, the following vulnerability has been resolved:\n\ninterconnect: Don't access req_list while it's being manipulated\n\nThe icc_lock mutex was split into separate icc_lock and icc_bw_lock\nmutexes in [1] to avoid lockdep splats. However, this didn't adequately\nprotect access to icc_node::req_list.\n\nThe icc_set_bw() function will eventually iterate over req_list while\nonly holding icc_bw_lock, but req_list can be modified while only\nholding icc_lock. This causes races between icc_set_bw(), of_icc_get(),\nand icc_put().\n\nExample A:\n\n CPU0 CPU1\n ---- ----\n icc_set_bw(path_a)\n mutex_lock(&icc_bw_lock);\n icc_put(path_b)\n mutex_lock(&icc_lock);\n aggregate_requests()\n hlist_for_each_entry(r, ...\n hlist_del(...\n <r = invalid pointer>\n\nExample B:\n\n CPU0 CPU1\n ---- ----\n icc_set_bw(path_a)\n mutex_lock(&icc_bw_lock);\n path_b = of_icc_get()\n of_icc_get_by_index()\n mutex_lock(&icc_lock);\n path_find()\n path_init()\n aggregate_requests()\n hlist_for_each_entry(r, ...\n hlist_add_head(...\n <r = invalid pointer>\n\nFix this by ensuring icc_bw_lock is always held before manipulating\nicc_node::req_list. The additional places icc_bw_lock is held don't\nperform any memory allocations, so we should still be safe from the\noriginal lockdep splats that motivated the separate locks.\n\n[1] commit af42269c3523 ("interconnect: Fix locking for runpm vs reclaim")

In the Linux kernel, the following vulnerability has been resolved:\n\nclk: Get runtime PM before walking tree for clk_summary\n\nSimilar to the previous commit, we should make sure that all devices are\nruntime resumed before printing the clk_summary through debugfs. Failure\nto do so would result in a deadlock if the thread is resuming a device\nto print clk state and that device is also runtime resuming in another\nthread, e.g the screen is turning on and the display driver is starting\nup. We remove the calls to clk_pm_runtime_{get,put}() in this path\nbecause they're superfluous now that we know the devices are runtime\nresumed. This also squashes a bug where the return value of\nclk_pm_runtime_get() wasn't checked, leading to an RPM count underflow\non error paths.

In the Linux kernel, the following vulnerability has been resolved:\n\nserial: core: Clearing the circular buffer before NULLifying it\n\nThe circular buffer is NULLified in uart_tty_port_shutdown()\nunder the spin lock. However, the PM or other timer based callbacks\nmay still trigger after this event without knowning that buffer pointer\nis not valid. Since the serial code is a bit inconsistent in checking\nthe buffer state (some rely on the head-tail positions, some on the\nbuffer pointer), it's better to have both aligned, i.e. buffer pointer\nto be NULL and head-tail possitions to be the same, meaning it's empty.\nThis will prevent asynchronous calls to dereference NULL pointer as\nreported recently in 8250 case:\n\n BUG: kernel NULL pointer dereference, address: 00000cf5\n Workqueue: pm pm_runtime_work\n EIP: serial8250_tx_chars (drivers/tty/serial/8250/8250_port.c:1809)\n ...\n ? serial8250_tx_chars (drivers/tty/serial/8250/8250_port.c:1809)\n __start_tx (drivers/tty/serial/8250/8250_port.c:1551)\n serial8250_start_tx (drivers/tty/serial/8250/8250_port.c:1654)\n serial_port_runtime_suspend (include/linux/serial_core.h:667 drivers/tty/serial/serial_port.c:63)\n __rpm_callback (drivers/base/power/runtime.c:393)\n ? serial_port_remove (drivers/tty/serial/serial_port.c:50)\n rpm_suspend (drivers/base/power/runtime.c:447)\n\nThe proposed change will prevent ->start_tx() to be called during\nsuspend on shut down port.

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: dwc2: host: Fix dereference issue in DDMA completion flow.\n\nFixed variable dereference issue in DDMA completion flow.

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: tcpm: Correct the PDO counting in pd_set\n\nOff-by-one errors happen because nr_snk_pdo and nr_src_pdo are\nincorrectly added one. The index of the loop is equal to the number of\nPDOs to be updated when leaving the loop and it doesn't need to be added\none.\n\nWhen doing the power negotiation, TCPM relies on the "nr_snk_pdo" as\nthe size of the local sink PDO array to match the Source capabilities\nof the partner port. If the off-by-one overflow occurs, a wrong RDO\nmight be sent and unexpected power transfer might happen such as over\nvoltage or over current (than expected).\n\n"nr_src_pdo" is used to set the Rp level when the port is in Source\nrole. It is also the array size of the local Source capabilities when\nfilling up the buffer which will be sent as the Source PDOs (such as\nin Power Negotiation). If the off-by-one overflow occurs, a wrong Rp\nlevel might be set and wrong Source PDOs will be sent to the partner\nport. This could potentially cause over current or port resets.

In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86/pmu: Disable support for adaptive PEBS\n\nDrop support for virtualizing adaptive PEBS, as KVM's implementation is\narchitecturally broken without an obvious/easy path forward, and because\nexposing adaptive PEBS can leak host LBRs to the guest, i.e. can leak\nhost kernel addresses to the guest.\n\nBug #1 is that KVM doesn't account for the upper 32 bits of\nIA32_FIXED_CTR_CTRL when (re)programming fixed counters, e.g\nfixed_ctrl_field() drops the upper bits, reprogram_fixed_counters()\nstores local variables as u8s and truncates the upper bits too, etc.\n\nBug #2 is that, because KVM _always_ sets precise_ip to a non-zero value\nfor PEBS events, perf will _always_ generate an adaptive record, even if\nthe guest requested a basic record. Note, KVM will also enable adaptive\nPEBS in individual *counter*, even if adaptive PEBS isn't exposed to the\nguest, but this is benign as MSR_PEBS_DATA_CFG is guaranteed to be zero,\ni.e. the guest will only ever see Basic records.\n\nBug #3 is in perf. intel_pmu_disable_fixed() doesn't clear the upper\nbits either, i.e. leaves ICL_FIXED_0_ADAPTIVE set, and\nintel_pmu_enable_fixed() effectively doesn't clear ICL_FIXED_0_ADAPTIVE\neither. I.e. perf _always_ enables ADAPTIVE counters, regardless of what\nKVM requests.\n\nBug #4 is that adaptive PEBS *might* effectively bypass event filters set\nby the host, as "Updated Memory Access Info Group" records information\nthat might be disallowed by userspace via KVM_SET_PMU_EVENT_FILTER.\n\nBug #5 is that KVM doesn't ensure LBR MSRs hold guest values (or at least\nzeros) when entering a vCPU with adaptive PEBS, which allows the guest\nto read host LBRs, i.e. host RIPs/addresses, by enabling "LBR Entries"\nrecords.\n\nDisable adaptive PEBS support as an immediate fix due to the severity of\nthe LBR leak in particular, and because fixing all of the bugs will be\nnon-trivial, e.g. not suitable for backporting to stable kernels.\n\nNote! This will break live migration, but trying to make KVM play nice\nwith live migration would be quite complicated, wouldn't be guaranteed to\nwork (i.e. KVM might still kill/confuse the guest), and it's not clear\nthat there are any publicly available VMMs that support adaptive PEBS,\nlet alone live migrate VMs that support adaptive PEBS, e.g. QEMU doesn't\nsupport PEBS in any capacity.

In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86/mmu: x86: Don't overflow lpage_info when checking attributes\n\nFix KVM_SET_MEMORY_ATTRIBUTES to not overflow lpage_info array and trigger\nKASAN splat, as seen in the private_mem_conversions_test selftest.\n\nWhen memory attributes are set on a GFN range, that range will have\nspecific properties applied to the TDP. A huge page cannot be used when\nthe attributes are inconsistent, so they are disabled for those the\nspecific huge pages. For internal KVM reasons, huge pages are also not\nallowed to span adjacent memslots regardless of whether the backing memory\ncould be mapped as huge.\n\nWhat GFNs support which huge page sizes is tracked by an array of arrays\n'lpage_info' on the memslot, of ‘kvm_lpage_info’ structs. Each index of\nlpage_info contains a vmalloc allocated array of these for a specific\nsupported page size. The kvm_lpage_info denotes whether a specific huge\npage (GFN and page size) on the memslot is supported. These arrays include\nindices for unaligned head and tail huge pages.\n\nPreventing huge pages from spanning adjacent memslot is covered by\nincrementing the count in head and tail kvm_lpage_info when the memslot is\nallocated, but disallowing huge pages for memory that has mixed attributes\nhas to be done in a more complicated way. During the\nKVM_SET_MEMORY_ATTRIBUTES ioctl KVM updates lpage_info for each memslot in\nthe range that has mismatched attributes. KVM does this a memslot at a\ntime, and marks a special bit, KVM_LPAGE_MIXED_FLAG, in the kvm_lpage_info\nfor any huge page. This bit is essentially a permanently elevated count.\nSo huge pages will not be mapped for the GFN at that page size if the\ncount is elevated in either case: a huge head or tail page unaligned to\nthe memslot or if KVM_LPAGE_MIXED_FLAG is set because it has mixed\nattributes.\n\nTo determine whether a huge page has consistent attributes, the\nKVM_SET_MEMORY_ATTRIBUTES operation checks an xarray to make sure it\nconsistently has the incoming attribute. Since level - 1 huge pages are\naligned to level huge pages, it employs an optimization. As long as the\nlevel - 1 huge pages are checked first, it can just check these and assume\nthat if each level - 1 huge page contained within the level sized huge\npage is not mixed, then the level size huge page is not mixed. This\noptimization happens in the helper hugepage_has_attrs().\n\nUnfortunately, although the kvm_lpage_info array representing page size\n'level' will contain an entry for an unaligned tail page of size level,\nthe array for level - 1 will not contain an entry for each GFN at page\nsize level. The level - 1 array will only contain an index for any\nunaligned region covered by level - 1 huge page size, which can be a\nsmaller region. So this causes the optimization to overflow the level - 1\nkvm_lpage_info and perform a vmalloc out of bounds read.\n\nIn some cases of head and tail pages where an overflow could happen,\ncallers skip the operation completely as KVM_LPAGE_MIXED_FLAG is not\nrequired to prevent huge pages as discussed earlier. But for memslots that\nare smaller than the 1GB page size, it does call hugepage_has_attrs(). In\nthis case the huge page is both the head and tail page. The issue can be\nobserved simply by compiling the kernel with CONFIG_KASAN_VMALLOC and\nrunning the selftest “private_mem_conversions_test”, which produces the\noutput like the following:\n\nBUG: KASAN: vmalloc-out-of-bounds in hugepage_has_attrs+0x7e/0x110\nRead of size 4 at addr ffffc900000a3008 by task private_mem_con/169\nCall Trace:\n dump_stack_lvl\n print_report\n ? __virt_addr_valid\n ? hugepage_has_attrs\n ? hugepage_has_attrs\n kasan_report\n ? hugepage_has_attrs\n hugepage_has_attrs\n kvm_arch_post_set_memory_attributes\n kvm_vm_ioctl\n\nIt is a little ambiguous whether the unaligned head page (in the bug case\nalso the tail page) should be expected to have KVM_LPAGE_MIXED_FLAG set.\nIt is not functionally required, as the unaligned head/tail pages will\nalready have their kvm_lpage_info count incremented. The comments imply\nnot setting it on unaligned head pages is intentional, so fix the callers\nto skip trying to set KVM_LPAGE_MIXED_FLAG in this case, and in doing so\nnot call hugepage_has_attrs().

In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86/mmu: Write-protect L2 SPTEs in TDP MMU when clearing dirty status\n\nCheck kvm_mmu_page_ad_need_write_protect() when deciding whether to\nwrite-protect or clear D-bits on TDP MMU SPTEs, so that the TDP MMU\naccounts for any role-specific reasons for disabling D-bit dirty logging.\n\nSpecifically, TDP MMU SPTEs must be write-protected when the TDP MMU is\nbeing used to run an L2 (i.e. L1 has disabled EPT) and PML is enabled.\nKVM always disables PML when running L2, even when L1 and L2 GPAs are in\nthe some domain, so failing to write-protect TDP MMU SPTEs will cause\nwrites made by L2 to not be reflected in the dirty log.\n\n[sean: massage shortlog and changelog, tweak ternary op formatting]

In the Linux kernel, the following vulnerability has been resolved:\n\narm64: hibernate: Fix level3 translation fault in swsusp_save()\n\nOn arm64 machines, swsusp_save() faults if it attempts to access\nMEMBLOCK_NOMAP memory ranges. This can be reproduced in QEMU using UEFI\nwhen booting with rodata=off debug_pagealloc=off and CONFIG_KFENCE=n:\n\n Unable to handle kernel paging request at virtual address ffffff8000000000\n Mem abort info:\n ESR = 0x0000000096000007\n EC = 0x25: DABT (current EL), IL = 32 bits\n SET = 0, FnV = 0\n EA = 0, S1PTW = 0\n FSC = 0x07: level 3 translation fault\n Data abort info:\n ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000\n CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n swapper pgtable: 4k pages, 39-bit VAs, pgdp=00000000eeb0b000\n [ffffff8000000000] pgd=180000217fff9803, p4d=180000217fff9803, pud=180000217fff9803, pmd=180000217fff8803, pte=0000000000000000\n Internal error: Oops: 0000000096000007 [#1] SMP\n Internal error: Oops: 0000000096000007 [#1] SMP\n Modules linked in: xt_multiport ipt_REJECT nf_reject_ipv4 xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c iptable_filter bpfilter rfkill at803x snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg dwmac_generic stmmac_platform snd_hda_codec stmmac joydev pcs_xpcs snd_hda_core phylink ppdev lp parport ramoops reed_solomon ip_tables x_tables nls_iso8859_1 vfat multipath linear amdgpu amdxcp drm_exec gpu_sched drm_buddy hid_generic usbhid hid radeon video drm_suballoc_helper drm_ttm_helper ttm i2c_algo_bit drm_display_helper cec drm_kms_helper drm\n CPU: 0 PID: 3663 Comm: systemd-sleep Not tainted 6.6.2+ #76\n Source Version: 4e22ed63a0a48e7a7cff9b98b7806d8d4add7dc0\n Hardware name: Greatwall GW-XXXXXX-XXX/GW-XXXXXX-XXX, BIOS KunLun BIOS V4.0 01/19/2021\n pstate: 600003c5 (nZCv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : swsusp_save+0x280/0x538\n lr : swsusp_save+0x280/0x538\n sp : ffffffa034a3fa40\n x29: ffffffa034a3fa40 x28: ffffff8000001000 x27: 0000000000000000\n x26: ffffff8001400000 x25: ffffffc08113e248 x24: 0000000000000000\n x23: 0000000000080000 x22: ffffffc08113e280 x21: 00000000000c69f2\n x20: ffffff8000000000 x19: ffffffc081ae2500 x18: 0000000000000000\n x17: 6666662074736420 x16: 3030303030303030 x15: 3038666666666666\n x14: 0000000000000b69 x13: ffffff9f89088530 x12: 00000000ffffffea\n x11: 00000000ffff7fff x10: 00000000ffff7fff x9 : ffffffc08193f0d0\n x8 : 00000000000bffe8 x7 : c0000000ffff7fff x6 : 0000000000000001\n x5 : ffffffa0fff09dc8 x4 : 0000000000000000 x3 : 0000000000000027\n x2 : 0000000000000000 x1 : 0000000000000000 x0 : 000000000000004e\n Call trace:\n swsusp_save+0x280/0x538\n swsusp_arch_suspend+0x148/0x190\n hibernation_snapshot+0x240/0x39c\n hibernate+0xc4/0x378\n state_store+0xf0/0x10c\n kobj_attr_store+0x14/0x24\n\nThe reason is swsusp_save() -> copy_data_pages() -> page_is_saveable()\n-> kernel_page_present() assuming that a page is always present when\ncan_set_direct_map() is false (all of rodata_full,\ndebug_pagealloc_enabled() and arm64_kfence_can_set_direct_map() false),\nirrespective of the MEMBLOCK_NOMAP ranges. Such MEMBLOCK_NOMAP regions\nshould not be saved during hibernation.\n\nThis problem was introduced by changes to the pfn_valid() logic in\ncommit a7d9f306ba70 ("arm64: drop pfn_valid_within() and simplify\npfn_valid()").\n\nSimilar to other architectures, drop the !can_set_direct_map() check in\nkernel_page_present() so that page_is_savable() skips such pages.\n\n[catalin.marinas@arm.com: rework commit message]

In the Linux kernel, the following vulnerability has been resolved:\n\nmm/memory-failure: fix deadlock when hugetlb_optimize_vmemmap is enabled\n\nWhen I did hard offline test with hugetlb pages, below deadlock occurs:\n\n======================================================\nWARNING: possible circular locking dependency detected\n6.8.0-11409-gf6cef5f8c37f #1 Not tainted\n------------------------------------------------------\nbash/46904 is trying to acquire lock:\nffffffffabe68910 (cpu_hotplug_lock){++++}-{0:0}, at: static_key_slow_dec+0x16/0x60\n\nbut task is already holding lock:\nffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-> #1 (pcp_batch_high_lock){+.+.}-{3:3}:\n __mutex_lock+0x6c/0x770\n page_alloc_cpu_online+0x3c/0x70\n cpuhp_invoke_callback+0x397/0x5f0\n __cpuhp_invoke_callback_range+0x71/0xe0\n _cpu_up+0xeb/0x210\n cpu_up+0x91/0xe0\n cpuhp_bringup_mask+0x49/0xb0\n bringup_nonboot_cpus+0xb7/0xe0\n smp_init+0x25/0xa0\n kernel_init_freeable+0x15f/0x3e0\n kernel_init+0x15/0x1b0\n ret_from_fork+0x2f/0x50\n ret_from_fork_asm+0x1a/0x30\n\n-> #0 (cpu_hotplug_lock){++++}-{0:0}:\n __lock_acquire+0x1298/0x1cd0\n lock_acquire+0xc0/0x2b0\n cpus_read_lock+0x2a/0xc0\n static_key_slow_dec+0x16/0x60\n __hugetlb_vmemmap_restore_folio+0x1b9/0x200\n dissolve_free_huge_page+0x211/0x260\n __page_handle_poison+0x45/0xc0\n memory_failure+0x65e/0xc70\n hard_offline_page_store+0x55/0xa0\n kernfs_fop_write_iter+0x12c/0x1d0\n vfs_write+0x387/0x550\n ksys_write+0x64/0xe0\n do_syscall_64+0xca/0x1e0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\n\nother info that might help us debug this:\n\n Possible unsafe locking scenario:\n\n CPU0 CPU1\n ---- ----\n lock(pcp_batch_high_lock);\n lock(cpu_hotplug_lock);\n lock(pcp_batch_high_lock);\n rlock(cpu_hotplug_lock);\n\n *** DEADLOCK ***\n\n5 locks held by bash/46904:\n #0: ffff98f6c3bb23f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0\n #1: ffff98f6c328e488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0\n #2: ffff98ef83b31890 (kn->active#113){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0\n #3: ffffffffabf9db48 (mf_mutex){+.+.}-{3:3}, at: memory_failure+0x44/0xc70\n #4: ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40\n\nstack backtrace:\nCPU: 10 PID: 46904 Comm: bash Kdump: loaded Not tainted 6.8.0-11409-gf6cef5f8c37f #1\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 dump_stack_lvl+0x68/0xa0\n check_noncircular+0x129/0x140\n __lock_acquire+0x1298/0x1cd0\n lock_acquire+0xc0/0x2b0\n cpus_read_lock+0x2a/0xc0\n static_key_slow_dec+0x16/0x60\n __hugetlb_vmemmap_restore_folio+0x1b9/0x200\n dissolve_free_huge_page+0x211/0x260\n __page_handle_poison+0x45/0xc0\n memory_failure+0x65e/0xc70\n hard_offline_page_store+0x55/0xa0\n kernfs_fop_write_iter+0x12c/0x1d0\n vfs_write+0x387/0x550\n ksys_write+0x64/0xe0\n do_syscall_64+0xca/0x1e0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\nRIP: 0033:0x7fc862314887\nCode: 10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24\nRSP: 002b:00007fff19311268 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007fc862314887\nRDX: 000000000000000c RSI: 000056405645fe10 RDI: 0000000000000001\nRBP: 000056405645fe10 R08: 00007fc8623d1460 R09: 000000007fffffff\nR10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c\nR13: 00007fc86241b780 R14: 00007fc862417600 R15: 00007fc862416a00\n\nIn short, below scene breaks the lock dependency chain:\n\n memory_failure\n __page_handle_poison\n zone_pcp_disable -- lock(pcp_batch_high_lock)\n dissolve_free_huge_page\n __hugetlb_vmemmap_restore_folio\n static_key_slow_dec\n cpus_read_lock -- rlock(cpu_hotplug_lock)\n\nFix this by calling drain_all_pages() instead.\n\nThis issue won't occur until commit a6b40850c442 ("mm: hugetlb: replace\nhugetlb_free_vmemmap_enabled with a static_key"). As it introduced\nrlock(cpu_hotplug_lock) in dissolve_free_huge_page() code path while\nlock(pcp_batch_high_lock) is already in the __page_handle_poison().\n\n[linmiaohe@huawei.com: extend comment per Oscar]\n[akpm@linux-foundation.org: reflow block comment]

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: Fix memory leak in create_process failure\n\nFix memory leak due to a leaked mmget reference on an error handling\ncode path that is triggered when attempting to create KFD processes\nwhile a GPU reset is in progress.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe: Fix bo leak in intel_fb_bo_framebuffer_init\n\nAdd a unreference bo in the error path, to prevent leaking a bo ref.\n\nReturn 0 on success to clarify the success path.\n\n(cherry picked from commit a2f3d731be3893e730417ae3190760fcaffdf549)

In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix OOB in nilfs_set_de_type\n\nThe size of the nilfs_type_by_mode array in the fs/nilfs2/dir.c file is\ndefined as "S_IFMT >> S_SHIFT", but the nilfs_set_de_type() function,\nwhich uses this array, specifies the index to read from the array in the\nsame way as "(mode & S_IFMT) >> S_SHIFT".\n\nstatic void nilfs_set_de_type(struct nilfs_dir_entry *de, struct inode\n *inode)\n{\n umode_t mode = inode->i_mode;\n\n de->file_type = nilfs_type_by_mode[(mode & S_IFMT)>>S_SHIFT]; // oob\n}\n\nHowever, when the index is determined this way, an out-of-bounds (OOB)\nerror occurs by referring to an index that is 1 larger than the array size\nwhen the condition "mode & S_IFMT == S_IFMT" is satisfied. Therefore, a\npatch to resize the nilfs_type_by_mode array should be applied to prevent\nOOB errors.

In the Linux kernel, the following vulnerability has been resolved:\n\nserial: max310x: fix NULL pointer dereference in I2C instantiation\n\nWhen trying to instantiate a max14830 device from userspace:\n\n echo max14830 0x60 > /sys/bus/i2c/devices/i2c-2/new_device\n\nwe get the following error:\n\n Unable to handle kernel NULL pointer dereference at virtual address...\n ...\n Call trace:\n max310x_i2c_probe+0x48/0x170 [max310x]\n i2c_device_probe+0x150/0x2a0\n ...\n\nAdd check for validity of devtype to prevent the error, and abort probe\nwith a meaningful error message.

In the Linux kernel, the following vulnerability has been resolved:\n\nclk: qcom: gcc-ipq9574: 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().\n\nOnly compile tested.

In the Linux kernel, the following vulnerability has been resolved:\n\nclk: qcom: camcc-sc8280xp: 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().\n\nOnly compile tested.

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: dwc3-am62: fix module unload/reload behavior\n\nAs runtime PM is enabled, the module can be runtime\nsuspended when .remove() is called.\n\nDo a pm_runtime_get_sync() to make sure module is active\nbefore doing any register operations.\n\nDoing a pm_runtime_put_sync() should disable the refclk\nso no need to disable it again.\n\nFixes the below warning at module removel.\n\n[ 39.705310] ------------[ cut here ]------------\n[ 39.710004] clk:162:3 already disabled\n[ 39.713941] WARNING: CPU: 0 PID: 921 at drivers/clk/clk.c:1090 clk_core_disable+0xb0/0xb8\n\nWe called of_platform_populate() in .probe() so call the\ncleanup function of_platform_depopulate() in .remove().\nGet rid of the now unnnecessary dwc3_ti_remove_core().\nWithout this, module re-load doesn't work properly.

In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix potencial out-of-bounds when buffer offset is invalid\n\nI found potencial out-of-bounds when buffer offset fields of a few requests\nis invalid. This patch set the minimum value of buffer offset field to\n->Buffer offset to validate buffer length.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: qcom: at803x: fix kernel panic with at8031_probe\n\nOn reworking and splitting the at803x driver, in splitting function of\nat803x PHYs it was added a NULL dereference bug where priv is referenced\nbefore it's actually allocated and then is tried to write to for the\nis_1000basex and is_fiber variables in the case of at8031, writing on\nthe wrong address.\n\nFix this by correctly setting priv local variable only after\nat803x_probe is called and actually allocates priv in the phydev struct.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: core: Fix unremoved procfs host directory regression\n\nCommit fc663711b944 ("scsi: core: Remove the /proc/scsi/${proc_name}\ndirectory earlier") fixed a bug related to modules loading/unloading, by\nadding a call to scsi_proc_hostdir_rm() on scsi_remove_host(). But that led\nto a potential duplicate call to the hostdir_rm() routine, since it's also\ncalled from scsi_host_dev_release(). That triggered a regression report,\nwhich was then fixed by commit be03df3d4bfe ("scsi: core: Fix a procfs host\ndirectory removal regression"). The fix just dropped the hostdir_rm() call\nfrom dev_release().\n\nBut it happens that this proc directory is created on scsi_host_alloc(),\nand that function "pairs" with scsi_host_dev_release(), while\nscsi_remove_host() pairs with scsi_add_host(). In other words, it seems the\nreason for removing the proc directory on dev_release() was meant to cover\ncases in which a SCSI host structure was allocated, but the call to\nscsi_add_host() didn't happen. And that pattern happens to exist in some\nerror paths, for example.\n\nSyzkaller causes that by using USB raw gadget device, error'ing on\nusb-storage driver, at usb_stor_probe2(). By checking that path, we can see\nthat the BadDevice label leads to a scsi_host_put() after a SCSI host\nallocation, but there's no call to scsi_add_host() in such path. That leads\nto messages like this in dmesg (and a leak of the SCSI host proc\nstructure):\n\nusb-storage 4-1:87.51: USB Mass Storage device detected\nproc_dir_entry 'scsi/usb-storage' already registered\nWARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 proc_register+0x347/0x4e0 fs/proc/generic.c:376\n\nThe proper fix seems to still call scsi_proc_hostdir_rm() on dev_release(),\nbut guard that with the state check for SHOST_CREATED; there is even a\ncomment in scsi_host_dev_release() detailing that: such conditional is\nmeant for cases where the SCSI host was allocated but there was no calls to\n{add,remove}_host(), like the usb-storage case.\n\nThis is what we propose here and with that, the error path of usb-storage\ndoes not trigger the warning anymore.

In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: SOF: Add some bounds checking to firmware data\n\nSmatch complains about "head->full_size - head->header_size" can\nunderflow. To some extent, we're always going to have to trust the\nfirmware a bit. However, it's easy enough to add a check for negatives,\nand let's add a upper bounds check as well.

In the Linux kernel, the following vulnerability has been resolved:\n\nbinder: check offset alignment in binder_get_object()\n\nCommit 6d98eb95b450 ("binder: avoid potential data leakage when copying\ntxn") introduced changes to how binder objects are copied. In doing so,\nit unintentionally removed an offset alignment check done through calls\nto binder_alloc_copy_from_buffer() -> check_buffer().\n\nThese calls were replaced in binder_get_object() with copy_from_user(),\nso now an explicit offset alignment check is needed here. This avoids\nlater complications when unwinding the objects gets harder.\n\nIt is worth noting this check existed prior to commit 7a67a39320df\n("binder: add function to copy binder object from buffer"), likely\nremoved due to redundancy at the time.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: Revert "scsi: fcoe: Fix potential deadlock on &fip->ctlr_lock"\n\nThis reverts commit 1a1975551943f681772720f639ff42fbaa746212.\n\nThis commit causes interrupts to be lost for FCoE devices, since it changed\nsping locks from "bh" to "irqsave".\n\nInstead, a work queue should be used, and will be addressed in a separate\ncommit.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: fix incorrect mpc_combine array size\n\n[why]\nMAX_SURFACES is per stream, while MAX_PLANES is per asic. The\nmpc_combine is an array that records all the planes per asic. Therefore\nMAX_PLANES should be used as the array size. Using MAX_SURFACES causes\narray overflow when there are more than 3 planes.\n\n[how]\nUse the MAX_PLANES for the mpc_combine array size.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau: fix several DMA buffer leaks\n\nNouveau manages GSP-RM DMA buffers with nvkm_gsp_mem objects. Several of\nthese buffers are never dealloced. Some of them can be deallocated\nright after GSP-RM is initialized, but the rest need to stay until the\ndriver unloads.\n\nAlso futher bullet-proof these objects by poisoning the buffer and\nclearing the nvkm_gsp_mem object when it is deallocated. Poisoning\nthe buffer should trigger an error (or crash) from GSP-RM if it tries\nto access the buffer after we've deallocated it, because we were wrong\nabout when it is safe to deallocate.\n\nFinally, change the mem->size field to a size_t because that's the same\ntype that dma_alloc_coherent expects.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/buddy: Fix alloc_range() error handling code\n\nFew users have observed display corruption when they boot\nthe machine to KDE Plasma or playing games. We have root\ncaused the problem that whenever alloc_range() couldn't\nfind the required memory blocks the function was returning\nSUCCESS in some of the corner cases.\n\nThe right approach would be if the total allocated size\nis less than the required size, the function should\nreturn -ENOSPC.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ipset: fix performance regression in swap operation\n\nThe patch "netfilter: ipset: fix race condition between swap/destroy\nand kernel side add/del/test", commit 28628fa9 fixes a race condition.\nBut the synchronize_rcu() added to the swap function unnecessarily slows\nit down: it can safely be moved to destroy and use call_rcu() instead.\n\nEric Dumazet pointed out that simply calling the destroy functions as\nrcu callback does not work: sets with timeout use garbage collectors\nwhich need cancelling at destroy which can wait. Therefore the destroy\nfunctions are split into two: cancelling garbage collectors safely at\nexecuting the command received by netlink and moving the remaining\npart only into the rcu callback.

In the Linux kernel, the following vulnerability has been resolved:\n\nsoc: qcom: pmic_glink_altmode: fix drm bridge use-after-free\n\nA recent DRM series purporting to simplify support for "transparent\nbridges" and handling of probe deferrals ironically exposed a\nuse-after-free issue on pmic_glink_altmode probe deferral.\n\nThis has manifested itself as the display subsystem occasionally failing\nto initialise and NULL-pointer dereferences during boot of machines like\nthe Lenovo ThinkPad X13s.\n\nSpecifically, the dp-hpd bridge is currently registered before all\nresources have been acquired which means that it can also be\nderegistered on probe deferrals.\n\nIn the meantime there is a race window where the new aux bridge driver\n(or PHY driver previously) may have looked up the dp-hpd bridge and\nstored a (non-reference-counted) pointer to the bridge which is about to\nbe deallocated.\n\nWhen the display controller is later initialised, this triggers a\nuse-after-free when attaching the bridges:\n\n dp -> aux -> dp-hpd (freed)\n\nwhich may, for example, result in the freed bridge failing to attach:\n\n [drm:drm_bridge_attach [drm]] *ERROR* failed to attach bridge /soc@0/phy@88eb000 to encoder TMDS-31: -16\n\nor a NULL-pointer dereference:\n\n Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n ...\n Call trace:\n drm_bridge_attach+0x70/0x1a8 [drm]\n drm_aux_bridge_attach+0x24/0x38 [aux_bridge]\n drm_bridge_attach+0x80/0x1a8 [drm]\n dp_bridge_init+0xa8/0x15c [msm]\n msm_dp_modeset_init+0x28/0xc4 [msm]\n\nThe DRM bridge implementation is clearly fragile and implicitly built on\nthe assumption that bridges may never go away. In this case, the fix is\nto move the bridge registration in the pmic_glink_altmode driver to\nafter all resources have been looked up.\n\nIncidentally, with the new dp-hpd bridge implementation, which registers\nchild devices, this is also a requirement due to a long-standing issue\nin driver core that can otherwise lead to a probe deferral loop (see\ncommit fbc35b45f9f6 ("Add documentation on meaning of -EPROBE_DEFER")).\n\n[DB: slightly fixed commit message by adding the word 'commit']

In the Linux kernel, the following vulnerability has been resolved:\n\nperf: RISCV: Fix panic on pmu overflow handler\n\n(1 << idx) of int is not desired when setting bits in unsigned long\noverflowed_ctrs, use BIT() instead. This panic happens when running\n'perf record -e branches' on sophgo sg2042.\n\n[ 273.311852] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000098\n[ 273.320851] Oops [#1]\n[ 273.323179] Modules linked in:\n[ 273.326303] CPU: 0 PID: 1475 Comm: perf Not tainted 6.6.0-rc3+ #9\n[ 273.332521] Hardware name: Sophgo Mango (DT)\n[ 273.336878] epc : riscv_pmu_ctr_get_width_mask+0x8/0x62\n[ 273.342291] ra : pmu_sbi_ovf_handler+0x2e0/0x34e\n[ 273.347091] epc : ffffffff80aecd98 ra : ffffffff80aee056 sp : fffffff6e36928b0\n[ 273.354454] gp : ffffffff821f82d0 tp : ffffffd90c353200 t0 : 0000002ade4f9978\n[ 273.361815] t1 : 0000000000504d55 t2 : ffffffff8016cd8c s0 : fffffff6e3692a70\n[ 273.369180] s1 : 0000000000000020 a0 : 0000000000000000 a1 : 00001a8e81800000\n[ 273.376540] a2 : 0000003c00070198 a3 : 0000003c00db75a4 a4 : 0000000000000015\n[ 273.383901] a5 : ffffffd7ff8804b0 a6 : 0000000000000015 a7 : 000000000000002a\n[ 273.391327] s2 : 000000000000ffff s3 : 0000000000000000 s4 : ffffffd7ff8803b0\n[ 273.398773] s5 : 0000000000504d55 s6 : ffffffd905069800 s7 : ffffffff821fe210\n[ 273.406139] s8 : 000000007fffffff s9 : ffffffd7ff8803b0 s10: ffffffd903f29098\n[ 273.413660] s11: 0000000080000000 t3 : 0000000000000003 t4 : ffffffff8017a0ca\n[ 273.421022] t5 : ffffffff8023cfc2 t6 : ffffffd9040780e8\n[ 273.426437] status: 0000000200000100 badaddr: 0000000000000098 cause: 000000000000000d\n[ 273.434512] [<ffffffff80aecd98>] riscv_pmu_ctr_get_width_mask+0x8/0x62\n[ 273.441169] [<ffffffff80076bd8>] handle_percpu_devid_irq+0x98/0x1ee\n[ 273.447562] [<ffffffff80071158>] generic_handle_domain_irq+0x28/0x36\n[ 273.454151] [<ffffffff8047a99a>] riscv_intc_irq+0x36/0x4e\n[ 273.459659] [<ffffffff80c944de>] handle_riscv_irq+0x4a/0x74\n[ 273.465442] [<ffffffff80c94c48>] do_irq+0x62/0x92\n[ 273.470360] Code: 0420 60a2 6402 5529 0141 8082 0013 0000 0013 0000 (6d5c) b783\n[ 273.477921] ---[ end trace 0000000000000000 ]---\n[ 273.482630] Kernel panic - not syncing: Fatal exception in interrupt

In the Linux kernel, the following vulnerability has been resolved:\n\nblock: fix deadlock between bd_link_disk_holder and partition scan\n\n'open_mutex' of gendisk is used to protect open/close block devices. But\nin bd_link_disk_holder(), it is used to protect the creation of symlink\nbetween holding disk and slave bdev, which introduces some issues.\n\nWhen bd_link_disk_holder() is called, the driver is usually in the process\nof initialization/modification and may suspend submitting io. At this\ntime, any io hold 'open_mutex', such as scanning partitions, can cause\ndeadlocks. For example, in raid:\n\nT1 T2\nbdev_open_by_dev\n lock open_mutex [1]\n ...\n efi_partition\n ...\n md_submit_bio\n md_ioctl mddev_syspend\n -> suspend all io\n md_add_new_disk\n bind_rdev_to_array\n bd_link_disk_holder\n try lock open_mutex [2]\n md_handle_request\n -> wait mddev_resume\n\nT1 scan partition, T2 add a new device to raid. T1 waits for T2 to resume\nmddev, but T2 waits for open_mutex held by T1. Deadlock occurs.\n\nFix it by introducing a local mutex 'blk_holder_mutex' to replace\n'open_mutex'.

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: btrtl: fix out of bounds memory access\n\nThe problem is detected by KASAN.\nbtrtl driver uses private hci data to store 'struct btrealtek_data'.\nIf btrtl driver is used with btusb, then memory for private hci data\nis allocated in btusb. But no private data is allocated after hci_dev,\nwhen btrtl is used with hci_h5.\n\nThis commit adds memory allocation for hci_h5 case.\n\n ==================================================================\n BUG: KASAN: slab-out-of-bounds in btrtl_initialize+0x6cc/0x958 [btrtl]\n Write of size 8 at addr ffff00000f5a5748 by task kworker/u9:0/76\n\n Hardware name: Pine64 PinePhone (1.2) (DT)\n Workqueue: hci0 hci_power_on [bluetooth]\n Call trace:\n dump_backtrace+0x9c/0x128\n show_stack+0x20/0x38\n dump_stack_lvl+0x48/0x60\n print_report+0xf8/0x5d8\n kasan_report+0x90/0xd0\n __asan_store8+0x9c/0xc0\n [btrtl]\n h5_btrtl_setup+0xd0/0x2f8 [hci_uart]\n h5_setup+0x50/0x80 [hci_uart]\n hci_uart_setup+0xd4/0x260 [hci_uart]\n hci_dev_open_sync+0x1cc/0xf68 [bluetooth]\n hci_dev_do_open+0x34/0x90 [bluetooth]\n hci_power_on+0xc4/0x3c8 [bluetooth]\n process_one_work+0x328/0x6f0\n worker_thread+0x410/0x778\n kthread+0x168/0x178\n ret_from_fork+0x10/0x20\n\n Allocated by task 53:\n kasan_save_stack+0x3c/0x68\n kasan_save_track+0x20/0x40\n kasan_save_alloc_info+0x68/0x78\n __kasan_kmalloc+0xd4/0xd8\n __kmalloc+0x1b4/0x3b0\n hci_alloc_dev_priv+0x28/0xa58 [bluetooth]\n hci_uart_register_device+0x118/0x4f8 [hci_uart]\n h5_serdev_probe+0xf4/0x178 [hci_uart]\n serdev_drv_probe+0x54/0xa0\n really_probe+0x254/0x588\n __driver_probe_device+0xc4/0x210\n driver_probe_device+0x64/0x160\n __driver_attach_async_helper+0x88/0x158\n async_run_entry_fn+0xd0/0x388\n process_one_work+0x328/0x6f0\n worker_thread+0x410/0x778\n kthread+0x168/0x178\n ret_from_fork+0x10/0x20\n\n Last potentially related work creation:\n kasan_save_stack+0x3c/0x68\n __kasan_record_aux_stack+0xb0/0x150\n kasan_record_aux_stack_noalloc+0x14/0x20\n __queue_work+0x33c/0x960\n queue_work_on+0x98/0xc0\n hci_recv_frame+0xc8/0x1e8 [bluetooth]\n h5_complete_rx_pkt+0x2c8/0x800 [hci_uart]\n h5_rx_payload+0x98/0xb8 [hci_uart]\n h5_recv+0x158/0x3d8 [hci_uart]\n hci_uart_receive_buf+0xa0/0xe8 [hci_uart]\n ttyport_receive_buf+0xac/0x178\n flush_to_ldisc+0x130/0x2c8\n process_one_work+0x328/0x6f0\n worker_thread+0x410/0x778\n kthread+0x168/0x178\n ret_from_fork+0x10/0x20\n\n Second to last potentially related work creation:\n kasan_save_stack+0x3c/0x68\n __kasan_record_aux_stack+0xb0/0x150\n kasan_record_aux_stack_noalloc+0x14/0x20\n __queue_work+0x788/0x960\n queue_work_on+0x98/0xc0\n __hci_cmd_sync_sk+0x23c/0x7a0 [bluetooth]\n __hci_cmd_sync+0x24/0x38 [bluetooth]\n btrtl_initialize+0x760/0x958 [btrtl]\n h5_btrtl_setup+0xd0/0x2f8 [hci_uart]\n h5_setup+0x50/0x80 [hci_uart]\n hci_uart_setup+0xd4/0x260 [hci_uart]\n hci_dev_open_sync+0x1cc/0xf68 [bluetooth]\n hci_dev_do_open+0x34/0x90 [bluetooth]\n hci_power_on+0xc4/0x3c8 [bluetooth]\n process_one_work+0x328/0x6f0\n worker_thread+0x410/0x778\n kthread+0x168/0x178\n ret_from_fork+0x10/0x20\n ==================================================================