Leaking of file descriptors from the fork server to web content processes could allow for privilege escalation attacks. This vulnerability affects Firefox < 137 and Thunderbird < 137.

An attacker could read 32 bits of values spilled onto the stack in a JIT compiled function. This vulnerability affects Firefox < 137 and Thunderbird < 137.

Memory safety bugs present in Firefox 136, Thunderbird 136, Firefox ESR 128.8, and Thunderbird 128.8. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 137, Firefox ESR < 128.9, Thunderbird < 137, and Thunderbird ESR < 128.9.

A crafted URL containing specific Unicode characters could have hidden the true origin of the page, resulting in a potential spoofing attack. This vulnerability affects Firefox < 137, Firefox ESR < 128.9, Thunderbird < 137, and Thunderbird ESR < 128.9.

JavaScript code running while transforming a document with the XSLTProcessor could lead to a use-after-free. This vulnerability affects Firefox < 137, Firefox ESR < 115.22, Firefox ESR < 128.9, Thunderbird < 137, and Thunderbird ESR < 128.9.

Following the recent Chrome sandbox escape (CVE-2025-2783), various Firefox developers identified a similar pattern in our IPC code. A compromised child process could cause the parent process to return an unintentionally powerful handle, leading to a sandbox escape. \nThe original vulnerability was being exploited in the wild. \n*This only affects Firefox on Windows. Other operating systems are unaffected.* This vulnerability affects Firefox < 136.0.4, Firefox ESR < 128.8.1, and Firefox ESR < 115.21.1.

Null Pointer Dereference vulnerability in libarchive 3.7.6 and earlier when running program bsdtar in function header_pax_extension at rchive_read_support_format_tar.c:1844:8.

A file dialog shown while in full-screen mode could have resulted in the window remaining disabled. This vulnerability affects Firefox < 126.

An HTTP digest authentication nonce value was generated using `rand()` which could lead to predictable values. This vulnerability affects Firefox < 126.

A memory allocation check was missing which would lead to a use-after-free if the allocation failed. This could have triggered a crash or potentially be leveraged to achieve code execution. This vulnerability affects Firefox < 126.

Passing invalid data could have led to invalid wasm values being created, such as arbitrary integers turning into pointer values. This vulnerability affects Firefox < 124.

The issue was addressed with improved memory handling. This issue is fixed in visionOS 2.4, tvOS 18.4, iPadOS 17.7.6, iOS 18.4 and iPadOS 18.4, macOS Sequoia 15.4, Safari 18.4. Processing maliciously crafted web content may lead to an unexpected Safari crash.

Memory safety bugs present in Firefox 124. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 125.

It was possible to mutate a JavaScript object so that the JIT could crash while tracing it. This vulnerability affects Firefox < 125.

In certain cases the JIT incorrectly optimized MSubstr operations, which led to out-of-bounds reads. This vulnerability affects Firefox < 125.

Buffer Overflow vulnerability in load function in PluginICO.cpp in FreeImage 3.19.0 [r1859] allows remote attackers to run arbitrary code via opening of crafted ico file.

Buffer Overflow vulnerability in function LoadRGB in PluginDDS.cpp in FreeImage 3.18.0 allows remote attackers to run arbitrary code and cause other impacts via crafted image file.

In the Linux kernel, the following vulnerability has been resolved:\n\nptdma: pt_core_execute_cmd() should use spinlock\n\nThe interrupt handler (pt_core_irq_handler()) of the ptdma\ndriver can be called from interrupt context. The code flow\nin this function can lead down to pt_core_execute_cmd() which\nwill attempt to grab a mutex, which is not appropriate in\ninterrupt context and ultimately leads to a kernel panic.\nThe fix here changes this mutex to a spinlock, which has\nbeen verified to resolve the issue.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: enable all safety features by default\n\nIn the original implementation of dwmac5\ncommit 8bf993a5877e ("net: stmmac: Add support for DWMAC5 and implement Safety Features")\nall safety features were enabled by default.\n\nLater it seems some implementations didn't have support for all the\nfeatures, so in\ncommit 5ac712dcdfef ("net: stmmac: enable platform specific safety features")\nthe safety_feat_cfg structure was added to the callback and defined for\nsome platforms to selectively enable these safety features.\n\nThe problem is that only certain platforms were given that software\nsupport. If the automotive safety package bit is set in the hardware\nfeatures register the safety feature callback is called for the platform,\nand for platforms that didn't get a safety_feat_cfg defined this results\nin the following NULL pointer dereference:\n\n[ 7.933303] Call trace:\n[ 7.935812] dwmac5_safety_feat_config+0x20/0x170 [stmmac]\n[ 7.941455] __stmmac_open+0x16c/0x474 [stmmac]\n[ 7.946117] stmmac_open+0x38/0x70 [stmmac]\n[ 7.950414] __dev_open+0x100/0x1dc\n[ 7.954006] __dev_change_flags+0x18c/0x204\n[ 7.958297] dev_change_flags+0x24/0x6c\n[ 7.962237] do_setlink+0x2b8/0xfa4\n[ 7.965827] __rtnl_newlink+0x4ec/0x840\n[ 7.969766] rtnl_newlink+0x50/0x80\n[ 7.973353] rtnetlink_rcv_msg+0x12c/0x374\n[ 7.977557] netlink_rcv_skb+0x5c/0x130\n[ 7.981500] rtnetlink_rcv+0x18/0x2c\n[ 7.985172] netlink_unicast+0x2e8/0x340\n[ 7.989197] netlink_sendmsg+0x1a8/0x420\n[ 7.993222] ____sys_sendmsg+0x218/0x280\n[ 7.997249] ___sys_sendmsg+0xac/0x100\n[ 8.001103] __sys_sendmsg+0x84/0xe0\n[ 8.004776] __arm64_sys_sendmsg+0x24/0x30\n[ 8.008983] invoke_syscall+0x48/0x114\n[ 8.012840] el0_svc_common.constprop.0+0xcc/0xec\n[ 8.017665] do_el0_svc+0x38/0xb0\n[ 8.021071] el0_svc+0x2c/0x84\n[ 8.024212] el0t_64_sync_handler+0xf4/0x120\n[ 8.028598] el0t_64_sync+0x190/0x194\n\nGo back to the original behavior, if the automotive safety package\nis found to be supported in hardware enable all the features unless\nsafety_feat_cfg is passed in saying this particular platform only\nsupports a subset of the features.

In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/imc-pmu: Fix use of mutex in IRQs disabled section\n\nCurrent imc-pmu code triggers a WARNING with CONFIG_DEBUG_ATOMIC_SLEEP\nand CONFIG_PROVE_LOCKING enabled, while running a thread_imc event.\n\nCommand to trigger the warning:\n # perf stat -e thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/ sleep 5\n\n Performance counter stats for 'sleep 5':\n\n 0 thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/\n\n 5.002117947 seconds time elapsed\n\n 0.000131000 seconds user\n 0.001063000 seconds sys\n\nBelow is snippet of the warning in dmesg:\n\n BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580\n in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 2869, name: perf-exec\n preempt_count: 2, expected: 0\n 4 locks held by perf-exec/2869:\n #0: c00000004325c540 (&sig->cred_guard_mutex){+.+.}-{3:3}, at: bprm_execve+0x64/0xa90\n #1: c00000004325c5d8 (&sig->exec_update_lock){++++}-{3:3}, at: begin_new_exec+0x460/0xef0\n #2: c0000003fa99d4e0 (&cpuctx_lock){-...}-{2:2}, at: perf_event_exec+0x290/0x510\n #3: c000000017ab8418 (&ctx->lock){....}-{2:2}, at: perf_event_exec+0x29c/0x510\n irq event stamp: 4806\n hardirqs last enabled at (4805): [<c000000000f65b94>] _raw_spin_unlock_irqrestore+0x94/0xd0\n hardirqs last disabled at (4806): [<c0000000003fae44>] perf_event_exec+0x394/0x510\n softirqs last enabled at (0): [<c00000000013c404>] copy_process+0xc34/0x1ff0\n softirqs last disabled at (0): [<0000000000000000>] 0x0\n CPU: 36 PID: 2869 Comm: perf-exec Not tainted 6.2.0-rc2-00011-g1247637727f2 #61\n Hardware name: 8375-42A POWER9 0x4e1202 opal:v7.0-16-g9b85f7d961 PowerNV\n Call Trace:\n dump_stack_lvl+0x98/0xe0 (unreliable)\n __might_resched+0x2f8/0x310\n __mutex_lock+0x6c/0x13f0\n thread_imc_event_add+0xf4/0x1b0\n event_sched_in+0xe0/0x210\n merge_sched_in+0x1f0/0x600\n visit_groups_merge.isra.92.constprop.166+0x2bc/0x6c0\n ctx_flexible_sched_in+0xcc/0x140\n ctx_sched_in+0x20c/0x2a0\n ctx_resched+0x104/0x1c0\n perf_event_exec+0x340/0x510\n begin_new_exec+0x730/0xef0\n load_elf_binary+0x3f8/0x1e10\n ...\n do not call blocking ops when !TASK_RUNNING; state=2001 set at [<00000000fd63e7cf>] do_nanosleep+0x60/0x1a0\n WARNING: CPU: 36 PID: 2869 at kernel/sched/core.c:9912 __might_sleep+0x9c/0xb0\n CPU: 36 PID: 2869 Comm: sleep Tainted: G W 6.2.0-rc2-00011-g1247637727f2 #61\n Hardware name: 8375-42A POWER9 0x4e1202 opal:v7.0-16-g9b85f7d961 PowerNV\n NIP: c000000000194a1c LR: c000000000194a18 CTR: c000000000a78670\n REGS: c00000004d2134e0 TRAP: 0700 Tainted: G W (6.2.0-rc2-00011-g1247637727f2)\n MSR: 9000000000021033 <SF,HV,ME,IR,DR,RI,LE> CR: 48002824 XER: 00000000\n CFAR: c00000000013fb64 IRQMASK: 1\n\nThe above warning triggered because the current imc-pmu code uses mutex\nlock in interrupt disabled sections. The function mutex_lock()\ninternally calls __might_resched(), which will check if IRQs are\ndisabled and in case IRQs are disabled, it will trigger the warning.\n\nFix the issue by changing the mutex lock to spinlock.\n\n[mpe: Fix comments, trim oops in change log, add reported-by tags]

In the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-pf: Fix the use of GFP_KERNEL in atomic context on rt\n\nThe commit 4af1b64f80fb ("octeontx2-pf: Fix lmtst ID used in aura\nfree") uses the get/put_cpu() to protect the usage of percpu pointer\nin ->aura_freeptr() callback, but it also unnecessarily disable the\npreemption for the blockable memory allocation. The commit 87b93b678e95\n("octeontx2-pf: Avoid use of GFP_KERNEL in atomic context") tried to\nfix these sleep inside atomic warnings. But it only fix the one for\nthe non-rt kernel. For the rt kernel, we still get the similar warnings\nlike below.\n BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46\n in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0\n preempt_count: 1, expected: 0\n RCU nest depth: 0, expected: 0\n 3 locks held by swapper/0/1:\n #0: ffff800009fc5fe8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock+0x24/0x30\n #1: ffff000100c276c0 (&mbox->lock){+.+.}-{3:3}, at: otx2_init_hw_resources+0x8c/0x3a4\n #2: ffffffbfef6537e0 (&cpu_rcache->lock){+.+.}-{2:2}, at: alloc_iova_fast+0x1ac/0x2ac\n Preemption disabled at:\n [<ffff800008b1908c>] otx2_rq_aura_pool_init+0x14c/0x284\n CPU: 20 PID: 1 Comm: swapper/0 Tainted: G W 6.2.0-rc3-rt1-yocto-preempt-rt #1\n Hardware name: Marvell OcteonTX CN96XX board (DT)\n Call trace:\n dump_backtrace.part.0+0xe8/0xf4\n show_stack+0x20/0x30\n dump_stack_lvl+0x9c/0xd8\n dump_stack+0x18/0x34\n __might_resched+0x188/0x224\n rt_spin_lock+0x64/0x110\n alloc_iova_fast+0x1ac/0x2ac\n iommu_dma_alloc_iova+0xd4/0x110\n __iommu_dma_map+0x80/0x144\n iommu_dma_map_page+0xe8/0x260\n dma_map_page_attrs+0xb4/0xc0\n __otx2_alloc_rbuf+0x90/0x150\n otx2_rq_aura_pool_init+0x1c8/0x284\n otx2_init_hw_resources+0xe4/0x3a4\n otx2_open+0xf0/0x610\n __dev_open+0x104/0x224\n __dev_change_flags+0x1e4/0x274\n dev_change_flags+0x2c/0x7c\n ic_open_devs+0x124/0x2f8\n ip_auto_config+0x180/0x42c\n do_one_initcall+0x90/0x4dc\n do_basic_setup+0x10c/0x14c\n kernel_init_freeable+0x10c/0x13c\n kernel_init+0x2c/0x140\n ret_from_fork+0x10/0x20\n\nOf course, we can shuffle the get/put_cpu() to only wrap the invocation\nof ->aura_freeptr() as what commit 87b93b678e95 does. But there are only\ntwo ->aura_freeptr() callbacks, otx2_aura_freeptr() and\ncn10k_aura_freeptr(). There is no usage of perpcu variable in the\notx2_aura_freeptr() at all, so the get/put_cpu() seems redundant to it.\nWe can move the get/put_cpu() into the corresponding callback which\nreally has the percpu variable usage and avoid the sprinkling of\nget/put_cpu() in several places.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: mdio: validate parameter addr in mdiobus_get_phy()\n\nThe caller may pass any value as addr, what may result in an out-of-bounds\naccess to array mdio_map. One existing case is stmmac_init_phy() that\nmay pass -1 as addr. Therefore validate addr before using it.

In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: tegra: Fix memory leak in terminate_all()\n\nTerminate vdesc when terminating an ongoing transfer.\nThis will ensure that the vdesc is present in the desc_terminated list\nThe descriptor will be freed later in desc_free_list().\n\nThis fixes the memory leaks which can happen when terminating an\nongoing transfer.

In the Linux kernel, the following vulnerability has been resolved:\n\nidpf: fix checksums set in idpf_rx_rsc()\n\nidpf_rx_rsc() uses skb_transport_offset(skb) while the transport header\nis not set yet.\n\nThis triggers the following warning for CONFIG_DEBUG_NET=y builds.\n\nDEBUG_NET_WARN_ON_ONCE(!skb_transport_header_was_set(skb))\n\n[ 69.261620] WARNING: CPU: 7 PID: 0 at ./include/linux/skbuff.h:3020 idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf\n[ 69.261629] Modules linked in: vfat fat dummy bridge intel_uncore_frequency_tpmi intel_uncore_frequency_common intel_vsec_tpmi idpf intel_vsec cdc_ncm cdc_eem cdc_ether usbnet mii xhci_pci xhci_hcd ehci_pci ehci_hcd libeth\n[ 69.261644] CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Tainted: G S W 6.14.0-smp-DEV #1697\n[ 69.261648] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN\n[ 69.261650] RIP: 0010:idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf\n[ 69.261677] ? __warn (kernel/panic.c:242 kernel/panic.c:748)\n[ 69.261682] ? idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf\n[ 69.261687] ? report_bug (lib/bug.c:?)\n[ 69.261690] ? handle_bug (arch/x86/kernel/traps.c:285)\n[ 69.261694] ? exc_invalid_op (arch/x86/kernel/traps.c:309)\n[ 69.261697] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621)\n[ 69.261700] ? __pfx_idpf_vport_splitq_napi_poll (drivers/net/ethernet/intel/idpf/idpf_txrx.c:4011) idpf\n[ 69.261704] ? idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf\n[ 69.261708] ? idpf_vport_splitq_napi_poll (drivers/net/ethernet/intel/idpf/idpf_txrx.c:3072) idpf\n[ 69.261712] __napi_poll (net/core/dev.c:7194)\n[ 69.261716] net_rx_action (net/core/dev.c:7265)\n[ 69.261718] ? __qdisc_run (net/sched/sch_generic.c:293)\n[ 69.261721] ? sched_clock (arch/x86/include/asm/preempt.h:84 arch/x86/kernel/tsc.c:288)\n[ 69.261726] handle_softirqs (kernel/softirq.c:561)

In the Linux kernel, the following vulnerability has been resolved:\n\nperf/core: Add RCU read lock protection to perf_iterate_ctx()\n\nThe perf_iterate_ctx() function performs RCU list traversal but\ncurrently lacks RCU read lock protection. This causes lockdep warnings\nwhen running perf probe with unshare(1) under CONFIG_PROVE_RCU_LIST=y:\n\n WARNING: suspicious RCU usage\n kernel/events/core.c:8168 RCU-list traversed in non-reader section!!\n\n Call Trace:\n lockdep_rcu_suspicious\n ? perf_event_addr_filters_apply\n perf_iterate_ctx\n perf_event_exec\n begin_new_exec\n ? load_elf_phdrs\n load_elf_binary\n ? lock_acquire\n ? find_held_lock\n ? bprm_execve\n bprm_execve\n do_execveat_common.isra.0\n __x64_sys_execve\n do_syscall_64\n entry_SYSCALL_64_after_hwframe\n\nThis protection was previously present but was removed in commit\nbd2756811766 ("perf: Rewrite core context handling"). Add back the\nnecessary rcu_read_lock()/rcu_read_unlock() pair around\nperf_iterate_ctx() call in perf_event_exec().\n\n[ mingo: Use scoped_guard() as suggested by Peter ]

In the Linux kernel, the following vulnerability has been resolved:\n\novl: fix UAF in ovl_dentry_update_reval by moving dput() in ovl_link_up\n\nThe issue was caused by dput(upper) being called before\novl_dentry_update_reval(), while upper->d_flags was still\naccessed in ovl_dentry_remote().\n\nMove dput(upper) after its last use to prevent use-after-free.\n\nBUG: KASAN: slab-use-after-free in ovl_dentry_remote fs/overlayfs/util.c:162 [inline]\nBUG: KASAN: slab-use-after-free in ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167\n\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0xc3/0x620 mm/kasan/report.c:488\n kasan_report+0xd9/0x110 mm/kasan/report.c:601\n ovl_dentry_remote fs/overlayfs/util.c:162 [inline]\n ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167\n ovl_link_up fs/overlayfs/copy_up.c:610 [inline]\n ovl_copy_up_one+0x2105/0x3490 fs/overlayfs/copy_up.c:1170\n ovl_copy_up_flags+0x18d/0x200 fs/overlayfs/copy_up.c:1223\n ovl_rename+0x39e/0x18c0 fs/overlayfs/dir.c:1136\n vfs_rename+0xf84/0x20a0 fs/namei.c:4893\n...\n </TASK>

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Fix implicit ODP hang on parent deregistration\n\nFix the destroy_unused_implicit_child_mr() to prevent hanging during\nparent deregistration as of below [1].\n\nUpon entering destroy_unused_implicit_child_mr(), the reference count\nfor the implicit MR parent is incremented using:\nrefcount_inc_not_zero().\n\nA corresponding decrement must be performed if\nfree_implicit_child_mr_work() is not called.\n\nThe code has been updated to properly manage the reference count that\nwas incremented.\n\n[1]\nINFO: task python3:2157 blocked for more than 120 seconds.\nNot tainted 6.12.0-rc7+ #1633\n"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.\ntask:python3 state:D stack:0 pid:2157 tgid:2157 ppid:1685 flags:0x00000000\nCall Trace:\n<TASK>\n__schedule+0x420/0xd30\nschedule+0x47/0x130\n__mlx5_ib_dereg_mr+0x379/0x5d0 [mlx5_ib]\n? __pfx_autoremove_wake_function+0x10/0x10\nib_dereg_mr_user+0x5f/0x120 [ib_core]\n? lock_release+0xc6/0x280\ndestroy_hw_idr_uobject+0x1d/0x60 [ib_uverbs]\nuverbs_destroy_uobject+0x58/0x1d0 [ib_uverbs]\nuobj_destroy+0x3f/0x70 [ib_uverbs]\nib_uverbs_cmd_verbs+0x3e4/0xbb0 [ib_uverbs]\n? __pfx_uverbs_destroy_def_handler+0x10/0x10 [ib_uverbs]\n? lock_acquire+0xc1/0x2f0\n? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs]\n? ib_uverbs_ioctl+0x116/0x170 [ib_uverbs]\n? lock_release+0xc6/0x280\nib_uverbs_ioctl+0xe7/0x170 [ib_uverbs]\n? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs]\n __x64_sys_ioctl+0x1b0/0xa70\n? kmem_cache_free+0x221/0x400\ndo_syscall_64+0x6b/0x140\nentry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7f20f21f017b\nRSP: 002b:00007ffcfc4a77c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\nRAX: ffffffffffffffda RBX: 00007ffcfc4a78d8 RCX: 00007f20f21f017b\nRDX: 00007ffcfc4a78c0 RSI: 00000000c0181b01 RDI: 0000000000000003\nRBP: 00007ffcfc4a78a0 R08: 000056147d125190 R09: 00007f20f1f14c60\nR10: 0000000000000001 R11: 0000000000000246 R12: 00007ffcfc4a7890\nR13: 000000000000001c R14: 000056147d100fc0 R15: 00007f20e365c9d0\n</TASK>

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Fix vport QoS cleanup on error\n\nWhen enabling vport QoS fails, the scheduling node was never freed,\ncausing a leak.\n\nAdd the missing free and reset the vport scheduling node pointer to\nNULL.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe/userptr: fix EFAULT handling\n\nCurrently we treat EFAULT from hmm_range_fault() as a non-fatal error\nwhen called from xe_vm_userptr_pin() with the idea that we want to avoid\nkilling the entire vm and chucking an error, under the assumption that\nthe user just did an unmap or something, and has no intention of\nactually touching that memory from the GPU. At this point we have\nalready zapped the PTEs so any access should generate a page fault, and\nif the pin fails there also it will then become fatal.\n\nHowever it looks like it's possible for the userptr vma to still be on\nthe rebind list in preempt_rebind_work_func(), if we had to retry the\npin again due to something happening in the caller before we did the\nrebind step, but in the meantime needing to re-validate the userptr and\nthis time hitting the EFAULT.\n\nThis explains an internal user report of hitting:\n\n[ 191.738349] WARNING: CPU: 1 PID: 157 at drivers/gpu/drm/xe/xe_res_cursor.h:158 xe_pt_stage_bind.constprop.0+0x60a/0x6b0 [xe]\n[ 191.738551] Workqueue: xe-ordered-wq preempt_rebind_work_func [xe]\n[ 191.738616] RIP: 0010:xe_pt_stage_bind.constprop.0+0x60a/0x6b0 [xe]\n[ 191.738690] Call Trace:\n[ 191.738692] <TASK>\n[ 191.738694] ? show_regs+0x69/0x80\n[ 191.738698] ? __warn+0x93/0x1a0\n[ 191.738703] ? xe_pt_stage_bind.constprop.0+0x60a/0x6b0 [xe]\n[ 191.738759] ? report_bug+0x18f/0x1a0\n[ 191.738764] ? handle_bug+0x63/0xa0\n[ 191.738767] ? exc_invalid_op+0x19/0x70\n[ 191.738770] ? asm_exc_invalid_op+0x1b/0x20\n[ 191.738777] ? xe_pt_stage_bind.constprop.0+0x60a/0x6b0 [xe]\n[ 191.738834] ? ret_from_fork_asm+0x1a/0x30\n[ 191.738849] bind_op_prepare+0x105/0x7b0 [xe]\n[ 191.738906] ? dma_resv_reserve_fences+0x301/0x380\n[ 191.738912] xe_pt_update_ops_prepare+0x28c/0x4b0 [xe]\n[ 191.738966] ? kmemleak_alloc+0x4b/0x80\n[ 191.738973] ops_execute+0x188/0x9d0 [xe]\n[ 191.739036] xe_vm_rebind+0x4ce/0x5a0 [xe]\n[ 191.739098] ? trace_hardirqs_on+0x4d/0x60\n[ 191.739112] preempt_rebind_work_func+0x76f/0xd00 [xe]\n\nFollowed by NPD, when running some workload, since the sg was never\nactually populated but the vma is still marked for rebind when it should\nbe skipped for this special EFAULT case. This is confirmed to fix the\nuser report.\n\nv2 (MattB):\n - Move earlier.\nv3 (MattB):\n - Update the commit message to make it clear that this indeed fixes the\n issue.\n\n(cherry picked from commit 6b93cb98910c826c2e2004942f8b060311e43618)

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix use-after-free on inode when scanning root during em shrinking\n\nAt btrfs_scan_root() we are accessing the inode's root (and fs_info) in a\ncall to btrfs_fs_closing() after we have scheduled the inode for a delayed\niput, and that can result in a use-after-free on the inode in case the\ncleaner kthread does the iput before we dereference the inode in the call\nto btrfs_fs_closing().\n\nFix this by using the fs_info stored already in a local variable instead\nof doing inode->root->fs_info.

In the Linux kernel, the following vulnerability has been resolved:\n\nusbnet: gl620a: fix endpoint checking in genelink_bind()\n\nSyzbot reports [1] a warning in usb_submit_urb() triggered by\ninconsistencies between expected and actually present endpoints\nin gl620a driver. Since genelink_bind() does not properly\nverify whether specified eps are in fact provided by the device,\nin this case, an artificially manufactured one, one may get a\nmismatch.\n\nFix the issue by resorting to a usbnet utility function\nusbnet_get_endpoints(), usually reserved for this very problem.\nCheck for endpoints and return early before proceeding further if\nany are missing.\n\n[1] Syzbot report:\nusb 5-1: Manufacturer: syz\nusb 5-1: SerialNumber: syz\nusb 5-1: config 0 descriptor??\ngl620a 5-1:0.23 usb0: register 'gl620a' at usb-dummy_hcd.0-1, ...\n------------[ cut here ]------------\nusb 5-1: BOGUS urb xfer, pipe 3 != type 1\nWARNING: CPU: 2 PID: 1841 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503\nModules linked in:\nCPU: 2 UID: 0 PID: 1841 Comm: kworker/2:2 Not tainted 6.12.0-syzkaller-07834-g06afb0f36106 #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nWorkqueue: mld mld_ifc_work\nRIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503\n...\nCall Trace:\n <TASK>\n usbnet_start_xmit+0x6be/0x2780 drivers/net/usb/usbnet.c:1467\n __netdev_start_xmit include/linux/netdevice.h:5002 [inline]\n netdev_start_xmit include/linux/netdevice.h:5011 [inline]\n xmit_one net/core/dev.c:3590 [inline]\n dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3606\n sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343\n __dev_xmit_skb net/core/dev.c:3827 [inline]\n __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4400\n dev_queue_xmit include/linux/netdevice.h:3168 [inline]\n neigh_resolve_output net/core/neighbour.c:1514 [inline]\n neigh_resolve_output+0x5bc/0x950 net/core/neighbour.c:1494\n neigh_output include/net/neighbour.h:539 [inline]\n ip6_finish_output2+0xb1b/0x2070 net/ipv6/ip6_output.c:141\n __ip6_finish_output net/ipv6/ip6_output.c:215 [inline]\n ip6_finish_output+0x3f9/0x1360 net/ipv6/ip6_output.c:226\n NF_HOOK_COND include/linux/netfilter.h:303 [inline]\n ip6_output+0x1f8/0x540 net/ipv6/ip6_output.c:247\n dst_output include/net/dst.h:450 [inline]\n NF_HOOK include/linux/netfilter.h:314 [inline]\n NF_HOOK include/linux/netfilter.h:308 [inline]\n mld_sendpack+0x9f0/0x11d0 net/ipv6/mcast.c:1819\n mld_send_cr net/ipv6/mcast.c:2120 [inline]\n mld_ifc_work+0x740/0xca0 net/ipv6/mcast.c:2651\n process_one_work+0x9c5/0x1ba0 kernel/workqueue.c:3229\n process_scheduled_works kernel/workqueue.c:3310 [inline]\n worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391\n kthread+0x2c1/0x3a0 kernel/kthread.c:389\n ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n </TASK>

In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: always handle address removal under msk socket lock\n\nSyzkaller reported a lockdep splat in the PM control path:\n\n WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 sock_owned_by_me include/net/sock.h:1711 [inline]\n WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 msk_owned_by_me net/mptcp/protocol.h:363 [inline]\n WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788\n Modules linked in:\n CPU: 0 UID: 0 PID: 6693 Comm: syz.0.205 Not tainted 6.14.0-rc2-syzkaller-00303-gad1b832bf1cf #0\n Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024\n RIP: 0010:sock_owned_by_me include/net/sock.h:1711 [inline]\n RIP: 0010:msk_owned_by_me net/mptcp/protocol.h:363 [inline]\n RIP: 0010:mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788\n Code: 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ca 7b d3 f5 eb b9 e8 c3 7b d3 f5 90 0f 0b 90 e9 dd fb ff ff e8 b5 7b d3 f5 90 <0f> 0b 90 e9 3e fb ff ff 44 89 f1 80 e1 07 38 c1 0f 8c eb fb ff ff\n RSP: 0000:ffffc900034f6f60 EFLAGS: 00010283\n RAX: ffffffff8bee3c2b RBX: 0000000000000001 RCX: 0000000000080000\n RDX: ffffc90004d42000 RSI: 000000000000a407 RDI: 000000000000a408\n RBP: ffffc900034f7030 R08: ffffffff8bee37f6 R09: 0100000000000000\n R10: dffffc0000000000 R11: ffffed100bcc62e4 R12: ffff88805e6316e0\n R13: ffff88805e630c00 R14: dffffc0000000000 R15: ffff88805e630c00\n FS: 00007f7e9a7e96c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000001b2fd18ff8 CR3: 0000000032c24000 CR4: 00000000003526f0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n <TASK>\n mptcp_pm_remove_addr+0x103/0x1d0 net/mptcp/pm.c:59\n mptcp_pm_remove_anno_addr+0x1f4/0x2f0 net/mptcp/pm_netlink.c:1486\n mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_netlink.c:1518 [inline]\n mptcp_pm_nl_del_addr_doit+0x118d/0x1af0 net/mptcp/pm_netlink.c:1629\n genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline]\n genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]\n genl_rcv_msg+0xb1f/0xec0 net/netlink/genetlink.c:1210\n netlink_rcv_skb+0x206/0x480 net/netlink/af_netlink.c:2543\n genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219\n netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline]\n netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1348\n netlink_sendmsg+0x8de/0xcb0 net/netlink/af_netlink.c:1892\n sock_sendmsg_nosec net/socket.c:718 [inline]\n __sock_sendmsg+0x221/0x270 net/socket.c:733\n ____sys_sendmsg+0x53a/0x860 net/socket.c:2573\n ___sys_sendmsg net/socket.c:2627 [inline]\n __sys_sendmsg+0x269/0x350 net/socket.c:2659\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n RIP: 0033:0x7f7e9998cde9\n Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 a8 ff ff ff f7 d8 64 89 01 48\n RSP: 002b:00007f7e9a7e9038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\n RAX: ffffffffffffffda RBX: 00007f7e99ba5fa0 RCX: 00007f7e9998cde9\n RDX: 000000002000c094 RSI: 0000400000000000 RDI: 0000000000000007\n RBP: 00007f7e99a0e2a0 R08: 0000000000000000 R09: 0000000000000000\n R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\n R13: 0000000000000000 R14: 00007f7e99ba5fa0 R15: 00007fff49231088\n\nIndeed the PM can try to send a RM_ADDR over a msk without acquiring\nfirst the msk socket lock.\n\nThe bugged code-path comes from an early optimization: when there\nare no subflows, the PM should (usually) not send RM_ADDR\nnotifications.\n\nThe above statement is incorrect, as without locks another process\ncould concurrent create a new subflow and cause the RM_ADDR generation.\n\nAdditionally the supposed optimization is not very effective even\nperformance-wise, as most mptcp sockets should have at least one\nsubflow: the MPC one.\n\nAddress the issue removing the buggy code path, the existing "slow-path"\nwill handle correctly even the edge case.

In the Linux kernel, the following vulnerability has been resolved:\n\nefi: Don't map the entire mokvar table to determine its size\n\nCurrently, when validating the mokvar table, we (re)map the entire table\non each iteration of the loop, adding space as we discover new entries.\nIf the table grows over a certain size, this fails due to limitations of\nearly_memmap(), and we get a failure and traceback:\n\n ------------[ cut here ]------------\n WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:139 __early_ioremap+0xef/0x220\n ...\n Call Trace:\n <TASK>\n ? __early_ioremap+0xef/0x220\n ? __warn.cold+0x93/0xfa\n ? __early_ioremap+0xef/0x220\n ? report_bug+0xff/0x140\n ? early_fixup_exception+0x5d/0xb0\n ? early_idt_handler_common+0x2f/0x3a\n ? __early_ioremap+0xef/0x220\n ? efi_mokvar_table_init+0xce/0x1d0\n ? setup_arch+0x864/0xc10\n ? start_kernel+0x6b/0xa10\n ? x86_64_start_reservations+0x24/0x30\n ? x86_64_start_kernel+0xed/0xf0\n ? common_startup_64+0x13e/0x141\n </TASK>\n ---[ end trace 0000000000000000 ]---\n mokvar: Failed to map EFI MOKvar config table pa=0x7c4c3000, size=265187.\n\nMapping the entire structure isn't actually necessary, as we don't ever\nneed more than one entry header mapped at once.\n\nChanges efi_mokvar_table_init() to only map each entry header, not the\nentire table, when determining the table size. Since we're not mapping\nany data past the variable name, it also changes the code to enforce\nthat each variable name is NUL terminated, rather than attempting to\nverify it in place.

In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: SOF: ipc4-topology: Harden loops for looking up ALH copiers\n\nOther, non DAI copier widgets could have the same stream name (sname) as\nthe ALH copier and in that case the copier->data is NULL, no alh_data is\nattached, which could lead to NULL pointer dereference.\nWe could check for this NULL pointer in sof_ipc4_prepare_copier_module()\nand avoid the crash, but a similar loop in sof_ipc4_widget_setup_comp_dai()\nwill miscalculate the ALH device count, causing broken audio.\n\nThe correct fix is to harden the matching logic by making sure that the\n1. widget is a DAI widget - so dai = w->private is valid\n2. the dai (and thus the copier) is ALH copier

In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/code-patching: Disable KASAN report during patching via temporary mm\n\nErhard reports the following KASAN hit on Talos II (power9) with kernel 6.13:\n\n[ 12.028126] ==================================================================\n[ 12.028198] BUG: KASAN: user-memory-access in copy_to_kernel_nofault+0x8c/0x1a0\n[ 12.028260] Write of size 8 at addr 0000187e458f2000 by task systemd/1\n\n[ 12.028346] CPU: 87 UID: 0 PID: 1 Comm: systemd Tainted: G T 6.13.0-P9-dirty #3\n[ 12.028408] Tainted: [T]=RANDSTRUCT\n[ 12.028446] Hardware name: T2P9D01 REV 1.01 POWER9 0x4e1202 opal:skiboot-bc106a0 PowerNV\n[ 12.028500] Call Trace:\n[ 12.028536] [c000000008dbf3b0] [c000000001656a48] dump_stack_lvl+0xbc/0x110 (unreliable)\n[ 12.028609] [c000000008dbf3f0] [c0000000006e2fc8] print_report+0x6b0/0x708\n[ 12.028666] [c000000008dbf4e0] [c0000000006e2454] kasan_report+0x164/0x300\n[ 12.028725] [c000000008dbf600] [c0000000006e54d4] kasan_check_range+0x314/0x370\n[ 12.028784] [c000000008dbf640] [c0000000006e6310] __kasan_check_write+0x20/0x40\n[ 12.028842] [c000000008dbf660] [c000000000578e8c] copy_to_kernel_nofault+0x8c/0x1a0\n[ 12.028902] [c000000008dbf6a0] [c0000000000acfe4] __patch_instructions+0x194/0x210\n[ 12.028965] [c000000008dbf6e0] [c0000000000ade80] patch_instructions+0x150/0x590\n[ 12.029026] [c000000008dbf7c0] [c0000000001159bc] bpf_arch_text_copy+0x6c/0xe0\n[ 12.029085] [c000000008dbf800] [c000000000424250] bpf_jit_binary_pack_finalize+0x40/0xc0\n[ 12.029147] [c000000008dbf830] [c000000000115dec] bpf_int_jit_compile+0x3bc/0x930\n[ 12.029206] [c000000008dbf990] [c000000000423720] bpf_prog_select_runtime+0x1f0/0x280\n[ 12.029266] [c000000008dbfa00] [c000000000434b18] bpf_prog_load+0xbb8/0x1370\n[ 12.029324] [c000000008dbfb70] [c000000000436ebc] __sys_bpf+0x5ac/0x2e00\n[ 12.029379] [c000000008dbfd00] [c00000000043a228] sys_bpf+0x28/0x40\n[ 12.029435] [c000000008dbfd20] [c000000000038eb4] system_call_exception+0x334/0x610\n[ 12.029497] [c000000008dbfe50] [c00000000000c270] system_call_vectored_common+0xf0/0x280\n[ 12.029561] --- interrupt: 3000 at 0x3fff82f5cfa8\n[ 12.029608] NIP: 00003fff82f5cfa8 LR: 00003fff82f5cfa8 CTR: 0000000000000000\n[ 12.029660] REGS: c000000008dbfe80 TRAP: 3000 Tainted: G T (6.13.0-P9-dirty)\n[ 12.029735] MSR: 900000000280f032 <SF,HV,VEC,VSX,EE,PR,FP,ME,IR,DR,RI> CR: 42004848 XER: 00000000\n[ 12.029855] IRQMASK: 0\n GPR00: 0000000000000169 00003fffdcf789a0 00003fff83067100 0000000000000005\n GPR04: 00003fffdcf78a98 0000000000000090 0000000000000000 0000000000000008\n GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000\n GPR12: 0000000000000000 00003fff836ff7e0 c000000000010678 0000000000000000\n GPR16: 0000000000000000 0000000000000000 00003fffdcf78f28 00003fffdcf78f90\n GPR20: 0000000000000000 0000000000000000 0000000000000000 00003fffdcf78f80\n GPR24: 00003fffdcf78f70 00003fffdcf78d10 00003fff835c7239 00003fffdcf78bd8\n GPR28: 00003fffdcf78a98 0000000000000000 0000000000000000 000000011f547580\n[ 12.030316] NIP [00003fff82f5cfa8] 0x3fff82f5cfa8\n[ 12.030361] LR [00003fff82f5cfa8] 0x3fff82f5cfa8\n[ 12.030405] --- interrupt: 3000\n[ 12.030444] ==================================================================\n\nCommit c28c15b6d28a ("powerpc/code-patching: Use temporary mm for\nRadix MMU") is inspired from x86 but unlike x86 is doesn't disable\nKASAN reports during patching. This wasn't a problem at the begining\nbecause __patch_mem() is not instrumented.\n\nCommit 465cabc97b42 ("powerpc/code-patching: introduce\npatch_instructions()") use copy_to_kernel_nofault() to copy several\ninstructions at once. But when using temporary mm the destination is\nnot regular kernel memory but a kind of kernel-like memory located\nin user address space. Because it is not in kernel address space it is\nnot covered by KASAN shadow memory. Since commit e4137f08816b ("mm,\nkasan, kmsan: instrument copy_from/to_kernel_nofault") KASAN reports\nbad accesses from copy_to_kernel_nofault(). Here a bad access to user\nmemory is reported because KASAN detects the lack of shadow memory and\nthe address is below TASK_SIZE.\n\nDo like x86 in commit b3fd8e83ada0 ("x86/alternatives: Use temporary\nmm for text poking") and disable KASAN reports during patching when\nusing temporary mm.\n\nClose: https://lore.kernel.org/all/20250201151435.48400261@yea/

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: allow small head cache usage with large MAX_SKB_FRAGS values\n\nSabrina reported the following splat:\n\n WARNING: CPU: 0 PID: 1 at net/core/dev.c:6935 netif_napi_add_weight_locked+0x8f2/0xba0\n Modules linked in:\n CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.14.0-rc1-net-00092-g011b03359038 #996\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014\n RIP: 0010:netif_napi_add_weight_locked+0x8f2/0xba0\n Code: e8 c3 e6 6a fe 48 83 c4 28 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc c7 44 24 10 ff ff ff ff e9 8f fb ff ff e8 9e e6 6a fe <0f> 0b e9 d3 fe ff ff e8 92 e6 6a fe 48 8b 04 24 be ff ff ff ff 48\n RSP: 0000:ffffc9000001fc60 EFLAGS: 00010293\n RAX: 0000000000000000 RBX: ffff88806ce48128 RCX: 1ffff11001664b9e\n RDX: ffff888008f00040 RSI: ffffffff8317ca42 RDI: ffff88800b325cb6\n RBP: ffff88800b325c40 R08: 0000000000000001 R09: ffffed100167502c\n R10: ffff88800b3a8163 R11: 0000000000000000 R12: ffff88800ac1c168\n R13: ffff88800ac1c168 R14: ffff88800ac1c168 R15: 0000000000000007\n FS: 0000000000000000(0000) GS:ffff88806ce00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: ffff888008201000 CR3: 0000000004c94001 CR4: 0000000000370ef0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n <TASK>\n gro_cells_init+0x1ba/0x270\n xfrm_input_init+0x4b/0x2a0\n xfrm_init+0x38/0x50\n ip_rt_init+0x2d7/0x350\n ip_init+0xf/0x20\n inet_init+0x406/0x590\n do_one_initcall+0x9d/0x2e0\n do_initcalls+0x23b/0x280\n kernel_init_freeable+0x445/0x490\n kernel_init+0x20/0x1d0\n ret_from_fork+0x46/0x80\n ret_from_fork_asm+0x1a/0x30\n </TASK>\n irq event stamp: 584330\n hardirqs last enabled at (584338): [<ffffffff8168bf87>] __up_console_sem+0x77/0xb0\n hardirqs last disabled at (584345): [<ffffffff8168bf6c>] __up_console_sem+0x5c/0xb0\n softirqs last enabled at (583242): [<ffffffff833ee96d>] netlink_insert+0x14d/0x470\n softirqs last disabled at (583754): [<ffffffff8317c8cd>] netif_napi_add_weight_locked+0x77d/0xba0\n\non kernel built with MAX_SKB_FRAGS=45, where SKB_WITH_OVERHEAD(1024)\nis smaller than GRO_MAX_HEAD.\n\nSuch built additionally contains the revert of the single page frag cache\nso that napi_get_frags() ends up using the page frag allocator, triggering\nthe splat.\n\nNote that the underlying issue is independent from the mentioned\nrevert; address it ensuring that the small head cache will fit either TCP\nand GRO allocation and updating napi_alloc_skb() and __netdev_alloc_skb()\nto select kmalloc() usage for any allocation fitting such cache.

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, test_run: Fix use-after-free issue in eth_skb_pkt_type()\n\nKMSAN reported a use-after-free issue in eth_skb_pkt_type()[1]. The\ncause of the issue was that eth_skb_pkt_type() accessed skb's data\nthat didn't contain an Ethernet header. This occurs when\nbpf_prog_test_run_xdp() passes an invalid value as the user_data\nargument to bpf_test_init().\n\nFix this by returning an error when user_data is less than ETH_HLEN in\nbpf_test_init(). Additionally, remove the check for "if (user_size >\nsize)" as it is unnecessary.\n\n[1]\nBUG: KMSAN: use-after-free in eth_skb_pkt_type include/linux/etherdevice.h:627 [inline]\nBUG: KMSAN: use-after-free in eth_type_trans+0x4ee/0x980 net/ethernet/eth.c:165\n eth_skb_pkt_type include/linux/etherdevice.h:627 [inline]\n eth_type_trans+0x4ee/0x980 net/ethernet/eth.c:165\n __xdp_build_skb_from_frame+0x5a8/0xa50 net/core/xdp.c:635\n xdp_recv_frames net/bpf/test_run.c:272 [inline]\n xdp_test_run_batch net/bpf/test_run.c:361 [inline]\n bpf_test_run_xdp_live+0x2954/0x3330 net/bpf/test_run.c:390\n bpf_prog_test_run_xdp+0x148e/0x1b10 net/bpf/test_run.c:1318\n bpf_prog_test_run+0x5b7/0xa30 kernel/bpf/syscall.c:4371\n __sys_bpf+0x6a6/0xe20 kernel/bpf/syscall.c:5777\n __do_sys_bpf kernel/bpf/syscall.c:5866 [inline]\n __se_sys_bpf kernel/bpf/syscall.c:5864 [inline]\n __x64_sys_bpf+0xa4/0xf0 kernel/bpf/syscall.c:5864\n x64_sys_call+0x2ea0/0x3d90 arch/x86/include/generated/asm/syscalls_64.h:322\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xd9/0x1d0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nUninit was created at:\n free_pages_prepare mm/page_alloc.c:1056 [inline]\n free_unref_page+0x156/0x1320 mm/page_alloc.c:2657\n __free_pages+0xa3/0x1b0 mm/page_alloc.c:4838\n bpf_ringbuf_free kernel/bpf/ringbuf.c:226 [inline]\n ringbuf_map_free+0xff/0x1e0 kernel/bpf/ringbuf.c:235\n bpf_map_free kernel/bpf/syscall.c:838 [inline]\n bpf_map_free_deferred+0x17c/0x310 kernel/bpf/syscall.c:862\n process_one_work kernel/workqueue.c:3229 [inline]\n process_scheduled_works+0xa2b/0x1b60 kernel/workqueue.c:3310\n worker_thread+0xedf/0x1550 kernel/workqueue.c:3391\n kthread+0x535/0x6b0 kernel/kthread.c:389\n ret_from_fork+0x6e/0x90 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n\nCPU: 1 UID: 0 PID: 17276 Comm: syz.1.16450 Not tainted 6.12.0-05490-g9bb88c659673 #8\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/fbdev-dma: Add shadow buffering for deferred I/O\n\nDMA areas are not necessarily backed by struct page, so we cannot\nrely on it for deferred I/O. Allocate a shadow buffer for drivers\nthat require deferred I/O and use it as framebuffer memory.\n\nFixes driver errors about being "Unable to handle kernel NULL pointer\ndereference at virtual address" or "Unable to handle kernel paging\nrequest at virtual address".\n\nThe patch splits drm_fbdev_dma_driver_fbdev_probe() in an initial\nallocation, which creates the DMA-backed buffer object, and a tail\nthat sets up the fbdev data structures. There is a tail function for\ndirect memory mappings and a tail function for deferred I/O with\nthe shadow buffer.\n\nIt is no longer possible to use deferred I/O without shadow buffer.\nIt can be re-added if there exists a reliably test for usable struct\npage in the allocated DMA-backed buffer object.

In the Linux kernel, the following vulnerability has been resolved:\n\nsched/core: Prevent rescheduling when interrupts are disabled\n\nDavid reported a warning observed while loop testing kexec jump:\n\n Interrupts enabled after irqrouter_resume+0x0/0x50\n WARNING: CPU: 0 PID: 560 at drivers/base/syscore.c:103 syscore_resume+0x18a/0x220\n kernel_kexec+0xf6/0x180\n __do_sys_reboot+0x206/0x250\n do_syscall_64+0x95/0x180\n\nThe corresponding interrupt flag trace:\n\n hardirqs last enabled at (15573): [<ffffffffa8281b8e>] __up_console_sem+0x7e/0x90\n hardirqs last disabled at (15580): [<ffffffffa8281b73>] __up_console_sem+0x63/0x90\n\nThat means __up_console_sem() was invoked with interrupts enabled. Further\ninstrumentation revealed that in the interrupt disabled section of kexec\njump one of the syscore_suspend() callbacks woke up a task, which set the\nNEED_RESCHED flag. A later callback in the resume path invoked\ncond_resched() which in turn led to the invocation of the scheduler:\n\n __cond_resched+0x21/0x60\n down_timeout+0x18/0x60\n acpi_os_wait_semaphore+0x4c/0x80\n acpi_ut_acquire_mutex+0x3d/0x100\n acpi_ns_get_node+0x27/0x60\n acpi_ns_evaluate+0x1cb/0x2d0\n acpi_rs_set_srs_method_data+0x156/0x190\n acpi_pci_link_set+0x11c/0x290\n irqrouter_resume+0x54/0x60\n syscore_resume+0x6a/0x200\n kernel_kexec+0x145/0x1c0\n __do_sys_reboot+0xeb/0x240\n do_syscall_64+0x95/0x180\n\nThis is a long standing problem, which probably got more visible with\nthe recent printk changes. Something does a task wakeup and the\nscheduler sets the NEED_RESCHED flag. cond_resched() sees it set and\ninvokes schedule() from a completely bogus context. The scheduler\nenables interrupts after context switching, which causes the above\nwarning at the end.\n\nQuite some of the code paths in syscore_suspend()/resume() can result in\ntriggering a wakeup with the exactly same consequences. They might not\nhave done so yet, but as they share a lot of code with normal operations\nit's just a question of time.\n\nThe problem only affects the PREEMPT_NONE and PREEMPT_VOLUNTARY scheduling\nmodels. Full preemption is not affected as cond_resched() is disabled and\nthe preemption check preemptible() takes the interrupt disabled flag into\naccount.\n\nCure the problem by adding a corresponding check into cond_resched().

In the Linux kernel, the following vulnerability has been resolved:\n\nRevert "wifi: mac80211: fix memory leak in ieee80211_if_add()"\n\nThis reverts commit 13e5afd3d773c6fc6ca2b89027befaaaa1ea7293.\n\nieee80211_if_free() is already called from free_netdev(ndev)\nbecause ndev->priv_destructor == ieee80211_if_free\n\nsyzbot reported:\n\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000004: 0000 [#1] PREEMPT SMP KASAN\nKASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]\nCPU: 0 PID: 10041 Comm: syz-executor.0 Not tainted 6.2.0-rc2-syzkaller-00388-g55b98837e37d #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022\nRIP: 0010:pcpu_get_page_chunk mm/percpu.c:262 [inline]\nRIP: 0010:pcpu_chunk_addr_search mm/percpu.c:1619 [inline]\nRIP: 0010:free_percpu mm/percpu.c:2271 [inline]\nRIP: 0010:free_percpu+0x186/0x10f0 mm/percpu.c:2254\nCode: 80 3c 02 00 0f 85 f5 0e 00 00 48 8b 3b 48 01 ef e8 cf b3 0b 00 48 ba 00 00 00 00 00 fc ff df 48 8d 78 20 48 89 f9 48 c1 e9 03 <80> 3c 11 00 0f 85 3b 0e 00 00 48 8b 58 20 48 b8 00 00 00 00 00 fc\nRSP: 0018:ffffc90004ba7068 EFLAGS: 00010002\nRAX: 0000000000000000 RBX: ffff88823ffe2b80 RCX: 0000000000000004\nRDX: dffffc0000000000 RSI: ffffffff81c1f4e7 RDI: 0000000000000020\nRBP: ffffe8fffe8fc220 R08: 0000000000000005 R09: 0000000000000000\nR10: 0000000000000000 R11: 1ffffffff2179ab2 R12: ffff8880b983d000\nR13: 0000000000000003 R14: 0000607f450fc220 R15: ffff88823ffe2988\nFS: 00007fcb349de700(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000001b32220000 CR3: 000000004914f000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n<TASK>\nnetdev_run_todo+0x6bf/0x1100 net/core/dev.c:10352\nieee80211_register_hw+0x2663/0x4040 net/mac80211/main.c:1411\nmac80211_hwsim_new_radio+0x2537/0x4d80 drivers/net/wireless/mac80211_hwsim.c:4583\nhwsim_new_radio_nl+0xa09/0x10f0 drivers/net/wireless/mac80211_hwsim.c:5176\ngenl_family_rcv_msg_doit.isra.0+0x1e6/0x2d0 net/netlink/genetlink.c:968\ngenl_family_rcv_msg net/netlink/genetlink.c:1048 [inline]\ngenl_rcv_msg+0x4ff/0x7e0 net/netlink/genetlink.c:1065\nnetlink_rcv_skb+0x165/0x440 net/netlink/af_netlink.c:2564\ngenl_rcv+0x28/0x40 net/netlink/genetlink.c:1076\nnetlink_unicast_kernel net/netlink/af_netlink.c:1330 [inline]\nnetlink_unicast+0x547/0x7f0 net/netlink/af_netlink.c:1356\nnetlink_sendmsg+0x91b/0xe10 net/netlink/af_netlink.c:1932\nsock_sendmsg_nosec net/socket.c:714 [inline]\nsock_sendmsg+0xd3/0x120 net/socket.c:734\n____sys_sendmsg+0x712/0x8c0 net/socket.c:2476\n___sys_sendmsg+0x110/0x1b0 net/socket.c:2530\n__sys_sendmsg+0xf7/0x1c0 net/socket.c:2559\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix pointer-leak due to insufficient speculative store bypass mitigation\n\nTo mitigate Spectre v4, 2039f26f3aca ("bpf: Fix leakage due to\ninsufficient speculative store bypass mitigation") inserts lfence\ninstructions after 1) initializing a stack slot and 2) spilling a\npointer to the stack.\n\nHowever, this does not cover cases where a stack slot is first\ninitialized with a pointer (subject to sanitization) but then\noverwritten with a scalar (not subject to sanitization because\nthe slot was already initialized). In this case, the second write\nmay be subject to speculative store bypass (SSB) creating a\nspeculative pointer-as-scalar type confusion. This allows the\nprogram to subsequently leak the numerical pointer value using,\nfor example, a branch-based cache side channel.\n\nTo fix this, also sanitize scalars if they write a stack slot\nthat previously contained a pointer. Assuming that pointer-spills\nare only generated by LLVM on register-pressure, the performance\nimpact on most real-world BPF programs should be small.\n\nThe following unprivileged BPF bytecode drafts a minimal exploit\nand the mitigation:\n\n [...]\n // r6 = 0 or 1 (skalar, unknown user input)\n // r7 = accessible ptr for side channel\n // r10 = frame pointer (fp), to be leaked\n //\n r9 = r10 # fp alias to encourage ssb\n *(u64 *)(r9 - 8) = r10 // fp[-8] = ptr, to be leaked\n // lfence added here because of pointer spill to stack.\n //\n // Ommitted: Dummy bpf_ringbuf_output() here to train alias predictor\n // for no r9-r10 dependency.\n //\n *(u64 *)(r10 - 8) = r6 // fp[-8] = scalar, overwrites ptr\n // 2039f26f3aca: no lfence added because stack slot was not STACK_INVALID,\n // store may be subject to SSB\n //\n // fix: also add an lfence when the slot contained a ptr\n //\n r8 = *(u64 *)(r9 - 8)\n // r8 = architecturally a scalar, speculatively a ptr\n //\n // leak ptr using branch-based cache side channel:\n r8 &= 1 // choose bit to leak\n if r8 == 0 goto SLOW // no mispredict\n // architecturally dead code if input r6 is 0,\n // only executes speculatively iff ptr bit is 1\n r8 = *(u64 *)(r7 + 0) # encode bit in cache (0: slow, 1: fast)\nSLOW:\n [...]\n\nAfter running this, the program can time the access to *(r7 + 0) to\ndetermine whether the chosen pointer bit was 0 or 1. Repeat this 64\ntimes to recover the whole address on amd64.\n\nIn summary, sanitization can only be skipped if one scalar is\noverwritten with another scalar. Scalar-confusion due to speculative\nstore bypass can not lead to invalid accesses because the pointer\nbounds deducted during verification are enforced using branchless\nlogic. See 979d63d50c0c ("bpf: prevent out of bounds speculation on\npointer arithmetic") for details.\n\nDo not make the mitigation depend on !env->allow_{uninit_stack,ptr_leaks}\nbecause speculative leaks are likely unexpected if these were enabled.\nFor example, leaking the address to a protected log file may be acceptable\nwhile disabling the mitigation might unintentionally leak the address\ninto the cached-state of a map that is accessible to unprivileged\nprocesses.

In the Linux kernel, the following vulnerability has been resolved:\n\nHID: betop: check shape of output reports\n\nbetopff_init() only checks the total sum of the report counts for each\nreport field to be at least 4, but hid_betopff_play() expects 4 report\nfields.\nA device advertising an output report with one field and 4 report counts\nwould pass the check but crash the kernel with a NULL pointer dereference\nin hid_betopff_play().

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: Add sync after creating vram bo\n\nThere will be data corruption on vram allocated by svm\nif the initialization is not complete and application is\nwritting on the memory. Adding sync to wait for the\ninitialization completion is to resolve this issue.

In the Linux kernel, the following vulnerability has been resolved:\n\novl: fix tmpfile leak\n\nMissed an error cleanup.

In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: SOF: ipc4-mtrace: prevent underflow in sof_ipc4_priority_mask_dfs_write()\n\nThe "id" comes from the user. Change the type to unsigned to prevent\nan array underflow.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915: Fix request ref counting during error capture & debugfs dump\n\nWhen GuC support was added to error capture, the reference counting\naround the request object was broken. Fix it up.\n\nThe context based search manages the spinlocking around the search\ninternally. So it needs to grab the reference count internally as\nwell. The execlist only request based search relies on external\nlocking, so it needs an external reference count but within the\nspinlock not outside it.\n\nThe only other caller of the context based search is the code for\ndumping engine state to debugfs. That code wasn't previously getting\nan explicit reference at all as it does everything while holding the\nexeclist specific spinlock. So, that needs updaing as well as that\nspinlock doesn't help when using GuC submission. Rather than trying to\nconditionally get/put depending on submission model, just change it to\nalways do the get/put.\n\nv2: Explicitly document adding an extra blank line in some dense code\n(Andy Shevchenko). Fix multiple potential null pointer derefs in case\nof no request found (some spotted by Tvrtko, but there was more!).\nAlso fix a leaked request in case of !started and another in\n__guc_reset_context now that intel_context_find_active_request is\nactually reference counting the returned request.\nv3: Add a _get suffix to intel_context_find_active_request now that it\ngrabs a reference (Daniele).\nv4: Split the intel_guc_find_hung_context change to a separate patch\nand rename intel_context_find_active_request_get to\nintel_context_get_active_request (Tvrtko).\nv5: s/locking/reference counting/ in commit message (Tvrtko)\n\n(cherry picked from commit 3700e353781e27f1bc7222f51f2cc36cbeb9b4ec)

In the Linux kernel, the following vulnerability has been resolved:\n\nmm: memcg: fix NULL pointer in mem_cgroup_track_foreign_dirty_slowpath()\n\nAs commit 18365225f044 ("hwpoison, memcg: forcibly uncharge LRU pages"),\nhwpoison will forcibly uncharg a LRU hwpoisoned page, the folio_memcg\ncould be NULl, then, mem_cgroup_track_foreign_dirty_slowpath() could\noccurs a NULL pointer dereference, let's do not record the foreign\nwritebacks for folio memcg is null in mem_cgroup_track_foreign_dirty() to\nfix it.

In the Linux kernel, the following vulnerability has been resolved:\n\nSquashfs: fix handling and sanity checking of xattr_ids count\n\nA Sysbot [1] corrupted filesystem exposes two flaws in the handling and\nsanity checking of the xattr_ids count in the filesystem. Both of these\nflaws cause computation overflow due to incorrect typing.\n\nIn the corrupted filesystem the xattr_ids value is 4294967071, which\nstored in a signed variable becomes the negative number -225.\n\nFlaw 1 (64-bit systems only):\n\nThe signed integer xattr_ids variable causes sign extension.\n\nThis causes variable overflow in the SQUASHFS_XATTR_*(A) macros. The\nvariable is first multiplied by sizeof(struct squashfs_xattr_id) where the\ntype of the sizeof operator is "unsigned long".\n\nOn a 64-bit system this is 64-bits in size, and causes the negative number\nto be sign extended and widened to 64-bits and then become unsigned. This\nproduces the very large number 18446744073709548016 or 2^64 - 3600. This\nnumber when rounded up by SQUASHFS_METADATA_SIZE - 1 (8191 bytes) and\ndivided by SQUASHFS_METADATA_SIZE overflows and produces a length of 0\n(stored in len).\n\nFlaw 2 (32-bit systems only):\n\nOn a 32-bit system the integer variable is not widened by the unsigned\nlong type of the sizeof operator (32-bits), and the signedness of the\nvariable has no effect due it always being treated as unsigned.\n\nThe above corrupted xattr_ids value of 4294967071, when multiplied\noverflows and produces the number 4294963696 or 2^32 - 3400. This number\nwhen rounded up by SQUASHFS_METADATA_SIZE - 1 (8191 bytes) and divided by\nSQUASHFS_METADATA_SIZE overflows again and produces a length of 0.\n\nThe effect of the 0 length computation:\n\nIn conjunction with the corrupted xattr_ids field, the filesystem also has\na corrupted xattr_table_start value, where it matches the end of\nfilesystem value of 850.\n\nThis causes the following sanity check code to fail because the\nincorrectly computed len of 0 matches the incorrect size of the table\nreported by the superblock (0 bytes).\n\n len = SQUASHFS_XATTR_BLOCK_BYTES(*xattr_ids);\n indexes = SQUASHFS_XATTR_BLOCKS(*xattr_ids);\n\n /*\n * The computed size of the index table (len bytes) should exactly\n * match the table start and end points\n */\n start = table_start + sizeof(*id_table);\n end = msblk->bytes_used;\n\n if (len != (end - start))\n return ERR_PTR(-EINVAL);\n\nChanging the xattr_ids variable to be "usigned int" fixes the flaw on a\n64-bit system. This relies on the fact the computation is widened by the\nunsigned long type of the sizeof operator.\n\nCasting the variable to u64 in the above macro fixes this flaw on a 32-bit\nsystem.\n\nIt also means 64-bit systems do not implicitly rely on the type of the\nsizeof operator to widen the computation.\n\n[1] https://lore.kernel.org/lkml/000000000000cd44f005f1a0f17f@google.com/

In the Linux kernel, the following vulnerability has been resolved:\n\nnvmem: core: fix cleanup after dev_set_name()\n\nIf dev_set_name() fails, we leak nvmem->wp_gpio as the cleanup does not\nput this. While a minimal fix for this would be to add the gpiod_put()\ncall, we can do better if we split device_register(), and use the\ntested nvmem_release() cleanup code by initialising the device early,\nand putting the device.\n\nThis results in a slightly larger fix, but results in clear code.\n\nNote: this patch depends on "nvmem: core: initialise nvmem->id early"\nand "nvmem: core: remove nvmem_config wp_gpio".\n\n[Srini: Fixed subject line and error code handing with wp_gpio while applying.]

In the Linux kernel, the following vulnerability has been resolved:\n\nEDAC/highbank: Fix memory leak in highbank_mc_probe()\n\nWhen devres_open_group() fails, it returns -ENOMEM without freeing memory\nallocated by edac_mc_alloc().\n\nCall edac_mc_free() on the error handling path to avoid a memory leak.\n\n [ bp: Massage commit message. ]

In the Linux kernel, the following vulnerability has been resolved:\n\nw1: fix WARNING after calling w1_process()\n\nI got the following WARNING message while removing driver(ds2482):\n\n------------[ cut here ]------------\ndo not call blocking ops when !TASK_RUNNING; state=1 set at [<000000002d50bfb6>] w1_process+0x9e/0x1d0 [wire]\nWARNING: CPU: 0 PID: 262 at kernel/sched/core.c:9817 __might_sleep+0x98/0xa0\nCPU: 0 PID: 262 Comm: w1_bus_master1 Tainted: G N 6.1.0-rc3+ #307\nRIP: 0010:__might_sleep+0x98/0xa0\nCall Trace:\n exit_signals+0x6c/0x550\n do_exit+0x2b4/0x17e0\n kthread_exit+0x52/0x60\n kthread+0x16d/0x1e0\n ret_from_fork+0x1f/0x30\n\nThe state of task is set to TASK_INTERRUPTIBLE in loop in w1_process(),\nset it to TASK_RUNNING when it breaks out of the loop to avoid the\nwarning.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm/uffd: fix pte marker when fork() without fork event\n\nPatch series "mm: Fixes on pte markers".\n\nPatch 1 resolves the syzkiller report from Pengfei.\n\nPatch 2 further harden pte markers when used with the recent swapin error\nmarkers. The major case is we should persist a swapin error marker after\nfork(), so child shouldn't read a corrupted page.\n\n\nThis patch (of 2):\n\nWhen fork(), dst_vma is not guaranteed to have VM_UFFD_WP even if src may\nhave it and has pte marker installed. The warning is improper along with\nthe comment. The right thing is to inherit the pte marker when needed, or\nkeep the dst pte empty.\n\nA vague guess is this happened by an accident when there's the prior patch\nto introduce src/dst vma into this helper during the uffd-wp feature got\ndeveloped and I probably messed up in the rebase, since if we replace\ndst_vma with src_vma the warning & comment it all makes sense too.\n\nHugetlb did exactly the right here (copy_hugetlb_page_range()). Fix the\ngeneral path.\n\nReproducer:\n\nhttps://github.com/xupengfe/syzkaller_logs/blob/main/221208_115556_copy_page_range/repro.c\n\nBugzilla report: https://bugzilla.kernel.org/show_bug.cgi?id=216808

In the Linux kernel, the following vulnerability has been resolved:\n\ncan: j1939: fix errant WARN_ON_ONCE in j1939_session_deactivate\n\nThe conclusion "j1939_session_deactivate() should be called with a\nsession ref-count of at least 2" is incorrect. In some concurrent\nscenarios, j1939_session_deactivate can be called with the session\nref-count less than 2. But there is not any problem because it\nwill check the session active state before session putting in\nj1939_session_deactivate_locked().\n\nHere is the concurrent scenario of the problem reported by syzbot\nand my reproduction log.\n\n cpu0 cpu1\n j1939_xtp_rx_eoma\nj1939_xtp_rx_abort_one\n j1939_session_get_by_addr [kref == 2]\nj1939_session_get_by_addr [kref == 3]\nj1939_session_deactivate [kref == 2]\nj1939_session_put [kref == 1]\n j1939_session_completed\n j1939_session_deactivate\n WARN_ON_ONCE(kref < 2)\n\n=====================================================\nWARNING: CPU: 1 PID: 21 at net/can/j1939/transport.c:1088 j1939_session_deactivate+0x5f/0x70\nCPU: 1 PID: 21 Comm: ksoftirqd/1 Not tainted 5.14.0-rc7+ #32\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/01/2014\nRIP: 0010:j1939_session_deactivate+0x5f/0x70\nCall Trace:\n j1939_session_deactivate_activate_next+0x11/0x28\n j1939_xtp_rx_eoma+0x12a/0x180\n j1939_tp_recv+0x4a2/0x510\n j1939_can_recv+0x226/0x380\n can_rcv_filter+0xf8/0x220\n can_receive+0x102/0x220\n ? process_backlog+0xf0/0x2c0\n can_rcv+0x53/0xf0\n __netif_receive_skb_one_core+0x67/0x90\n ? process_backlog+0x97/0x2c0\n __netif_receive_skb+0x22/0x80

A flaw was found in grub2. During the network boot process, when trying to search for the configuration file, grub copies data from a user controlled environment variable into an internal buffer using the grub_strcpy() function. During this step, it fails to consider the environment variable length when allocating the internal buffer, resulting in an out-of-bounds write. If correctly exploited, this issue may result in remote code execution through the same network segment grub is searching for the boot information, which can be used to by-pass secure boot protections.

In the Linux kernel, the following vulnerability has been resolved:padata: use integer wrap around to prevent deadlock on seq_nr overflowWhen submitting more than 2^32 padata objects to padata_do_serial, thecurrent sorting implementation incorrectly sorts padata objects withoverflowed seq_nr, causing them to be placed before existing objects inthe reorder list. This leads to a deadlock in the serialization processas padata_find_next cannot match padata->seq_nr and pd->processedbecause the padata instance with overflowed seq_nr will be selectednext.To fix this, we use an unsigned integer wrap around to correctly sortpadata objects in scenarios with integer overflow.

An attacker could have executed unauthorized scripts on top origin sites using a JavaScript URI when opening an external URL with a custom Firefox scheme. This vulnerability affects Firefox for iOS < 123.

Upon scanning a JavaScript URI with the QR code scanner, an attacker could have executed unauthorized scripts on the current top origin sites in the URL bar. This vulnerability affects Firefox for iOS < 123.

The incorrect object was checked for NULL in the built-in profiler, potentially leading to invalid memory access and undefined behavior. *Note:* This issue only affects the application when the profiler is running. This vulnerability affects Firefox < 123.

When opening a website using the `firefox://` protocol handler, SameSite cookies were not properly respected. This vulnerability affects Firefox < 123.

Cross-Site Request Forgery (CSRF) vulnerability in mandegarweb Replace Default Words allows Stored XSS. This issue affects Replace Default Words: from n/a through 1.3.

An issue was discovered in Artifex Ghostscript before 10.05.0. Access to arbitrary files can occur through a truncated path with invalid UTF-8 characters, for base/gp_mswin.c and base/winrtsup.cpp.

An issue was discovered in Artifex Ghostscript before 10.05.0. A buffer overflow occurs for a long TTF font name to pdf/pdf_fmap.c.

An issue was discovered in Artifex Ghostscript before 10.05.0. The NPDL device has a Compression buffer overflow for contrib/japanese/gdevnpdl.c.

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Remove the direct link to net_device\n\nThe similar patch in siw is in the link:\nhttps://git.kernel.org/rdma/rdma/c/16b87037b48889\n\nThis problem also occurred in RXE. The following analyze this problem.\nIn the following Call Traces:\n"\nBUG: KASAN: slab-use-after-free in dev_get_flags+0x188/0x1d0 net/core/dev.c:8782\nRead of size 4 at addr ffff8880554640b0 by task kworker/1:4/5295\n\nCPU: 1 UID: 0 PID: 5295 Comm: kworker/1:4 Not tainted\n6.12.0-rc3-syzkaller-00399-g9197b73fd7bb #0\nHardware name: Google Compute Engine/Google Compute Engine,\nBIOS Google 09/13/2024\nWorkqueue: infiniband ib_cache_event_task\nCall Trace:\n \n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n dev_get_flags+0x188/0x1d0 net/core/dev.c:8782\n rxe_query_port+0x12d/0x260 drivers/infiniband/sw/rxe/rxe_verbs.c:60\n __ib_query_port drivers/infiniband/core/device.c:2111 [inline]\n ib_query_port+0x168/0x7d0 drivers/infiniband/core/device.c:2143\n ib_cache_update+0x1a9/0xb80 drivers/infiniband/core/cache.c:1494\n ib_cache_event_task+0xf3/0x1e0 drivers/infiniband/core/cache.c:1568\n process_one_work kernel/workqueue.c:3229 [inline]\n process_scheduled_works+0xa65/0x1850 kernel/workqueue.c:3310\n worker_thread+0x870/0xd30 kernel/workqueue.c:3391\n kthread+0x2f2/0x390 kernel/kthread.c:389\n ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n \n"\n\n1). In the link [1],\n\n"\n infiniband syz2: set down\n"\n\nThis means that on 839.350575, the event ib_cache_event_task was sent andi\nqueued in ib_wq.\n\n2). In the link [1],\n\n"\n team0 (unregistering): Port device team_slave_0 removed\n"\n\nIt indicates that before 843.251853, the net device should be freed.\n\n3). In the link [1],\n\n"\n BUG: KASAN: slab-use-after-free in dev_get_flags+0x188/0x1d0\n"\n\nThis means that on 850.559070, this slab-use-after-free problem occurred.\n\nIn all, on 839.350575, the event ib_cache_event_task was sent and queued\nin ib_wq,\n\nbefore 843.251853, the net device veth was freed.\n\non 850.559070, this event was executed, and the mentioned freed net device\nwas called. Thus, the above call trace occurred.\n\n[1] https://syzkaller.appspot.com/x/log.txt?x=12e7025f980000

Next.js is a React framework for building full-stack web applications. Prior to 14.2.25 and 15.2.3, it is possible to bypass authorization checks within a Next.js application, if the authorization check occurs in middleware. If patching to a safe version is infeasible, it is recommend that you prevent external user requests which contain the x-middleware-subrequest header from reaching your Next.js application. This vulnerability is fixed in 14.2.25 and 15.2.3.

A vulnerability was found in WebAssembly wabt 1.0.36. It has been declared as critical. This vulnerability affects the function BinaryReaderInterp::GetReturnCallDropKeepCount of the file wabt/src/interp/binary-reader-interp.cc. The manipulation leads to heap-based buffer overflow. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used.

GNU GRUB (aka GRUB2) through 2.12 has a heap-based buffer overflow in fs/hfs.c via crafted sblock data in an HFS filesystem.

UnRAR before 6.2.3 allows extraction of files outside of the destination folder via symlink chains.

p7zip 16.02 was discovered to contain a heap-buffer-overflow vulnerability via the function NArchive::NZip::CInArchive::FindCd(bool) at CPP/7zip/Archive/Zip/ZipIn.cpp.

A heap overflow vulnerability in FreeImage 1.18.0 via the ofLoad function in PluginTIFF.cpp.

A memory leak was found in Open vSwitch (OVS) during userspace IP fragmentation processing. An attacker could use this flaw to potentially exhaust available memory by keeping sending packet fragments.

sqlparse is a non-validating SQL parser module for Python. In sqlparse versions 0.4.0 and 0.4.1 there is a regular Expression Denial of Service in sqlparse vulnerability. The regular expression may cause exponential backtracking on strings containing many repetitions of '\\\n' in SQL comments. Only the formatting feature that removes comments from SQL statements is affected by this regular expression. As a workaround don't use the sqlformat.format function with keyword strip_comments=True or the --strip-comments command line flag when using the sqlformat command line tool. The issues has been fixed in sqlparse 0.4.2.

An issue found in SQLite SQLite3 v.3.35.4 that allows a remote attacker to cause a denial of service via the appendvfs.c function.

Artifex Ghostscript before 9.53.0 has an out-of-bounds write and use-after-free in devices/vector/gdevtxtw.c (for txtwrite) because a single character code in a PDF document can map to more than one Unicode code point (e.g., for a ligature).

An issue was discovered in decode_frame in libavcodec/tiff.c in FFmpeg version 4.3, allows remote attackers to cause a denial of service (DoS).

An issue was discovered in TCG Accelerator in QEMU 4.2.0, allows local attackers to execute arbitrary code, escalate privileges, and cause a denial of service (DoS). Note: This is disputed as a bug and not a valid security issue by multiple third parties.

Buffer Overflow vulnerability in function LoadPixelDataRLE8 in PluginBMP.cpp in FreeImage 3.18.0 allows remote attackers to run arbitrary code and cause other impacts via crafted image file.

Buffer Overflow vulnerability in function C_IStream::read in PluginEXR.cpp in FreeImage 3.18.0 allows remote attackers to run arbitrary code and cause other impacts via crafted image file.

Buffer Overflow vulnerability in function H5S_close in H5S.c in HDF5 1.10.4 allows remote attackers to run arbitrary code via creation of crafted file.

A vulnerability was found in WebAssembly wabt 1.0.36 and classified as critical. This issue affects the function wabt::interp::(anonymous namespace)::BinaryReaderInterp::OnExport of the file wabt/src/interp/binary-reader-interp.cc of the component Malformed File Handler. The manipulation leads to heap-based buffer overflow. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue.

GNU objdump 2.43 is vulnerable to Buffer Overflow in the BFD (Binary File Descriptor) library's handling of tekhex format files.

The issue was addressed with improved memory handling. This issue is fixed in macOS Sonoma 14.4, visionOS 1.1, iOS 17.4 and iPadOS 17.4, watchOS 10.4, tvOS 17.4. Processing web content may lead to arbitrary code execution.

An issue was discovered in Poppler 0.74.0. A recursive function call, in JBIG2Stream::readGenericBitmap() located in JBIG2Stream.cc, can be triggered by sending a crafted pdf file to (for example) the pdfseparate binary. It allows an attacker to cause Denial of Service (Segmentation fault) or possibly have unspecified other impact. This is related to JArithmeticDecoder::decodeBit.

An out-of-bounds read in the vrend_blit_need_swizzle function in vrend_renderer.c in virglrenderer through 0.8.0 allows guest OS users to cause a denial of service via VIRGL_CCMD_BLIT commands.

qemu-bridge-helper.c in QEMU 3.1 and 4.0.0 does not ensure that a network interface name (obtained from bridge.conf or a --br=bridge option) is limited to the IFNAMSIZ size, which can lead to an ACL bypass.

The agroot() function in cgraph\\obj.c in libcgraph.a in Graphviz 2.39.20160612.1140 has a NULL pointer dereference, as demonstrated by graphml2gv.

An error when processing the EXIF_IFD_INTEROPERABILITY and EXIF_IFD_EXIF tags within libexif version 0.6.21 can be exploited to exhaust available CPU resources.

numbers.c in libxslt before 1.1.43 has a use-after-free because, in nested XPath evaluations, an XPath context node can be modified but never restored. This is related to xsltNumberFormatGetValue, xsltEvalXPathPredicate, xsltEvalXPathStringNs, and xsltComputeSortResultInternal.

An out-of-bounds write issue was addressed with improved checks to prevent unauthorized actions. This issue is fixed in visionOS 2.3.2, iOS 18.3.2 and iPadOS 18.3.2, macOS Sequoia 15.3.2, Safari 18.3.1. Maliciously crafted web content may be able to break out of Web Content sandbox. This is a supplementary fix for an attack that was blocked in iOS 17.2. (Apple is aware of a report that this issue may have been exploited in an extremely sophisticated attack against specific targeted individuals on versions of iOS before iOS 17.2.).

A stack overflow vulnerability exists in the libexpat library due to the way it handles recursive entity expansion in XML documents. When parsing an XML document with deeply nested entity references, libexpat can be forced to recurse indefinitely, exhausting the stack space and causing a crash. This issue could lead to denial of service (DoS) or, in some cases, exploitable memory corruption, depending on the environment and library usage.

xsltGetInheritedNsList in libxslt before 1.1.43 has a use-after-free issue related to exclusion of result prefixes.

The issue was addressed with improved checks. This issue is fixed in macOS Sonoma 14.5, iOS 16.7.8 and iPadOS 16.7.8, Safari 17.5, iOS 17.5 and iPadOS 17.5, watchOS 10.5, tvOS 17.5, visionOS 1.2. Processing a file may lead to unexpected app termination or arbitrary code execution.

Using an AMP url with a canonical element, an attacker could have executed JavaScript from an opened bookmarked page. This vulnerability affects Firefox for iOS < 123.

Focus was incorrectly allowing internal links to utilize the app scheme used for deeplinking, which could result in links potentially circumventing some URL safety checks This vulnerability affects Focus for iOS < 132.

A buffer overflow was found in perl-DBI < 1.643 in DBI.xs. A local attacker who is able to supply a string longer than 300 characters could cause an out-of-bounds write, affecting the availability of the service or integrity of data.

An issue was discovered in Contiki through 3.0. An Out-of-Bounds Read vulnerability exists in the uIP TCP/IP Stack component when calculating the checksums for IP packets in upper_layer_chksum in net/ipv4/uip.c.

An issue was discovered in libgit2 before 0.28.4 and 0.9x before 0.99.0. path.c mishandles equivalent filenames that exist because of NTFS Alternate Data Streams. This may allow remote code execution when cloning a repository. This issue is similar to CVE-2019-1352.

sqlite3Select in select.c in SQLite 3.30.1 allows a crash if a sub-select uses both DISTINCT and window functions, and also has certain ORDER BY usage.