No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mt76: mt7996: Fix possible OOB access in mt7996_tx()\n\nFis possible Out-Of-Boundary access in mt7996_tx routine if link_id is\nset to IEEE80211_LINK_UNSPECIFIED

No description is available for this CVE.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: Fix UAF on sva unbind with pending IOPFs\n\nCommit 17fce9d2336d ("iommu/vt-d: Put iopf enablement in domain attach\npath") disables IOPF on device by removing the device from its IOMMU's\nIOPF queue when the last IOPF-capable domain is detached from the device.\nUnfortunately, it did this in a wrong place where there are still pending\nIOPFs. As a result, a use-after-free error is potentially triggered and\neventually a kernel panic with a kernel trace similar to the following:\n\n refcount_t: underflow; use-after-free.\n WARNING: CPU: 3 PID: 313 at lib/refcount.c:28 refcount_warn_saturate+0xd8/0xe0\n Workqueue: iopf_queue/dmar0-iopfq iommu_sva_handle_iopf\n Call Trace:\n \n iopf_free_group+0xe/0x20\n process_one_work+0x197/0x3d0\n worker_thread+0x23a/0x350\n ? rescuer_thread+0x4a0/0x4a0\n kthread+0xf8/0x230\n ? finish_task_switch.isra.0+0x81/0x260\n ? kthreads_online_cpu+0x110/0x110\n ? kthreads_online_cpu+0x110/0x110\n ret_from_fork+0x13b/0x170\n ? kthreads_online_cpu+0x110/0x110\n ret_from_fork_asm+0x11/0x20\n \n ---[ end trace 0000000000000000 ]---\n\nThe intel_pasid_tear_down_entry() function is responsible for blocking\nhardware from generating new page faults and flushing all in-flight\nones. Therefore, moving iopf_for_domain_remove() after this function\nshould resolve this.

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_devcd_dump: fix out-of-bounds via dev_coredumpv\n\nCurrently both dev_coredumpv and skb_put_data in hci_devcd_dump use\nhdev->dump.head. However, dev_coredumpv can free the buffer. From\ndev_coredumpm_timeout documentation, which is used by dev_coredumpv:\n\n > Creates a new device coredump for the given device. If a previous one hasn't\n > been read yet, the new coredump is discarded. The data lifetime is determined\n > by the device coredump framework and when it is no longer needed the @free\n > function will be called to free the data.\n\nIf the data has not been read by the userspace yet, dev_coredumpv will\ndiscard new buffer, freeing hdev->dump.head. This leads to\nvmalloc-out-of-bounds error when skb_put_data tries to access\nhdev->dump.head.\n\nA crash report from syzbot illustrates this:\n\n ==================================================================\n BUG: KASAN: vmalloc-out-of-bounds in skb_put_data\n include/linux/skbuff.h:2752 [inline]\n BUG: KASAN: vmalloc-out-of-bounds in hci_devcd_dump+0x142/0x240\n net/bluetooth/coredump.c:258\n Read of size 140 at addr ffffc90004ed5000 by task kworker/u9:2/5844\n\n CPU: 1 UID: 0 PID: 5844 Comm: kworker/u9:2 Not tainted\n 6.14.0-syzkaller-10892-g4e82c87058f4 #0 PREEMPT(full)\n Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS\n Google 02/12/2025\n Workqueue: hci0 hci_devcd_timeout\n Call Trace:\n \n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:408 [inline]\n print_report+0xc3/0x670 mm/kasan/report.c:521\n kasan_report+0xe0/0x110 mm/kasan/report.c:634\n check_region_inline mm/kasan/generic.c:183 [inline]\n kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189\n __asan_memcpy+0x23/0x60 mm/kasan/shadow.c:105\n skb_put_data include/linux/skbuff.h:2752 [inline]\n hci_devcd_dump+0x142/0x240 net/bluetooth/coredump.c:258\n hci_devcd_timeout+0xb5/0x2e0 net/bluetooth/coredump.c:413\n process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238\n process_scheduled_works kernel/workqueue.c:3319 [inline]\n worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400\n kthread+0x3c2/0x780 kernel/kthread.c:464\n ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245\n \n\n The buggy address ffffc90004ed5000 belongs to a vmalloc virtual mapping\n Memory state around the buggy address:\n ffffc90004ed4f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ffffc90004ed4f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n >ffffc90004ed5000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ^\n ffffc90004ed5080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ffffc90004ed5100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ==================================================================\n\nTo avoid this issue, reorder dev_coredumpv to be called after\nskb_put_data that does not free the data.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nbenet: fix BUG when creating VFs\n\nbenet crashes as soon as SRIOV VFs are created:\n\n kernel BUG at mm/vmalloc.c:3457!\n Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI\n CPU: 4 UID: 0 PID: 7408 Comm: test.sh Kdump: loaded Not tainted 6.16.0+ #1 PREEMPT(voluntary)\n [...]\n RIP: 0010:vunmap+0x5f/0x70\n [...]\n Call Trace:\n \n __iommu_dma_free+0xe8/0x1c0\n be_cmd_set_mac_list+0x3fe/0x640 [be2net]\n be_cmd_set_mac+0xaf/0x110 [be2net]\n be_vf_eth_addr_config+0x19f/0x330 [be2net]\n be_vf_setup+0x4f7/0x990 [be2net]\n be_pci_sriov_configure+0x3a1/0x470 [be2net]\n sriov_numvfs_store+0x20b/0x380\n kernfs_fop_write_iter+0x354/0x530\n vfs_write+0x9b9/0xf60\n ksys_write+0xf3/0x1d0\n do_syscall_64+0x8c/0x3d0\n\nbe_cmd_set_mac_list() calls dma_free_coherent() under a spin_lock_bh.\nFix it by freeing only after the lock has been released.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nperf/core: Handle buffer mapping fail correctly in perf_mmap()\n\nAfter successful allocation of a buffer or a successful attachment to an\nexisting buffer perf_mmap() tries to map the buffer read only into the page\ntable. If that fails, the already set up page table entries are zapped, but\nthe other perf specific side effects of that failure are not handled. The\ncalling code just cleans up the VMA and does not invoke perf_mmap_close().\n\nThis leaks reference counts, corrupts user->vm accounting and also results\nin an unbalanced invocation of event::event_mapped().\n\nCure this by moving the event::event_mapped() invocation before the\nmap_range() call so that on map_range() failure perf_mmap_close() can be\ninvoked without causing an unbalanced event::event_unmapped() call.\n\nperf_mmap_close() undoes the reference counts and eventually frees buffers.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nHID: core: Harden s32ton() against conversion to 0 bits\n\nTesting by the syzbot fuzzer showed that the HID core gets a\nshift-out-of-bounds exception when it tries to convert a 32-bit\nquantity to a 0-bit quantity. Ideally this should never occur, but\nthere are buggy devices and some might have a report field with size\nset to zero; we shouldn't reject the report or the device just because\nof that.\n\nInstead, harden the s32ton() routine so that it returns a reasonable\nresult instead of crashing when it is called with the number of bits\nset to 0 -- the same as what snto32() does.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm: fix a UAF when vma->mm is freed after vma->vm_refcnt got dropped\n\nBy inducing delays in the right places, Jann Horn created a reproducer for\na hard to hit UAF issue that became possible after VMAs were allowed to be\nrecycled by adding SLAB_TYPESAFE_BY_RCU to their cache.\n\nRace description is borrowed from Jann's discovery report:\nlock_vma_under_rcu() looks up a VMA locklessly with mas_walk() under\nrcu_read_lock(). At that point, the VMA may be concurrently freed, and it\ncan be recycled by another process. vma_start_read() then increments the\nvma->vm_refcnt (if it is in an acceptable range), and if this succeeds,\nvma_start_read() can return a recycled VMA.\n\nIn this scenario where the VMA has been recycled, lock_vma_under_rcu()\nwill then detect the mismatching ->vm_mm pointer and drop the VMA through\nvma_end_read(), which calls vma_refcount_put(). vma_refcount_put() drops\nthe refcount and then calls rcuwait_wake_up() using a copy of vma->vm_mm. \nThis is wrong: It implicitly assumes that the caller is keeping the VMA's\nmm alive, but in this scenario the caller has no relation to the VMA's mm,\nso the rcuwait_wake_up() can cause UAF.\n\nThe diagram depicting the race:\nT1 T2 T3\n== == ==\nlock_vma_under_rcu\n mas_walk\n \n mmap\n \n vma_start_read\n __refcount_inc_not_zero_limited_acquire\n munmap\n __vma_enter_locked\n refcount_add_not_zero\n vma_end_read\n vma_refcount_put\n __refcount_dec_and_test\n rcuwait_wait_event\n \n rcuwait_wake_up [UAF]\n\nNote that rcuwait_wait_event() in T3 does not block because refcount was\nalready dropped by T1. At this point T3 can exit and free the mm causing\nUAF in T1.\n\nTo avoid this we move vma->vm_mm verification into vma_start_read() and\ngrab vma->vm_mm to stabilize it before vma_refcount_put() operation.\n\n[surenb@google.com: v3]

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:drm/xe: Don't free job in TDRFreeing job in TDR is not safe as TDR can pass the run_job threadresulting in UAF. It is only safe for free job to naturally be called bythe scheduler. Rather free job in TDR, add to pending list.(cherry picked from commit ea2f6a77d0c40d97f4a4dc93fee4afe15d94926d)

In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: Fix shift-out-of-bounds bugFix a shift-out-of-bounds bug reported by UBSAN when runningVM with MTE enabled host kernel.UBSAN: shift-out-of-bounds in arch/arm64/kvm/sys_regs.c:1988:14shift exponent 33 is too large for 32-bit type 'int'CPU: 26 UID: 0 PID: 7629 Comm: qemu-kvm Not tainted 6.12.0-rc2 #34Hardware name: IEI NF5280R7/Mitchell MB, BIOS 00.00. 2024-10-12 09:28:54 10/14/2024Call trace:dump_backtrace+0xa0/0x128show_stack+0x20/0x38dump_stack_lvl+0x74/0x90dump_stack+0x18/0x28__ubsan_handle_shift_out_of_bounds+0xf8/0x1e0reset_clidr+0x10c/0x1c8kvm_reset_sys_regs+0x50/0x1c8kvm_reset_vcpu+0xec/0x2b0__kvm_vcpu_set_target+0x84/0x158kvm_vcpu_set_target+0x138/0x168kvm_arch_vcpu_ioctl_vcpu_init+0x40/0x2b0kvm_arch_vcpu_ioctl+0x28c/0x4b8kvm_vcpu_ioctl+0x4bc/0x7a8__arm64_sys_ioctl+0xb4/0x100invoke_syscall+0x70/0x100el0_svc_common.constprop.0+0x48/0xf0do_el0_svc+0x24/0x38el0_svc+0x3c/0x158el0t_64_sync_handler+0x120/0x130el0t_64_sync+0x194/0x198

In the Linux kernel, the following vulnerability has been resolved:tracing/probes: Fix MAX_TRACE_ARGS limit handlingWhen creating a trace_probe we would set nr_args prior to truncating thearguments to MAX_TRACE_ARGS. However, we would only initialize argumentsup to the limit.This caused invalid memory access when attempting to set up probes withmore than 128 fetchargs.BUG: kernel NULL pointer dereference, address: 0000000000000020#PF: supervisor read access in kernel mode#PF: error_code(0x0000) - not-present pagePGD 0 P4D 0Oops: Oops: 0000 [#1] PREEMPT SMP PTICPU: 0 UID: 0 PID: 1769 Comm: cat Not tainted 6.11.0-rc7+ #8Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014RIP: 0010:__set_print_fmt+0x134/0x330Resolve the issue by applying the MAX_TRACE_ARGS limit earlier. Returnan error when there are too many arguments instead of silentlytruncating.

In the Linux kernel, the following vulnerability has been resolved:net: pse-pd: Fix out of bound for loopAdjust the loop limit to prevent out-of-bounds access when iterating overPI structures. The loop should not reach the index pcdev->nr_lines sincewe allocate exactly pcdev->nr_lines number of PI structures. This fixensures proper bounds are maintained during iterations.

In the Linux kernel, the following vulnerability has been resolved:bpf: Add the missing BPF_LINK_TYPE invocation for sockmapThere is an out-of-bounds read in bpf_link_show_fdinfo() for the sockmaplink fd. Fix it by adding the missing BPF_LINK_TYPE invocation forsockmap linkAlso add comments for bpf_link_type to prevent missing updates in thefuture.

In the Linux kernel, the following vulnerability has been resolved:PCI: Hold rescan lock while adding devices during host probeSince adding the PCI power control code, we may end up with a race betweenthe pwrctl platform device rescanning the bus and host controller probefunctions. The latter need to take the rescan lock when adding devices orwe may end up in an undefined state having two incompletely added devicesand hit the following crash when trying to remove the device over sysfs:Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000Internal error: Oops: 0000000096000004 [#1] SMPCall trace:__pi_strlen+0x14/0x150kernfs_find_ns+0x80/0x13ckernfs_remove_by_name_ns+0x54/0xf0sysfs_remove_bin_file+0x24/0x34pci_remove_resource_files+0x3c/0x84pci_remove_sysfs_dev_files+0x28/0x38pci_stop_bus_device+0x8c/0xd8pci_stop_bus_device+0x40/0xd8pci_stop_and_remove_bus_device_locked+0x28/0x48remove_store+0x70/0xb0dev_attr_store+0x20/0x38sysfs_kf_write+0x58/0x78kernfs_fop_write_iter+0xe8/0x184vfs_write+0x2dc/0x308ksys_write+0x7c/0xec

In the Linux kernel, the following vulnerability has been resolved:cifs: fix warning when destroy 'cifs_io_request_pool'There's a issue as follows:WARNING: CPU: 1 PID: 27826 at mm/slub.c:4698 free_large_kmalloc+0xac/0xe0RIP: 0010:free_large_kmalloc+0xac/0xe0Call Trace:? __warn+0xea/0x330mempool_destroy+0x13f/0x1d0init_cifs+0xa50/0xff0 [cifs]do_one_initcall+0xdc/0x550do_init_module+0x22d/0x6b0load_module+0x4e96/0x5ff0init_module_from_file+0xcd/0x130idempotent_init_module+0x330/0x620__x64_sys_finit_module+0xb3/0x110do_syscall_64+0xc1/0x1d0entry_SYSCALL_64_after_hwframe+0x77/0x7fObviously, 'cifs_io_request_pool' is not created by mempool_create().So just use mempool_exit() to revert 'cifs_io_request_pool'.

In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: Unregister redistributor for failed vCPU creationAlex reports that syzkaller has managed to trigger a use-after-free whentearing down a VM:BUG: KASAN: slab-use-after-free in kvm_put_kvm+0x300/0xe68 virt/kvm/kvm_main.c:5769Read of size 8 at addr ffffff801c6890d0 by task syz.3.2219/10758CPU: 3 UID: 0 PID: 10758 Comm: syz.3.2219 Not tainted 6.11.0-rc6-dirty #64Hardware name: linux,dummy-virt (DT)Call trace:dump_backtrace+0x17c/0x1a8 arch/arm64/kernel/stacktrace.c:317show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:324__dump_stack lib/dump_stack.c:93 [inline]dump_stack_lvl+0x94/0xc0 lib/dump_stack.c:119print_report+0x144/0x7a4 mm/kasan/report.c:377kasan_report+0xcc/0x128 mm/kasan/report.c:601__asan_report_load8_noabort+0x20/0x2c mm/kasan/report_generic.c:381kvm_put_kvm+0x300/0xe68 virt/kvm/kvm_main.c:5769kvm_vm_release+0x4c/0x60 virt/kvm/kvm_main.c:1409__fput+0x198/0x71c fs/file_table.c:422____fput+0x20/0x30 fs/file_table.c:450task_work_run+0x1cc/0x23c kernel/task_work.c:228do_notify_resume+0x144/0x1a0 include/linux/resume_user_mode.h:50el0_svc+0x64/0x68 arch/arm64/kernel/entry-common.c:169el0t_64_sync_handler+0x90/0xfc arch/arm64/kernel/entry-common.c:730el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598Upon closer inspection, it appears that we do not properly tear down theMMIO registration for a vCPU that fails creation late in the game, e.g.a vCPU w/ the same ID already exists in the VM.It is important to consider the context of commit that introduced this bugby moving the unregistration out of __kvm_vgic_vcpu_destroy(). Thatchange correctly sought to avoid an srcu v. config_lock inversion bybreaking up the vCPU teardown into two parts, one guarded by theconfig_lock.Fix the use-after-free while avoiding lock inversion by adding aspecial-cased unregistration to __kvm_vgic_vcpu_destroy(). This is safebecause failed vCPUs are torn down outside of the config_lock.

In the Linux kernel, the following vulnerability has been resolved:firewire: core: fix invalid port index for parent deviceIn a commit 24b7f8e5cd65 ("firewire: core: use helper functions for selfID sequence"), the enumeration over self ID sequence was refactored withsome helper functions with KUnit tests. These helper functions areguaranteed to work expectedly by the KUnit tests, however their applicationincludes a mistake to assign invalid value to the index of port connectedto parent device.This bug affects the case that any extra node devices which has three ormore ports are connected to 1394 OHCI controller. In the case, the pathto update the tree cache could hits WARN_ON(), and gets general protectionfault due to the access to invalid address computed by the invalid value.This commit fixes the bug to assign correct port index.

In the Linux kernel, the following vulnerability has been resolved:x86/lam: Disable ADDRESS_MASKING in most casesLinear Address Masking (LAM) has a weakness related to transientexecution as described in the SLAM paper[1]. Unless Linear AddressSpace Separation (LASS) is enabled this weakness may be exploitable.Until kernel adds support for LASS[2], only allow LAM for COMPILE_TEST,or when speculation mitigations have been disabled at compile time,otherwise keep LAM disabled.There are no processors in market that support LAM yet, so currentlynobody is affected by this issue.[1] SLAM: https://download.vusec.net/papers/slam_sp24.pdf[2] LASS: https://lore.kernel.org/lkml/20230609183632.48706-1-alexander.shishkin@linux.intel.com/[ dhansen: update SPECULATION_MITIGATIONS -> CPU_MITIGATIONS ]

In the Linux kernel, the following vulnerability has been resolved:ASoC: qcom: sc7280: Fix missing Soundwire runtime stream allocCommit 15c7fab0e047 ("ASoC: qcom: Move Soundwire runtime stream alloc tosoundcards") moved the allocation of Soundwire stream runtime from theQualcomm Soundwire driver to each individual machine sound card driver,except that it forgot to update SC7280 card.Just like for other Qualcomm sound cards using Soundwire, the carddriver should allocate and release the runtime. Otherwise soundplayback will result in a NULL pointer dereference or other effect ofuninitialized memory accesses (which was confirmed on SDM845 havingsimilar issue).

In the Linux kernel, the following vulnerability has been resolved:ASoC: qcom: sdm845: add missing soundwire runtime stream allocDuring the migration of Soundwire runtime stream allocation fromthe Qualcomm Soundwire controller to SoC's soundcard drivers the sdm845soundcard was forgotten.At this point any playback attempt or audio daemon startup, for instanceon sdm845-db845c (Qualcomm RB3 board), will result in stream pointerNULL dereference:Unable to handle kernel NULL pointer dereference at virtualaddress 0000000000000020Mem abort info:ESR = 0x0000000096000004EC = 0x25: DABT (current EL), IL = 32 bitsSET = 0, FnV = 0EA = 0, S1PTW = 0FSC = 0x04: level 0 translation faultData abort info:ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000CM = 0, WnR = 0, TnD = 0, TagAccess = 0GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0user pgtable: 4k pages, 48-bit VAs, pgdp=0000000101ecf000[0000000000000020] pgd=0000000000000000, p4d=0000000000000000Internal error: Oops: 0000000096000004 [#1] PREEMPT SMPModules linked in: ...CPU: 5 UID: 0 PID: 1198 Comm: aplayNot tainted 6.12.0-rc2-qcomlt-arm64-00059-g9d78f315a362-dirty #18Hardware name: Thundercomm Dragonboard 845c (DT)pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : sdw_stream_add_slave+0x44/0x380 [soundwire_bus]lr : sdw_stream_add_slave+0x44/0x380 [soundwire_bus]sp : ffff80008a2035c0x29: ffff80008a2035c0 x28: ffff80008a203978 x27: 0000000000000000x26: 00000000000000c0 x25: 0000000000000000 x24: ffff1676025f4800x23: ffff167600ff1cb8 x22: ffff167600ff1c98 x21: 0000000000000003x20: ffff167607316000 x19: ffff167604e64e80 x18: 0000000000000000x17: 0000000000000000 x16: ffffcec265074160 x15: 0000000000000000x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000x8 : 0000000000000000 x7 : 0000000000000000 x6 : ffff167600ff1cecx5 : ffffcec22cfa2010 x4 : 0000000000000000 x3 : 0000000000000003x2 : ffff167613f836c0 x1 : 0000000000000000 x0 : ffff16761feb60b8Call trace:sdw_stream_add_slave+0x44/0x380 [soundwire_bus]wsa881x_hw_params+0x68/0x80 [snd_soc_wsa881x]snd_soc_dai_hw_params+0x3c/0xa4__soc_pcm_hw_params+0x230/0x660dpcm_be_dai_hw_params+0x1d0/0x3f8dpcm_fe_dai_hw_params+0x98/0x268snd_pcm_hw_params+0x124/0x460snd_pcm_common_ioctl+0x998/0x16e8snd_pcm_ioctl+0x34/0x58__arm64_sys_ioctl+0xac/0xf8invoke_syscall+0x48/0x104el0_svc_common.constprop.0+0x40/0xe0do_el0_svc+0x1c/0x28el0_svc+0x34/0xe0el0t_64_sync_handler+0x120/0x12cel0t_64_sync+0x190/0x194Code: aa0403fb f9418400 9100e000 9400102f (f8420f22)---[ end trace 0000000000000000 ]---0000000000006108 :6108: d503233f paciasp610c: a9b97bfd stp x29, x30, [sp, #-112]!6110: 910003fd mov x29, sp6114: a90153f3 stp x19, x20, [sp, #16]6118: a9025bf5 stp x21, x22, [sp, #32]611c: aa0103f6 mov x22, x16120: 2a0303f5 mov w21, w36124: a90363f7 stp x23, x24, [sp, #48]6128: aa0003f8 mov x24, x0612c: aa0203f7 mov x23, x26130: a9046bf9 stp x25, x26, [sp, #64]6134: aa0403f9 mov x25, x4 <-- x4 copied to x256138: a90573fb stp x27, x28, [sp, #80]613c: aa0403fb mov x27, x46140: f9418400 ldr x0, [x0, #776]6144: 9100e000 add x0, x0, #0x386148: 94000000 bl 0 614c: f8420f22 ldr x2, [x25, #32]! <-- offset 0x44^^^This is 0x6108 + offset 0x44 from the beginning of sdw_stream_add_slave()where data abort happens.wsa881x_hw_params() is called with stream = NULL and passes it furtherin register x4 (5th argu---truncated---

In the Linux kernel, the following vulnerability has been resolved:USB: gadget: dummy-hcd: Fix "task hung" problemThe syzbot fuzzer has been encountering "task hung" problems eversince the dummy-hcd driver was changed to use hrtimers instead ofregular timers. It turns out that the problems are caused by a subtledifference between the timer_pending() and hrtimer_active() APIs.The changeover blindly replaced the first by the second. However,timer_pending() returns True when the timer is queued but not when itscallback is running, whereas hrtimer_active() returns True when thehrtimer is queued _or_ its callback is running. This differenceoccasionally caused dummy_urb_enqueue() to think that the callbackroutine had not yet started when in fact it was almost finished. As aresult the hrtimer was not restarted, which made it impossible for thedriver to dequeue later the URB that was just enqueued. This causedusb_kill_urb() to hang, and things got worse from there.Since hrtimers have no API for telling when they are queued and thecallback isn't running, the driver must keep track of this for itself.That's what this patch does, adding a new "timer_pending" flag andsetting or clearing it at the appropriate times.

In the Linux kernel, the following vulnerability has been resolved:net: fec: don't save PTP state if PTP is unsupportedSome platforms (such as i.MX25 and i.MX27) do not support PTP, so onthese platforms fec_ptp_init() is not called and the related membersin fep are not initialized. However, fec_ptp_save_state() is calledunconditionally, which causes the kernel to panic. Therefore, add acondition so that fec_ptp_save_state() is not called if PTP is notsupported.

In the Linux kernel, the following vulnerability has been resolved:dm vdo: don't refer to dedupe_context after releasing itClear the dedupe_context pointer in a data_vio whenever ownership ofthe context is lost, so that vdo can't examine it accidentally.

In the Linux kernel, the following vulnerability has been resolved:drm/xe/oa: Fix overflow in oa batch bufferBy default xe_bb_create_job() appends a MI_BATCH_BUFFER_END to batchbuffer, this is not a problem if batch buffer is only used once butoa reuses the batch buffer for the same metric and at each callit appends a MI_BATCH_BUFFER_END, printing the warning below and thenoverflowing.[ 381.072016] ------------[ cut here ]------------[ 381.072019] xe 0000:00:02.0: [drm] Assertion `bb->len * 4 + bb_prefetch(q->gt) <= size` failed!platform: LUNARLAKE subplatform: 1graphics: Xe2_LPG / Xe2_HPG 20.04 step B0media: Xe2_LPM / Xe2_HPM 20.00 step B0tile: 0 VRAM 0 BGT: 0 type 1So here checking if batch buffer already have MI_BATCH_BUFFER_END ifnot append it.v2:- simply fix, suggestion from Ashutosh(cherry picked from commit 9ba0e0f30ca42a98af3689460063edfb6315718a)

In the Linux kernel, the following vulnerability has been resolved:net: microchip: vcap api: Fix memory leaks in vcap_api_encode_rule_test()Commit a3c1e45156ad ("net: microchip: vcap: Fix use-after-free error inkunit test") fixed the use-after-free error, but introduced belowmemory leaks by removing necessary vcap_free_rule(), add it to fix it.unreferenced object 0xffffff80ca58b700 (size 192):comm "kunit_try_catch", pid 1215, jiffies 4294898264hex dump (first 32 bytes):00 12 7a 00 05 00 00 00 0a 00 00 00 64 00 00 00 ..z.........d...00 00 00 00 00 00 00 00 00 04 0b cc 80 ff ff ff ................backtrace (crc 9c09c3fe):[<0000000052a0be73>] kmemleak_alloc+0x34/0x40[<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4[<0000000040a01b8d>] vcap_alloc_rule+0x3cc/0x9c4[<000000003fe86110>] vcap_api_encode_rule_test+0x1ac/0x16b0[<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac[<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec[<00000000c5d82c9a>] kthread+0x2e8/0x374[<00000000f4287308>] ret_from_fork+0x10/0x20unreferenced object 0xffffff80cc0b0400 (size 64):comm "kunit_try_catch", pid 1215, jiffies 4294898265hex dump (first 32 bytes):80 04 0b cc 80 ff ff ff 18 b7 58 ca 80 ff ff ff ..........X.....39 00 00 00 02 00 00 00 06 05 04 03 02 01 ff ff 9...............backtrace (crc daf014e9):[<0000000052a0be73>] kmemleak_alloc+0x34/0x40[<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4[<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528[<00000000dfdb1e81>] vcap_api_encode_rule_test+0x224/0x16b0[<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac[<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec[<00000000c5d82c9a>] kthread+0x2e8/0x374[<00000000f4287308>] ret_from_fork+0x10/0x20unreferenced object 0xffffff80cc0b0700 (size 64):comm "kunit_try_catch", pid 1215, jiffies 4294898265hex dump (first 32 bytes):80 07 0b cc 80 ff ff ff 28 b7 58 ca 80 ff ff ff ........(.X.....3c 00 00 00 00 00 00 00 01 2f 03 b3 ec ff ff ff <......../......backtrace (crc 8d877792):[<0000000052a0be73>] kmemleak_alloc+0x34/0x40[<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4[<000000006eadfab7>] vcap_rule_add_action+0x2d0/0x52c[<00000000323475d1>] vcap_api_encode_rule_test+0x4d4/0x16b0[<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac[<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec[<00000000c5d82c9a>] kthread+0x2e8/0x374[<00000000f4287308>] ret_from_fork+0x10/0x20unreferenced object 0xffffff80cc0b0900 (size 64):comm "kunit_try_catch", pid 1215, jiffies 4294898266hex dump (first 32 bytes):80 09 0b cc 80 ff ff ff 80 06 0b cc 80 ff ff ff ................7d 00 00 00 01 00 00 00 00 00 00 00 ff 00 00 00 }...............backtrace (crc 34181e56):[<0000000052a0be73>] kmemleak_alloc+0x34/0x40[<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4[<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528[<00000000991e3564>] vcap_val_rule+0xcf0/0x13e8[<00000000fc9868e5>] vcap_api_encode_rule_test+0x678/0x16b0[<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac[<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec[<00000000c5d82c9a>] kthread+0x2e8/0x374[<00000000f4287308>] ret_from_fork+0x10/0x20unreferenced object 0xffffff80cc0b0980 (size 64):comm "kunit_try_catch", pid 1215, jiffies 4294898266hex dump (first 32 bytes):18 b7 58 ca 80 ff ff ff 00 09 0b cc 80 ff ff ff ..X.............67 00 00 00 00 00 00 00 01 01 74 88 c0 ff ff ff g.........t.....backtrace (crc 275fd9be):[<0000000052a0be73>] kmemleak_alloc+0x34/0x40[<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4[<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528[<000000001396a1a2>] test_add_de---truncated---

In the Linux kernel, the following vulnerability has been resolved:pinctrl: nuvoton: fix a double free in ma35_pinctrl_dt_node_to_map_func()'new_map' is allocated using devm_* which takes care of freeing theallocated data on device removal, call to.dt_free_map = pinconf_generic_dt_free_mapdouble frees the map as pinconf_generic_dt_free_map() callspinctrl_utils_free_map().Fix this by using kcalloc() instead of auto-managed devm_kcalloc().

In the Linux kernel, the following vulnerability has been resolved:mm/damon/tests/sysfs-kunit.h: fix memory leak in damon_sysfs_test_add_targets()The sysfs_target->regions allocated in damon_sysfs_regions_alloc() is notfreed in damon_sysfs_test_add_targets(), which cause the following memoryleak, free it to fix it.unreferenced object 0xffffff80c2a8db80 (size 96):comm "kunit_try_catch", pid 187, jiffies 4294894363hex dump (first 32 bytes):00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................backtrace (crc 0):[<0000000001e3714d>] kmemleak_alloc+0x34/0x40[<000000008e6835c1>] __kmalloc_cache_noprof+0x26c/0x2f4[<000000001286d9f8>] damon_sysfs_test_add_targets+0x1cc/0x738[<0000000032ef8f77>] kunit_try_run_case+0x13c/0x3ac[<00000000f3edea23>] kunit_generic_run_threadfn_adapter+0x80/0xec[<00000000adf936cf>] kthread+0x2e8/0x374[<0000000041bb1628>] ret_from_fork+0x10/0x20

In the Linux kernel, the following vulnerability has been resolved:drm/xe/hdcp: Check GSC structure validitySometimes xe_gsc is not initialized when checked at HDCP capabilitycheck. Add gsc structure check to avoid null pointer error.

In the Linux kernel, the following vulnerability has been resolved:platform/x86: x86-android-tablets: Fix use after free on platform_device_register() errorsx86_android_tablet_remove() frees the pdevs[] array, so it should notbe used after calling x86_android_tablet_remove().When platform_device_register() fails, store the pdevs[x] PTR_ERR() valueinto the local ret variable before calling x86_android_tablet_remove()to avoid using pdevs[] after it has been freed.

In the Linux kernel, the following vulnerability has been resolved:drm/v3d: Prevent out of bounds access in performance query extensionsCheck that the number of perfmons userspace is passing in the copy andreset extensions is not greater than the internal kernel storage wherethe ids will be copied into.

In the Linux kernel, the following vulnerability has been resolved:net: gso: fix tcp fraglist segmentation after pull from frag_listDetect tcp gso fraglist skbs with corrupted geometry (see below) andpass these to skb_segment instead of skb_segment_list, as the firstcan segment them correctly.Valid SKB_GSO_FRAGLIST skbs- consist of two or more segments- the head_skb holds the protocol headers plus first gso_size- one or more frag_list skbs hold exactly one segment- all but the last must be gso_sizeOptional datapath hooks such as NAT and BPF (bpf_skb_pull_data) canmodify these skbs, breaking these invariants.In extreme cases they pull all data into skb linear. For TCP, thiscauses a NULL ptr deref in __tcpv4_gso_segment_list_csum attcp_hdr(seg->next).Detect invalid geometry due to pull, by checking head_skb size.Don't just drop, as this may blackhole a destination. Convert to beable to pass to regular skb_segment.Approach and description based on a patch by Willem de Bruijn.

In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Deallocate DML memory if allocation fails[Why]When DC state create DML memory allocation fails, memory is notdeallocated subsequently, resulting in uninitialized structurethat is not NULL.[How]Deallocate memory if DML memory allocation fails.

In the Linux kernel, the following vulnerability has been resolved:mm/hugetlb: fix memfd_pin_folios free_huge_pages leakmemfd_pin_folios followed by unpin_folios fails to restore free_huge_pagesif the pages were not already faulted in, because the folio refcount forpages created by memfd_alloc_folio never goes to 0. memfd_pin_foliosneeds another folio_put to undo the folio_try_get below:memfd_alloc_folio()alloc_hugetlb_folio_nodemask()dequeue_hugetlb_folio_nodemask()dequeue_hugetlb_folio_node_exact()folio_ref_unfreeze(folio, 1); ; adds 1 refcountfolio_try_get() ; adds 1 refcounthugetlb_add_to_page_cache() ; adds 512 refcount (on x86)With the fix, after memfd_pin_folios + unpin_folios, the refcount for the(unfaulted) page is 512, which is correct, as the refcount for a faultedunpinned page is 513.

In the Linux kernel, the following vulnerability has been resolved:net: test for not too small csum_start in virtio_net_hdr_to_skb()syzbot was able to trigger this warning [1], after injecting amalicious packet through af_packet, setting skb->csum_start and thusthe transport header to an incorrect value.We can at least make sure the transport header is afterthe end of the network header (with a estimated minimal size).[1][ 67.873027] skb len=4096 headroom=16 headlen=14 tailroom=0mac=(-1,-1) mac_len=0 net=(16,-6) trans=10shinfo(txflags=0 nr_frags=1 gso(size=0 type=0 segs=0))csum(0xa start=10 offset=0 ip_summed=3 complete_sw=0 valid=0 level=0)hash(0x0 sw=0 l4=0) proto=0x0800 pkttype=0 iif=0priority=0x0 mark=0x0 alloc_cpu=10 vlan_all=0x0encapsulation=0 inner(proto=0x0000, mac=0, net=0, trans=0)[ 67.877172] dev name=veth0_vlan feat=0x000061164fdd09e9[ 67.877764] sk family=17 type=3 proto=0[ 67.878279] skb linear: 00000000: 00 00 10 00 00 00 00 00 0f 00 00 00 08 00[ 67.879128] skb frag: 00000000: 0e 00 07 00 00 00 28 00 08 80 1c 00 04 00 00 02[ 67.879877] skb frag: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[ 67.880647] skb frag: 00000020: 00 00 02 00 00 00 08 00 1b 00 00 00 00 00 00 00[ 67.881156] skb frag: 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[ 67.881753] skb frag: 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[ 67.882173] skb frag: 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[ 67.882790] skb frag: 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[ 67.883171] skb frag: 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[ 67.883733] skb frag: 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[ 67.884206] skb frag: 00000090: 00 00 00 00 00 00 00 00 00 00 69 70 76 6c 61 6e[ 67.884704] skb frag: 000000a0: 31 00 00 00 00 00 00 00 00 00 2b 00 00 00 00 00[ 67.885139] skb frag: 000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[ 67.885677] skb frag: 000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[ 67.886042] skb frag: 000000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[ 67.886408] skb frag: 000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[ 67.887020] skb frag: 000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[ 67.887384] skb frag: 00000100: 00 00[ 67.887878] ------------[ cut here ]------------[ 67.887908] offset (-6) >= skb_headlen() (14)[ 67.888445] WARNING: CPU: 10 PID: 2088 at net/core/dev.c:3332 skb_checksum_help (net/core/dev.c:3332 (discriminator 2))[ 67.889353] Modules linked in: macsec macvtap macvlan hsr wireguard curve25519_x86_64 libcurve25519_generic libchacha20poly1305 chacha_x86_64 libchacha poly1305_x86_64 dummy bridge sr_mod cdrom evdev pcspkr i2c_piix4 9pnet_virtio 9p 9pnet netfs[ 67.890111] CPU: 10 UID: 0 PID: 2088 Comm: b363492833 Not tainted 6.11.0-virtme #1011[ 67.890183] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 67.890309] RIP: 0010:skb_checksum_help (net/core/dev.c:3332 (discriminator 2))[ 67.891043] Call Trace:[ 67.891173] [ 67.891274] ? __warn (kernel/panic.c:741)[ 67.891320] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2))[ 67.891333] ? report_bug (lib/bug.c:180 lib/bug.c:219)[ 67.891348] ? handle_bug (arch/x86/kernel/traps.c:239)[ 67.891363] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1))[ 67.891372] ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621)[ 67.891388] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2))[ 67.891399] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2))[ 67.891416] ip_do_fragment (net/ipv4/ip_output.c:777 (discriminator 1))[ 67.891448] ? __ip_local_out (./include/linux/skbuff.h:1146 ./include/net/l3mdev.h:196 ./include/net/l3mdev.h:213 ne---truncated---

In the Linux kernel, the following vulnerability has been resolved:drm/xe/guc_submit: add missing locking in wedged_finiAny non-wedged queue can have a zero refcount here and can be runningconcurrently with an async queue destroy, therefore dereferencing thequeue ptr to check wedge status after the lookup can trigger UAF ifqueue is not wedged. Fix this by keeping the submission_state lock heldaround the check to postpone the free and make the check safe, beforedropping again around the put() to avoid the deadlock.(cherry picked from commit d28af0b6b9580b9f90c265a7da0315b0ad20bbfd)

In the Linux kernel, the following vulnerability has been resolved:gpiolib: Fix potential NULL pointer dereference in gpiod_get_label()In `gpiod_get_label()`, it is possible that `srcu_dereference_check()` mayreturn a NULL pointer, leading to a scenario where `label->str` is accessedwithout verifying if `label` itself is NULL.This patch adds a proper NULL check for `label` before accessing`label->str`. The check for `label->str != NULL` is removed because`label->str` can never be NULL if `label` is not NULL.This fixes the issue where the label name was being printed as `(efault)`when dumping the sysfs GPIO file when `label == NULL`.

In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to don't panic system for no free segment fault injectionf2fs: fix to don't panic system for no free segment fault injectionsyzbot reports a f2fs bug as below:F2FS-fs (loop0): inject no free segment in get_new_segment of __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167F2FS-fs (loop0): Stopped filesystem due to reason: 7------------[ cut here ]------------kernel BUG at fs/f2fs/segment.c:2748!CPU: 0 UID: 0 PID: 5109 Comm: syz-executor304 Not tainted 6.11.0-rc6-syzkaller-00363-g89f5e14d05b4 #0RIP: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline]RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836Call Trace:__allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167f2fs_allocate_new_section fs/f2fs/segment.c:3181 [inline]f2fs_allocate_pinning_section+0xfa/0x4e0 fs/f2fs/segment.c:3195f2fs_expand_inode_data+0x5d6/0xbb0 fs/f2fs/file.c:1799f2fs_fallocate+0x448/0x960 fs/f2fs/file.c:1903vfs_fallocate+0x553/0x6c0 fs/open.c:334do_vfs_ioctl+0x2592/0x2e50 fs/ioctl.c:886__do_sys_ioctl fs/ioctl.c:905 [inline]__se_sys_ioctl+0x81/0x170 fs/ioctl.c:893do_syscall_x64 arch/x86/entry/common.c:52 [inline]do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline]RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836The root cause is when we inject no free segment fault into f2fs,we should not panic system, fix it.

In the Linux kernel, the following vulnerability has been resolved:drm/xe: fix UAF around queue destructionWe currently do stuff like queuing the final destruction step on arandom system wq, which will outlive the driver instance. With badtiming we can teardown the driver with one or more work workqueue stillbeing alive leading to various UAF splats. Add a fini step to ensureuser queues are properly torn down. At this point GuC should already benuked so queue itself should no longer be referenced from hw pov.v2 (Matt B)- Looks much safer to use a waitqueue and then just wait for thexa_array to become empty before triggering the drain.(cherry picked from commit 861108666cc0e999cffeab6aff17b662e68774e3)

In the Linux kernel, the following vulnerability has been resolved:mm/gup: fix memfd_pin_folios alloc race panicIf memfd_pin_folios tries to create a hugetlb page, but someone elsealready did, then folio gets the value -EEXIST here:folio = memfd_alloc_folio(memfd, start_idx);if (IS_ERR(folio)) {ret = PTR_ERR(folio);if (ret != -EEXIST)goto err;then on the next trip through the "while start_idx" loop we panic here:if (folio) {folio_put(folio);To fix, set the folio to NULL on error.

In the Linux kernel, the following vulnerability has been resolved:btrfs: send: fix buffer overflow detection when copying path to cache entryStarting with commit c0247d289e73 ("btrfs: send: annotate structname_cache_entry with __counted_by()") we annotated the variable lengtharray "name" from the name_cache_entry structure with __counted_by() toimprove overflow detection. However that alone was not correct, becausethe length of that array does not match the "name_len" field - it matchesthat plus 1 to include the NUL string terminator, so that makes afortified kernel think there's an overflow and report a splat like this:strcpy: detected buffer overflow: 20 byte write of buffer size 19WARNING: CPU: 3 PID: 3310 at __fortify_report+0x45/0x50CPU: 3 UID: 0 PID: 3310 Comm: btrfs Not tainted 6.11.0-prnet #1Hardware name: CompuLab Ltd. sbc-ihsw/Intense-PC2 (IPC2), BIOS IPC2_3.330.7 X64 03/15/2018RIP: 0010:__fortify_report+0x45/0x50Code: 48 8b 34 (...)RSP: 0018:ffff97ebc0d6f650 EFLAGS: 00010246RAX: 7749924ef60fa600 RBX: ffff8bf5446a521a RCX: 0000000000000027RDX: 00000000ffffdfff RSI: ffff97ebc0d6f548 RDI: ffff8bf84e7a1cc8RBP: ffff8bf548574080 R08: ffffffffa8c40e10 R09: 0000000000005ffdR10: 0000000000000004 R11: ffffffffa8c70e10 R12: ffff8bf551eef400R13: 0000000000000000 R14: 0000000000000013 R15: 00000000000003a8FS: 00007fae144de8c0(0000) GS:ffff8bf84e780000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fae14691690 CR3: 00000001027a2003 CR4: 00000000001706f0Call Trace:? __warn+0x12a/0x1d0? __fortify_report+0x45/0x50? report_bug+0x154/0x1c0? handle_bug+0x42/0x70? exc_invalid_op+0x1a/0x50? asm_exc_invalid_op+0x1a/0x20? __fortify_report+0x45/0x50__fortify_panic+0x9/0x10__get_cur_name_and_parent+0x3bc/0x3c0get_cur_path+0x207/0x3b0send_extent_data+0x709/0x10d0? find_parent_nodes+0x22df/0x25d0? mas_nomem+0x13/0x90? mtree_insert_range+0xa5/0x110? btrfs_lru_cache_store+0x5f/0x1e0? iterate_extent_inodes+0x52d/0x5a0process_extent+0xa96/0x11a0? __pfx_lookup_backref_cache+0x10/0x10? __pfx_store_backref_cache+0x10/0x10? __pfx_iterate_backrefs+0x10/0x10? __pfx_check_extent_item+0x10/0x10changed_cb+0x6fa/0x930? tree_advance+0x362/0x390? memcmp_extent_buffer+0xd7/0x160send_subvol+0xf0a/0x1520btrfs_ioctl_send+0x106b/0x11d0? __pfx___clone_root_cmp_sort+0x10/0x10_btrfs_ioctl_send+0x1ac/0x240btrfs_ioctl+0x75b/0x850__se_sys_ioctl+0xca/0x150do_syscall_64+0x85/0x160? __count_memcg_events+0x69/0x100? handle_mm_fault+0x1327/0x15c0? __se_sys_rt_sigprocmask+0xf1/0x180? syscall_exit_to_user_mode+0x75/0xa0? do_syscall_64+0x91/0x160? do_user_addr_fault+0x21d/0x630entry_SYSCALL_64_after_hwframe+0x76/0x7eRIP: 0033:0x7fae145eeb4fCode: 00 48 89 (...)RSP: 002b:00007ffdf1cb09b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fae145eeb4fRDX: 00007ffdf1cb0ad0 RSI: 0000000040489426 RDI: 0000000000000004RBP: 00000000000078fe R08: 00007fae144006c0 R09: 00007ffdf1cb0927R10: 0000000000000008 R11: 0000000000000246 R12: 00007ffdf1cb1ce8R13: 0000000000000003 R14: 000055c499fab2e0 R15: 0000000000000004Fix this by not storing the NUL string terminator since we don't actuallyneed it for name cache entries, this way "name_len" corresponds to theactual size of the "name" array. This requires marking the "name" arrayfield with __nonstring and using memcpy() instead of strcpy() asrecommended by the guidelines at:https://github.com/KSPP/linux/issues/90

In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: use work queue to process beacon tx eventCommit 3a415daa3e8b ("wifi: ath11k: add P2P IE in beacon template")from Feb 28, 2024 (linux-next), leads to the following Smatch staticchecker warning:drivers/net/wireless/ath/ath11k/wmi.c:1742 ath11k_wmi_p2p_go_bcn_ie()warn: sleeping in atomic contextThe reason is that ath11k_bcn_tx_status_event() will directly call mightsleep function ath11k_wmi_cmd_send() during RCU read-side criticalsections. The call trace is like:ath11k_bcn_tx_status_event()-> rcu_read_lock()-> ath11k_mac_bcn_tx_event()-> ath11k_mac_setup_bcn_tmpl()……-> ath11k_wmi_bcn_tmpl()-> ath11k_wmi_cmd_send()-> rcu_read_unlock()Commit 886433a98425 ("ath11k: add support for BSS color change") added theath11k_mac_bcn_tx_event(), commit 01e782c89108 ("ath11k: fix warningof RCU usage for ath11k_mac_get_arvif_by_vdev_id()") added the RCU lockto avoid warning but also introduced this BUG.Use work queue to avoid directly calling ath11k_mac_bcn_tx_event()during RCU critical sections. No need to worry about the deletion of vifbecause cancel_work_sync() will drop the work if it doesn't start orblock vif deletion until the running work is done.Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30

In the Linux kernel, the following vulnerability has been resolved:wifi: rtw89: remove unused C2H event ID RTW89_MAC_C2H_FUNC_READ_WOW_CAM to prevent out-of-bounds readingThe handler of firmware C2H event RTW89_MAC_C2H_FUNC_READ_WOW_CAM isn'timplemented, but driver expects number of handlers isNUM_OF_RTW89_MAC_C2H_FUNC_WOW causing out-of-bounds access. Fix it byremoving ID.Addresses-Coverity-ID: 1598775 ("Out-of-bounds read")

In the Linux kernel, the following vulnerability has been resolved:RISC-V: KVM: Don't zero-out PMU snapshot area before freeing dataWith the latest Linux-6.11-rc3, the below NULL pointer crash is observedwhen SBI PMU snapshot is enabled for the guest and the guest is forcefullypowered-off.Unable to handle kernel NULL pointer dereference at virtual address 0000000000000508Oops [#1]Modules linked in: kvmCPU: 0 UID: 0 PID: 61 Comm: term-poll Not tainted 6.11.0-rc3-00018-g44d7178dd77a #3Hardware name: riscv-virtio,qemu (DT)epc : __kvm_write_guest_page+0x94/0xa6 [kvm]ra : __kvm_write_guest_page+0x54/0xa6 [kvm]epc : ffffffff01590e98 ra : ffffffff01590e58 sp : ffff8f80001f39b0gp : ffffffff81512a60 tp : ffffaf80024872c0 t0 : ffffaf800247e000t1 : 00000000000007e0 t2 : 0000000000000000 s0 : ffff8f80001f39f0s1 : 00007fff89ac4000 a0 : ffffffff015dd7e8 a1 : 0000000000000086a2 : 0000000000000000 a3 : ffffaf8000000000 a4 : ffffaf80024882c0a5 : 0000000000000000 a6 : ffffaf800328d780 a7 : 00000000000001ccs2 : ffffaf800197bd00 s3 : 00000000000828c4 s4 : ffffaf800248c000s5 : ffffaf800247d000 s6 : 0000000000001000 s7 : 0000000000001000s8 : 0000000000000000 s9 : 00007fff861fd500 s10: 0000000000000001s11: 0000000000800000 t3 : 00000000000004d3 t4 : 00000000000004d3t5 : ffffffff814126e0 t6 : ffffffff81412700status: 0000000200000120 badaddr: 0000000000000508 cause: 000000000000000d[] __kvm_write_guest_page+0x94/0xa6 [kvm][] kvm_vcpu_write_guest+0x56/0x90 [kvm][] kvm_pmu_clear_snapshot_area+0x42/0x7e [kvm][] kvm_riscv_vcpu_pmu_deinit.part.0+0xe0/0x14e [kvm][] kvm_riscv_vcpu_pmu_deinit+0x1a/0x24 [kvm][] kvm_arch_vcpu_destroy+0x28/0x4c [kvm][] kvm_destroy_vcpus+0x5a/0xda [kvm][] kvm_arch_destroy_vm+0x14/0x28 [kvm][] kvm_destroy_vm+0x168/0x2a0 [kvm][] kvm_put_kvm+0x3c/0x58 [kvm][] kvm_vm_release+0x22/0x2e [kvm]Clearly, the kvm_vcpu_write_guest() function is crashing because it isbeing called from kvm_pmu_clear_snapshot_area() upon guest tear down.To address the above issue, simplify the kvm_pmu_clear_snapshot_area() tonot zero-out PMU snapshot area from kvm_pmu_clear_snapshot_area() becausethe guest is anyway being tore down.The kvm_pmu_clear_snapshot_area() is also called when guest changesPMU snapshot area of a VCPU but even in this case the previous PMUsnaphsot area must not be zeroed-out because the guest might havereclaimed the pervious PMU snapshot area for some other purpose.

In the Linux kernel, the following vulnerability has been resolved:af_unix: Don't return OOB skb in manage_oob().syzbot reported use-after-free in unix_stream_recv_urg(). [0]The scenario is1. send(MSG_OOB)2. recv(MSG_OOB)-> The consumed OOB remains in recv queue3. send(MSG_OOB)4. recv()-> manage_oob() returns the next skb of the consumed OOB-> This is also OOB, but unix_sk(sk)->oob_skb is not cleared5. recv(MSG_OOB)-> unix_sk(sk)->oob_skb is used but already freedThe recent commit 8594d9b85c07 ("af_unix: Don't call skb_get() for OOBskb.") uncovered the issue.If the OOB skb is consumed and the next skb is peeked in manage_oob(),we still need to check if the skb is OOB.Let's do so by falling back to the following checks in manage_oob()and add the test case in selftest.Note that we need to add a similar check for SIOCATMARK.[0]:BUG: KASAN: slab-use-after-free in unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959Read of size 4 at addr ffff8880326abcc4 by task syz-executor178/5235CPU: 0 UID: 0 PID: 5235 Comm: syz-executor178 Not tainted 6.11.0-rc5-syzkaller-00742-gfbdaffe41adc #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024Call Trace:__dump_stack lib/dump_stack.c:93 [inline]dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119print_address_description mm/kasan/report.c:377 [inline]print_report+0x169/0x550 mm/kasan/report.c:488kasan_report+0x143/0x180 mm/kasan/report.c:601unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959unix_stream_recv_urg+0x1df/0x320 net/unix/af_unix.c:2640unix_stream_read_generic+0x2456/0x2520 net/unix/af_unix.c:2778unix_stream_recvmsg+0x22b/0x2c0 net/unix/af_unix.c:2996sock_recvmsg_nosec net/socket.c:1046 [inline]sock_recvmsg+0x22f/0x280 net/socket.c:1068____sys_recvmsg+0x1db/0x470 net/socket.c:2816___sys_recvmsg net/socket.c:2858 [inline]__sys_recvmsg+0x2f0/0x3e0 net/socket.c:2888do_syscall_x64 arch/x86/entry/common.c:52 [inline]do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f5360d6b4e9Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007fff29b3a458 EFLAGS: 00000246 ORIG_RAX: 000000000000002fRAX: ffffffffffffffda RBX: 00007fff29b3a638 RCX: 00007f5360d6b4e9RDX: 0000000000002001 RSI: 0000000020000640 RDI: 0000000000000003RBP: 00007f5360dde610 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001R13: 00007fff29b3a628 R14: 0000000000000001 R15: 0000000000000001Allocated by task 5235:kasan_save_stack mm/kasan/common.c:47 [inline]kasan_save_track+0x3f/0x80 mm/kasan/common.c:68unpoison_slab_object mm/kasan/common.c:312 [inline]__kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338kasan_slab_alloc include/linux/kasan.h:201 [inline]slab_post_alloc_hook mm/slub.c:3988 [inline]slab_alloc_node mm/slub.c:4037 [inline]kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4080__alloc_skb+0x1c3/0x440 net/core/skbuff.c:667alloc_skb include/linux/skbuff.h:1320 [inline]alloc_skb_with_frags+0xc3/0x770 net/core/skbuff.c:6528sock_alloc_send_pskb+0x91a/0xa60 net/core/sock.c:2815sock_alloc_send_skb include/net/sock.h:1778 [inline]queue_oob+0x108/0x680 net/unix/af_unix.c:2198unix_stream_sendmsg+0xd24/0xf80 net/unix/af_unix.c:2351sock_sendmsg_nosec net/socket.c:730 [inline]__sock_sendmsg+0x221/0x270 net/socket.c:745____sys_sendmsg+0x525/0x7d0 net/socket.c:2597___sys_sendmsg net/socket.c:2651 [inline]__sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680do_syscall_x64 arch/x86/entry/common.c:52 [inline]do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83entry_SYSCALL_64_after_hwframe+0x77/0x7fFreed by task 5235:kasan_save_stack mm/kasan/common.c:47---truncated---

In the Linux kernel, the following vulnerability has been resolved:netkit: Assign missing bpf_net_contextDuring the introduction of struct bpf_net_context handling forXDP-redirect, the netkit driver has been missed, which also requires itbecause NETKIT_REDIRECT invokes skb_do_redirect() which is accessing theper-CPU variables. Otherwise we see the following crash:BUG: kernel NULL pointer dereference, address: 0000000000000038bpf_redirect()netkit_xmit()dev_hard_start_xmit()Set the bpf_net_context before invoking netkit_xmit() program within thenetkit driver.

In the Linux kernel, the following vulnerability has been resolved:RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependencyIn the commit aee2424246f9 ("RDMA/iwcm: Fix a use-after-free related todestroying CM IDs"), the function flush_workqueue is invoked to flush thework queue iwcm_wq.But at that time, the work queue iwcm_wq was created via the functionalloc_ordered_workqueue without the flag WQ_MEM_RECLAIM.Because the current process is trying to flush the whole iwcm_wq, ifiwcm_wq doesn't have the flag WQ_MEM_RECLAIM, verify that the currentprocess is not reclaiming memory or running on a workqueue which doesn'thave the flag WQ_MEM_RECLAIM as that can break forward-progress guaranteeleading to a deadlock.The call trace is as below:[ 125.350876][ T1430] Call Trace:[ 125.356281][ T1430] [ 125.361285][ T1430] ? __warn (kernel/panic.c:693)[ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))[ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219)[ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239)[ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1))[ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621)[ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))[ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))[ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970)[ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151)[ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm[ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910)[ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162)[ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161)[ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm[ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma[ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma[ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231)[ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393)[ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339)[ 125.531837][ T1430] kthread (kernel/kthread.c:389)[ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342)[ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147)[ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342)[ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257)[ 125.566487][ T1430] [ 125.566488][ T1430] ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:IB/mlx5: Fix UMR pd cleanup on error flow of driver initThe cited commit moves the pd allocation from functionmlx5r_umr_resource_cleanup() to a new function mlx5r_umr_cleanup().So the fix in commit [1] is broken. In error flow, will hit panic [2].Fix it by checking pd pointer to avoid panic if it is NULL;[1] RDMA/mlx5: Fix UMR cleanup on error flow of driver init[2][ 347.567063] infiniband mlx5_0: Couldn't register device with driver model[ 347.591382] BUG: kernel NULL pointer dereference, address: 0000000000000020[ 347.593438] #PF: supervisor read access in kernel mode[ 347.595176] #PF: error_code(0x0000) - not-present page[ 347.596962] PGD 0 P4D 0[ 347.601361] RIP: 0010:ib_dealloc_pd_user+0x12/0xc0 [ib_core][ 347.604171] RSP: 0018:ffff888106293b10 EFLAGS: 00010282[ 347.604834] RAX: 0000000000000000 RBX: 000000000000000e RCX: 0000000000000000[ 347.605672] RDX: ffff888106293ad0 RSI: 0000000000000000 RDI: 0000000000000000[ 347.606529] RBP: 0000000000000000 R08: ffff888106293ae0 R09: ffff888106293ae0[ 347.607379] R10: 0000000000000a06 R11: 0000000000000000 R12: 0000000000000000[ 347.608224] R13: ffffffffa0704dc0 R14: 0000000000000001 R15: 0000000000000001[ 347.609067] FS: 00007fdc720cd9c0(0000) GS:ffff88852c880000(0000) knlGS:0000000000000000[ 347.610094] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 347.610727] CR2: 0000000000000020 CR3: 0000000103012003 CR4: 0000000000370eb0[ 347.611421] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 347.612113] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 347.612804] Call Trace:[ 347.613130] [ 347.613417] ? __die+0x20/0x60[ 347.613793] ? page_fault_oops+0x150/0x3e0[ 347.614243] ? free_msg+0x68/0x80 [mlx5_core][ 347.614840] ? cmd_exec+0x48f/0x11d0 [mlx5_core][ 347.615359] ? exc_page_fault+0x74/0x130[ 347.615808] ? asm_exc_page_fault+0x22/0x30[ 347.616273] ? ib_dealloc_pd_user+0x12/0xc0 [ib_core][ 347.616801] mlx5r_umr_cleanup+0x23/0x90 [mlx5_ib][ 347.617365] mlx5_ib_stage_pre_ib_reg_umr_cleanup+0x36/0x40 [mlx5_ib][ 347.618025] __mlx5_ib_add+0x96/0xd0 [mlx5_ib][ 347.618539] mlx5r_probe+0xe9/0x310 [mlx5_ib][ 347.619032] ? kernfs_add_one+0x107/0x150[ 347.619478] ? __mlx5_ib_add+0xd0/0xd0 [mlx5_ib][ 347.619984] auxiliary_bus_probe+0x3e/0x90[ 347.620448] really_probe+0xc5/0x3a0[ 347.620857] __driver_probe_device+0x80/0x160[ 347.621325] driver_probe_device+0x1e/0x90[ 347.621770] __driver_attach+0xec/0x1c0[ 347.622213] ? __device_attach_driver+0x100/0x100[ 347.622724] bus_for_each_dev+0x71/0xc0[ 347.623151] bus_add_driver+0xed/0x240[ 347.623570] driver_register+0x58/0x100[ 347.623998] __auxiliary_driver_register+0x6a/0xc0[ 347.624499] ? driver_register+0xae/0x100[ 347.624940] ? 0xffffffffa0893000[ 347.625329] mlx5_ib_init+0x16a/0x1e0 [mlx5_ib][ 347.625845] do_one_initcall+0x4a/0x2a0[ 347.626273] ? gcov_event+0x2e2/0x3a0[ 347.626706] do_init_module+0x8a/0x260[ 347.627126] init_module_from_file+0x8b/0xd0[ 347.627596] __x64_sys_finit_module+0x1ca/0x2f0[ 347.628089] do_syscall_64+0x4c/0x100

In the Linux kernel, the following vulnerability has been resolved:driver core: Fix a potential null-ptr-deref in module_add_driver()Inject fault while probing of-fpga-region, if kasprintf() fails inmodule_add_driver(), the second sysfs_remove_link() in exit path will causenull-ptr-deref as below because kernfs_name_hash() will call strlen() withNULL driver_name.Fix it by releasing resources based on the exit path sequence.KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]Mem abort info:ESR = 0x0000000096000005EC = 0x25: DABT (current EL), IL = 32 bitsSET = 0, FnV = 0EA = 0, S1PTW = 0FSC = 0x05: level 1 translation faultData abort info:ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000CM = 0, WnR = 0, TnD = 0, TagAccess = 0GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[dfffffc000000000] address between user and kernel address rangesInternal error: Oops: 0000000096000005 [#1] PREEMPT SMPDumping ftrace buffer:(ftrace buffer empty)Modules linked in: of_fpga_region(+) fpga_region fpga_bridge cfg80211 rfkill 8021q garp mrp stp llc ipv6 [last unloaded: of_fpga_region]CPU: 2 UID: 0 PID: 2036 Comm: modprobe Not tainted 6.11.0-rc2-g6a0e38264012 #295Hardware name: linux,dummy-virt (DT)pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : strlen+0x24/0xb0lr : kernfs_name_hash+0x1c/0xc4sp : ffffffc081f97380x29: ffffffc081f97380 x28: ffffffc081f97b90 x27: ffffff80c821c2a0x26: ffffffedac0be418 x25: 0000000000000000 x24: ffffff80c09d2000x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000001840x17: 0000000000000000 x16: 0000000000000000 x15: 1ffffff8103f2e42x14: 00000000f1f1f1f1 x13: 0000000000000004 x12: ffffffb01812d61dx11: 1ffffff01812d61c x10: ffffffb01812d61c x9 : dfffffc000000000x8 : 0000004fe7ed29e4 x7 : ffffff80c096b0e7 x6 : 0000000000000001x5 : ffffff80c096b0e0 x4 : 1ffffffdb990efa2 x3 : 0000000000000000x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000000Call trace:strlen+0x24/0xb0kernfs_name_hash+0x1c/0xc4kernfs_find_ns+0x118/0x2e8kernfs_remove_by_name_ns+0x80/0x100sysfs_remove_link+0x74/0xa8module_add_driver+0x278/0x394bus_add_driver+0x1f0/0x43cdriver_register+0xf4/0x3c0__platform_driver_register+0x60/0x88of_fpga_region_init+0x20/0x1000 [of_fpga_region]do_one_initcall+0x110/0x788do_init_module+0x1dc/0x5c8load_module+0x3c38/0x4cacinit_module_from_file+0xd4/0x128idempotent_init_module+0x2cc/0x528__arm64_sys_finit_module+0xac/0x100invoke_syscall+0x6c/0x258el0_svc_common.constprop.0+0x160/0x22cdo_el0_svc+0x44/0x5cel0_svc+0x48/0xb8el0t_64_sync_handler+0x13c/0x158el0t_64_sync+0x190/0x194Code: f2fbffe1 a90157f4 12000802 aa0003f5 (38e16861)---[ end trace 0000000000000000 ]---Kernel panic - not syncing: Oops: Fatal exception

In the Linux kernel, the following vulnerability has been resolved:f2fs: check discard support for conventional zonesAs the helper function f2fs_bdev_support_discard() shows, f2fs checks ifthe target block devices support discard by callingbdev_max_discard_sectors() and bdev_is_zoned(). This check works wellfor most cases, but it does not work for conventional zones on zonedblock devices. F2fs assumes that zoned block devices support discard,and calls __submit_discard_cmd(). When __submit_discard_cmd() is calledfor sequential write required zones, it works fine since__submit_discard_cmd() issues zone reset commands instead of discardcommands. However, when __submit_discard_cmd() is called forconventional zones, __blkdev_issue_discard() is called even when thedevices do not support discard.The inappropriate __blkdev_issue_discard() call was not a problem beforethe commit 30f1e7241422 ("block: move discard checks into the ioctlhandler") because __blkdev_issue_discard() checked if the target devicessupport discard or not. If not, it returned EOPNOTSUPP. After thecommit, __blkdev_issue_discard() no longer checks it. It always returnszero and sets NULL to the given bio pointer. This NULL pointer triggersf2fs_bug_on() in __submit_discard_cmd(). The BUG is recreated with thecommands below at the umount step, where /dev/nullb0 is a zoned null_blkwith 5GB total size, 128MB zone size and 10 conventional zones.$ mkfs.f2fs -f -m /dev/nullb0$ mount /dev/nullb0 /mnt$ for ((i=0;i<5;i++)); do dd if=/dev/zero of=/mnt/test bs=65536 count=1600 conv=fsync; done$ umount /mntTo fix the BUG, avoid the inappropriate __blkdev_issue_discard() call.When discard is requested for conventional zones, check if the devicesupports discard or not. If not, return EOPNOTSUPP.

In the Linux kernel, the following vulnerability has been resolved:exfat: resolve memory leak from exfat_create_upcase_table()If exfat_load_upcase_table reaches end and returns -EINVAL,allocated memory doesn't get freed and whileexfat_load_default_upcase_table allocates more memory, leading to amemory leak.Here's link to syzkaller crash report illustrating this issue:https://syzkaller.appspot.com/text?tag=CrashReport&x=1406c201980000

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: allow exp not to be removed in nf_ct_find_expectation\n\nCurrently nf_conntrack_in() calling nf_ct_find_expectation() will\nremove the exp from the hash table. However, in some scenario, we\nexpect the exp not to be removed when the created ct will not be\nconfirmed, like in OVS and TC conntrack in the following patches.\n\nThis patch allows exp not to be removed by setting IPS_CONFIRMED\nin the status of the tmpl.

In the Linux kernel, the following vulnerability has been resolved:net: phy: fix null-ptr-deref while probe() failedI got a null-ptr-deref report as following when doing fault injection test:BUG: kernel NULL pointer dereference, address: 0000000000000058Oops: 0000 [#1] PREEMPT SMP KASAN PTICPU: 1 PID: 253 Comm: 507-spi-dm9051 Tainted: G B N 6.1.0-rc3+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014RIP: 0010:klist_put+0x2d/0xd0Call Trace:klist_remove+0xf1/0x1c0device_release_driver_internal+0x23e/0x2d0bus_remove_device+0x1bd/0x240device_del+0x357/0x770phy_device_remove+0x11/0x30mdiobus_unregister+0xa5/0x140release_nodes+0x6a/0xa0devres_release_all+0xf8/0x150device_unbind_cleanup+0x19/0xd0//probe path:phy_device_register()device_add()phy_connectphy_attach_direct() //set device driverprobe() //it's failed, driver is not bounddevice_bind_driver() // probe failed, it's not called//remove path:phy_device_remove()device_del()device_release_driver_internal()__device_release_driver() //dev->drv is not NULLklist_remove() <- knode_driver is not added yet, cause null-ptr-derefIn phy_attach_direct(), after setting the 'dev->driver', probe() fails,device_bind_driver() is not called, so the knode_driver->n_klist is notset, then it causes null-ptr-deref in __device_release_driver() whiledeleting device. Fix this by setting dev->driver to NULL in the errorpath in phy_attach_direct().

In the Linux kernel, the following vulnerability has been resolved:mptcp: fix sleep in atomic at close timeMatt reported a splat at msk close time:BUG: sleeping function called from invalid context at net/mptcp/protocol.c:2877in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 155, name: packetdrillpreempt_count: 201, expected: 0RCU nest depth: 0, expected: 04 locks held by packetdrill/155:#0: ffff888001536990 (&sb->s_type->i_mutex_key#6){+.+.}-{3:3}, at: __sock_release (net/socket.c:650)#1: ffff88800b498130 (sk_lock-AF_INET){+.+.}-{0:0}, at: mptcp_close (net/mptcp/protocol.c:2973)#2: ffff88800b49a130 (sk_lock-AF_INET/1){+.+.}-{0:0}, at: __mptcp_close_ssk (net/mptcp/protocol.c:2363)#3: ffff88800b49a0b0 (slock-AF_INET){+...}-{2:2}, at: __lock_sock_fast (include/net/sock.h:1820)Preemption disabled at:0x0CPU: 1 PID: 155 Comm: packetdrill Not tainted 6.1.0-rc5 #365Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Call Trace:dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4))__might_resched.cold (kernel/sched/core.c:9891)__mptcp_destroy_sock (include/linux/kernel.h:110)__mptcp_close (net/mptcp/protocol.c:2959)mptcp_subflow_queue_clean (include/net/sock.h:1777)__mptcp_close_ssk (net/mptcp/protocol.c:2363)mptcp_destroy_common (net/mptcp/protocol.c:3170)mptcp_destroy (include/net/sock.h:1495)__mptcp_destroy_sock (net/mptcp/protocol.c:2886)__mptcp_close (net/mptcp/protocol.c:2959)mptcp_close (net/mptcp/protocol.c:2974)inet_release (net/ipv4/af_inet.c:432)__sock_release (net/socket.c:651)sock_close (net/socket.c:1367)__fput (fs/file_table.c:320)task_work_run (kernel/task_work.c:181 (discriminator 1))exit_to_user_mode_prepare (include/linux/resume_user_mode.h:49)syscall_exit_to_user_mode (kernel/entry/common.c:130)do_syscall_64 (arch/x86/entry/common.c:87)entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)We can't call mptcp_close under the 'fast' socket lock variant, replaceit with a sock_lock_nested() as the relevant code is already under thelistening msk socket lock protection.

In the Linux kernel, the following vulnerability has been resolved:net: mdiobus: fix unbalanced node reference countI got the following report while doing device(mscc-miim) load testwith CONFIG_OF_UNITTEST and CONFIG_OF_DYNAMIC enabled:OF: ERROR: memory leak, expected refcount 1 instead of 2,of_node_get()/of_node_put() unbalanced - destroy cset entry:attach overlay node /spi/soc@0/mdio@7107009c/ethernet-phy@0If the 'fwnode' is not an acpi node, the refcount is get infwnode_mdiobus_phy_device_register(), but it has never beenput when the device is freed in the normal path. So callfwnode_handle_put() in phy_device_release() to avoid leak.If it's an acpi node, it has never been get, but it's putin the error path, so call fwnode_handle_get() beforephy_device_register() to keep get/put operation balanced.

In the Linux kernel, the following vulnerability has been resolved:afs: Fix server->active leak in afs_put_serverThe atomic_read was accidentally replaced with atomic_inc_return,which prevents the server from getting cleaned up and causes rmmodto hang with a warning:Can't purge s=00000001

In the Linux kernel, the following vulnerability has been resolved:can: can327: can327_feed_frame_to_netdev(): fix potential skb leak when netdev is downIn can327_feed_frame_to_netdev(), it did not free the skb when netdevis down, and all callers of can327_feed_frame_to_netdev() did not freeallocated skb too. That would trigger skb leak.Fix it by adding kfree_skb() in can327_feed_frame_to_netdev() when netdevis down. Not tested, just compiled.

In the Linux kernel, the following vulnerability has been resolved:powerpc/bpf/32: Fix Oops on tail call teststest_bpf tail call tests end up as:test_bpf: #0 Tail call leaf jited:1 85 PASStest_bpf: #1 Tail call 2 jited:1 111 PASStest_bpf: #2 Tail call 3 jited:1 145 PASStest_bpf: #3 Tail call 4 jited:1 170 PASStest_bpf: #4 Tail call load/store leaf jited:1 190 PASStest_bpf: #5 Tail call load/store jited:1BUG: Unable to handle kernel data access on write at 0xf1b4e000Faulting instruction address: 0xbe86b710Oops: Kernel access of bad area, sig: 11 [#1]BE PAGE_SIZE=4K MMU=Hash PowerMacModules linked in: test_bpf(+)CPU: 0 PID: 97 Comm: insmod Not tainted 6.1.0-rc4+ #195Hardware name: PowerMac3,1 750CL 0x87210 PowerMacNIP: be86b710 LR: be857e88 CTR: be86b704REGS: f1b4df20 TRAP: 0300 Not tainted (6.1.0-rc4+)MSR: 00009032 CR: 28008242 XER: 00000000DAR: f1b4e000 DSISR: 42000000GPR00: 00000001 f1b4dfe0 c11d2280 00000000 00000000 00000000 00000002 00000000GPR08: f1b4e000 be86b704 f1b4e000 00000000 00000000 100d816a f2440000 fe73baa8GPR16: f2458000 00000000 c1941ae4 f1fe2248 00000045 c0de0000 f2458030 00000000GPR24: 000003e8 0000000f f2458000 f1b4dc90 3e584b46 00000000 f24466a0 c1941a00NIP [be86b710] 0xbe86b710LR [be857e88] __run_one+0xec/0x264 [test_bpf]Call Trace:[f1b4dfe0] [00000002] 0x2 (unreliable)Instruction dump:XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXXXXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX---[ end trace 0000000000000000 ]---This is a tentative to write above the stack. The problem is encouteredwith tests added by commit 38608ee7b690 ("bpf, tests: Add load storetest case for tail call")This happens because tail call is done to a BPF prog with a differentstack_depth. At the time being, the stack is kept as is when the callertail calls its callee. But at exit, the callee restores the stack basedon its own properties. Therefore here, at each run, r1 is erroneouslyincreased by 32 - 16 = 16 bytes.This was done that way in order to pass the tail call count from callerto callee through the stack. As powerpc32 doesn't have a red zone inthe stack, it was necessary the maintain the stack as is for the tailcall. But it was not anticipated that the BPF frame size could bedifferent.Let's take a new approach. Use register r4 to carry the tail call countduring the tail call, and save it into the stack at function entry ifrequired. This means the input parameter must be in r3, which is morecorrect as it is a 32 bits parameter, then tail call better match withnormal BPF function entry, the down side being that we move that inputparameter back and forth between r3 and r4. That can be optimised later.Doing that also has the advantage of maximising the common parts betweentail calls and a normal function exit.With the fix, tail call tests are now successfull:test_bpf: #0 Tail call leaf jited:1 53 PASStest_bpf: #1 Tail call 2 jited:1 115 PASStest_bpf: #2 Tail call 3 jited:1 154 PASStest_bpf: #3 Tail call 4 jited:1 165 PASStest_bpf: #4 Tail call load/store leaf jited:1 101 PASStest_bpf: #5 Tail call load/store jited:1 141 PASStest_bpf: #6 Tail call error path, max count reached jited:1 994 PASStest_bpf: #7 Tail call count preserved across function calls jited:1 140975 PASStest_bpf: #8 Tail call error path, NULL target jited:1 110 PASStest_bpf: #9 Tail call error path, index out of range jited:1 69 PASStest_bpf: test_tail_calls: Summary: 10 PASSED, 0 FAILED, [10/10 JIT'ed]

In the Linux kernel, the following vulnerability has been resolved:mm/damon/sysfs: fix wrong empty schemes assumption under online tuning in damon_sysfs_set_schemes()Commit da87878010e5 ("mm/damon/sysfs: support online inputs update") made'damon_sysfs_set_schemes()' to be called for running DAMON context, whichcould have schemes. In the case, DAMON sysfs interface is supposed toupdate, remove, or add schemes to reflect the sysfs files. However, thecode is assuming the DAMON context wouldn't have schemes at all, andtherefore creates and adds new schemes. As a result, the code doesn'twork as intended for online schemes tuning and could have more thanexpected memory footprint. The schemes are all in the DAMON context, soit doesn't leak the memory, though.Remove the wrong asssumption (the DAMON context wouldn't have schemes) in'damon_sysfs_set_schemes()' to fix the bug.

In the Linux kernel, the following vulnerability has been resolved:

In the Linux kernel, the following vulnerability has been resolved:net: mana: Fix race on per-CQ variable napi work_doneAfter calling napi_complete_done(), the NAPIF_STATE_SCHED bit may becleared, and another CPU can start napi thread and access per-CQ variable,cq->work_done. If the other thread (for example, from busy_poll) setsit to a value >= budget, this thread will continue to run when it shouldstop, and cause memory corruption and panic.To fix this issue, save the per-CQ work_done variable in a local variablebefore napi_complete_done(), so it won't be corrupted by a possibleconcurrent thread after napi_complete_done().Also, add a flag bit to advertise to the NIC firmware: the NAPI work_donevariable race is fixed, so the driver is able to reliably support featureslike busy_poll.

In the Linux kernel, the following vulnerability has been resolved:can: slcan: fix freed work crashThe LTP test pty03 is causing a crash in slcan:BUG: kernel NULL pointer dereference, address: 0000000000000008#PF: supervisor read access in kernel mode#PF: error_code(0x0000) - not-present pagePGD 0 P4D 0Oops: 0000 [#1] PREEMPT SMP NOPTICPU: 0 PID: 348 Comm: kworker/0:3 Not tainted 6.0.8-1-default #1 openSUSE Tumbleweed 9d20364b934f5aab0a9bdf84e8f45cfdfae39dabHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014Workqueue: 0x0 (events)RIP: 0010:process_one_work (/home/rich/kernel/linux/kernel/workqueue.c:706 /home/rich/kernel/linux/kernel/workqueue.c:2185)Code: 49 89 ff 41 56 41 55 41 54 55 53 48 89 f3 48 83 ec 10 48 8b 06 48 8b 6f 48 49 89 c4 45 30 e4 a8 04 b8 00 00 00 00 4c 0f 44 e0 <49> 8b 44 24 08 44 8b a8 00 01 00 00 41 83 e5 20 f6 45 10 04 75 0eRSP: 0018:ffffaf7b40f47e98 EFLAGS: 00010046RAX: 0000000000000000 RBX: ffff9d644e1b8b48 RCX: ffff9d649e439968RDX: 00000000ffff8455 RSI: ffff9d644e1b8b48 RDI: ffff9d64764aa6c0RBP: ffff9d649e4335c0 R08: 0000000000000c00 R09: ffff9d64764aa734R10: 0000000000000007 R11: 0000000000000001 R12: 0000000000000000R13: ffff9d649e4335e8 R14: ffff9d64490da780 R15: ffff9d64764aa6c0FS: 0000000000000000(0000) GS:ffff9d649e400000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000008 CR3: 0000000036424000 CR4: 00000000000006f0Call Trace:worker_thread (/home/rich/kernel/linux/kernel/workqueue.c:2436)kthread (/home/rich/kernel/linux/kernel/kthread.c:376)ret_from_fork (/home/rich/kernel/linux/arch/x86/entry/entry_64.S:312)Apparently, the slcan's tx_work is freed while being scheduled. Whileslcan_netdev_close() (netdev side) calls flush_work(&sl->tx_work),slcan_close() (tty side) does not. So when the netdev is never set UP,but the tty is stuffed with bytes and forced to wakeup write, the workis scheduled, but never flushed.So add an additional flush_work() to slcan_close() to be sure the workis flushed under all circumstances.The Fixes commit below moved flush_work() from slcan_close() toslcan_netdev_close(). What was the rationale behind it? Maybe we candrop the one in slcan_netdev_close()?I see the same pattern in can327. So it perhaps needs the very same fix.

In the Linux kernel, the following vulnerability has been resolved:io_uring: Fix a null-ptr-deref in io_tctx_exit_cb()Syzkaller reports a NULL deref bug as follows:BUG: KASAN: null-ptr-deref in io_tctx_exit_cb+0x53/0xd3Read of size 4 at addr 0000000000000138 by task file1/1955CPU: 1 PID: 1955 Comm: file1 Not tainted 6.1.0-rc7-00103-gef4d3ea40565 #75Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014Call Trace:dump_stack_lvl+0xcd/0x134? io_tctx_exit_cb+0x53/0xd3kasan_report+0xbb/0x1f0? io_tctx_exit_cb+0x53/0xd3kasan_check_range+0x140/0x190io_tctx_exit_cb+0x53/0xd3task_work_run+0x164/0x250? task_work_cancel+0x30/0x30get_signal+0x1c3/0x2440? lock_downgrade+0x6e0/0x6e0? lock_downgrade+0x6e0/0x6e0? exit_signals+0x8b0/0x8b0? do_raw_read_unlock+0x3b/0x70? do_raw_spin_unlock+0x50/0x230arch_do_signal_or_restart+0x82/0x2470? kmem_cache_free+0x260/0x4b0? putname+0xfe/0x140? get_sigframe_size+0x10/0x10? do_execveat_common.isra.0+0x226/0x710? lockdep_hardirqs_on+0x79/0x100? putname+0xfe/0x140? do_execveat_common.isra.0+0x238/0x710exit_to_user_mode_prepare+0x15f/0x250syscall_exit_to_user_mode+0x19/0x50do_syscall_64+0x42/0xb0entry_SYSCALL_64_after_hwframe+0x63/0xcdRIP: 0023:0x0Code: Unable to access opcode bytes at 0xffffffffffffffd6.RSP: 002b:00000000fffb7790 EFLAGS: 00000200 ORIG_RAX: 000000000000000bRAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000Kernel panic - not syncing: panic_on_warn set ...This happens because the adding of task_work from io_ring_exit_work()isn't synchronized with canceling all work items from eg exec. Theexecution of the two are ordered in that they are both run by the taskitself, but if io_tctx_exit_cb() is queued while we're canceling allwork items off exec AND gets executed when the task exits to userspacerather than in the main loop in io_uring_cancel_generic(), then we canfind current->io_uring == NULL and hit the above crash.It's safe to add this NULL check here, because the execution of the twopaths are done by the task itself.[axboe: add code comment and also put an explanation in the commit msg]

In the Linux kernel, the following vulnerability has been resolved:net: dsa: sja1105: avoid out of bounds access in sja1105_init_l2_policing()The SJA1105 family has 45 L2 policing table entries(SJA1105_MAX_L2_POLICING_COUNT) and SJA1110 has 110(SJA1110_MAX_L2_POLICING_COUNT). Keeping the table structure butaccounting for the difference in port count (5 in SJA1105 vs 10 inSJA1110) does not fully explain the difference. Rather, the SJA1110 alsohas L2 ingress policers for multicast traffic. If a packet is classifiedas multicast, it will be processed by the policer index 99 + SRCPORT.The sja1105_init_l2_policing() function initializes all L2 policers suchthat they don't interfere with normal packet reception by default. To havea common code between SJA1105 and SJA1110, the index of the multicastpolicer for the port is calculated because it's an index that is out ofbounds for SJA1105 but in bounds for SJA1110, and a bounds check isperformed.The code fails to do the proper thing when determining what to do with themulticast policer of port 0 on SJA1105 (ds->num_ports = 5). The "mcast"index will be equal to 45, which is also equal totable->ops->max_entry_count (SJA1105_MAX_L2_POLICING_COUNT). So it passesthrough the check. But at the same time, SJA1105 doesn't have multicastpolicers. So the code programs the SHARINDX field of an out-of-boundselement in the L2 Policing table of the static config.The comparison between index 45 and 45 entries should have determined thecode to not access this policer index on SJA1105, since its memory wasn'teven allocated.With enough bad luck, the out-of-bounds write could even overwrite othervalid kernel data, but in this case, the issue was detected using KASAN.Kernel log:sja1105 spi5.0: Probed switch chip: SJA1105Q==================================================================BUG: KASAN: slab-out-of-bounds in sja1105_setup+0x1cbc/0x2340Write of size 8 at addr ffffff880bd57708 by task kworker/u8:0/8...Workqueue: events_unbound deferred_probe_work_funcCall trace:...sja1105_setup+0x1cbc/0x2340dsa_register_switch+0x1284/0x18d0sja1105_probe+0x748/0x840...Allocated by task 8:...sja1105_setup+0x1bcc/0x2340dsa_register_switch+0x1284/0x18d0sja1105_probe+0x748/0x840...

In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: fix array index out of bound error in DCN32 DML[Why&How]LinkCapacitySupport array is indexed with the number of voltage states andnot the number of max DPPs. Fix the error by changing the arraydeclaration to use the correct (larger) array size of total number ofvoltage states.

In the Linux kernel, the following vulnerability has been resolved:

In the Linux kernel, the following vulnerability has been resolved:netfilter: conntrack: fix using __this_cpu_add in preemptibleCurrently in nf_conntrack_hash_check_insert(), when it fails innf_ct_ext_valid_pre/post(), NF_CT_STAT_INC() will be called in thepreemptible context, a call trace can be triggered:BUG: using __this_cpu_add() in preemptible [00000000] code: conntrack/1636caller is nf_conntrack_hash_check_insert+0x45/0x430 [nf_conntrack]Call Trace:dump_stack_lvl+0x33/0x46check_preemption_disabled+0xc3/0xf0nf_conntrack_hash_check_insert+0x45/0x430 [nf_conntrack]ctnetlink_create_conntrack+0x3cd/0x4e0 [nf_conntrack_netlink]ctnetlink_new_conntrack+0x1c0/0x450 [nf_conntrack_netlink]nfnetlink_rcv_msg+0x277/0x2f0 [nfnetlink]netlink_rcv_skb+0x50/0x100nfnetlink_rcv+0x65/0x144 [nfnetlink]netlink_unicast+0x1ae/0x290netlink_sendmsg+0x257/0x4f0sock_sendmsg+0x5f/0x70This patch is to fix it by changing to use NF_CT_STAT_INC_ATOMIC() fornf_ct_ext_valid_pre/post() check in nf_conntrack_hash_check_insert(),as well as nf_ct_ext_valid_post() in __nf_conntrack_confirm().Note that nf_ct_ext_valid_pre() check in __nf_conntrack_confirm() issafe to use NF_CT_STAT_INC(), as it's under local_bh_disable().

In the Linux kernel, the following vulnerability has been resolved:af_unix: Get user_ns from in_skb in unix_diag_get_exact().Wei Chen reported a NULL deref in sk_user_ns() [0][1], and Paolo diagnosedthe root cause: in unix_diag_get_exact(), the newly allocated skb does nothave sk. [2]We must get the user_ns from the NETLINK_CB(in_skb).sk and pass it tosk_diag_fill().[0]:BUG: kernel NULL pointer dereference, address: 0000000000000270#PF: supervisor read access in kernel mode#PF: error_code(0x0000) - not-present pagePGD 12bbce067 P4D 12bbce067 PUD 12bc40067 PMD 0Oops: 0000 [#1] PREEMPT SMPCPU: 0 PID: 27942 Comm: syz-executor.0 Not tainted 6.1.0-rc5-next-20221118 #2Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOSrel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014RIP: 0010:sk_user_ns include/net/sock.h:920 [inline]RIP: 0010:sk_diag_dump_uid net/unix/diag.c:119 [inline]RIP: 0010:sk_diag_fill+0x77d/0x890 net/unix/diag.c:170Code: 89 ef e8 66 d4 2d fd c7 44 24 40 00 00 00 00 49 8d 7c 24 18 e854 d7 2d fd 49 8b 5c 24 18 48 8d bb 70 02 00 00 e8 43 d7 2d fd <48> 8b9b 70 02 00 00 48 8d 7b 10 e8 33 d7 2d fd 48 8b 5b 10 48 8dRSP: 0018:ffffc90000d67968 EFLAGS: 00010246RAX: ffff88812badaa48 RBX: 0000000000000000 RCX: ffffffff840d481dRDX: 0000000000000465 RSI: 0000000000000000 RDI: 0000000000000270RBP: ffffc90000d679a8 R08: 0000000000000277 R09: 0000000000000000R10: 0001ffffffffffff R11: 0001c90000d679a8 R12: ffff88812ac03800R13: ffff88812c87c400 R14: ffff88812ae42210 R15: ffff888103026940FS: 00007f08b4e6f700(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000270 CR3: 000000012c58b000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:unix_diag_get_exact net/unix/diag.c:285 [inline]unix_diag_handler_dump+0x3f9/0x500 net/unix/diag.c:317__sock_diag_cmd net/core/sock_diag.c:235 [inline]sock_diag_rcv_msg+0x237/0x250 net/core/sock_diag.c:266netlink_rcv_skb+0x13e/0x250 net/netlink/af_netlink.c:2564sock_diag_rcv+0x24/0x40 net/core/sock_diag.c:277netlink_unicast_kernel net/netlink/af_netlink.c:1330 [inline]netlink_unicast+0x5e9/0x6b0 net/netlink/af_netlink.c:1356netlink_sendmsg+0x739/0x860 net/netlink/af_netlink.c:1932sock_sendmsg_nosec net/socket.c:714 [inline]sock_sendmsg net/socket.c:734 [inline]____sys_sendmsg+0x38f/0x500 net/socket.c:2476___sys_sendmsg net/socket.c:2530 [inline]__sys_sendmsg+0x197/0x230 net/socket.c:2559__do_sys_sendmsg net/socket.c:2568 [inline]__se_sys_sendmsg net/socket.c:2566 [inline]__x64_sys_sendmsg+0x42/0x50 net/socket.c:2566do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdRIP: 0033:0x4697f9Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 4889 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f08b4e6ec48 EFLAGS: 00000246 ORIG_RAX: 000000000000002eRAX: ffffffffffffffda RBX: 000000000077bf80 RCX: 00000000004697f9RDX: 0000000000000000 RSI: 00000000200001c0 RDI: 0000000000000003RBP: 00000000004d29e9 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 000000000077bf80R13: 0000000000000000 R14: 000000000077bf80 R15: 00007ffdb36bc6c0Modules linked in:CR2: 0000000000000270[1]: https://lore.kernel.org/netdev/CAO4mrfdvyjFpokhNsiwZiP-wpdSD0AStcJwfKcKQdAALQ9_2Qw@mail.gmail.com/[2]: https://lore.kernel.org/netdev/e04315e7c90d9a75613f3993c2baf2d344eef7eb.camel@redhat.com/

In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: Fix potential memory leak in otx2_init_tc()In otx2_init_tc(), if rhashtable_init() failed, it does not freetc->tc_entries_bitmap which is allocated in otx2_tc_alloc_ent_bitmap().

In the Linux kernel, the following vulnerability has been resolved:gpio/rockchip: fix refcount leak in rockchip_gpiolib_register()The node returned by of_get_parent() with refcount incremented,of_node_put() needs be called when finish using it. So add it in theend of of_pinctrl_get().

In the Linux kernel, the following vulnerability has been resolved:

In the Linux kernel, the following vulnerability has been resolved:dpaa2-switch: Fix memory leak in dpaa2_switch_acl_entry_add() and dpaa2_switch_acl_entry_remove()The cmd_buff needs to be freed when error happened indpaa2_switch_acl_entry_add() and dpaa2_switch_acl_entry_remove().