In the Linux kernel, the following vulnerability has been resolved:\n\nnet: decrease cached dst counters in dst_release\n\nUpstream fix ac888d58869b ("net: do not delay dst_entries_add() in\ndst_release()") moved decrementing the dst count from dst_destroy to\ndst_release to avoid accessing already freed data in case of netns\ndismantle. However in case CONFIG_DST_CACHE is enabled and OvS+tunnels\nare used, this fix is incomplete as the same issue will be seen for\ncached dsts:\n\n Unable to handle kernel paging request at virtual address ffff5aabf6b5c000\n Call trace:\n percpu_counter_add_batch+0x3c/0x160 (P)\n dst_release+0xec/0x108\n dst_cache_destroy+0x68/0xd8\n dst_destroy+0x13c/0x168\n dst_destroy_rcu+0x1c/0xb0\n rcu_do_batch+0x18c/0x7d0\n rcu_core+0x174/0x378\n rcu_core_si+0x18/0x30\n\nFix this by invalidating the cache, and thus decrementing cached dst\ncounters, in dst_release too.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_tunnel: fix geneve_opt type confusion addition\n\nWhen handling multiple NFTA_TUNNEL_KEY_OPTS_GENEVE attributes, the\nparsing logic should place every geneve_opt structure one by one\ncompactly. Hence, when deciding the next geneve_opt position, the\npointer addition should be in units of char *.\n\nHowever, the current implementation erroneously does type conversion\nbefore the addition, which will lead to heap out-of-bounds write.\n\n[ 6.989857] ==================================================================\n[ 6.990293] BUG: KASAN: slab-out-of-bounds in nft_tunnel_obj_init+0x977/0xa70\n[ 6.990725] Write of size 124 at addr ffff888005f18974 by task poc/178\n[ 6.991162]\n[ 6.991259] CPU: 0 PID: 178 Comm: poc-oob-write Not tainted 6.1.132 #1\n[ 6.991655] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\n[ 6.992281] Call Trace:\n[ 6.992423] \n[ 6.992586] dump_stack_lvl+0x44/0x5c\n[ 6.992801] print_report+0x184/0x4be\n[ 6.993790] kasan_report+0xc5/0x100\n[ 6.994252] kasan_check_range+0xf3/0x1a0\n[ 6.994486] memcpy+0x38/0x60\n[ 6.994692] nft_tunnel_obj_init+0x977/0xa70\n[ 6.995677] nft_obj_init+0x10c/0x1b0\n[ 6.995891] nf_tables_newobj+0x585/0x950\n[ 6.996922] nfnetlink_rcv_batch+0xdf9/0x1020\n[ 6.998997] nfnetlink_rcv+0x1df/0x220\n[ 6.999537] netlink_unicast+0x395/0x530\n[ 7.000771] netlink_sendmsg+0x3d0/0x6d0\n[ 7.001462] __sock_sendmsg+0x99/0xa0\n[ 7.001707] ____sys_sendmsg+0x409/0x450\n[ 7.002391] ___sys_sendmsg+0xfd/0x170\n[ 7.003145] __sys_sendmsg+0xea/0x170\n[ 7.004359] do_syscall_64+0x5e/0x90\n[ 7.005817] entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n[ 7.006127] RIP: 0033:0x7ec756d4e407\n[ 7.006339] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf\n[ 7.007364] RSP: 002b:00007ffed5d46760 EFLAGS: 00000202 ORIG_RAX: 000000000000002e\n[ 7.007827] RAX: ffffffffffffffda RBX: 00007ec756cc4740 RCX: 00007ec756d4e407\n[ 7.008223] RDX: 0000000000000000 RSI: 00007ffed5d467f0 RDI: 0000000000000003\n[ 7.008620] RBP: 00007ffed5d468a0 R08: 0000000000000000 R09: 0000000000000000\n[ 7.009039] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000\n[ 7.009429] R13: 00007ffed5d478b0 R14: 00007ec756ee5000 R15: 00005cbd4e655cb8\n\nFix this bug with correct pointer addition and conversion in parse\nand dump code.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: fix geneve_opt length integer overflow\n\nstruct geneve_opt uses 5 bit length for each single option, which\nmeans every vary size option should be smaller than 128 bytes.\n\nHowever, all current related Netlink policies cannot promise this\nlength condition and the attacker can exploit a exact 128-byte size\noption to *fake* a zero length option and confuse the parsing logic,\nfurther achieve heap out-of-bounds read.\n\nOne example crash log is like below:\n\n[ 3.905425] ==================================================================\n[ 3.905925] BUG: KASAN: slab-out-of-bounds in nla_put+0xa9/0xe0\n[ 3.906255] Read of size 124 at addr ffff888005f291cc by task poc/177\n[ 3.906646]\n[ 3.906775] CPU: 0 PID: 177 Comm: poc-oob-read Not tainted 6.1.132 #1\n[ 3.907131] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\n[ 3.907784] Call Trace:\n[ 3.907925] \n[ 3.908048] dump_stack_lvl+0x44/0x5c\n[ 3.908258] print_report+0x184/0x4be\n[ 3.909151] kasan_report+0xc5/0x100\n[ 3.909539] kasan_check_range+0xf3/0x1a0\n[ 3.909794] memcpy+0x1f/0x60\n[ 3.909968] nla_put+0xa9/0xe0\n[ 3.910147] tunnel_key_dump+0x945/0xba0\n[ 3.911536] tcf_action_dump_1+0x1c1/0x340\n[ 3.912436] tcf_action_dump+0x101/0x180\n[ 3.912689] tcf_exts_dump+0x164/0x1e0\n[ 3.912905] fw_dump+0x18b/0x2d0\n[ 3.913483] tcf_fill_node+0x2ee/0x460\n[ 3.914778] tfilter_notify+0xf4/0x180\n[ 3.915208] tc_new_tfilter+0xd51/0x10d0\n[ 3.918615] rtnetlink_rcv_msg+0x4a2/0x560\n[ 3.919118] netlink_rcv_skb+0xcd/0x200\n[ 3.919787] netlink_unicast+0x395/0x530\n[ 3.921032] netlink_sendmsg+0x3d0/0x6d0\n[ 3.921987] __sock_sendmsg+0x99/0xa0\n[ 3.922220] __sys_sendto+0x1b7/0x240\n[ 3.922682] __x64_sys_sendto+0x72/0x90\n[ 3.922906] do_syscall_64+0x5e/0x90\n[ 3.923814] entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n[ 3.924122] RIP: 0033:0x7e83eab84407\n[ 3.924331] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf\n[ 3.925330] RSP: 002b:00007ffff505e370 EFLAGS: 00000202 ORIG_RAX: 000000000000002c\n[ 3.925752] RAX: ffffffffffffffda RBX: 00007e83eaafa740 RCX: 00007e83eab84407\n[ 3.926173] RDX: 00000000000001a8 RSI: 00007ffff505e3c0 RDI: 0000000000000003\n[ 3.926587] RBP: 00007ffff505f460 R08: 00007e83eace1000 R09: 000000000000000c\n[ 3.926977] R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffff505f3c0\n[ 3.927367] R13: 00007ffff505f5c8 R14: 00007e83ead1b000 R15: 00005d4fbbe6dcb8\n\nFix these issues by enforing correct length condition in related\npolicies.

In the Linux kernel, the following vulnerability has been resolved:\n\narcnet: Add NULL check in com20020pci_probe()\n\ndevm_kasprintf() returns NULL when memory allocation fails. Currently,\ncom20020pci_probe() does not check for this case, which results in a\nNULL pointer dereference.\n\nAdd NULL check after devm_kasprintf() to prevent this issue and ensure\nno resources are left allocated.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ibmveth: make veth_pool_store stop hanging\n\nv2:\n- Created a single error handling unlock and exit in veth_pool_store\n- Greatly expanded commit message with previous explanatory-only text\n\nSummary: Use rtnl_mutex to synchronize veth_pool_store with itself,\nibmveth_close and ibmveth_open, preventing multiple calls in a row to\nnapi_disable.\n\nBackground: Two (or more) threads could call veth_pool_store through\nwriting to /sys/devices/vio/30000002/pool*/*. You can do this easily\nwith a little shell script. This causes a hang.\n\nI configured LOCKDEP, compiled ibmveth.c with DEBUG, and built a new\nkernel. I ran this test again and saw:\n\n Setting pool0/active to 0\n Setting pool1/active to 1\n [ 73.911067][ T4365] ibmveth 30000002 eth0: close starting\n Setting pool1/active to 1\n Setting pool1/active to 0\n [ 73.911367][ T4366] ibmveth 30000002 eth0: close starting\n [ 73.916056][ T4365] ibmveth 30000002 eth0: close complete\n [ 73.916064][ T4365] ibmveth 30000002 eth0: open starting\n [ 110.808564][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification.\n [ 230.808495][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification.\n [ 243.683786][ T123] INFO: task stress.sh:4365 blocked for more than 122 seconds.\n [ 243.683827][ T123] Not tainted 6.14.0-01103-g2df0c02dab82-dirty #8\n [ 243.683833][ T123] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.\n [ 243.683838][ T123] task:stress.sh state:D stack:28096 pid:4365 tgid:4365 ppid:4364 task_flags:0x400040 flags:0x00042000\n [ 243.683852][ T123] Call Trace:\n [ 243.683857][ T123] [c00000000c38f690] [0000000000000001] 0x1 (unreliable)\n [ 243.683868][ T123] [c00000000c38f840] [c00000000001f908] __switch_to+0x318/0x4e0\n [ 243.683878][ T123] [c00000000c38f8a0] [c000000001549a70] __schedule+0x500/0x12a0\n [ 243.683888][ T123] [c00000000c38f9a0] [c00000000154a878] schedule+0x68/0x210\n [ 243.683896][ T123] [c00000000c38f9d0] [c00000000154ac80] schedule_preempt_disabled+0x30/0x50\n [ 243.683904][ T123] [c00000000c38fa00] [c00000000154dbb0] __mutex_lock+0x730/0x10f0\n [ 243.683913][ T123] [c00000000c38fb10] [c000000001154d40] napi_enable+0x30/0x60\n [ 243.683921][ T123] [c00000000c38fb40] [c000000000f4ae94] ibmveth_open+0x68/0x5dc\n [ 243.683928][ T123] [c00000000c38fbe0] [c000000000f4aa20] veth_pool_store+0x220/0x270\n [ 243.683936][ T123] [c00000000c38fc70] [c000000000826278] sysfs_kf_write+0x68/0xb0\n [ 243.683944][ T123] [c00000000c38fcb0] [c0000000008240b8] kernfs_fop_write_iter+0x198/0x2d0\n [ 243.683951][ T123] [c00000000c38fd00] [c00000000071b9ac] vfs_write+0x34c/0x650\n [ 243.683958][ T123] [c00000000c38fdc0] [c00000000071bea8] ksys_write+0x88/0x150\n [ 243.683966][ T123] [c00000000c38fe10] [c0000000000317f4] system_call_exception+0x124/0x340\n [ 243.683973][ T123] [c00000000c38fe50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec\n ...\n [ 243.684087][ T123] Showing all locks held in the system:\n [ 243.684095][ T123] 1 lock held by khungtaskd/123:\n [ 243.684099][ T123] #0: c00000000278e370 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x50/0x248\n [ 243.684114][ T123] 4 locks held by stress.sh/4365:\n [ 243.684119][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150\n [ 243.684132][ T123] #1: c000000041aea888 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x154/0x2d0\n [ 243.684143][ T123] #2: c0000000366fb9a8 (kn->active#64){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x160/0x2d0\n [ 243.684155][ T123] #3: c000000035ff4cb8 (&dev->lock){+.+.}-{3:3}, at: napi_enable+0x30/0x60\n [ 243.684166][ T123] 5 locks held by stress.sh/4366:\n [ 243.684170][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150\n [ 243.\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nstaging: gpib: Fix Oops after disconnect in ni_usb\n\nIf the usb dongle is disconnected subsequent calls to the\ndriver cause a NULL dereference Oops as the bus_interface\nis set to NULL on disconnect.\n\nThis problem was introduced by setting usb_dev from the bus_interface\nfor dev_xxx messages.\n\nPreviously bus_interface was checked for NULL only in the the functions\ndirectly calling usb_fill_bulk_urb or usb_control_msg.\n\nCheck for valid bus_interface on all interface entry points\nand return -ENODEV if it is NULL.

In the Linux kernel, the following vulnerability has been resolved:\n\nstaging: gpib: Fix Oops after disconnect in agilent usb\n\nIf the agilent usb dongle is disconnected subsequent calls to the\ndriver cause a NULL dereference Oops as the bus_interface\nis set to NULL on disconnect.\n\nThis problem was introduced by setting usb_dev from the bus_interface\nfor dev_xxx messages.\n\nPreviously bus_interface was checked for NULL only in the functions\ndirectly calling usb_fill_bulk_urb or usb_control_msg.\n\nCheck for valid bus_interface on all interface entry points\nand return -ENODEV if it is NULL.

In the Linux kernel, the following vulnerability has been resolved:\n\nusbnet:fix NPE during rx_complete\n\nMissing usbnet_going_away Check in Critical Path.\nThe usb_submit_urb function lacks a usbnet_going_away\nvalidation, whereas __usbnet_queue_skb includes this check.\n\nThis inconsistency creates a race condition where:\nA URB request may succeed, but the corresponding SKB data\nfails to be queued.\n\nSubsequent processes:\n(e.g., rx_complete → defer_bh → __skb_unlink(skb, list))\nattempt to access skb->next, triggering a NULL pointer\ndereference (Kernel Panic).

In the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: BPF: Don't override subprog's return value\n\nThe verifier test `calls: div by 0 in subprog` triggers a panic at the\nld.bu instruction. The ld.bu insn is trying to load byte from memory\naddress returned by the subprog. The subprog actually set the correct\naddress at the a5 register (dedicated register for BPF return values).\nBut at commit 73c359d1d356 ("LoongArch: BPF: Sign-extend return values")\nwe also sign extended a5 to the a0 register (return value in LoongArch).\nFor function call insn, we later propagate the a0 register back to a5\nregister. This is right for native calls but wrong for bpf2bpf calls\nwhich expect zero-extended return value in a5 register. So only move a0\nto a5 for native calls (i.e. non-BPF_PSEUDO_CALL).

In the Linux kernel, the following vulnerability has been resolved:\n\nx86/microcode/AMD: Fix __apply_microcode_amd()'s return value\n\nWhen verify_sha256_digest() fails, __apply_microcode_amd() should propagate\nthe failure by returning false (and not -1 which is promoted to true).

In the Linux kernel, the following vulnerability has been resolved:\n\nuprobes/x86: Harden uretprobe syscall trampoline check\n\nJann reported a possible issue when trampoline_check_ip returns\naddress near the bottom of the address space that is allowed to\ncall into the syscall if uretprobes are not set up:\n\n https://lore.kernel.org/bpf/202502081235.5A6F352985@keescook/T/#m9d416df341b8fbc11737dacbcd29f0054413cbbf\n\nThough the mmap minimum address restrictions will typically prevent\ncreating mappings there, let's make sure uretprobe syscall checks\nfor that.

In the Linux kernel, the following vulnerability has been resolved:\n\nacpi: nfit: fix narrowing conversion in acpi_nfit_ctl\n\nSyzkaller has reported a warning in to_nfit_bus_uuid(): "only secondary\nbus families can be translated". This warning is emited if the argument\nis equal to NVDIMM_BUS_FAMILY_NFIT == 0. Function acpi_nfit_ctl() first\nverifies that a user-provided value call_pkg->nd_family of type u64 is\nnot equal to 0. Then the value is converted to int, and only after that\nis compared to NVDIMM_BUS_FAMILY_MAX. This can lead to passing an invalid\nargument to acpi_nfit_ctl(), if call_pkg->nd_family is non-zero, while\nthe lower 32 bits are zero.\n\nFurthermore, it is best to return EINVAL immediately upon seeing the\ninvalid user input. The WARNING is insufficient to prevent further\nundefined behavior based on other invalid user input.\n\nAll checks of the input value should be applied to the original variable\ncall_pkg->nd_family.\n\n[iweiny: update commit message]

In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: validate zero num_subauth before sub_auth is accessed\n\nAccess psid->sub_auth[psid->num_subauth - 1] without checking\nif num_subauth is non-zero leads to an out-of-bounds read.\nThis patch adds a validation step to ensure num_subauth != 0\nbefore sub_auth is accessed.

In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix null pointer dereference in alloc_preauth_hash()\n\nThe Client send malformed smb2 negotiate request. ksmbd return error\nresponse. Subsequently, the client can send smb2 session setup even\nthought conn->preauth_info is not allocated.\nThis patch add KSMBD_SESS_NEED_SETUP status of connection to ignore\nsession setup request if smb2 negotiate phase is not complete.

In the Linux kernel, the following vulnerability has been resolved:\n\nexfat: fix random stack corruption after get_block\n\nWhen get_block is called with a buffer_head allocated on the stack, such\nas do_mpage_readpage, stack corruption due to buffer_head UAF may occur in\nthe following race condition situation.\n\n \nmpage_read_folio\n <>\n do_mpage_readpage\n exfat_get_block\n bh_read\n __bh_read\n get_bh(bh)\n submit_bh\n wait_on_buffer\n ...\n end_buffer_read_sync\n __end_buffer_read_notouch\n unlock_buffer\n <>\n ...\n ...\n ...\n ...\n<>\n .\n .\nanother_function\n <>\n put_bh(bh)\n atomic_dec(bh->b_count)\n * stack corruption here *\n\nThis patch returns -EAGAIN if a folio does not have buffers when bh_read\nneeds to be called. By doing this, the caller can fallback to functions\nlike block_read_full_folio(), create a buffer_head in the folio, and then\ncall get_block again.\n\nLet's do not call bh_read() with on-stack buffer_head.

In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix use-after-free in print_graph_function_flags during tracer switching\n\nKairui reported a UAF issue in print_graph_function_flags() during\nftrace stress testing [1]. This issue can be reproduced if puting a\n'mdelay(10)' after 'mutex_unlock(&trace_types_lock)' in s_start(),\nand executing the following script:\n\n $ echo function_graph > current_tracer\n $ cat trace > /dev/null &\n $ sleep 5 # Ensure the 'cat' reaches the 'mdelay(10)' point\n $ echo timerlat > current_tracer\n\nThe root cause lies in the two calls to print_graph_function_flags\nwithin print_trace_line during each s_show():\n\n * One through 'iter->trace->print_line()';\n * Another through 'event->funcs->trace()', which is hidden in\n print_trace_fmt() before print_trace_line returns.\n\nTracer switching only updates the former, while the latter continues\nto use the print_line function of the old tracer, which in the script\nabove is print_graph_function_flags.\n\nMoreover, when switching from the 'function_graph' tracer to the\n'timerlat' tracer, s_start only calls graph_trace_close of the\n'function_graph' tracer to free 'iter->private', but does not set\nit to NULL. This provides an opportunity for 'event->funcs->trace()'\nto use an invalid 'iter->private'.\n\nTo fix this issue, set 'iter->private' to NULL immediately after\nfreeing it in graph_trace_close(), ensuring that an invalid pointer\nis not passed to other tracers. Additionally, clean up the unnecessary\n'iter->private = NULL' during each 'cat trace' when using wakeup and\nirqsoff tracers.\n\n [1] https://lore.kernel.org/all/20231112150030.84609-1-ryncsn@gmail.com/

In the Linux kernel, the following vulnerability has been resolved:\n\narm64: Don't call NULL in do_compat_alignment_fixup()\n\ndo_alignment_t32_to_handler() only fixes up alignment faults for\nspecific instructions; it returns NULL otherwise (e.g. LDREX). When\nthat's the case, signal to the caller that it needs to proceed with the\nregular alignment fault handling (i.e. SIGBUS). Without this patch, the\nkernel panics:\n\n Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n Mem abort info:\n ESR = 0x0000000086000006\n EC = 0x21: IABT (current EL), IL = 32 bits\n SET = 0, FnV = 0\n EA = 0, S1PTW = 0\n FSC = 0x06: level 2 translation fault\n user pgtable: 4k pages, 48-bit VAs, pgdp=00000800164aa000\n [0000000000000000] pgd=0800081fdbd22003, p4d=0800081fdbd22003, pud=08000815d51c6003, pmd=0000000000000000\n Internal error: Oops: 0000000086000006 [#1] SMP\n Modules linked in: cfg80211 rfkill xt_nat xt_tcpudp xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat br_netfilter veth nvme_fa>\n libcrc32c crc32c_generic raid0 multipath linear dm_mod dax raid1 md_mod xhci_pci nvme xhci_hcd nvme_core t10_pi usbcore igb crc64_rocksoft crc64 crc_t10dif crct10dif_generic crct10dif_ce crct10dif_common usb_common i2c_algo_bit i2c>\n CPU: 2 PID: 3932954 Comm: WPEWebProcess Not tainted 6.1.0-31-arm64 #1 Debian 6.1.128-1\n Hardware name: GIGABYTE MP32-AR1-00/MP32-AR1-00, BIOS F18v (SCP: 1.08.20211002) 12/01/2021\n pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : 0x0\n lr : do_compat_alignment_fixup+0xd8/0x3dc\n sp : ffff80000f973dd0\n x29: ffff80000f973dd0 x28: ffff081b42526180 x27: 0000000000000000\n x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000\n x23: 0000000000000004 x22: 0000000000000000 x21: 0000000000000001\n x20: 00000000e8551f00 x19: ffff80000f973eb0 x18: 0000000000000000\n x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\n x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n x11: 0000000000000000 x10: 0000000000000000 x9 : ffffaebc949bc488\n x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000\n x5 : 0000000000400000 x4 : 0000fffffffffffe x3 : 0000000000000000\n x2 : ffff80000f973eb0 x1 : 00000000e8551f00 x0 : 0000000000000001\n Call trace:\n 0x0\n do_alignment_fault+0x40/0x50\n do_mem_abort+0x4c/0xa0\n el0_da+0x48/0xf0\n el0t_32_sync_handler+0x110/0x140\n el0t_32_sync+0x190/0x194\n Code: bad PC value\n ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mt76: mt7921: fix kernel panic due to null pointer dereference\n\nAddress a kernel panic caused by a null pointer dereference in the\n`mt792x_rx_get_wcid` function. The issue arises because the `deflink` structure\nis not properly initialized with the `sta` context. This patch ensures that the\n`deflink` structure is correctly linked to the `sta` context, preventing the\nnull pointer dereference.\n\n BUG: kernel NULL pointer dereference, address: 0000000000000400\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI\n CPU: 0 UID: 0 PID: 470 Comm: mt76-usb-rx phy Not tainted 6.12.13-gentoo-dist #1\n Hardware name: /AMD HUDSON-M1, BIOS 4.6.4 11/15/2011\n RIP: 0010:mt792x_rx_get_wcid+0x48/0x140 [mt792x_lib]\n RSP: 0018:ffffa147c055fd98 EFLAGS: 00010202\n RAX: 0000000000000000 RBX: ffff8e9ecb652000 RCX: 0000000000000000\n RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8e9ecb652000\n RBP: 0000000000000685 R08: ffff8e9ec6570000 R09: 0000000000000000\n R10: ffff8e9ecd2ca000 R11: ffff8e9f22a217c0 R12: 0000000038010119\n R13: 0000000080843801 R14: ffff8e9ec6570000 R15: ffff8e9ecb652000\n FS: 0000000000000000(0000) GS:ffff8e9f22a00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000400 CR3: 000000000d2ea000 CR4: 00000000000006f0\n Call Trace:\n \n ? __die_body.cold+0x19/0x27\n ? page_fault_oops+0x15a/0x2f0\n ? search_module_extables+0x19/0x60\n ? search_bpf_extables+0x5f/0x80\n ? exc_page_fault+0x7e/0x180\n ? asm_exc_page_fault+0x26/0x30\n ? mt792x_rx_get_wcid+0x48/0x140 [mt792x_lib]\n mt7921_queue_rx_skb+0x1c6/0xaa0 [mt7921_common]\n mt76u_alloc_queues+0x784/0x810 [mt76_usb]\n ? __pfx___mt76_worker_fn+0x10/0x10 [mt76]\n __mt76_worker_fn+0x4f/0x80 [mt76]\n kthread+0xd2/0x100\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x34/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \n ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:\n\nPCI/bwctrl: Fix NULL pointer dereference on bus number exhaustion\n\nWhen BIOS neglects to assign bus numbers to PCI bridges, the kernel\nattempts to correct that during PCI device enumeration. If it runs out\nof bus numbers, no pci_bus is allocated and the "subordinate" pointer in\nthe bridge's pci_dev remains NULL.\n\nThe PCIe bandwidth controller erroneously does not check for a NULL\nsubordinate pointer and dereferences it on probe.\n\nBandwidth control of unusable devices below the bridge is of questionable\nutility, so simply error out instead. This mirrors what PCIe hotplug does\nsince commit 62e4492c3063 ("PCI: Prevent NULL dereference during pciehp\nprobe").\n\nThe PCI core emits a message with KERN_INFO severity if it has run out of\nbus numbers. PCIe hotplug emits an additional message with KERN_ERR\nseverity to inform the user that hotplug functionality is disabled at the\nbridge. A similar message for bandwidth control does not seem merited,\ngiven that its only purpose so far is to expose an up-to-date link speed\nin sysfs and throttle the link speed on certain laptops with limited\nThermal Design Power. So error out silently.\n\nUser-visible messages:\n\n pci 0000:16:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring\n [...]\n pci_bus 0000:45: busn_res: [bus 45-74] end is updated to 74\n pci 0000:16:02.0: devices behind bridge are unusable because [bus 45-74] cannot be assigned for them\n [...]\n pcieport 0000:16:02.0: pciehp: Hotplug bridge without secondary bus, ignoring\n [...]\n BUG: kernel NULL pointer dereference\n RIP: pcie_update_link_speed\n pcie_bwnotif_enable\n pcie_bwnotif_probe\n pcie_port_probe_service\n really_probe

In the Linux kernel, the following vulnerability has been resolved:\n\nmm: zswap: fix crypto_free_acomp() deadlock in zswap_cpu_comp_dead()\n\nCurrently, zswap_cpu_comp_dead() calls crypto_free_acomp() while holding\nthe per-CPU acomp_ctx mutex. crypto_free_acomp() then holds scomp_lock\n(through crypto_exit_scomp_ops_async()).\n\nOn the other hand, crypto_alloc_acomp_node() holds the scomp_lock (through\ncrypto_scomp_init_tfm()), and then allocates memory. If the allocation\nresults in reclaim, we may attempt to hold the per-CPU acomp_ctx mutex.\n\nThe above dependencies can cause an ABBA deadlock. For example in the\nfollowing scenario:\n\n(1) Task A running on CPU #1:\n crypto_alloc_acomp_node()\n Holds scomp_lock\n Enters reclaim\n Reads per_cpu_ptr(pool->acomp_ctx, 1)\n\n(2) Task A is descheduled\n\n(3) CPU #1 goes offline\n zswap_cpu_comp_dead(CPU #1)\n Holds per_cpu_ptr(pool->acomp_ctx, 1))\n Calls crypto_free_acomp()\n Waits for scomp_lock\n\n(4) Task A running on CPU #2:\n Waits for per_cpu_ptr(pool->acomp_ctx, 1) // Read on CPU #1\n DEADLOCK\n\nSince there is no requirement to call crypto_free_acomp() with the per-CPU\nacomp_ctx mutex held in zswap_cpu_comp_dead(), move it after the mutex is\nunlocked. Also move the acomp_request_free() and kfree() calls for\nconsistency and to avoid any potential sublte locking dependencies in the\nfuture.\n\nWith this, only setting acomp_ctx fields to NULL occurs with the mutex\nheld. This is similar to how zswap_cpu_comp_prepare() only initializes\nacomp_ctx fields with the mutex held, after performing all allocations\nbefore holding the mutex.\n\nOpportunistically, move the NULL check on acomp_ctx so that it takes place\nbefore the mutex dereference.

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: vimc: skip .s_stream() for stopped entities\n\nSyzbot reported [1] a warning prompted by a check in call_s_stream()\nthat checks whether .s_stream() operation is warranted for unstarted\nor stopped subdevs.\n\nAdd a simple fix in vimc_streamer_pipeline_terminate() ensuring that\nentities skip a call to .s_stream() unless they have been previously\nproperly started.\n\n[1] Syzbot report:\n------------[ cut here ]------------\nWARNING: CPU: 0 PID: 5933 at drivers/media/v4l2-core/v4l2-subdev.c:460 call_s_stream+0x2df/0x350 drivers/media/v4l2-core/v4l2-subdev.c:460\nModules linked in:\nCPU: 0 UID: 0 PID: 5933 Comm: syz-executor330 Not tainted 6.13.0-rc2-syzkaller-00362-g2d8308bf5b67 #0\n...\nCall Trace:\n \n vimc_streamer_pipeline_terminate+0x218/0x320 drivers/media/test-drivers/vimc/vimc-streamer.c:62\n vimc_streamer_pipeline_init drivers/media/test-drivers/vimc/vimc-streamer.c:101 [inline]\n vimc_streamer_s_stream+0x650/0x9a0 drivers/media/test-drivers/vimc/vimc-streamer.c:203\n vimc_capture_start_streaming+0xa1/0x130 drivers/media/test-drivers/vimc/vimc-capture.c:256\n vb2_start_streaming+0x15f/0x5a0 drivers/media/common/videobuf2/videobuf2-core.c:1789\n vb2_core_streamon+0x2a7/0x450 drivers/media/common/videobuf2/videobuf2-core.c:2348\n vb2_streamon drivers/media/common/videobuf2/videobuf2-v4l2.c:875 [inline]\n vb2_ioctl_streamon+0xf4/0x170 drivers/media/common/videobuf2/videobuf2-v4l2.c:1118\n __video_do_ioctl+0xaf0/0xf00 drivers/media/v4l2-core/v4l2-ioctl.c:3122\n video_usercopy+0x4d2/0x1620 drivers/media/v4l2-core/v4l2-ioctl.c:3463\n v4l2_ioctl+0x1ba/0x250 drivers/media/v4l2-core/v4l2-dev.c:366\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:906 [inline]\n __se_sys_ioctl fs/ioctl.c:892 [inline]\n __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f2b85c01b19\n...

In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: don't ignore the return code of svc_proc_register()\n\nCurrently, nfsd_proc_stat_init() ignores the return value of\nsvc_proc_register(). If the procfile creation fails, then the kernel\nwill WARN when it tries to remove the entry later.\n\nFix nfsd_proc_stat_init() to return the same type of pointer as\nsvc_proc_register(), and fix up nfsd_net_init() to check that and fail\nthe nfsd_net construction if it occurs.\n\nsvc_proc_register() can fail if the dentry can't be allocated, or if an\nidentical dentry already exists. The second case is pretty unlikely in\nthe nfsd_net construction codepath, so if this happens, return -ENOMEM.

In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix management of listener transports\n\nCurrently, when no active threads are running, a root user using nfsdctl\ncommand can try to remove a particular listener from the list of previously\nadded ones, then start the server by increasing the number of threads,\nit leads to the following problem:\n\n[ 158.835354] refcount_t: addition on 0; use-after-free.\n[ 158.835603] WARNING: CPU: 2 PID: 9145 at lib/refcount.c:25 refcount_warn_saturate+0x160/0x1a0\n[ 158.836017] Modules linked in: rpcrdma rdma_cm iw_cm ib_cm ib_core nfsd auth_rpcgss nfs_acl lockd grace overlay isofs uinput snd_seq_dummy snd_hrtimer nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 rfkill ip_set nf_tables qrtr sunrpc vfat fat uvcvideo videobuf2_vmalloc videobuf2_memops uvc videobuf2_v4l2 videodev videobuf2_common snd_hda_codec_generic mc e1000e snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd soundcore sg loop dm_multipath dm_mod nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs libcrc32c crct10dif_ce ghash_ce vmwgfx sha2_ce sha256_arm64 sr_mod sha1_ce cdrom nvme drm_client_lib drm_ttm_helper ttm nvme_core drm_kms_helper nvme_auth drm fuse\n[ 158.840093] CPU: 2 UID: 0 PID: 9145 Comm: nfsd Kdump: loaded Tainted: G B W 6.13.0-rc6+ #7\n[ 158.840624] Tainted: [B]=BAD_PAGE, [W]=WARN\n[ 158.840802] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.24006586.BA64.2406042154 06/04/2024\n[ 158.841220] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n[ 158.841563] pc : refcount_warn_saturate+0x160/0x1a0\n[ 158.841780] lr : refcount_warn_saturate+0x160/0x1a0\n[ 158.842000] sp : ffff800089be7d80\n[ 158.842147] x29: ffff800089be7d80 x28: ffff00008e68c148 x27: ffff00008e68c148\n[ 158.842492] x26: ffff0002e3b5c000 x25: ffff600011cd1829 x24: ffff00008653c010\n[ 158.842832] x23: ffff00008653c000 x22: 1fffe00011cd1829 x21: ffff00008653c028\n[ 158.843175] x20: 0000000000000002 x19: ffff00008653c010 x18: 0000000000000000\n[ 158.843505] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\n[ 158.843836] x14: 0000000000000000 x13: 0000000000000001 x12: ffff600050a26493\n[ 158.844143] x11: 1fffe00050a26492 x10: ffff600050a26492 x9 : dfff800000000000\n[ 158.844475] x8 : 00009fffaf5d9b6e x7 : ffff000285132493 x6 : 0000000000000001\n[ 158.844823] x5 : ffff000285132490 x4 : ffff600050a26493 x3 : ffff8000805e72bc\n[ 158.845174] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000098588000\n[ 158.845528] Call trace:\n[ 158.845658] refcount_warn_saturate+0x160/0x1a0 (P)\n[ 158.845894] svc_recv+0x58c/0x680 [sunrpc]\n[ 158.846183] nfsd+0x1fc/0x348 [nfsd]\n[ 158.846390] kthread+0x274/0x2f8\n[ 158.846546] ret_from_fork+0x10/0x20\n[ 158.846714] ---[ end trace 0000000000000000 ]---\n\nnfsd_nl_listener_set_doit() would manipulate the list of transports of\nserver's sv_permsocks and close the specified listener but the other\nlist of transports (server's sp_xprts list) would not be changed leading\nto the problem above.\n\nInstead, determined if the nfsdctl is trying to remove a listener, in\nwhich case, delete all the existing listener transports and re-create\nall-but-the-removed ones.

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: xhci: Don't skip on Stopped - Length Invalid\n\nUp until commit d56b0b2ab142 ("usb: xhci: ensure skipped isoc TDs are\nreturned when isoc ring is stopped") in v6.11, the driver didn't skip\nmissed isochronous TDs when handling Stoppend and Stopped - Length\nInvalid events. Instead, it erroneously cleared the skip flag, which\nwould cause the ring to get stuck, as future events won't match the\nmissed TD which is never removed from the queue until it's cancelled.\n\nThis buggy logic seems to have been in place substantially unchanged\nsince the 3.x series over 10 years ago, which probably speaks first\nand foremost about relative rarity of this case in normal usage, but\nby the spec I see no reason why it shouldn't be possible.\n\nAfter d56b0b2ab142, TDs are immediately skipped when handling those\nStopped events. This poses a potential problem in case of Stopped -\nLength Invalid, which occurs either on completed TDs (likely already\ngiven back) or Link and No-Op TRBs. Such event won't be recognized\nas matching any TD (unless it's the rare Link TRB inside a TD) and\nwill result in skipping all pending TDs, giving them back possibly\nbefore they are done, risking isoc data loss and maybe UAF by HW.\n\nAs a compromise, don't skip and don't clear the skip flag on this\nkind of event. Then the next event will skip missed TDs. A downside\nof not handling Stopped - Length Invalid on a Link inside a TD is\nthat if the TD is cancelled, its actual length will not be updated\nto account for TRBs (silently) completed before the TD was stopped.\n\nI had no luck producing this sequence of completion events so there\nis no compelling demonstration of any resulting disaster. It may be\na very rare, obscure condition. The sole motivation for this patch\nis that if such unlikely event does occur, I'd rather risk reporting\na cancelled partially done isoc frame as empty than gamble with UAF.\n\nThis will be fixed more properly by looking at Stopped event's TRB\npointer when making skipping decisions, but such rework is unlikely\nto be backported to v6.12, which will stay around for a few years.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: socket: Lookup orig tuple for IPv6 SNAT\n\nnf_sk_lookup_slow_v4 does the conntrack lookup for IPv4 packets to\nrestore the original 5-tuple in case of SNAT, to be able to find the\nright socket (if any). Then socket_match() can correctly check whether\nthe socket was transparent.\n\nHowever, the IPv6 counterpart (nf_sk_lookup_slow_v6) lacks this\nconntrack lookup, making xt_socket fail to match on the socket when the\npacket was SNATed. Add the same logic to nf_sk_lookup_slow_v6.\n\nIPv6 SNAT is used in Kubernetes clusters for pod-to-world packets, as\npods' addresses are in the fd00::/8 ULA subnet and need to be replaced\nwith the node's external address. Cilium leverages Envoy to enforce L7\npolicies, and Envoy uses transparent sockets. Cilium inserts an iptables\nprerouting rule that matches on `-m socket --transparent` and redirects\nthe packets to localhost, but it fails to match SNATed IPv6 packets due\nto that missing conntrack lookup.

In the Linux kernel, the following vulnerability has been resolved:\n\nmemstick: rtsx_usb_ms: Fix slab-use-after-free in rtsx_usb_ms_drv_remove\n\nThis fixes the following crash:\n\n==================================================================\nBUG: KASAN: slab-use-after-free in rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\nRead of size 8 at addr ffff888136335380 by task kworker/6:0/140241\n\nCPU: 6 UID: 0 PID: 140241 Comm: kworker/6:0 Kdump: loaded Tainted: G E 6.14.0-rc6+ #1\nTainted: [E]=UNSIGNED_MODULE\nHardware name: LENOVO 30FNA1V7CW/1057, BIOS S0EKT54A 07/01/2024\nWorkqueue: events rtsx_usb_ms_poll_card [rtsx_usb_ms]\nCall Trace:\n \n dump_stack_lvl+0x51/0x70\n print_address_description.constprop.0+0x27/0x320\n ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\n print_report+0x3e/0x70\n kasan_report+0xab/0xe0\n ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\n rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\n ? __pfx_rtsx_usb_ms_poll_card+0x10/0x10 [rtsx_usb_ms]\n ? __pfx___schedule+0x10/0x10\n ? kick_pool+0x3b/0x270\n process_one_work+0x357/0x660\n worker_thread+0x390/0x4c0\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x190/0x1d0\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x2d/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \n\nAllocated by task 161446:\n kasan_save_stack+0x20/0x40\n kasan_save_track+0x10/0x30\n __kasan_kmalloc+0x7b/0x90\n __kmalloc_noprof+0x1a7/0x470\n memstick_alloc_host+0x1f/0xe0 [memstick]\n rtsx_usb_ms_drv_probe+0x47/0x320 [rtsx_usb_ms]\n platform_probe+0x60/0xe0\n call_driver_probe+0x35/0x120\n really_probe+0x123/0x410\n __driver_probe_device+0xc7/0x1e0\n driver_probe_device+0x49/0xf0\n __device_attach_driver+0xc6/0x160\n bus_for_each_drv+0xe4/0x160\n __device_attach+0x13a/0x2b0\n bus_probe_device+0xbd/0xd0\n device_add+0x4a5/0x760\n platform_device_add+0x189/0x370\n mfd_add_device+0x587/0x5e0\n mfd_add_devices+0xb1/0x130\n rtsx_usb_probe+0x28e/0x2e0 [rtsx_usb]\n usb_probe_interface+0x15c/0x460\n call_driver_probe+0x35/0x120\n really_probe+0x123/0x410\n __driver_probe_device+0xc7/0x1e0\n driver_probe_device+0x49/0xf0\n __device_attach_driver+0xc6/0x160\n bus_for_each_drv+0xe4/0x160\n __device_attach+0x13a/0x2b0\n rebind_marked_interfaces.isra.0+0xcc/0x110\n usb_reset_device+0x352/0x410\n usbdev_do_ioctl+0xe5c/0x1860\n usbdev_ioctl+0xa/0x20\n __x64_sys_ioctl+0xc5/0xf0\n do_syscall_64+0x59/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nFreed by task 161506:\n kasan_save_stack+0x20/0x40\n kasan_save_track+0x10/0x30\n kasan_save_free_info+0x36/0x60\n __kasan_slab_free+0x34/0x50\n kfree+0x1fd/0x3b0\n device_release+0x56/0xf0\n kobject_cleanup+0x73/0x1c0\n rtsx_usb_ms_drv_remove+0x13d/0x220 [rtsx_usb_ms]\n platform_remove+0x2f/0x50\n device_release_driver_internal+0x24b/0x2e0\n bus_remove_device+0x124/0x1d0\n device_del+0x239/0x530\n platform_device_del.part.0+0x19/0xe0\n platform_device_unregister+0x1c/0x40\n mfd_remove_devices_fn+0x167/0x170\n device_for_each_child_reverse+0xc9/0x130\n mfd_remove_devices+0x6e/0xa0\n rtsx_usb_disconnect+0x2e/0xd0 [rtsx_usb]\n usb_unbind_interface+0xf3/0x3f0\n device_release_driver_internal+0x24b/0x2e0\n proc_disconnect_claim+0x13d/0x220\n usbdev_do_ioctl+0xb5e/0x1860\n usbdev_ioctl+0xa/0x20\n __x64_sys_ioctl+0xc5/0xf0\n do_syscall_64+0x59/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nLast potentially related work creation:\n kasan_save_stack+0x20/0x40\n kasan_record_aux_stack+0x85/0x90\n insert_work+0x29/0x100\n __queue_work+0x34a/0x540\n call_timer_fn+0x2a/0x160\n expire_timers+0x5f/0x1f0\n __run_timer_base.part.0+0x1b6/0x1e0\n run_timer_softirq+0x8b/0xe0\n handle_softirqs+0xf9/0x360\n __irq_exit_rcu+0x114/0x130\n sysvec_apic_timer_interrupt+0x72/0x90\n asm_sysvec_apic_timer_interrupt+0x16/0x20\n\nSecond to last potentially related work creation:\n kasan_save_stack+0x20/0x40\n kasan_record_aux_stack+0x85/0x90\n insert_work+0x29/0x100\n __queue_work+0x34a/0x540\n call_timer_fn+0x2a/0x160\n expire_timers+0x5f/0x1f0\n __run_timer_base.part.0+0x1b6/0x1e0\n run_timer_softirq+0x8b/0xe0\n handle_softirqs+0xf9/0x\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nbcachefs: bch2_ioctl_subvolume_destroy() fixes\n\nbch2_evict_subvolume_inodes() was getting stuck - due to incorrectly\npruning the dcache.\n\nAlso, fix missing permissions checks.

In the Linux kernel, the following vulnerability has been resolved:\n\natm: Fix NULL pointer dereference\n\nWhen MPOA_cache_impos_rcvd() receives the msg, it can trigger\nNull Pointer Dereference Vulnerability if both entry and\nholding_time are NULL. Because there is only for the situation\nwhere entry is NULL and holding_time exists, it can be passed\nwhen both entry and holding_time are NULL. If these are NULL,\nthe entry will be passd to eg_cache_put() as parameter and\nit is referenced by entry->use code in it.\n\nkasan log:\n\n[ 3.316691] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006:I\n[ 3.317568] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]\n[ 3.318188] CPU: 3 UID: 0 PID: 79 Comm: ex Not tainted 6.14.0-rc2 #102\n[ 3.318601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n[ 3.319298] RIP: 0010:eg_cache_remove_entry+0xa5/0x470\n[ 3.319677] Code: c1 f7 6e fd 48 c7 c7 00 7e 38 b2 e8 95 64 54 fd 48 c7 c7 40 7e 38 b2 48 89 ee e80\n[ 3.321220] RSP: 0018:ffff88800583f8a8 EFLAGS: 00010006\n[ 3.321596] RAX: 0000000000000006 RBX: ffff888005989000 RCX: ffffffffaecc2d8e\n[ 3.322112] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000030\n[ 3.322643] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6558b88\n[ 3.323181] R10: 0000000000000003 R11: 203a207972746e65 R12: 1ffff11000b07f15\n[ 3.323707] R13: dffffc0000000000 R14: ffff888005989000 R15: ffff888005989068\n[ 3.324185] FS: 000000001b6313c0(0000) GS:ffff88806d380000(0000) knlGS:0000000000000000\n[ 3.325042] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 3.325545] CR2: 00000000004b4b40 CR3: 000000000248e000 CR4: 00000000000006f0\n[ 3.326430] Call Trace:\n[ 3.326725] \n[ 3.326927] ? die_addr+0x3c/0xa0\n[ 3.327330] ? exc_general_protection+0x161/0x2a0\n[ 3.327662] ? asm_exc_general_protection+0x26/0x30\n[ 3.328214] ? vprintk_emit+0x15e/0x420\n[ 3.328543] ? eg_cache_remove_entry+0xa5/0x470\n[ 3.328910] ? eg_cache_remove_entry+0x9a/0x470\n[ 3.329294] ? __pfx_eg_cache_remove_entry+0x10/0x10\n[ 3.329664] ? console_unlock+0x107/0x1d0\n[ 3.329946] ? __pfx_console_unlock+0x10/0x10\n[ 3.330283] ? do_syscall_64+0xa6/0x1a0\n[ 3.330584] ? entry_SYSCALL_64_after_hwframe+0x47/0x7f\n[ 3.331090] ? __pfx_prb_read_valid+0x10/0x10\n[ 3.331395] ? down_trylock+0x52/0x80\n[ 3.331703] ? vprintk_emit+0x15e/0x420\n[ 3.331986] ? __pfx_vprintk_emit+0x10/0x10\n[ 3.332279] ? down_trylock+0x52/0x80\n[ 3.332527] ? _printk+0xbf/0x100\n[ 3.332762] ? __pfx__printk+0x10/0x10\n[ 3.333007] ? _raw_write_lock_irq+0x81/0xe0\n[ 3.333284] ? __pfx__raw_write_lock_irq+0x10/0x10\n[ 3.333614] msg_from_mpoad+0x1185/0x2750\n[ 3.333893] ? __build_skb_around+0x27b/0x3a0\n[ 3.334183] ? __pfx_msg_from_mpoad+0x10/0x10\n[ 3.334501] ? __alloc_skb+0x1c0/0x310\n[ 3.334809] ? __pfx___alloc_skb+0x10/0x10\n[ 3.335283] ? _raw_spin_lock+0xe0/0xe0\n[ 3.335632] ? finish_wait+0x8d/0x1e0\n[ 3.335975] vcc_sendmsg+0x684/0xba0\n[ 3.336250] ? __pfx_vcc_sendmsg+0x10/0x10\n[ 3.336587] ? __pfx_autoremove_wake_function+0x10/0x10\n[ 3.337056] ? fdget+0x176/0x3e0\n[ 3.337348] __sys_sendto+0x4a2/0x510\n[ 3.337663] ? __pfx___sys_sendto+0x10/0x10\n[ 3.337969] ? ioctl_has_perm.constprop.0.isra.0+0x284/0x400\n[ 3.338364] ? sock_ioctl+0x1bb/0x5a0\n[ 3.338653] ? __rseq_handle_notify_resume+0x825/0xd20\n[ 3.339017] ? __pfx_sock_ioctl+0x10/0x10\n[ 3.339316] ? __pfx___rseq_handle_notify_resume+0x10/0x10\n[ 3.339727] ? selinux_file_ioctl+0xa4/0x260\n[ 3.340166] __x64_sys_sendto+0xe0/0x1c0\n[ 3.340526] ? syscall_exit_to_user_mode+0x123/0x140\n[ 3.340898] do_syscall_64+0xa6/0x1a0\n[ 3.341170] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[ 3.341533] RIP: 0033:0x44a380\n[ 3.341757] Code: 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c00\n[ \n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\ndevlink: fix xa_alloc_cyclic() error handling\n\nIn case of returning 1 from xa_alloc_cyclic() (wrapping) ERR_PTR(1) will\nbe returned, which will cause IS_ERR() to be false. Which can lead to\ndereference not allocated pointer (rel).\n\nFix it by checking if err is lower than zero.\n\nThis wasn't found in real usecase, only noticed. Credit to Pierre.

In the Linux kernel, the following vulnerability has been resolved:\n\ndpll: fix xa_alloc_cyclic() error handling\n\nIn case of returning 1 from xa_alloc_cyclic() (wrapping) ERR_PTR(1) will\nbe returned, which will cause IS_ERR() to be false. Which can lead to\ndereference not allocated pointer (pin).\n\nFix it by checking if err is lower than zero.\n\nThis wasn't found in real usecase, only noticed. Credit to Pierre.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm/migrate: fix shmem xarray update during migration\n\nA shmem folio can be either in page cache or in swap cache, but not at the\nsame time. Namely, once it is in swap cache, folio->mapping should be\nNULL, and the folio is no longer in a shmem mapping.\n\nIn __folio_migrate_mapping(), to determine the number of xarray entries to\nupdate, folio_test_swapbacked() is used, but that conflates shmem in page\ncache case and shmem in swap cache case. It leads to xarray multi-index\nentry corruption, since it turns a sibling entry to a normal entry during\nxas_store() (see [1] for a userspace reproduction). Fix it by only using\nfolio_test_swapcache() to determine whether xarray is storing swap cache\nentries or not to choose the right number of xarray entries to update.\n\n[1] https://lore.kernel.org/linux-mm/Z8idPCkaJW1IChjT@casper.infradead.org/\n\nNote:\nIn __split_huge_page(), folio_test_anon() && folio_test_swapcache() is\nused to get swap_cache address space, but that ignores the shmem folio in\nswap cache case. It could lead to NULL pointer dereferencing when a\nin-swap-cache shmem folio is split at __xa_store(), since\n!folio_test_anon() is true and folio->mapping is NULL. But fortunately,\nits caller split_huge_page_to_list_to_order() bails out early with EBUSY\nwhen folio->mapping is NULL. So no need to take care of it here.

In the Linux kernel, the following vulnerability has been resolved:\n\nsoc: qcom: pdr: Fix the potential deadlock\n\nWhen some client process A call pdr_add_lookup() to add the look up for\nthe service and does schedule locator work, later a process B got a new\nserver packet indicating locator is up and call pdr_locator_new_server()\nwhich eventually sets pdr->locator_init_complete to true which process A\nsees and takes list lock and queries domain list but it will timeout due\nto deadlock as the response will queued to the same qmi->wq and it is\nordered workqueue and process B is not able to complete new server\nrequest work due to deadlock on list lock.\n\nFix it by removing the unnecessary list iteration as the list iteration\nis already being done inside locator work, so avoid it here and just\ncall schedule_work() here.\n\n Process A Process B\n\n process_scheduled_works()\npdr_add_lookup() qmi_data_ready_work()\n process_scheduled_works() pdr_locator_new_server()\n pdr->locator_init_complete=true;\n pdr_locator_work()\n mutex_lock(&pdr->list_lock);\n\n pdr_locate_service() mutex_lock(&pdr->list_lock);\n\n pdr_get_domain_list()\n pr_err("PDR: %s get domain list\n txn wait failed: %d\\n",\n req->service_name,\n ret);\n\nTimeout error log due to deadlock:\n\n"\n PDR: tms/servreg get domain list txn wait failed: -110\n PDR: service lookup for msm/adsp/sensor_pd:tms/servreg failed: -110\n"\n\nThanks to Bjorn and Johan for letting me know that this commit also fixes\nan audio regression when using the in-kernel pd-mapper as that makes it\neasier to hit this race. [1]

In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: Unconditionally save+flush host FPSIMD/SVE/SME state\n\nThere are several problems with the way hyp code lazily saves the host's\nFPSIMD/SVE state, including:\n\n* Host SVE being discarded unexpectedly due to inconsistent\n configuration of TIF_SVE and CPACR_ELx.ZEN. This has been seen to\n result in QEMU crashes where SVE is used by memmove(), as reported by\n Eric Auger:\n\n https://issues.redhat.com/browse/RHEL-68997\n\n* Host SVE state is discarded *after* modification by ptrace, which was an\n unintentional ptrace ABI change introduced with lazy discarding of SVE state.\n\n* The host FPMR value can be discarded when running a non-protected VM,\n where FPMR support is not exposed to a VM, and that VM uses\n FPSIMD/SVE. In these cases the hyp code does not save the host's FPMR\n before unbinding the host's FPSIMD/SVE/SME state, leaving a stale\n value in memory.\n\nAvoid these by eagerly saving and "flushing" the host's FPSIMD/SVE/SME\nstate when loading a vCPU such that KVM does not need to save any of the\nhost's FPSIMD/SVE/SME state. For clarity, fpsimd_kvm_prepare() is\nremoved and the necessary call to fpsimd_save_and_flush_cpu_state() is\nplaced in kvm_arch_vcpu_load_fp(). As 'fpsimd_state' and 'fpmr_ptr'\nshould not be used, they are set to NULL; all uses of these will be\nremoved in subsequent patches.\n\nHistorical problems go back at least as far as v5.17, e.g. erroneous\nassumptions about TIF_SVE being clear in commit:\n\n 8383741ab2e773a9 ("KVM: arm64: Get rid of host SVE tracking/saving")\n\n... and so this eager save+flush probably needs to be backported to ALL\nstable trees.

In the Linux kernel, the following vulnerability has been resolved:\n\nRevert "arm64: dts: qcom: sdm845: Affirm IDR0.CCTW on apps_smmu"\n\nThere are reports that the pagetable walker cache coherency is not a\ngiven across the spectrum of SDM845/850 devices, leading to lock-ups\nand resets. It works fine on some devices (like the Dragonboard 845c,\nbut not so much on the Lenovo Yoga C630).\n\nThis unfortunately looks like a fluke in firmware development, where\nlikely somewhere in the vast hypervisor stack, a change to accommodate\nfor this was only introduced after the initial software release (which\noften serves as a baseline for products).\n\nRevert the change to avoid additional guesswork around crashes.\n\nThis reverts commit 6b31a9744b8726c69bb0af290f8475a368a4b805.

In the Linux kernel, the following vulnerability has been resolved:\n\nARM: dts: bcm2711: Fix xHCI power-domain\n\nDuring s2idle tests on the Raspberry CM4 the VPU firmware always crashes\non xHCI power-domain resume:\n\nroot@raspberrypi:/sys/power# echo freeze > state\n[ 70.724347] xhci_suspend finished\n[ 70.727730] xhci_plat_suspend finished\n[ 70.755624] bcm2835-power bcm2835-power: Power grafx off\n[ 70.761127] USB: Set power to 0\n\n[ 74.653040] USB: Failed to set power to 1 (-110)\n\nThis seems to be caused because of the mixed usage of\nraspberrypi-power and bcm2835-power at the same time. So avoid\nthe usage of the VPU firmware power-domain driver, which\nprevents the VPU crash.

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/hns: Fix soft lockup during bt pages loop\n\nDriver runs a for-loop when allocating bt pages and mapping them with\nbuffer pages. When a large buffer (e.g. MR over 100GB) is being allocated,\nit may require a considerable loop count. This will lead to soft lockup:\n\n watchdog: BUG: soft lockup - CPU#27 stuck for 22s!\n ...\n Call trace:\n hem_list_alloc_mid_bt+0x124/0x394 [hns_roce_hw_v2]\n hns_roce_hem_list_request+0xf8/0x160 [hns_roce_hw_v2]\n hns_roce_mtr_create+0x2e4/0x360 [hns_roce_hw_v2]\n alloc_mr_pbl+0xd4/0x17c [hns_roce_hw_v2]\n hns_roce_reg_user_mr+0xf8/0x190 [hns_roce_hw_v2]\n ib_uverbs_reg_mr+0x118/0x290\n\n watchdog: BUG: soft lockup - CPU#35 stuck for 23s!\n ...\n Call trace:\n hns_roce_hem_list_find_mtt+0x7c/0xb0 [hns_roce_hw_v2]\n mtr_map_bufs+0xc4/0x204 [hns_roce_hw_v2]\n hns_roce_mtr_create+0x31c/0x3c4 [hns_roce_hw_v2]\n alloc_mr_pbl+0xb0/0x160 [hns_roce_hw_v2]\n hns_roce_reg_user_mr+0x108/0x1c0 [hns_roce_hw_v2]\n ib_uverbs_reg_mr+0x120/0x2bc\n\nAdd a cond_resched() to fix soft lockup during these loops. In order not\nto affect the allocation performance of normal-size buffer, set the loop\ncount of a 100GB MR as the threshold to call cond_resched().

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Fix error code in chan_alloc_skb_cb()\n\nThe chan_alloc_skb_cb() function is supposed to return error pointers on\nerror. Returning NULL will lead to a NULL dereference.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ethernet: ti: am65-cpsw: Fix NAPI registration sequence\n\nRegistering the interrupts for TX or RX DMA Channels prior to registering\ntheir respective NAPI callbacks can result in a NULL pointer dereference.\nThis is seen in practice as a random occurrence since it depends on the\nrandomness associated with the generation of traffic by Linux and the\nreception of traffic from the wire.

In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw().\n\nfib_check_nh_v6_gw() expects that fib6_nh_init() cleans up everything\nwhen it fails.\n\nCommit 7dd73168e273 ("ipv6: Always allocate pcpu memory in a fib6_nh")\nmoved fib_nh_common_init() before alloc_percpu_gfp() within fib6_nh_init()\nbut forgot to add cleanup for fib6_nh->nh_common.nhc_pcpu_rth_output in\ncase it fails to allocate fib6_nh->rt6i_pcpu, resulting in memleak.\n\nLet's call fib_nh_common_release() and clear nhc_pcpu_rth_output in the\nerror path.\n\nNote that we can remove the fib6_nh_release() call in nh_create_ipv6()\nlater in net-next.git.

In the Linux kernel, the following vulnerability has been resolved:\n\ncan: ucan: fix out of bound read in strscpy() source\n\nCommit 7fdaf8966aae ("can: ucan: use strscpy() to instead of strncpy()")\nunintentionally introduced a one byte out of bound read on strscpy()'s\nsource argument (which is kind of ironic knowing that strscpy() is meant\nto be a more secure alternative :)).\n\nLet's consider below buffers:\n\n dest[len + 1]; /* will be NUL terminated */\n src[len]; /* may not be NUL terminated */\n\nWhen doing:\n\n strncpy(dest, src, len);\n dest[len] = '\\0';\n\nstrncpy() will read up to len bytes from src.\n\nOn the other hand:\n\n strscpy(dest, src, len + 1);\n\nwill read up to len + 1 bytes from src, that is to say, an out of bound\nread of one byte will occur on src if it is not NUL terminated. Note\nthat the src[len] byte is never copied, but strscpy() still needs to\nread it to check whether a truncation occurred or not.\n\nThis exact pattern happened in ucan.\n\nThe root cause is that the source is not NUL terminated. Instead of\ndoing a copy in a local buffer, directly NUL terminate it as soon as\nusb_control_msg() returns. With this, the local firmware_str[] variable\ncan be removed.\n\nOn top of this do a couple refactors:\n\n - ucan_ctl_payload->raw is only used for the firmware string, so\n rename it to ucan_ctl_payload->fw_str and change its type from u8 to\n char.\n\n - ucan_device_request_in() is only used to retrieve the firmware\n string, so rename it to ucan_get_fw_str() and refactor it to make it\n directly handle all the string termination logic.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: Call `invalidate_cache` only if implemented\n\nMany filesystems such as NFS and Ceph do not implement the\n`invalidate_cache` method. On those filesystems, if writing to the\ncache (`NETFS_WRITE_TO_CACHE`) fails for some reason, the kernel\ncrashes like this:\n\n BUG: kernel NULL pointer dereference, address: 0000000000000000\n #PF: supervisor instruction fetch in kernel mode\n #PF: error_code(0x0010) - not-present page\n PGD 0 P4D 0\n Oops: Oops: 0010 [#1] SMP PTI\n CPU: 9 UID: 0 PID: 3380 Comm: kworker/u193:11 Not tainted 6.13.3-cm4all1-hp #437\n Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/17/2018\n Workqueue: events_unbound netfs_write_collection_worker\n RIP: 0010:0x0\n Code: Unable to access opcode bytes at 0xffffffffffffffd6.\n RSP: 0018:ffff9b86e2ca7dc0 EFLAGS: 00010202\n RAX: 0000000000000000 RBX: 0000000000000000 RCX: 7fffffffffffffff\n RDX: 0000000000000001 RSI: ffff89259d576a18 RDI: ffff89259d576900\n RBP: ffff89259d5769b0 R08: ffff9b86e2ca7d28 R09: 0000000000000002\n R10: ffff89258ceaca80 R11: 0000000000000001 R12: 0000000000000020\n R13: ffff893d158b9338 R14: ffff89259d576900 R15: ffff89259d5769b0\n FS: 0000000000000000(0000) GS:ffff893c9fa40000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: ffffffffffffffd6 CR3: 000000054442e003 CR4: 00000000001706f0\n Call Trace:\n <TASK>\n ? __die+0x1f/0x60\n ? page_fault_oops+0x15c/0x460\n ? try_to_wake_up+0x2d2/0x530\n ? exc_page_fault+0x5e/0x100\n ? asm_exc_page_fault+0x22/0x30\n netfs_write_collection_worker+0xe9f/0x12b0\n ? xs_poll_check_readable+0x3f/0x80\n ? xs_stream_data_receive_workfn+0x8d/0x110\n process_one_work+0x134/0x2d0\n worker_thread+0x299/0x3a0\n ? __pfx_worker_thread+0x10/0x10\n kthread+0xba/0xe0\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x30/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n </TASK>\n Modules linked in:\n CR2: 0000000000000000\n\nThis patch adds the missing `NULL` check.

In the Linux kernel, the following vulnerability has been resolved:\n\naccel/qaic: Fix integer overflow in qaic_validate_req()\n\nThese are u64 variables that come from the user via\nqaic_attach_slice_bo_ioctl(). Use check_add_overflow() to ensure that\nthe math doesn't have an integer wrapping bug.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm/huge_memory: drop beyond-EOF folios with the right number of refs\n\nWhen an after-split folio is large and needs to be dropped due to EOF,\nfolio_put_refs(folio, folio_nr_pages(folio)) should be used to drop all\npage cache refs. Otherwise, the folio will not be freed, causing memory\nleak.\n\nThis leak would happen on a filesystem with blocksize > page_size and a\ntruncate is performed, where the blocksize makes folios split to >0 order\nones, causing truncated folios not being freed.

In the Linux kernel, the following vulnerability has been resolved:\n\nproc: fix UAF in proc_get_inode()\n\nFix race between rmmod and /proc/XXX's inode instantiation.\n\nThe bug is that pde->proc_ops don't belong to /proc, it belongs to a\nmodule, therefore dereferencing it after /proc entry has been registered\nis a bug unless use_pde/unuse_pde() pair has been used.\n\nuse_pde/unuse_pde can be avoided (2 atomic ops!) because pde->proc_ops\nnever changes so information necessary for inode instantiation can be\nsaved _before_ proc_register() in PDE itself and used later, avoiding\npde->proc_ops->... dereference.\n\n rmmod lookup\nsys_delete_module\n proc_lookup_de\n pde_get(de);\n proc_get_inode(dir->i_sb, de);\n mod->exit()\n proc_remove\n remove_proc_subtree\n proc_entry_rundown(de);\n free_module(mod);\n\n if (S_ISREG(inode->i_mode))\n if (de->proc_ops->proc_read_iter)\n --> As module is already freed, will trigger UAF\n\nBUG: unable to handle page fault for address: fffffbfff80a702b\nPGD 817fc4067 P4D 817fc4067 PUD 817fc0067 PMD 102ef4067 PTE 0\nOops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 26 UID: 0 PID: 2667 Comm: ls Tainted: G\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996)\nRIP: 0010:proc_get_inode+0x302/0x6e0\nRSP: 0018:ffff88811c837998 EFLAGS: 00010a06\nRAX: dffffc0000000000 RBX: ffffffffc0538140 RCX: 0000000000000007\nRDX: 1ffffffff80a702b RSI: 0000000000000001 RDI: ffffffffc0538158\nRBP: ffff8881299a6000 R08: 0000000067bbe1e5 R09: 1ffff11023906f20\nR10: ffffffffb560ca07 R11: ffffffffb2b43a58 R12: ffff888105bb78f0\nR13: ffff888100518048 R14: ffff8881299a6004 R15: 0000000000000001\nFS: 00007f95b9686840(0000) GS:ffff8883af100000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: fffffbfff80a702b CR3: 0000000117dd2000 CR4: 00000000000006f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \n proc_lookup_de+0x11f/0x2e0\n __lookup_slow+0x188/0x350\n walk_component+0x2ab/0x4f0\n path_lookupat+0x120/0x660\n filename_lookup+0x1ce/0x560\n vfs_statx+0xac/0x150\n __do_sys_newstat+0x96/0x110\n do_syscall_64+0x5f/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n[adobriyan@gmail.com: don't do 2 atomic ops on the common path]

In the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: qcom: uefisecapp: fix efivars registration race\n\nSince the conversion to using the TZ allocator, the efivars service is\nregistered before the memory pool has been allocated, something which\ncan lead to a NULL-pointer dereference in case of a racing EFI variable\naccess.\n\nMake sure that all resources have been set up before registering the\nefivars.

In the Linux kernel, the following vulnerability has been resolved:\n\nxsk: fix an integer overflow in xp_create_and_assign_umem()\n\nSince the i and pool->chunk_size variables are of type 'u32',\ntheir product can wrap around and then be cast to 'u64'.\nThis can lead to two different XDP buffers pointing to the same\nmemory area.\n\nFound by InfoTeCS on behalf of Linux Verification Center\n(linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix incorrect validation for num_aces field of smb_acl\n\nparse_dcal() validate num_aces to allocate posix_ace_state_array.\n\nif (num_aces > ULONG_MAX / sizeof(struct smb_ace *))\n\nIt is an incorrect validation that we can create an array of size ULONG_MAX.\nsmb_acl has ->size field to calculate actual number of aces in request buffer\nsize. Use this to check invalid num_aces.

In the Linux kernel, the following vulnerability has been resolved:\n\niscsi_ibft: Fix UBSAN shift-out-of-bounds warning in ibft_attr_show_nic()\n\nWhen performing an iSCSI boot using IPv6, iscsistart still reads the\n/sys/firmware/ibft/ethernetX/subnet-mask entry. Since the IPv6 prefix\nlength is 64, this causes the shift exponent to become negative,\ntriggering a UBSAN warning. As the concept of a subnet mask does not\napply to IPv6, the value is set to ~0 to suppress the warning message.

In the Linux kernel, the following vulnerability has been resolved:\n\nx86/microcode/AMD: Fix out-of-bounds on systems with CPU-less NUMA nodes\n\nCurrently, load_microcode_amd() iterates over all NUMA nodes, retrieves their\nCPU masks and unconditionally accesses per-CPU data for the first CPU of each\nmask.\n\nAccording to Documentation/admin-guide/mm/numaperf.rst:\n\n "Some memory may share the same node as a CPU, and others are provided as\n memory only nodes."\n\nTherefore, some node CPU masks may be empty and wouldn't have a "first CPU".\n\nOn a machine with far memory (and therefore CPU-less NUMA nodes):\n- cpumask_of_node(nid) is 0\n- cpumask_first(0) is CONFIG_NR_CPUS\n- cpu_data(CONFIG_NR_CPUS) accesses the cpu_info per-CPU array at an\n index that is 1 out of bounds\n\nThis does not have any security implications since flashing microcode is\na privileged operation but I believe this has reliability implications by\npotentially corrupting memory while flashing a microcode update.\n\nWhen booting with CONFIG_UBSAN_BOUNDS=y on an AMD machine that flashes\na microcode update. I get the following splat:\n\n UBSAN: array-index-out-of-bounds in arch/x86/kernel/cpu/microcode/amd.c:X:Y\n index 512 is out of range for type 'unsigned long[512]'\n [...]\n Call Trace:\n dump_stack\n __ubsan_handle_out_of_bounds\n load_microcode_amd\n request_microcode_amd\n reload_store\n kernfs_fop_write_iter\n vfs_write\n ksys_write\n do_syscall_64\n entry_SYSCALL_64_after_hwframe\n\nChange the loop to go over only NUMA nodes which have CPUs before determining\nwhether the first CPU on the respective node needs microcode update.\n\n [ bp: Massage commit message, fix typo. ]

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: NULL-check BO's backing store when determining GFX12 PTE flags\n\nPRT BOs may not have any backing store, so bo->tbo.resource will be\nNULL. Check for that before dereferencing.\n\n(cherry picked from commit 3e3fcd29b505cebed659311337ea03b7698767fc)

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: fix missing .is_two_pixels_per_container\n\nStarting from 6.11, AMDGPU driver, while being loaded with amdgpu.dc=1,\ndue to lack of .is_two_pixels_per_container function in dce60_tg_funcs,\ncauses a NULL pointer dereference on PCs with old GPUs, such as R9 280X.\n\nSo this fix adds missing .is_two_pixels_per_container to dce60_tg_funcs.\n\n(cherry picked from commit bd4b125eb949785c6f8a53b0494e32795421209d)

In the Linux kernel, the following vulnerability has been resolved:\n\nfs/netfs/read_collect: add to next->prev_donated\n\nIf multiple subrequests donate data to the same "next" request\n(depending on the subrequest completion order), each of them would\noverwrite the `prev_donated` field, causing data corruption and a\nBUG() crash ("Can't donate prior to front").

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: init return value in amdgpu_ttm_clear_buffer\n\nOtherwise an uninitialized value can be returned if\namdgpu_res_cleared returns true for all regions.\n\nPossibly closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3812\n\n(cherry picked from commit 7c62aacc3b452f73a1284198c81551035fac6d71)

In the Linux kernel, the following vulnerability has been resolved:\n\nsched: address a potential NULL pointer dereference in the GRED scheduler.\n\nIf kzalloc in gred_init returns a NULL pointer, the code follows the\nerror handling path, invoking gred_destroy. This, in turn, calls\ngred_offload, where memset could receive a NULL pointer as input,\npotentially leading to a kernel crash.\n\nWhen table->opt is NULL in gred_init(), gred_change_table_def()\nis not called yet, so it is not necessary to call ->ndo_setup_tc()\nin gred_offload().

In the Linux kernel, the following vulnerability has been resolved:\n\nsched_ext: Validate prev_cpu in scx_bpf_select_cpu_dfl()\n\nIf a BPF scheduler provides an invalid CPU (outside the nr_cpu_ids\nrange) as prev_cpu to scx_bpf_select_cpu_dfl() it can cause a kernel\ncrash.\n\nTo prevent this, validate prev_cpu in scx_bpf_select_cpu_dfl() and\ntrigger an scx error if an invalid CPU is specified.

In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Fix integer overflow while processing acregmax mount option\n\nUser-provided mount parameter acregmax of type u32 is intended to have\nan upper limit, but before it is validated, the value is converted from\nseconds to jiffies which can lead to an integer overflow.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:\n\nRevert "openvswitch: switch to per-action label counting in conntrack"\n\nCurrently, ovs_ct_set_labels() is only called for confirmed conntrack\nentries (ct) within ovs_ct_commit(). However, if the conntrack entry\ndoes not have the labels_ext extension, attempting to allocate it in\novs_ct_get_conn_labels() for a confirmed entry triggers a warning in\nnf_ct_ext_add():\n\n WARN_ON(nf_ct_is_confirmed(ct));\n\nThis happens when the conntrack entry is created externally before OVS\nincrements net->ct.labels_used. The issue has become more likely since\ncommit fcb1aa5163b1 ("openvswitch: switch to per-action label counting\nin conntrack"), which changed to use per-action label counting and\nincrement net->ct.labels_used when a flow with ct action is added.\n\nSince there’s no straightforward way to fully resolve this issue at the\nmoment, this reverts the commit to avoid breaking existing use cases.

In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix 'scheduling while atomic' in mptcp_pm_nl_append_new_local_addr\n\nIf multiple connection requests attempt to create an implicit mptcp\nendpoint in parallel, more than one caller may end up in\nmptcp_pm_nl_append_new_local_addr because none found the address in\nlocal_addr_list during their call to mptcp_pm_nl_get_local_id. In this\ncase, the concurrent new_local_addr calls may delete the address entry\ncreated by the previous caller. These deletes use synchronize_rcu, but\nthis is not permitted in some of the contexts where this function may be\ncalled. During packet recv, the caller may be in a rcu read critical\nsection and have preemption disabled.\n\nAn example stack:\n\n BUG: scheduling while atomic: swapper/2/0/0x00000302\n\n Call Trace:\n <IRQ>\n dump_stack_lvl (lib/dump_stack.c:117 (discriminator 1))\n dump_stack (lib/dump_stack.c:124)\n __schedule_bug (kernel/sched/core.c:5943)\n schedule_debug.constprop.0 (arch/x86/include/asm/preempt.h:33 kernel/sched/core.c:5970)\n __schedule (arch/x86/include/asm/jump_label.h:27 include/linux/jump_label.h:207 kernel/sched/features.h:29 kernel/sched/core.c:6621)\n schedule (arch/x86/include/asm/preempt.h:84 kernel/sched/core.c:6804 kernel/sched/core.c:6818)\n schedule_timeout (kernel/time/timer.c:2160)\n wait_for_completion (kernel/sched/completion.c:96 kernel/sched/completion.c:116 kernel/sched/completion.c:127 kernel/sched/completion.c:148)\n __wait_rcu_gp (include/linux/rcupdate.h:311 kernel/rcu/update.c:444)\n synchronize_rcu (kernel/rcu/tree.c:3609)\n mptcp_pm_nl_append_new_local_addr (net/mptcp/pm_netlink.c:966 net/mptcp/pm_netlink.c:1061)\n mptcp_pm_nl_get_local_id (net/mptcp/pm_netlink.c:1164)\n mptcp_pm_get_local_id (net/mptcp/pm.c:420)\n subflow_check_req (net/mptcp/subflow.c:98 net/mptcp/subflow.c:213)\n subflow_v4_route_req (net/mptcp/subflow.c:305)\n tcp_conn_request (net/ipv4/tcp_input.c:7216)\n subflow_v4_conn_request (net/mptcp/subflow.c:651)\n tcp_rcv_state_process (net/ipv4/tcp_input.c:6709)\n tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1934)\n tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2334)\n ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205 (discriminator 1))\n ip_local_deliver_finish (include/linux/rcupdate.h:813 net/ipv4/ip_input.c:234)\n ip_local_deliver (include/linux/netfilter.h:314 include/linux/netfilter.h:308 net/ipv4/ip_input.c:254)\n ip_sublist_rcv_finish (include/net/dst.h:461 net/ipv4/ip_input.c:580)\n ip_sublist_rcv (net/ipv4/ip_input.c:640)\n ip_list_rcv (net/ipv4/ip_input.c:675)\n __netif_receive_skb_list_core (net/core/dev.c:5583 net/core/dev.c:5631)\n netif_receive_skb_list_internal (net/core/dev.c:5685 net/core/dev.c:5774)\n napi_complete_done (include/linux/list.h:37 include/net/gro.h:449 include/net/gro.h:444 net/core/dev.c:6114)\n igb_poll (drivers/net/ethernet/intel/igb/igb_main.c:8244) igb\n __napi_poll (net/core/dev.c:6582)\n net_rx_action (net/core/dev.c:6653 net/core/dev.c:6787)\n handle_softirqs (kernel/softirq.c:553)\n __irq_exit_rcu (kernel/softirq.c:588 kernel/softirq.c:427 kernel/softirq.c:636)\n irq_exit_rcu (kernel/softirq.c:651)\n common_interrupt (arch/x86/kernel/irq.c:247 (discriminator 14))\n </IRQ>\n\nThis problem seems particularly prevalent if the user advertises an\nendpoint that has a different external vs internal address. In the case\nwhere the external address is advertised and multiple connections\nalready exist, multiple subflow SYNs arrive in parallel which tends to\ntrigger the race during creation of the first local_addr_list entries\nwhich have the internal address instead.\n\nFix by skipping the replacement of an existing implicit local address if\ncalled via mptcp_pm_nl_get_local_id.

In the Linux kernel, the following vulnerability has been resolved:\n\nacpi: typec: ucsi: Introduce a ->poll_cci method\n\nFor the ACPI backend of UCSI the UCSI "registers" are just a memory copy\nof the register values in an opregion. The ACPI implementation in the\nBIOS ensures that the opregion contents are synced to the embedded\ncontroller and it ensures that the registers (in particular CCI) are\nsynced back to the opregion on notifications. While there is an ACPI call\nthat syncs the actual registers to the opregion there is rarely a need to\ndo this and on some ACPI implementations it actually breaks in various\ninteresting ways.\n\nThe only reason to force a sync from the embedded controller is to poll\nCCI while notifications are disabled. Only the ucsi core knows if this\nis the case and guessing based on the current command is suboptimal, i.e.\nleading to the following spurious assertion splat:\n\nWARNING: CPU: 3 PID: 76 at drivers/usb/typec/ucsi/ucsi.c:1388 ucsi_reset_ppm+0x1b4/0x1c0 [typec_ucsi]\nCPU: 3 UID: 0 PID: 76 Comm: kworker/3:0 Not tainted 6.12.11-200.fc41.x86_64 #1\nHardware name: LENOVO 21D0/LNVNB161216, BIOS J6CN45WW 03/17/2023\nWorkqueue: events_long ucsi_init_work [typec_ucsi]\nRIP: 0010:ucsi_reset_ppm+0x1b4/0x1c0 [typec_ucsi]\nCall Trace:\n <TASK>\n ucsi_init_work+0x3c/0xac0 [typec_ucsi]\n process_one_work+0x179/0x330\n worker_thread+0x252/0x390\n kthread+0xd2/0x100\n ret_from_fork+0x34/0x50\n ret_from_fork_asm+0x1a/0x30\n </TASK>\n\nThus introduce a ->poll_cci() method that works like ->read_cci() with an\nadditional forced sync and document that this should be used when polling\nwith notifications disabled. For all other backends that presumably don't\nhave this issue use the same implementation for both methods.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ufs: core: bsg: Fix crash when arpmb command fails\n\nIf the device doesn't support arpmb we'll crash due to copying user data in\nbsg_transport_sg_io_fn().\n\nIn the case where ufs_bsg_exec_advanced_rpmb_req() returns an error, do not\nset the job's reply_len.\n\nMemory crash backtrace:\n3,1290,531166405,-;ufshcd 0000:00:12.5: ARPMB OP failed: error code -22\n\n4,1308,531166555,-;Call Trace:\n\n4,1309,531166559,-; <TASK>\n\n4,1310,531166565,-; ? show_regs+0x6d/0x80\n\n4,1311,531166575,-; ? die+0x37/0xa0\n\n4,1312,531166583,-; ? do_trap+0xd4/0xf0\n\n4,1313,531166593,-; ? do_error_trap+0x71/0xb0\n\n4,1314,531166601,-; ? usercopy_abort+0x6c/0x80\n\n4,1315,531166610,-; ? exc_invalid_op+0x52/0x80\n\n4,1316,531166622,-; ? usercopy_abort+0x6c/0x80\n\n4,1317,531166630,-; ? asm_exc_invalid_op+0x1b/0x20\n\n4,1318,531166643,-; ? usercopy_abort+0x6c/0x80\n\n4,1319,531166652,-; __check_heap_object+0xe3/0x120\n\n4,1320,531166661,-; check_heap_object+0x185/0x1d0\n\n4,1321,531166670,-; __check_object_size.part.0+0x72/0x150\n\n4,1322,531166679,-; __check_object_size+0x23/0x30\n\n4,1323,531166688,-; bsg_transport_sg_io_fn+0x314/0x3b0

In the Linux kernel, the following vulnerability has been resolved:\n\ncpufreq/amd-pstate: Fix cpufreq_policy ref counting\n\namd_pstate_update_limits() takes a cpufreq_policy reference but doesn't\ndecrement the refcount in one of the exit paths, fix that.

In the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: Avoid use of NULL after WARN_ON_ONCE\n\nThere is a WARN_ON_ONCE to catch an unlikely situation when\ndomain_remove_dev_pasid can't find the `pasid`. In case it nevertheless\nhappens we must avoid using a NULL pointer.

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()\n\nThe documentation for usb_driver_claim_interface() says that "the\ndevice lock" is needed when the function is called from places other\nthan probe(). This appears to be the lock for the USB interface\ndevice. The Mediatek btusb code gets called via this path:\n\n Workqueue: hci0 hci_power_on [bluetooth]\n Call trace:\n usb_driver_claim_interface\n btusb_mtk_claim_iso_intf\n btusb_mtk_setup\n hci_dev_open_sync\n hci_power_on\n process_scheduled_works\n worker_thread\n kthread\n\nWith the above call trace the device lock hasn't been claimed. Claim\nit.\n\nWithout this fix, we'd sometimes see the error "Failed to claim iso\ninterface". Sometimes we'd even see worse errors, like a NULL pointer\ndereference (where `intf->dev.driver` was NULL) with a trace like:\n\n Call trace:\n usb_suspend_both\n usb_runtime_suspend\n __rpm_callback\n rpm_suspend\n pm_runtime_work\n process_scheduled_works\n\nBoth errors appear to be fixed with the proper locking.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: let net.core.dev_weight always be non-zero\n\nThe following problem was encountered during stability test:\n\n(NULL net_device): NAPI poll function process_backlog+0x0/0x530 \\\n returned 1, exceeding its budget of 0.\n------------[ cut here ]------------\nlist_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, \\\n next=ffff88905f746e40.\nWARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 \\\n __list_add_valid_or_report+0xf3/0x130\nCPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+\nRIP: 0010:__list_add_valid_or_report+0xf3/0x130\nCall Trace:\n? __warn+0xcd/0x250\n? __list_add_valid_or_report+0xf3/0x130\nenqueue_to_backlog+0x923/0x1070\nnetif_rx_internal+0x92/0x2b0\n__netif_rx+0x15/0x170\nloopback_xmit+0x2ef/0x450\ndev_hard_start_xmit+0x103/0x490\n__dev_queue_xmit+0xeac/0x1950\nip_finish_output2+0x6cc/0x1620\nip_output+0x161/0x270\nip_push_pending_frames+0x155/0x1a0\nraw_sendmsg+0xe13/0x1550\n__sys_sendto+0x3bf/0x4e0\n__x64_sys_sendto+0xdc/0x1b0\ndo_syscall_64+0x5b/0x170\nentry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe reproduction command is as follows:\n sysctl -w net.core.dev_weight=0\n ping 127.0.0.1\n\nThis is because when the napi's weight is set to 0, process_backlog() may\nreturn 0 and clear the NAPI_STATE_SCHED bit of napi->state, causing this\nnapi to be re-polled in net_rx_action() until __do_softirq() times out.\nSince the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() can\nbe retriggered in enqueue_to_backlog(), causing this issue.\n\nMaking the napi's weight always non-zero solves this problem.\n\nTriggering this issue requires system-wide admin (setting is\nnot namespaced).

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rtrs: Add missing deinit() call\n\nA warning is triggered when repeatedly connecting and disconnecting the\nrnbd:\n list_add corruption. prev->next should be next (ffff88800b13e480), but was ffff88801ecd1338. (prev=ffff88801ecd1340).\n WARNING: CPU: 1 PID: 36562 at lib/list_debug.c:32 __list_add_valid_or_report+0x7f/0xa0\n Workqueue: ib_cm cm_work_handler [ib_cm]\n RIP: 0010:__list_add_valid_or_report+0x7f/0xa0\n ? __list_add_valid_or_report+0x7f/0xa0\n ib_register_event_handler+0x65/0x93 [ib_core]\n rtrs_srv_ib_dev_init+0x29/0x30 [rtrs_server]\n rtrs_ib_dev_find_or_add+0x124/0x1d0 [rtrs_core]\n __alloc_path+0x46c/0x680 [rtrs_server]\n ? rtrs_rdma_connect+0xa6/0x2d0 [rtrs_server]\n ? rcu_is_watching+0xd/0x40\n ? __mutex_lock+0x312/0xcf0\n ? get_or_create_srv+0xad/0x310 [rtrs_server]\n ? rtrs_rdma_connect+0xa6/0x2d0 [rtrs_server]\n rtrs_rdma_connect+0x23c/0x2d0 [rtrs_server]\n ? __lock_release+0x1b1/0x2d0\n cma_cm_event_handler+0x4a/0x1a0 [rdma_cm]\n cma_ib_req_handler+0x3a0/0x7e0 [rdma_cm]\n cm_process_work+0x28/0x1a0 [ib_cm]\n ? _raw_spin_unlock_irq+0x2f/0x50\n cm_req_handler+0x618/0xa60 [ib_cm]\n cm_work_handler+0x71/0x520 [ib_cm]\n\nCommit 667db86bcbe8 ("RDMA/rtrs: Register ib event handler") introduced a\nnew element .deinit but never used it at all. Fix it by invoking the\n`deinit()` to appropriately unregister the IB event handler.

In the Linux kernel, the following vulnerability has been resolved:\npadata: fix UAF in padata_reorder\nA bug was found when run ltp test:\nBUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0\nRead of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206\nCPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+\nWorkqueue: pdecrypt_parallel padata_parallel_worker\nCall Trace:\n\ndump_stack_lvl+0x32/0x50\nprint_address_description.constprop.0+0x6b/0x3d0\nprint_report+0xdd/0x2c0\nkasan_report+0xa5/0xd0\npadata_find_next+0x29/0x1a0\npadata_reorder+0x131/0x220\npadata_parallel_worker+0x3d/0xc0\nprocess_one_work+0x2ec/0x5a0\nIf 'mdelay(10)' is added before calling 'padata_find_next' in the\n'padata_reorder' function, this issue could be reproduced easily with\nltp test (pcrypt_aead01).\nThis can be explained as bellow:\npcrypt_aead_encrypt\n...\npadata_do_parallel\nrefcount_inc(&pd->refcnt); // add refcnt\n...\npadata_do_serial\npadata_reorder // pd\nwhile (1) {\npadata_find_next(pd, true); // using pd\nqueue_work_on\n...\npadata_serial_workercrypto_del_alg\npadata_put_pd_cnt // sub refcnt\npadata_free_shell\npadata_put_pd(ps->pd);\n// pd is freed\n// loop again, but pd is freed\n// call padata_find_next, UAF\n}\nIn the padata_reorder function, when it loops in 'while', if the alg is\ndeleted, the refcnt may be decreased to 0 before entering\n'padata_find_next', which leads to UAF.\nAs mentioned in [1], do_serial is supposed to be called with BHs disabled\nand always happen under RCU protection, to address this issue, add\nsynchronize_rcu() in 'padata_free_shell' wait for all _do_serial calls\nto finish.\n[1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/\n[2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/

In the Linux kernel, the following vulnerability has been resolved:\niommufd/iova_bitmap: Fix shift-out-of-bounds in iova_bitmap_offset_to_index()\nResolve a UBSAN shift-out-of-bounds issue in iova_bitmap_offset_to_index()\nwhere shifting the constant "1" (of type int) by bitmap->mapped.pgshift\n(an unsigned long value) could result in undefined behavior.\nThe constant "1" defaults to a 32-bit "int", and when "pgshift" exceeds\n31 (e.g., pgshift = 63) the shift operation overflows, as the result\ncannot be represented in a 32-bit type.\nTo resolve this, the constant is updated to "1UL", promoting it to an\nunsigned long type to match the operand's type.

A specially crafted filename containing a large number of spaces could obscure the file's extension when displayed in the download dialog.\n*This bug only affects Firefox for Android. Other versions of Firefox are unaffected.* This vulnerability affects Firefox < 131.

A user who enables full-screen mode on a specially crafted web page could potentially be prevented from exiting full screen mode. This may allow spoofing of other sites as the address bar is no longer visible.\n*This bug only affects Firefox Focus for Android. Other versions of Firefox are unaffected.* This vulnerability affects Firefox < 131.

A flaw was found in the freeimage library. Processing a crafted image can cause a buffer over-read of 1 byte in the read_iptc_profile function in the Source/Metadata/IPTC.cpp file because the size of the profile is not being sanitized, causing a crash in the application linked to the library, resulting in a denial of service.

Under certain conditions, an attacker with the ability to redirect users to a malicious site via an open redirect on a trusted site, may be able to spoof the address bar contents. This can lead to a malicious site to appear to have the same URL as the trusted site.\n*This bug only affects Firefox for Android. Other versions of Firefox are unaffected.* This vulnerability affects Firefox for Android < 130.0.1.

SPRT dissector crash in Wireshark 4.2.0 to 4.0.5 and 4.0.0 to 4.0.15 allows denial of service via packet injection or crafted capture file

A heap-based buffer overflow vulnerability was found in the libopensc OpenPGP driver. A crafted USB device or smart card with malicious responses to the APDUs during the card enrollment process using the `pkcs15-init` tool may lead to out-of-bound rights, possibly resulting in arbitrary code execution.

Incorrect garbage collection interaction could have led to a use-after-free. This vulnerability affects Firefox < 129.

A select option could partially obscure security prompts. This could be used by a malicious site to trick a user into granting permissions. \n*This issue only affects Android versions of Firefox.* This vulnerability affects Firefox < 129.

Memory safety bugs present in Firefox 127 and Thunderbird 127. 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 < 128 and Thunderbird < 128.

The frame iterator could get stuck in a loop when encountering certain wasm frames leading to incorrect stack traces. This vulnerability affects Firefox < 128 and Thunderbird < 128.

When almost out-of-memory an elliptic curve key which was never allocated could have been freed again. This vulnerability affects Firefox < 128 and Thunderbird < 128.

It was possible to move the cursor using pointerlock from an iframe. This allowed moving the cursor outside of the viewport and the Firefox window. This vulnerability affects Firefox < 128 and Thunderbird < 128.

It was possible to prevent a user from exiting pointerlock when pressing escape and to overlay customValidity notifications from a `<select>` element over certain permission prompts. This could be used to confuse a user into giving a site unintended permissions. This vulnerability affects Firefox < 128 and Thunderbird < 128.

Firefox Android allowed immediate interaction with permission prompts. This could be used for tapjacking. This vulnerability affects Firefox < 128.

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: consider that tail calls invalidate packet pointers\n\nTail-called programs could execute any of the helpers that invalidate\npacket pointers. Hence, conservatively assume that each tail call\ninvalidates packet pointers.\n\nMaking the change in bpf_helper_changes_pkt_data() automatically makes\nuse of check_cfg() logic that computes 'changes_pkt_data' effect for\nglobal sub-programs, such that the following program could be\nrejected:\n\n int tail_call(struct __sk_buff *sk)\n {\n bpf_tail_call_static(sk, &jmp_table, 0);\n return 0;\n }\n\n SEC("tc")\n int not_safe(struct __sk_buff *sk)\n {\n int *p = (void *)(long)sk->data;\n ... make p valid ...\n tail_call(sk);\n *p = 42; /* this is unsafe */\n ...\n }\n\nThe tc_bpf2bpf.c:subprog_tc() needs change: mark it as a function that\ncan invalidate packet pointers. Otherwise, it can't be freplaced with\ntailcall_freplace.c:entry_freplace() that does a tail call.

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: check changes_pkt_data property for extension programs\n\nWhen processing calls to global sub-programs, verifier decides whether\nto invalidate all packet pointers in current state depending on the\nchanges_pkt_data property of the global sub-program.\n\nBecause of this, an extension program replacing a global sub-program\nmust be compatible with changes_pkt_data property of the sub-program\nbeing replaced.\n\nThis commit:\n- adds changes_pkt_data flag to struct bpf_prog_aux:\n - this flag is set in check_cfg() for main sub-program;\n - in jit_subprogs() for other sub-programs;\n- modifies bpf_check_attach_btf_id() to check changes_pkt_data flag;\n- moves call to check_attach_btf_id() after the call to check_cfg(),\n because it needs changes_pkt_data flag to be set:\n\n bpf_check:\n ... ...\n - check_attach_btf_id resolve_pseudo_ldimm64\n resolve_pseudo_ldimm64 --> bpf_prog_is_offloaded\n bpf_prog_is_offloaded check_cfg\n check_cfg + check_attach_btf_id\n ... ...\n\nThe following fields are set by check_attach_btf_id():\n- env->ops\n- prog->aux->attach_btf_trace\n- prog->aux->attach_func_name\n- prog->aux->attach_func_proto\n- prog->aux->dst_trampoline\n- prog->aux->mod\n- prog->aux->saved_dst_attach_type\n- prog->aux->saved_dst_prog_type\n- prog->expected_attach_type\n\nNeither of these fields are used by resolve_pseudo_ldimm64() or\nbpf_prog_offload_verifier_prep() (for netronome and netdevsim\ndrivers), so the reordering is safe.

In the Linux kernel, the following vulnerability has been resolved:\n\nvmxnet3: Fix packet corruption in vmxnet3_xdp_xmit_frame\n\nAndrew and Nikolay reported connectivity issues with Cilium's service\nload-balancing in case of vmxnet3.\n\nIf a BPF program for native XDP adds an encapsulation header such as\nIPIP and transmits the packet out the same interface, then in case\nof vmxnet3 a corrupted packet is being sent and subsequently dropped\non the path.\n\nvmxnet3_xdp_xmit_frame() which is called e.g. via vmxnet3_run_xdp()\nthrough vmxnet3_xdp_xmit_back() calculates an incorrect DMA address:\n\n page = virt_to_page(xdpf->data);\n tbi->dma_addr = page_pool_get_dma_addr(page) +\n VMXNET3_XDP_HEADROOM;\n dma_sync_single_for_device(&adapter->pdev->dev,\n tbi->dma_addr, buf_size,\n DMA_TO_DEVICE);\n\nThe above assumes a fixed offset (VMXNET3_XDP_HEADROOM), but the XDP\nBPF program could have moved xdp->data. While the passed buf_size is\ncorrect (xdpf->len), the dma_addr needs to have a dynamic offset which\ncan be calculated as xdpf->data - (void *)xdpf, that is, xdp->data -\nxdp->data_hard_start.

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: track changes_pkt_data property for global functions\n\nWhen processing calls to certain helpers, verifier invalidates all\npacket pointers in a current state. For example, consider the\nfollowing program:\n\n __attribute__((__noinline__))\n long skb_pull_data(struct __sk_buff *sk, __u32 len)\n {\n return bpf_skb_pull_data(sk, len);\n }\n\n SEC("tc")\n int test_invalidate_checks(struct __sk_buff *sk)\n {\n int *p = (void *)(long)sk->data;\n if ((void *)(p + 1) > (void *)(long)sk->data_end) return TCX_DROP;\n skb_pull_data(sk, 0);\n *p = 42;\n return TCX_PASS;\n }\n\nAfter a call to bpf_skb_pull_data() the pointer 'p' can't be used\nsafely. See function filter.c:bpf_helper_changes_pkt_data() for a list\nof such helpers.\n\nAt the moment verifier invalidates packet pointers when processing\nhelper function calls, and does not traverse global sub-programs when\nprocessing calls to global sub-programs. This means that calls to\nhelpers done from global sub-programs do not invalidate pointers in\nthe caller state. E.g. the program above is unsafe, but is not\nrejected by verifier.\n\nThis commit fixes the omission by computing field\nbpf_subprog_info->changes_pkt_data for each sub-program before main\nverification pass.\nchanges_pkt_data should be set if:\n- subprogram calls helper for which bpf_helper_changes_pkt_data\n returns true;\n- subprogram calls a global function,\n for which bpf_subprog_info->changes_pkt_data should be set.\n\nThe verifier.c:check_cfg() pass is modified to compute this\ninformation. The commit relies on depth first instruction traversal\ndone by check_cfg() and absence of recursive function calls:\n- check_cfg() would eventually visit every call to subprogram S in a\n state when S is fully explored;\n- when S is fully explored:\n - every direct helper call within S is explored\n (and thus changes_pkt_data is set if needed);\n - every call to subprogram S1 called by S was visited with S1 fully\n explored (and thus S inherits changes_pkt_data from S1).\n\nThe downside of such approach is that dead code elimination is not\ntaken into account: if a helper call inside global function is dead\nbecause of current configuration, verifier would conservatively assume\nthat the call occurs for the purpose of the changes_pkt_data\ncomputation.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath11k: fix RCU stall while reaping monitor destination ring\n\nWhile processing the monitor destination ring, MSDUs are reaped from the\nlink descriptor based on the corresponding buf_id.\n\nHowever, sometimes the driver cannot obtain a valid buffer corresponding\nto the buf_id received from the hardware. This causes an infinite loop\nin the destination processing, resulting in a kernel crash.\n\nkernel log:\nath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309\nath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failed\nath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309\nath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failed\n\nFix this by skipping the problematic buf_id and reaping the next entry,\nreplacing the break with the next MSDU processing.\n\nTested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30\nTested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath11k: add srng->lock for ath11k_hal_srng_* in monitor mode\n\nath11k_hal_srng_* should be used with srng->lock to protect srng data.\n\nFor ath11k_dp_rx_mon_dest_process() and ath11k_dp_full_mon_process_rx(),\nthey use ath11k_hal_srng_* for many times but never call srng->lock.\n\nSo when running (full) monitor mode, warning will occur:\nRIP: 0010:ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k]\nCall Trace:\n ? ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k]\n ath11k_dp_rx_process_mon_status+0xc45/0x1190 [ath11k]\n ? idr_alloc_u32+0x97/0xd0\n ath11k_dp_rx_process_mon_rings+0x32a/0x550 [ath11k]\n ath11k_dp_service_srng+0x289/0x5a0 [ath11k]\n ath11k_pcic_ext_grp_napi_poll+0x30/0xd0 [ath11k]\n __napi_poll+0x30/0x1f0\n net_rx_action+0x198/0x320\n __do_softirq+0xdd/0x319\n\nSo add srng->lock for them to avoid such warnings.\n\nInorder to fetch the srng->lock, should change srng's definition from\n'void' to 'struct hal_srng'. And initialize them elsewhere to prevent\none line of code from being too long. This is consistent with other ring\nprocess functions, such as ath11k_dp_process_rx().\n\nTested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30\nTested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:\n\njfs: add check read-only before txBeginAnon() call\n\nAdded a read-only check before calling `txBeginAnon` in `extAlloc`\nand `extRecord`. This prevents modification attempts on a read-only\nmounted filesystem, avoiding potential errors or crashes.\n\nCall trace:\n txBeginAnon+0xac/0x154\n extAlloc+0xe8/0xdec fs/jfs/jfs_extent.c:78\n jfs_get_block+0x340/0xb98 fs/jfs/inode.c:248\n __block_write_begin_int+0x580/0x166c fs/buffer.c:2128\n __block_write_begin fs/buffer.c:2177 [inline]\n block_write_begin+0x98/0x11c fs/buffer.c:2236\n jfs_write_begin+0x44/0x88 fs/jfs/inode.c:299

In the Linux kernel, the following vulnerability has been resolved:\n\njfs: add check read-only before truncation in jfs_truncate_nolock()\n\nAdded a check for "read-only" mode in the `jfs_truncate_nolock`\nfunction to avoid errors related to writing to a read-only\nfilesystem.\n\nCall stack:\n\nblock_write_begin() {\n jfs_write_failed() {\n jfs_truncate() {\n jfs_truncate_nolock() {\n txEnd() {\n ...\n log = JFS_SBI(tblk->sb)->log;\n // (log == NULL)\n\nIf the `isReadOnly(ip)` condition is triggered in\n`jfs_truncate_nolock`, the function execution will stop, and no\nfurther data modification will occur. Instead, the `xtTruncate`\nfunction will be called with the "COMMIT_WMAP" flag, preventing\nmodifications in "read-only" mode.

In the Linux kernel, the following vulnerability has been resolved:\n\nPCI/ASPM: Fix link state exit during switch upstream function removal\n\nBefore 456d8aa37d0f ("PCI/ASPM: Disable ASPM on MFD function removal to\navoid use-after-free"), we would free the ASPM link only after the last\nfunction on the bus pertaining to the given link was removed.\n\nThat was too late. If function 0 is removed before sibling function,\nlink->downstream would point to free'd memory after.\n\nAfter above change, we freed the ASPM parent link state upon any function\nremoval on the bus pertaining to a given link.\n\nThat is too early. If the link is to a PCIe switch with MFD on the upstream\nport, then removing functions other than 0 first would free a link which\nstill remains parent_link to the remaining downstream ports.\n\nThe resulting GPFs are especially frequent during hot-unplug, because\npciehp removes devices on the link bus in reverse order.\n\nOn that switch, function 0 is the virtual P2P bridge to the internal bus.\nFree exactly when function 0 is removed -- before the parent link is\nobsolete, but after all subordinate links are gone.\n\n[kwilczynski: commit log]

In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix legacy client tracking initialization\n\nGet rid of the nfsd4_legacy_tracking_ops->init() call in\ncheck_for_legacy_methods(). That will be handled in the caller\n(nfsd4_client_tracking_init()). Otherwise, we'll wind up calling\nnfsd4_legacy_tracking_ops->init() twice, and the second time we'll\ntrigger the BUG_ON() in nfsd4_init_recdir().

In the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: qcom: scm: Fix missing read barrier in qcom_scm_get_tzmem_pool()\n\nCommit 2e4955167ec5 ("firmware: qcom: scm: Fix __scm and waitq\ncompletion variable initialization") introduced a write barrier in probe\nfunction to store global '__scm' variable. We all known barriers are\npaired (see memory-barriers.txt: "Note that write barriers should\nnormally be paired with read or address-dependency barriers"), therefore\naccessing it from concurrent contexts requires read barrier. Previous\ncommit added such barrier in qcom_scm_is_available(), so let's use that\ndirectly.\n\nLack of this read barrier can result in fetching stale '__scm' variable\nvalue, NULL, and dereferencing it.\n\nNote that barrier in qcom_scm_is_available() satisfies here the control\ndependency.

In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: Explicitly verify target vCPU is online in kvm_get_vcpu()\n\nExplicitly verify the target vCPU is fully online _prior_ to clamping the\nindex in kvm_get_vcpu(). If the index is "bad", the nospec clamping will\ngenerate '0', i.e. KVM will return vCPU0 instead of NULL.\n\nIn practice, the bug is unlikely to cause problems, as it will only come\ninto play if userspace or the guest is buggy or misbehaving, e.g. KVM may\nsend interrupts to vCPU0 instead of dropping them on the floor.\n\nHowever, returning vCPU0 when it shouldn't exist per online_vcpus is\nproblematic now that KVM uses an xarray for the vCPUs array, as KVM needs\nto insert into the xarray before publishing the vCPU to userspace (see\ncommit c5b077549136 ("KVM: Convert the kvm->vcpus array to a xarray")),\ni.e. before vCPU creation is guaranteed to succeed.\n\nAs a result, incorrectly providing access to vCPU0 will trigger a\nuse-after-free if vCPU0 is dereferenced and kvm_vm_ioctl_create_vcpu()\nbails out of vCPU creation due to an error and frees vCPU0. Commit\nafb2acb2e3a3 ("KVM: Fix vcpu_array[0] races") papered over that issue, but\nin doing so introduced an unsolvable teardown conundrum. Preventing\naccesses to vCPU0 before it's fully online will allow reverting commit\nafb2acb2e3a3, without re-introducing the vcpu_array[0] UAF race.

In the Linux kernel, the following vulnerability has been resolved:\n\nclk: mmp2: call pm_genpd_init() only after genpd.name is set\n\nSetting the genpd's struct device's name with dev_set_name() is\nhappening within pm_genpd_init(). If it remains NULL, things can blow up\nlater, such as when crafting the devfs hierarchy for the power domain:\n\n Unable to handle kernel NULL pointer dereference at virtual address 00000000 when read\n ...\n Call trace:\n strlen from start_creating+0x90/0x138\n start_creating from debugfs_create_dir+0x20/0x178\n debugfs_create_dir from genpd_debug_add.part.0+0x4c/0x144\n genpd_debug_add.part.0 from genpd_debug_init+0x74/0x90\n genpd_debug_init from do_one_initcall+0x5c/0x244\n do_one_initcall from kernel_init_freeable+0x19c/0x1f4\n kernel_init_freeable from kernel_init+0x1c/0x12c\n kernel_init from ret_from_fork+0x14/0x28\n\nBisecting tracks this crash back to commit 899f44531fe6 ("pmdomain: core:\nAdd GENPD_FLAG_DEV_NAME_FW flag"), which exchanges use of genpd->name\nwith dev_name(&genpd->dev) in genpd_debug_add.part().

In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: tegra - do not transfer req when tegra init fails\n\nThe tegra_cmac_init or tegra_sha_init function may return an error when\nmemory is exhausted. It should not transfer the request when they return\nan error.