In the Linux kernel, the following vulnerability has been resolved:\n\nthermal/drivers/cpufreq_cooling: Fix slab OOB issue\n\nSlab OOB issue is scanned by KASAN in cpu_power_to_freq().\nIf power is limited below the power of OPP0 in EM table,\nit will cause slab out-of-bound issue with negative array\nindex.\n\nReturn the lowest frequency if limited power cannot found\na suitable OPP in EM table to fix this issue.\n\nBacktrace:\n[<ffffffd02d2a37f0>] die+0x104/0x5ac\n[<ffffffd02d2a5630>] bug_handler+0x64/0xd0\n[<ffffffd02d288ce4>] brk_handler+0x160/0x258\n[<ffffffd02d281e5c>] do_debug_exception+0x248/0x3f0\n[<ffffffd02d284488>] el1_dbg+0x14/0xbc\n[<ffffffd02d75d1d4>] __kasan_report+0x1dc/0x1e0\n[<ffffffd02d75c2e0>] kasan_report+0x10/0x20\n[<ffffffd02d75def8>] __asan_report_load8_noabort+0x18/0x28\n[<ffffffd02e6fce5c>] cpufreq_power2state+0x180/0x43c\n[<ffffffd02e6ead80>] power_actor_set_power+0x114/0x1d4\n[<ffffffd02e6fac24>] allocate_power+0xaec/0xde0\n[<ffffffd02e6f9f80>] power_allocator_throttle+0x3ec/0x5a4\n[<ffffffd02e6ea888>] handle_thermal_trip+0x160/0x294\n[<ffffffd02e6edd08>] thermal_zone_device_check+0xe4/0x154\n[<ffffffd02d351cb4>] process_one_work+0x5e4/0xe28\n[<ffffffd02d352f44>] worker_thread+0xa4c/0xfac\n[<ffffffd02d360124>] kthread+0x33c/0x358\n[<ffffffd02d289940>] ret_from_fork+0xc/0x18

In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to avoid potential deadlock\n\nUsing f2fs_trylock_op() in f2fs_write_compressed_pages() to avoid potential\ndeadlock like we did in f2fs_write_single_data_page().

In the Linux kernel, the following vulnerability has been resolved:\n\nnetlabel: fix out-of-bounds memory accesses\n\nThere are two array out-of-bounds memory accesses, one in\ncipso_v4_map_lvl_valid(), the other in netlbl_bitmap_walk(). Both\nerrors are embarassingly simple, and the fixes are straightforward.\n\nAs a FYI for anyone backporting this patch to kernels prior to v4.8,\nyou'll want to apply the netlbl_bitmap_walk() patch to\ncipso_v4_bitmap_walk() as netlbl_bitmap_walk() doesn't exist before\nLinux v4.8.

ITS dissector crash in Wireshark 4.4.0 allows denial of service via packet injection or crafted capture file

There is a LOW severity vulnerability affecting CPython, specifically the\n'http.cookies' standard library module.\n\n\nWhen parsing cookies that contained backslashes for quoted characters in\nthe cookie value, the parser would use an algorithm with quadratic\ncomplexity, resulting in excess CPU resources being used while parsing the\nvalue.

libcurl's ASN1 parser has this utf8asn1str() function used for parsing an ASN.1 UTF-8 string. Itcan detect an invalid field and return error. Unfortunately, when doing so it also invokes `free()` on a 4 byte localstack buffer. Most modern malloc implementations detect this error and immediately abort. Some however accept the input pointer and add that memory to its list of available chunks. This leads to the overwriting of nearby stack memory. The content of the overwrite is decided by the `free()` implementation; likely to be memory pointers and a set of flags. The most likely outcome of exploting this flaw is a crash, although it cannot be ruled out that more serious results can be had in special circumstances.

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

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

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

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

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

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

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

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

JupyterLab extension template is a `copier` template for JupyterLab extensions. Repositories created using this template with `test` option include `update-integration-tests.yml` workflow which has an RCE vulnerability. Extension authors hosting their code on GitHub are urged to upgrade the template to the latest version. Users who made changes to `update-integration-tests.yml`, accept overwriting of this file and re-apply your changes later. Users may wish to temporarily disable GitHub Actions while working on the upgrade. We recommend rebasing all open pull requests from untrusted users as actions may run using the version from the `main` branch at the time when the pull request was created. Users who are upgrading from template version prior to 4.3.0 may wish to leave out proposed changes to the release workflow for now as it requires additional configuration.

In the Linux kernel, the following vulnerability has been resolved:\nbonding: fix xfrm real_dev null pointer dereference\nWe shouldn't set real_dev to NULL because packets can be in transit and\nxfrm might call xdo_dev_offload_ok() in parallel. All callbacks assume\nreal_dev is set.\nExample trace:\nkernel: BUG: unable to handle page fault for address: 0000000000001030\nkernel: bond0: (slave eni0np1): making interface the new active one\nkernel: #PF: supervisor write access in kernel mode\nkernel: #PF: error_code(0x0002) - not-present page\nkernel: PGD 0 P4D 0\nkernel: Oops: 0002 [#1] PREEMPT SMP\nkernel: CPU: 4 PID: 2237 Comm: ping Not tainted 6.7.7+ #12\nkernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014\nkernel: RIP: 0010:nsim_ipsec_offload_ok+0xc/0x20 [netdevsim]\nkernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA\nkernel: Code: e0 0f 0b 48 83 7f 38 00 74 de 0f 0b 48 8b 47 08 48 8b 37 48 8b 78 40 e9 b2 e5 9a d7 66 90 0f 1f 44 00 00 48 8b 86 80 02 00 00 <83> 80 30 10 00 00 01 b8 01 00 00 00 c3 0f 1f 80 00 00 00 00 0f 1f\nkernel: bond0: (slave eni0np1): making interface the new active one\nkernel: RSP: 0018:ffffabde81553b98 EFLAGS: 00010246\nkernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA\nkernel:\nkernel: RAX: 0000000000000000 RBX: ffff9eb404e74900 RCX: ffff9eb403d97c60\nkernel: RDX: ffffffffc090de10 RSI: ffff9eb404e74900 RDI: ffff9eb3c5de9e00\nkernel: RBP: ffff9eb3c0a42000 R08: 0000000000000010 R09: 0000000000000014\nkernel: R10: 7974203030303030 R11: 3030303030303030 R12: 0000000000000000\nkernel: R13: ffff9eb3c5de9e00 R14: ffffabde81553cc8 R15: ffff9eb404c53000\nkernel: FS: 00007f2a77a3ad00(0000) GS:ffff9eb43bd00000(0000) knlGS:0000000000000000\nkernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nkernel: CR2: 0000000000001030 CR3: 00000001122ab000 CR4: 0000000000350ef0\nkernel: bond0: (slave eni0np1): making interface the new active one\nkernel: Call Trace:\nkernel: \nkernel: ? __die+0x1f/0x60\nkernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA\nkernel: ? page_fault_oops+0x142/0x4c0\nkernel: ? do_user_addr_fault+0x65/0x670\nkernel: ? kvm_read_and_reset_apf_flags+0x3b/0x50\nkernel: bond0: (slave eni0np1): making interface the new active one\nkernel: ? exc_page_fault+0x7b/0x180\nkernel: ? asm_exc_page_fault+0x22/0x30\nkernel: ? nsim_bpf_uninit+0x50/0x50 [netdevsim]\nkernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA\nkernel: ? nsim_ipsec_offload_ok+0xc/0x20 [netdevsim]\nkernel: bond0: (slave eni0np1): making interface the new active one\nkernel: bond_ipsec_offload_ok+0x7b/0x90 [bonding]\nkernel: xfrm_output+0x61/0x3b0\nkernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA\nkernel: ip_push_pending_frames+0x56/0x80

In the Linux kernel, the following vulnerability has been resolved:\nnetfilter: bridge: replace physindev with physinif in nf_bridge_info\nAn skb can be added to a neigh->arp_queue while waiting for an arp\nreply. Where original skb's skb->dev can be different to neigh's\nneigh->dev. For instance in case of bridging dnated skb from one veth to\nanother, the skb would be added to a neigh->arp_queue of the bridge.\nAs skb->dev can be reset back to nf_bridge->physindev and used, and as\nthere is no explicit mechanism that prevents this physindev from been\nfreed under us (for instance neigh_flush_dev doesn't cleanup skbs from\ndifferent device's neigh queue) we can crash on e.g. this stack:\narp_process\nneigh_update\nskb = __skb_dequeue(&neigh->arp_queue)\nneigh_resolve_output(..., skb)\n...\nbr_nf_dev_xmit\nbr_nf_pre_routing_finish_bridge_slow\nskb->dev = nf_bridge->physindev\nbr_handle_frame_finish\nLet's use plain ifindex instead of net_device link. To peek into the\noriginal net_device we will use dev_get_by_index_rcu(). Thus either we\nget device and are safe to use it or we don't get it and drop skb.

In the Linux kernel, the following vulnerability has been resolved:\n\nlib/generic-radix-tree.c: Fix rare race in __genradix_ptr_alloc()\n\nIf we need to increase the tree depth, allocate a new node, and then\nrace with another thread that increased the tree depth before us, we'll\nstill have a preallocated node that might be used later.\n\nIf we then use that node for a new non-root node, it'll still have a\npointer to the old root instead of being zeroed - fix this by zeroing it\nin the cmpxchg failure path.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: flowtable: initialise extack before use\n\nFix missing initialisation of extack in flow offload.

In the Linux kernel, the following vulnerability has been resolved:\n\nbonding: fix null pointer deref in bond_ipsec_offload_ok\n\nWe must check if there is an active slave before dereferencing the pointer.

In the Linux kernel, the following vulnerability has been resolved:\n\nsctp: Fix null-ptr-deref in reuseport_add_sock().\n\nsyzbot reported a null-ptr-deref while accessing sk2->sk_reuseport_cb in\nreuseport_add_sock(). [0]\n\nThe repro first creates a listener with SO_REUSEPORT. Then, it creates\nanother listener on the same port and concurrently closes the first\nlistener.\n\nThe second listen() calls reuseport_add_sock() with the first listener as\nsk2, where sk2->sk_reuseport_cb is not expected to be cleared concurrently,\nbut the close() does clear it by reuseport_detach_sock().\n\nThe problem is SCTP does not properly synchronise reuseport_alloc(),\nreuseport_add_sock(), and reuseport_detach_sock().\n\nThe caller of reuseport_alloc() and reuseport_{add,detach}_sock() must\nprovide synchronisation for sockets that are classified into the same\nreuseport group.\n\nOtherwise, such sockets form multiple identical reuseport groups, and\nall groups except one would be silently dead.\n\n 1. Two sockets call listen() concurrently\n 2. No socket in the same group found in sctp_ep_hashtable[]\n 3. Two sockets call reuseport_alloc() and form two reuseport groups\n 4. Only one group hit first in __sctp_rcv_lookup_endpoint() receives\n incoming packets\n\nAlso, the reported null-ptr-deref could occur.\n\nTCP/UDP guarantees that would not happen by holding the hash bucket lock.\n\nLet's apply the locking strategy to __sctp_hash_endpoint() and\n__sctp_unhash_endpoint().\n\n[0]:\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]\nCPU: 1 UID: 0 PID: 10230 Comm: syz-executor119 Not tainted 6.10.0-syzkaller-12585-g301927d2d2eb #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024\nRIP: 0010:reuseport_add_sock+0x27e/0x5e0 net/core/sock_reuseport.c:350\nCode: 00 0f b7 5d 00 bf 01 00 00 00 89 de e8 1b a4 ff f7 83 fb 01 0f 85 a3 01 00 00 e8 6d a0 ff f7 49 8d 7e 12 48 89 f8 48 c1 e8 03 <42> 0f b6 04 28 84 c0 0f 85 4b 02 00 00 41 0f b7 5e 12 49 8d 7e 14\nRSP: 0018:ffffc9000b947c98 EFLAGS: 00010202\nRAX: 0000000000000002 RBX: ffff8880252ddf98 RCX: ffff888079478000\nRDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000012\nRBP: 0000000000000001 R08: ffffffff8993e18d R09: 1ffffffff1fef385\nR10: dffffc0000000000 R11: fffffbfff1fef386 R12: ffff8880252ddac0\nR13: dffffc0000000000 R14: 0000000000000000 R15: 0000000000000000\nFS: 00007f24e45b96c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007ffcced5f7b8 CR3: 00000000241be000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n __sctp_hash_endpoint net/sctp/input.c:762 [inline]\n sctp_hash_endpoint+0x52a/0x600 net/sctp/input.c:790\n sctp_listen_start net/sctp/socket.c:8570 [inline]\n sctp_inet_listen+0x767/0xa20 net/sctp/socket.c:8625\n __sys_listen_socket net/socket.c:1883 [inline]\n __sys_listen+0x1b7/0x230 net/socket.c:1894\n __do_sys_listen net/socket.c:1902 [inline]\n __se_sys_listen net/socket.c:1900 [inline]\n __x64_sys_listen+0x5a/0x70 net/socket.c:1900\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f24e46039b9\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 1a 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f24e45b9228 EFLAGS: 00000246 ORIG_RAX: 0000000000000032\nRAX: ffffffffffffffda RBX: 00007f24e468e428 RCX: 00007f24e46039b9\nRDX: 00007f24e46039b9 RSI: 0000000000000003 RDI: 0000000000000004\nRBP: 00007f24e468e420 R08: 00007f24e45b96c0 R09: 00007f24e45b96c0\nR10: 00007f24e45b96c0 R11: 0000000000000246 R12: 00007f24e468e42c\nR13: 00007f24e465a5dc R14: 0020000000000001 R15: 00007ffcced5f7d8\n </TASK>\nModules linked in:

In the Linux kernel, the following vulnerability has been resolved:\n\npadata: Fix possible divide-by-0 panic in padata_mt_helper()\n\nWe are hit with a not easily reproducible divide-by-0 panic in padata.c at\nbootup time.\n\n [ 10.017908] Oops: divide error: 0000 1 PREEMPT SMP NOPTI\n [ 10.017908] CPU: 26 PID: 2627 Comm: kworker/u1666:1 Not tainted 6.10.0-15.el10.x86_64 #1\n [ 10.017908] Hardware name: Lenovo ThinkSystem SR950 [7X12CTO1WW]/[7X12CTO1WW], BIOS [PSE140J-2.30] 07/20/2021\n [ 10.017908] Workqueue: events_unbound padata_mt_helper\n [ 10.017908] RIP: 0010:padata_mt_helper+0x39/0xb0\n :\n [ 10.017963] Call Trace:\n [ 10.017968] <TASK>\n [ 10.018004] ? padata_mt_helper+0x39/0xb0\n [ 10.018084] process_one_work+0x174/0x330\n [ 10.018093] worker_thread+0x266/0x3a0\n [ 10.018111] kthread+0xcf/0x100\n [ 10.018124] ret_from_fork+0x31/0x50\n [ 10.018138] ret_from_fork_asm+0x1a/0x30\n [ 10.018147] </TASK>\n\nLooking at the padata_mt_helper() function, the only way a divide-by-0\npanic can happen is when ps->chunk_size is 0. The way that chunk_size is\ninitialized in padata_do_multithreaded(), chunk_size can be 0 when the\nmin_chunk in the passed-in padata_mt_job structure is 0.\n\nFix this divide-by-0 panic by making sure that chunk_size will be at least\n1 no matter what the input parameters are.

In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: serial: mos7840: fix crash on resume\n\nSince commit c49cfa917025 ("USB: serial: use generic method if no\nalternative is provided in usb serial layer"), USB serial core calls the\ngeneric resume implementation when the driver has not provided one.\n\nThis can trigger a crash on resume with mos7840 since support for\nmultiple read URBs was added back in 2011. Specifically, both port read\nURBs are now submitted on resume for open ports, but the context pointer\nof the second URB is left set to the core rather than mos7840 port\nstructure.\n\nFix this by implementing dedicated suspend and resume functions for\nmos7840.\n\nTested with Delock 87414 USB 2.0 to 4x serial adapter.\n\n[ johan: analyse crash and rewrite commit message; set busy flag on\n resume; drop bulk-in check; drop unnecessary usb_kill_urb() ]

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers\n\nregister store validation for NFT_DATA_VALUE is conditional, however,\nthe datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. This\nonly requires a new helper function to infer the register type from the\nset datatype so this conditional check can be removed. Otherwise,\npointer to chain object can be leaked through the registers.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/gt: Fix potential UAF by revoke of fence registers\n\nCI has been sporadically reporting the following issue triggered by\nigt@i915_selftest@live@hangcheck on ADL-P and similar machines:\n\n<6> [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence\n...\n<6> [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled\n<6> [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled\n<3> [414.070354] Unable to pin Y-tiled fence; err:-4\n<3> [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(&fence->active))\n...\n<4>[ 609.603992] ------------[ cut here ]------------\n<2>[ 609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301!\n<4>[ 609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\n<4>[ 609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G U W 6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1\n<4>[ 609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023\n<4>[ 609.604010] Workqueue: i915 __i915_gem_free_work [i915]\n<4>[ 609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915]\n...\n<4>[ 609.604271] Call Trace:\n<4>[ 609.604273] <TASK>\n...\n<4>[ 609.604716] __i915_vma_evict+0x2e9/0x550 [i915]\n<4>[ 609.604852] __i915_vma_unbind+0x7c/0x160 [i915]\n<4>[ 609.604977] force_unbind+0x24/0xa0 [i915]\n<4>[ 609.605098] i915_vma_destroy+0x2f/0xa0 [i915]\n<4>[ 609.605210] __i915_gem_object_pages_fini+0x51/0x2f0 [i915]\n<4>[ 609.605330] __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915]\n<4>[ 609.605440] process_scheduled_works+0x351/0x690\n...\n\nIn the past, there were similar failures reported by CI from other IGT\ntests, observed on other platforms.\n\nBefore commit 63baf4f3d587 ("drm/i915/gt: Only wait for GPU activity\nbefore unbinding a GGTT fence"), i915_vma_revoke_fence() was waiting for\nidleness of vma->active via fence_update(). That commit introduced\nvma->fence->active in order for the fence_update() to be able to wait\nselectively on that one instead of vma->active since only idleness of\nfence registers was needed. But then, another commit 0d86ee35097a\n("drm/i915/gt: Make fence revocation unequivocal") replaced the call to\nfence_update() in i915_vma_revoke_fence() with only fence_write(), and\nalso added that GEM_BUG_ON(!i915_active_is_idle(&fence->active)) in front.\nNo justification was provided on why we might then expect idleness of\nvma->fence->active without first waiting on it.\n\nThe issue can be potentially caused by a race among revocation of fence\nregisters on one side and sequential execution of signal callbacks invoked\non completion of a request that was using them on the other, still\nprocessed in parallel to revocation of those fence registers. Fix it by\nwaiting for idleness of vma->fence->active in i915_vma_revoke_fence().\n\n(cherry picked from commit 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1)

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: prefer nft_chain_validate\n\nnft_chain_validate already performs loop detection because a cycle will\nresult in a call stack overflow (ctx->level >= NFT_JUMP_STACK_SIZE).\n\nIt also follows maps via ->validate callback in nft_lookup, so there\nappears no reason to iterate the maps again.\n\nnf_tables_check_loops() and all its helper functions can be removed.\nThis improves ruleset load time significantly, from 23s down to 12s.\n\nThis also fixes a crash bug. Old loop detection code can result in\nunbounded recursion:\n\nBUG: TASK stack guard page was hit at ....\nOops: stack guard page: 0000 [#1] PREEMPT SMP KASAN\nCPU: 4 PID: 1539 Comm: nft Not tainted 6.10.0-rc5+ #1\n[..]\n\nwith a suitable ruleset during validation of register stores.\n\nI can't see any actual reason to attempt to check for this from\nnft_validate_register_store(), at this point the transaction is still in\nprogress, so we don't have a full picture of the rule graph.\n\nFor nf-next it might make sense to either remove it or make this depend\non table->validate_state in case we could catch an error earlier\n(for improved error reporting to userspace).

In the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: Revert "ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine."\n\nUndo the modifications made in commit d410ee5109a1 ("ACPICA: avoid\n"Info: mapping multiple BARs. Your kernel is fine.""). The initial\npurpose of this commit was to stop memory mappings for operation\nregions from overlapping page boundaries, as it can trigger warnings\nif different page attributes are present.\n\nHowever, it was found that when this situation arises, mapping\ncontinues until the boundary's end, but there is still an attempt to\nread/write the entire length of the map, leading to a NULL pointer\ndeference. For example, if a four-byte mapping request is made but\nonly one byte is mapped because it hits the current page boundary's\nend, a four-byte read/write attempt is still made, resulting in a NULL\npointer deference.\n\nInstead, map the entire length, as the ACPI specification does not\nmandate that it must be within the same page boundary. It is\npermissible for it to be mapped across different regions.

In the Linux kernel, the following vulnerability has been resolved:\n\ntipc: force a dst refcount before doing decryption\n\nAs it says in commit 3bc07321ccc2 ("xfrm: Force a dst refcount before\nentering the xfrm type handlers"):\n\n"Crypto requests might return asynchronous. In this case we leave the\n rcu protected region, so force a refcount on the skb's destination\n entry before we enter the xfrm type input/output handlers."\n\nOn TIPC decryption path it has the same problem, and skb_dst_force()\nshould be called before doing decryption to avoid a possible crash.\n\nShuang reported this issue when this warning is triggered:\n\n [] WARNING: include/net/dst.h:337 tipc_sk_rcv+0x1055/0x1ea0 [tipc]\n [] Kdump: loaded Tainted: G W --------- - - 4.18.0-496.el8.x86_64+debug\n [] Workqueue: crypto cryptd_queue_worker\n [] RIP: 0010:tipc_sk_rcv+0x1055/0x1ea0 [tipc]\n [] Call Trace:\n [] tipc_sk_mcast_rcv+0x548/0xea0 [tipc]\n [] tipc_rcv+0xcf5/0x1060 [tipc]\n [] tipc_aead_decrypt_done+0x215/0x2e0 [tipc]\n [] cryptd_aead_crypt+0xdb/0x190\n [] cryptd_queue_worker+0xed/0x190\n [] process_one_work+0x93d/0x17e0

In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: prevent possible NULL deref in fib6_nh_init()\n\nsyzbot reminds us that in6_dev_get() can return NULL.\n\nfib6_nh_init()\n ip6_validate_gw( &idev )\n ip6_route_check_nh( idev )\n *idev = in6_dev_get(dev); // can be NULL\n\nOops: general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7]\nCPU: 0 PID: 11237 Comm: syz-executor.3 Not tainted 6.10.0-rc2-syzkaller-00249-gbe27b8965297 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024\n RIP: 0010:fib6_nh_init+0x640/0x2160 net/ipv6/route.c:3606\nCode: 00 00 fc ff df 4c 8b 64 24 58 48 8b 44 24 28 4c 8b 74 24 30 48 89 c1 48 89 44 24 28 48 8d 98 e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 0f 85 b3 17 00 00 8b 1b 31 ff 89 de e8 b8 8b\nRSP: 0018:ffffc900032775a0 EFLAGS: 00010202\nRAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000000000\nRDX: 0000000000000010 RSI: ffffc90003277a54 RDI: ffff88802b3a08d8\nRBP: ffffc900032778b0 R08: 00000000000002fc R09: 0000000000000000\nR10: 00000000000002fc R11: 0000000000000000 R12: ffff88802b3a08b8\nR13: 1ffff9200064eec8 R14: ffffc90003277a00 R15: dffffc0000000000\nFS: 00007f940feb06c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000000 CR3: 00000000245e8000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n ip6_route_info_create+0x99e/0x12b0 net/ipv6/route.c:3809\n ip6_route_add+0x28/0x160 net/ipv6/route.c:3853\n ipv6_route_ioctl+0x588/0x870 net/ipv6/route.c:4483\n inet6_ioctl+0x21a/0x280 net/ipv6/af_inet6.c:579\n sock_do_ioctl+0x158/0x460 net/socket.c:1222\n sock_ioctl+0x629/0x8e0 net/socket.c:1341\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:907 [inline]\n __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f940f07cea9

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ipset: Fix race between namespace cleanup and gc in the list:set type\n\nLion Ackermann reported that there is a race condition between namespace cleanup\nin ipset and the garbage collection of the list:set type. The namespace\ncleanup can destroy the list:set type of sets while the gc of the set type is\nwaiting to run in rcu cleanup. The latter uses data from the destroyed set which\nthus leads use after free. The patch contains the following parts:\n\n- When destroying all sets, first remove the garbage collectors, then wait\n if needed and then destroy the sets.\n- Fix the badly ordered "wait then remove gc" for the destroy a single set\n case.\n- Fix the missing rcu locking in the list:set type in the userspace test\n case.\n- Use proper RCU list handlings in the list:set type.\n\nThe patch depends on c1193d9bbbd3 (netfilter: ipset: Add list flush to cancel_gc).

In the Linux kernel, the following vulnerability has been resolved:\n\nr8169: Fix possible ring buffer corruption on fragmented Tx packets.\n\nAn issue was found on the RTL8125b when transmitting small fragmented\npackets, whereby invalid entries were inserted into the transmit ring\nbuffer, subsequently leading to calls to dma_unmap_single() with a null\naddress.\n\nThis was caused by rtl8169_start_xmit() not noticing changes to nr_frags\nwhich may occur when small packets are padded (to work around hardware\nquirks) in rtl8169_tso_csum_v2().\n\nTo fix this, postpone inspecting nr_frags until after any padding has been\napplied.

In the Linux kernel, the following vulnerability has been resolved:\n\nbnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq\n\nUndefined behavior is triggered when bnxt_qplib_alloc_init_hwq is called\nwith hwq_attr->aux_depth != 0 and hwq_attr->aux_stride == 0.\nIn that case, "roundup_pow_of_two(hwq_attr->aux_stride)" gets called.\nroundup_pow_of_two is documented as undefined for 0.\n\nFix it in the one caller that had this combination.\n\nThe undefined behavior was detected by UBSAN:\n UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13\n shift exponent 64 is too large for 64-bit type 'long unsigned int'\n CPU: 24 PID: 1075 Comm: (udev-worker) Not tainted 6.9.0-rc6+ #4\n Hardware name: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.7 10/25/2023\n Call Trace:\n <TASK>\n dump_stack_lvl+0x5d/0x80\n ubsan_epilogue+0x5/0x30\n __ubsan_handle_shift_out_of_bounds.cold+0x61/0xec\n __roundup_pow_of_two+0x25/0x35 [bnxt_re]\n bnxt_qplib_alloc_init_hwq+0xa1/0x470 [bnxt_re]\n bnxt_qplib_create_qp+0x19e/0x840 [bnxt_re]\n bnxt_re_create_qp+0x9b1/0xcd0 [bnxt_re]\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? __kmalloc+0x1b6/0x4f0\n ? create_qp.part.0+0x128/0x1c0 [ib_core]\n ? __pfx_bnxt_re_create_qp+0x10/0x10 [bnxt_re]\n create_qp.part.0+0x128/0x1c0 [ib_core]\n ib_create_qp_kernel+0x50/0xd0 [ib_core]\n create_mad_qp+0x8e/0xe0 [ib_core]\n ? __pfx_qp_event_handler+0x10/0x10 [ib_core]\n ib_mad_init_device+0x2be/0x680 [ib_core]\n add_client_context+0x10d/0x1a0 [ib_core]\n enable_device_and_get+0xe0/0x1d0 [ib_core]\n ib_register_device+0x53c/0x630 [ib_core]\n ? srso_alias_return_thunk+0x5/0xfbef5\n bnxt_re_probe+0xbd8/0xe50 [bnxt_re]\n ? __pfx_bnxt_re_probe+0x10/0x10 [bnxt_re]\n auxiliary_bus_probe+0x49/0x80\n ? driver_sysfs_add+0x57/0xc0\n really_probe+0xde/0x340\n ? pm_runtime_barrier+0x54/0x90\n ? __pfx___driver_attach+0x10/0x10\n __driver_probe_device+0x78/0x110\n driver_probe_device+0x1f/0xa0\n __driver_attach+0xba/0x1c0\n bus_for_each_dev+0x8f/0xe0\n bus_add_driver+0x146/0x220\n driver_register+0x72/0xd0\n __auxiliary_driver_register+0x6e/0xd0\n ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re]\n bnxt_re_mod_init+0x3e/0xff0 [bnxt_re]\n ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re]\n do_one_initcall+0x5b/0x310\n do_init_module+0x90/0x250\n init_module_from_file+0x86/0xc0\n idempotent_init_module+0x121/0x2b0\n __x64_sys_finit_module+0x5e/0xb0\n do_syscall_64+0x82/0x160\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? syscall_exit_to_user_mode_prepare+0x149/0x170\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? syscall_exit_to_user_mode+0x75/0x230\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? do_syscall_64+0x8e/0x160\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? __count_memcg_events+0x69/0x100\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? count_memcg_events.constprop.0+0x1a/0x30\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? handle_mm_fault+0x1f0/0x300\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? do_user_addr_fault+0x34e/0x640\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? srso_alias_return_thunk+0x5/0xfbef5\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n RIP: 0033:0x7f4e5132821d\n Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e3 db 0c 00 f7 d8 64 89 01 48\n RSP: 002b:00007ffca9c906a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139\n RAX: ffffffffffffffda RBX: 0000563ec8a8f130 RCX: 00007f4e5132821d\n RDX: 0000000000000000 RSI: 00007f4e518fa07d RDI: 000000000000003b\n RBP: 00007ffca9c90760 R08: 00007f4e513f6b20 R09: 00007ffca9c906f0\n R10: 0000563ec8a8faa0 R11: 0000000000000246 R12: 00007f4e518fa07d\n R13: 0000000000020000 R14: 0000563ec8409e90 R15: 0000563ec8a8fa60\n </TASK>\n ---[ end trace ]---

In the Linux kernel, the following vulnerability has been resolved:\n\ndma-direct: Leak pages on dma_set_decrypted() failure\n\nOn TDX it is possible for the untrusted host to cause\nset_memory_encrypted() or set_memory_decrypted() to fail such that an\nerror is returned and the resulting memory is shared. Callers need to\ntake care to handle these errors to avoid returning decrypted (shared)\nmemory to the page allocator, which could lead to functional or security\nissues.\n\nDMA could free decrypted/shared pages if dma_set_decrypted() fails. This\nshould be a rare case. Just leak the pages in this case instead of\nfreeing them.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get()\n\nnft_unregister_flowtable_type() within nf_flow_inet_module_exit() can\nconcurrent with __nft_flowtable_type_get() within nf_tables_newflowtable().\nAnd thhere is not any protection when iterate over nf_tables_flowtables\nlist in __nft_flowtable_type_get(). Therefore, there is pertential\ndata-race of nf_tables_flowtables list entry.\n\nUse list_for_each_entry_rcu() to iterate over nf_tables_flowtables list\nin __nft_flowtable_type_get(), and use rcu_read_lock() in the caller\nnft_flowtable_type_get() to protect the entire type query process.

In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: Always flush async #PF workqueue when vCPU is being destroyed\n\nAlways flush the per-vCPU async #PF workqueue when a vCPU is clearing its\ncompletion queue, e.g. when a VM and all its vCPUs is being destroyed.\nKVM must ensure that none of its workqueue callbacks is running when the\nlast reference to the KVM _module_ is put. Gifting a reference to the\nassociated VM prevents the workqueue callback from dereferencing freed\nvCPU/VM memory, but does not prevent the KVM module from being unloaded\nbefore the callback completes.\n\nDrop the misguided VM refcount gifting, as calling kvm_put_kvm() from\nasync_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue will\nresult in deadlock. async_pf_execute() can't return until kvm_put_kvm()\nfinishes, and kvm_put_kvm() can't return until async_pf_execute() finishes:\n\n WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm]\n Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass\n CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n Workqueue: events async_pf_execute [kvm]\n RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm]\n Call Trace:\n <TASK>\n async_pf_execute+0x198/0x260 [kvm]\n process_one_work+0x145/0x2d0\n worker_thread+0x27e/0x3a0\n kthread+0xba/0xe0\n ret_from_fork+0x2d/0x50\n ret_from_fork_asm+0x11/0x20\n </TASK>\n ---[ end trace 0000000000000000 ]---\n INFO: task kworker/8:1:251 blocked for more than 120 seconds.\n Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119\n "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.\n task:kworker/8:1 state:D stack:0 pid:251 ppid:2 flags:0x00004000\n Workqueue: events async_pf_execute [kvm]\n Call Trace:\n <TASK>\n __schedule+0x33f/0xa40\n schedule+0x53/0xc0\n schedule_timeout+0x12a/0x140\n __wait_for_common+0x8d/0x1d0\n __flush_work.isra.0+0x19f/0x2c0\n kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm]\n kvm_arch_destroy_vm+0x78/0x1b0 [kvm]\n kvm_put_kvm+0x1c1/0x320 [kvm]\n async_pf_execute+0x198/0x260 [kvm]\n process_one_work+0x145/0x2d0\n worker_thread+0x27e/0x3a0\n kthread+0xba/0xe0\n ret_from_fork+0x2d/0x50\n ret_from_fork_asm+0x11/0x20\n </TASK>\n\nIf kvm_clear_async_pf_completion_queue() actually flushes the workqueue,\nthen there's no need to gift async_pf_execute() a reference because all\ninvocations of async_pf_execute() will be forced to complete before the\nvCPU and its VM are destroyed/freed. And that in turn fixes the module\nunloading bug as __fput() won't do module_put() on the last vCPU reference\nuntil the vCPU has been freed, e.g. if closing the vCPU file also puts the\nlast reference to the KVM module.\n\nNote that kvm_check_async_pf_completion() may also take the work item off\nthe completion queue and so also needs to flush the work queue, as the\nwork will not be seen by kvm_clear_async_pf_completion_queue(). Waiting\non the workqueue could theoretically delay a vCPU due to waiting for the\nwork to complete, but that's a very, very small chance, and likely a very\nsmall delay. kvm_arch_async_page_present_queued() unconditionally makes a\nnew request, i.e. will effectively delay entering the guest, so the\nremaining work is really just:\n\n trace_kvm_async_pf_completed(addr, cr2_or_gpa);\n\n __kvm_vcpu_wake_up(vcpu);\n\n mmput(mm);\n\nand mmput() can't drop the last reference to the page tables if the vCPU is\nstill alive, i.e. the vCPU won't get stuck tearing down page tables.\n\nAdd a helper to do the flushing, specifically to deal with "wakeup all"\nwork items, as they aren't actually work items, i.e. are never placed in a\nworkqueue. Trying to flush a bogus workqueue entry rightly makes\n__flush_work() complain (kudos to whoever added that sanity check).\n\nNote, commit 5f6de5cbebee ("KVM: Prevent module exit until all VMs are\nfreed") *tried* to fix the module refcounting issue by having VMs grab a\nreference to the module, but that only made the bug slightly harder to hit\nas it gave async_pf_execute() a bit more time to complete before the KVM\nmodule could be unloaded.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_set_pipapo: do not free live element\n\nPablo reports a crash with large batches of elements with a\nback-to-back add/remove pattern. Quoting Pablo:\n\n add_elem("00000000") timeout 100 ms\n ...\n add_elem("0000000X") timeout 100 ms\n del_elem("0000000X") <---------------- delete one that was just added\n ...\n add_elem("00005000") timeout 100 ms\n\n 1) nft_pipapo_remove() removes element 0000000X\n Then, KASAN shows a splat.\n\nLooking at the remove function there is a chance that we will drop a\nrule that maps to a non-deactivated element.\n\nRemoval happens in two steps, first we do a lookup for key k and return the\nto-be-removed element and mark it as inactive in the next generation.\nThen, in a second step, the element gets removed from the set/map.\n\nThe _remove function does not work correctly if we have more than one\nelement that share the same key.\n\nThis can happen if we insert an element into a set when the set already\nholds an element with same key, but the element mapping to the existing\nkey has timed out or is not active in the next generation.\n\nIn such case its possible that removal will unmap the wrong element.\nIf this happens, we will leak the non-deactivated element, it becomes\nunreachable.\n\nThe element that got deactivated (and will be freed later) will\nremain reachable in the set data structure, this can result in\na crash when such an element is retrieved during lookup (stale\npointer).\n\nAdd a check that the fully matching key does in fact map to the element\nthat we have marked as inactive in the deactivation step.\nIf not, we need to continue searching.\n\nAdd a bug/warn trap at the end of the function as well, the remove\nfunction must not ever be called with an invisible/unreachable/non-existent\nelement.\n\nv2: avoid uneeded temporary variable (Stefano)

In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: fix NULL pointer in channel unregistration function\n\n__dma_async_device_channel_register() can fail. In case of failure,\nchan->local is freed (with free_percpu()), and chan->local is nullified.\nWhen dma_async_device_unregister() is called (because of managed API or\nintentionally by DMA controller driver), channels are unconditionally\nunregistered, leading to this NULL pointer:\n[ 1.318693] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0\n[...]\n[ 1.484499] Call trace:\n[ 1.486930] device_del+0x40/0x394\n[ 1.490314] device_unregister+0x20/0x7c\n[ 1.494220] __dma_async_device_channel_unregister+0x68/0xc0\n\nLook at dma_async_device_register() function error path, channel device\nunregistration is done only if chan->local is not NULL.\n\nThen add the same condition at the beginning of\n__dma_async_device_channel_unregister() function, to avoid NULL pointer\nissue whatever the API used to reach this function.

In the Linux kernel, the following vulnerability has been resolved:\nhwmon: (coretemp) Check for null before removing sysfs attrs\nIf coretemp_add_core() gets an error then pdata->core_data[indx]\nis already NULL and has been kfreed. Don't pass that to\nsysfs_remove_group() as that will crash in sysfs_remove_group().\n[Shortened for readability]\n[91854.020159] sysfs: cannot create duplicate filename '/devices/platform/coretemp.0/hwmon/hwmon2/temp20_label'\n<cpu offline>\n[91855.126115] BUG: kernel NULL pointer dereference, address: 0000000000000188\n[91855.165103] #PF: supervisor read access in kernel mode\n[91855.194506] #PF: error_code(0x0000) - not-present page\n[91855.224445] PGD 0 P4D 0\n[91855.238508] Oops: 0000 [#1] PREEMPT SMP PTI\n...\n[91855.342716] RIP: 0010:sysfs_remove_group+0xc/0x80\n...\n[91855.796571] Call Trace:\n[91855.810524] coretemp_cpu_offline+0x12b/0x1dd [coretemp]\n[91855.841738] ? coretemp_cpu_online+0x180/0x180 [coretemp]\n[91855.871107] cpuhp_invoke_callback+0x105/0x4b0\n[91855.893432] cpuhp_thread_fun+0x8e/0x150\n...\nFix this by checking for NULL first.

In the Linux kernel, the following vulnerability has been resolved:\nBluetooth: L2CAP: Fix u8 overflow\nBy keep sending L2CAP_CONF_REQ packets, chan->num_conf_rsp increases\nmultiple times and eventually it will wrap around the maximum number\n(i.e., 255).\nThis patch prevents this by adding a boundary check with\nL2CAP_MAX_CONF_RSP\nBtmon log:\nBluetooth monitor ver 5.64\n= Note: Linux version 6.1.0-rc2 (x86_64) 0.264594\n= Note: Bluetooth subsystem version 2.22 0.264636\n@ MGMT Open: btmon (privileged) version 1.22 {0x0001} 0.272191\n= New Index: : (Primary,Virtual,hci0) [hci0] 13.877604\n@ RAW Open: 9496 (privileged) version 2.22 {0x0002} 13.890741\n= Open Index: : [hci0] 13.900426\n(...)\n> ACL Data RX: Handle 200 flags 0x00 dlen 1033 #32 [hci0] 14.273106\ninvalid packet size (12 != 1033)\n08 00 01 00 02 01 04 00 01 10 ff ff ............\n> ACL Data RX: Handle 200 flags 0x00 dlen 1547 #33 [hci0] 14.273561\ninvalid packet size (14 != 1547)\n0a 00 01 00 04 01 06 00 40 00 00 00 00 00 ........@.....\n> ACL Data RX: Handle 200 flags 0x00 dlen 2061 #34 [hci0] 14.274390\ninvalid packet size (16 != 2061)\n0c 00 01 00 04 01 08 00 40 00 00 00 00 00 00 04 ........@.......\n> ACL Data RX: Handle 200 flags 0x00 dlen 2061 #35 [hci0] 14.274932\ninvalid packet size (16 != 2061)\n0c 00 01 00 04 01 08 00 40 00 00 00 07 00 03 00 ........@.......\n= bluetoothd: Bluetooth daemon 5.43 14.401828\n> ACL Data RX: Handle 200 flags 0x00 dlen 1033 #36 [hci0] 14.275753\ninvalid packet size (12 != 1033)\n08 00 01 00 04 01 04 00 40 00 00 00 ........@...

In the Linux kernel, the following vulnerability has been resolved:\n\nxprtrdma: fix pointer derefs in error cases of rpcrdma_ep_create\n\nIf there are failures then we must not leave the non-NULL pointers with\nthe error value, otherwise `rpcrdma_ep_destroy` gets confused and tries\nfree them, resulting in an Oops.

The Smart PopUp Blaster plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin's 'spb-button' shortcode in all versions up to, and including, 1.4.3 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

Memory safety bugs present in Firefox 131, Firefox ESR 128.3, and Thunderbird 128.3. 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 < 132, Firefox ESR < 128.4, Thunderbird < 128.4, and Thunderbird < 132.

By sending a specially crafted push message, a remote server could have hung the parent process, causing the browser to become unresponsive. This vulnerability affects Firefox < 132, Firefox ESR < 128.4, Thunderbird < 128.4, and Thunderbird < 132.

A clipboard "paste" button could persist across tabs which allowed a spoofing attack. This vulnerability affects Firefox < 132, Firefox ESR < 128.4, Thunderbird < 128.4, and Thunderbird < 132.

Repeated writes to history interface attributes could have been used to cause a Denial of Service condition in the browser. This was addressed by introducing rate-limiting to this API. This vulnerability affects Firefox < 132, Firefox ESR < 128.4, Thunderbird < 128.4, and Thunderbird < 132.

Video frames could have been leaked between origins in some situations. This vulnerability affects Firefox < 132, Firefox ESR < 128.4, Firefox ESR < 115.17, Thunderbird < 128.4, and Thunderbird < 132.

Truncation of a long URL could have allowed origin spoofing in a permission prompt. This vulnerability affects Firefox < 132, Firefox ESR < 128.4, Thunderbird < 128.4, and Thunderbird < 132.

In multipart/x-mixed-replace responses, `Content-Disposition: attachment` in the response header was not respected and did not force a download, which could allow XSS attacks. This vulnerability affects Firefox < 132, Firefox ESR < 128.4, Thunderbird < 128.4, and Thunderbird < 132.

The origin of an external protocol handler prompt could have been obscured using a data: URL within an `iframe`. This vulnerability affects Firefox < 132, Firefox ESR < 128.4, Thunderbird < 128.4, and Thunderbird < 132.

An attacker could have caused a use-after-free when accessibility was enabled, leading to a potentially exploitable crash. This vulnerability affects Firefox < 132, Firefox ESR < 128.4, Firefox ESR < 115.17, Thunderbird < 128.4, and Thunderbird < 132.

A permission leak could have occurred from a trusted site to an untrusted site via `embed` or `object` elements. This vulnerability affects Firefox < 132, Firefox ESR < 128.4, Firefox ESR < 115.17, Thunderbird < 128.4, and Thunderbird < 132.

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

An integer overflow was addressed with improved input validation. This issue is fixed in tvOS 17.5, iOS 16.7.8 and iPadOS 16.7.8, visionOS 1.2, Safari 17.5, iOS 17.5 and iPadOS 17.5. Processing maliciously crafted web content may lead to arbitrary code execution.

In the Linux kernel, the following vulnerability has been resolved:\n\ndm: fix mempool NULL pointer race when completing IO\n\ndm_io_dec_pending() calls end_io_acct() first and will then dec md\nin-flight pending count. But if a task is swapping DM table at same\ntime this can result in a crash due to mempool->elements being NULL:\n\ntask1 task2\ndo_resume\n ->do_suspend\n ->dm_wait_for_completion\n bio_endio\n ->clone_endio\n ->dm_io_dec_pending\n ->end_io_acct\n ->wakeup task1\n ->dm_swap_table\n ->__bind\n ->__bind_mempools\n ->bioset_exit\n ->mempool_exit\n ->free_io\n\n[ 67.330330] Unable to handle kernel NULL pointer dereference at\nvirtual address 0000000000000000\n......\n[ 67.330494] pstate: 80400085 (Nzcv daIf +PAN -UAO)\n[ 67.330510] pc : mempool_free+0x70/0xa0\n[ 67.330515] lr : mempool_free+0x4c/0xa0\n[ 67.330520] sp : ffffff8008013b20\n[ 67.330524] x29: ffffff8008013b20 x28: 0000000000000004\n[ 67.330530] x27: ffffffa8c2ff40a0 x26: 00000000ffff1cc8\n[ 67.330535] x25: 0000000000000000 x24: ffffffdada34c800\n[ 67.330541] x23: 0000000000000000 x22: ffffffdada34c800\n[ 67.330547] x21: 00000000ffff1cc8 x20: ffffffd9a1304d80\n[ 67.330552] x19: ffffffdada34c970 x18: 000000b312625d9c\n[ 67.330558] x17: 00000000002dcfbf x16: 00000000000006dd\n[ 67.330563] x15: 000000000093b41e x14: 0000000000000010\n[ 67.330569] x13: 0000000000007f7a x12: 0000000034155555\n[ 67.330574] x11: 0000000000000001 x10: 0000000000000001\n[ 67.330579] x9 : 0000000000000000 x8 : 0000000000000000\n[ 67.330585] x7 : 0000000000000000 x6 : ffffff80148b5c1a\n[ 67.330590] x5 : ffffff8008013ae0 x4 : 0000000000000001\n[ 67.330596] x3 : ffffff80080139c8 x2 : ffffff801083bab8\n[ 67.330601] x1 : 0000000000000000 x0 : ffffffdada34c970\n[ 67.330609] Call trace:\n[ 67.330616] mempool_free+0x70/0xa0\n[ 67.330627] bio_put+0xf8/0x110\n[ 67.330638] dec_pending+0x13c/0x230\n[ 67.330644] clone_endio+0x90/0x180\n[ 67.330649] bio_endio+0x198/0x1b8\n[ 67.330655] dec_pending+0x190/0x230\n[ 67.330660] clone_endio+0x90/0x180\n[ 67.330665] bio_endio+0x198/0x1b8\n[ 67.330673] blk_update_request+0x214/0x428\n[ 67.330683] scsi_end_request+0x2c/0x300\n[ 67.330688] scsi_io_completion+0xa0/0x710\n[ 67.330695] scsi_finish_command+0xd8/0x110\n[ 67.330700] scsi_softirq_done+0x114/0x148\n[ 67.330708] blk_done_softirq+0x74/0xd0\n[ 67.330716] __do_softirq+0x18c/0x374\n[ 67.330724] irq_exit+0xb4/0xb8\n[ 67.330732] __handle_domain_irq+0x84/0xc0\n[ 67.330737] gic_handle_irq+0x148/0x1b0\n[ 67.330744] el1_irq+0xe8/0x190\n[ 67.330753] lpm_cpuidle_enter+0x4f8/0x538\n[ 67.330759] cpuidle_enter_state+0x1fc/0x398\n[ 67.330764] cpuidle_enter+0x18/0x20\n[ 67.330772] do_idle+0x1b4/0x290\n[ 67.330778] cpu_startup_entry+0x20/0x28\n[ 67.330786] secondary_start_kernel+0x160/0x170\n\nFix this by:\n1) Establishing pointers to 'struct dm_io' members in\ndm_io_dec_pending() so that they may be passed into end_io_acct()\n_after_ free_io() is called.\n2) Moving end_io_acct() after free_io().

An information disclosure flaw was found in ansible-core due to a failure to respect the ANSIBLE_NO_LOG configuration in some scenarios. Information is still included in the output in certain tasks, such as loop items. Depending on the task, this issue may include sensitive information, such as decrypted secret values.

The issue was addressed with improved memory handling. This issue is fixed in tvOS 17.5, visionOS 1.2, Safari 17.5, iOS 17.5 and iPadOS 17.5, watchOS 10.5, macOS Sonoma 14.5. Processing web content may lead to arbitrary code execution.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/fbdev-dma: Only cleanup deferred I/O if necessary\n\nCommit 5a498d4d06d6 ("drm/fbdev-dma: Only install deferred I/O if\nnecessary") initializes deferred I/O only if it is used.\ndrm_fbdev_dma_fb_destroy() however calls fb_deferred_io_cleanup()\nunconditionally with struct fb_info.fbdefio == NULL. KASAN with the\nout-of-tree Apple silicon display driver posts following warning from\n__flush_work() of a random struct work_struct instead of the expected\nNULL pointer derefs.\n\n[ 22.053799] ------------[ cut here ]------------\n[ 22.054832] WARNING: CPU: 2 PID: 1 at kernel/workqueue.c:4177 __flush_work+0x4d8/0x580\n[ 22.056597] Modules linked in: uhid bnep uinput nls_ascii ip6_tables ip_tables i2c_dev loop fuse dm_multipath nfnetlink zram hid_magicmouse btrfs xor xor_neon brcmfmac_wcc raid6_pq hci_bcm4377 bluetooth brcmfmac hid_apple brcmutil nvmem_spmi_mfd simple_mfd_spmi dockchannel_hid cfg80211 joydev regmap_spmi nvme_apple ecdh_generic ecc macsmc_hid rfkill dwc3 appledrm snd_soc_macaudio macsmc_power nvme_core apple_isp phy_apple_atc apple_sart apple_rtkit_helper apple_dockchannel tps6598x macsmc_hwmon snd_soc_cs42l84 videobuf2_v4l2 spmi_apple_controller nvmem_apple_efuses videobuf2_dma_sg apple_z2 videobuf2_memops spi_nor panel_summit videobuf2_common asahi videodev pwm_apple apple_dcp snd_soc_apple_mca apple_admac spi_apple clk_apple_nco i2c_pasemi_platform snd_pcm_dmaengine mc i2c_pasemi_core mux_core ofpart adpdrm drm_dma_helper apple_dart apple_soc_cpufreq leds_pwm phram\n[ 22.073768] CPU: 2 UID: 0 PID: 1 Comm: systemd-shutdow Not tainted 6.11.2-asahi+ #asahi-dev\n[ 22.075612] Hardware name: Apple MacBook Pro (13-inch, M2, 2022) (DT)\n[ 22.077032] pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n[ 22.078567] pc : __flush_work+0x4d8/0x580\n[ 22.079471] lr : __flush_work+0x54/0x580\n[ 22.080345] sp : ffffc000836ef820\n[ 22.081089] x29: ffffc000836ef880 x28: 0000000000000000 x27: ffff80002ddb7128\n[ 22.082678] x26: dfffc00000000000 x25: 1ffff000096f0c57 x24: ffffc00082d3e358\n[ 22.084263] x23: ffff80004b7862b8 x22: dfffc00000000000 x21: ffff80005aa1d470\n[ 22.085855] x20: ffff80004b786000 x19: ffff80004b7862a0 x18: 0000000000000000\n[ 22.087439] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000005\n[ 22.089030] x14: 1ffff800106ddf0a x13: 0000000000000000 x12: 0000000000000000\n[ 22.090618] x11: ffffb800106ddf0f x10: dfffc00000000000 x9 : 1ffff800106ddf0e\n[ 22.092206] x8 : 0000000000000000 x7 : aaaaaaaaaaaaaaaa x6 : 0000000000000001\n[ 22.093790] x5 : ffffc000836ef728 x4 : 0000000000000000 x3 : 0000000000000020\n[ 22.095368] x2 : 0000000000000008 x1 : 00000000000000aa x0 : 0000000000000000\n[ 22.096955] Call trace:\n[ 22.097505] __flush_work+0x4d8/0x580\n[ 22.098330] flush_delayed_work+0x80/0xb8\n[ 22.099231] fb_deferred_io_cleanup+0x3c/0x130\n[ 22.100217] drm_fbdev_dma_fb_destroy+0x6c/0xe0 [drm_dma_helper]\n[ 22.101559] unregister_framebuffer+0x210/0x2f0\n[ 22.102575] drm_fb_helper_unregister_info+0x48/0x60\n[ 22.103683] drm_fbdev_dma_client_unregister+0x4c/0x80 [drm_dma_helper]\n[ 22.105147] drm_client_dev_unregister+0x1cc/0x230\n[ 22.106217] drm_dev_unregister+0x58/0x570\n[ 22.107125] apple_drm_unbind+0x50/0x98 [appledrm]\n[ 22.108199] component_del+0x1f8/0x3a8\n[ 22.109042] dcp_platform_shutdown+0x24/0x38 [apple_dcp]\n[ 22.110357] platform_shutdown+0x70/0x90\n[ 22.111219] device_shutdown+0x368/0x4d8\n[ 22.112095] kernel_restart+0x6c/0x1d0\n[ 22.112946] __arm64_sys_reboot+0x1c8/0x328\n[ 22.113868] invoke_syscall+0x78/0x1a8\n[ 22.114703] do_el0_svc+0x124/0x1a0\n[ 22.115498] el0_svc+0x3c/0xe0\n[ 22.116181] el0t_64_sync_handler+0x70/0xc0\n[ 22.117110] el0t_64_sync+0x190/0x198\n[ 22.117931] ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/v3d: Stop the active perfmon before being destroyed\n\nWhen running `kmscube` with one or more performance monitors enabled\nvia `GALLIUM_HUD`, the following kernel panic can occur:\n\n[ 55.008324] Unable to handle kernel paging request at virtual address 00000000052004a4\n[ 55.008368] Mem abort info:\n[ 55.008377] ESR = 0x0000000096000005\n[ 55.008387] EC = 0x25: DABT (current EL), IL = 32 bits\n[ 55.008402] SET = 0, FnV = 0\n[ 55.008412] EA = 0, S1PTW = 0\n[ 55.008421] FSC = 0x05: level 1 translation fault\n[ 55.008434] Data abort info:\n[ 55.008442] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000\n[ 55.008455] CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[ 55.008467] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[ 55.008481] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001046c6000\n[ 55.008497] [00000000052004a4] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000\n[ 55.008525] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP\n[ 55.008542] Modules linked in: rfcomm [...] vc4 v3d snd_soc_hdmi_codec drm_display_helper\ngpu_sched drm_shmem_helper cec drm_dma_helper drm_kms_helper i2c_brcmstb\ndrm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight\n[ 55.008799] CPU: 2 PID: 166 Comm: v3d_bin Tainted: G C 6.6.47+rpt-rpi-v8 #1 Debian 1:6.6.47-1+rpt1\n[ 55.008824] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT)\n[ 55.008838] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 55.008855] pc : __mutex_lock.constprop.0+0x90/0x608\n[ 55.008879] lr : __mutex_lock.constprop.0+0x58/0x608\n[ 55.008895] sp : ffffffc080673cf0\n[ 55.008904] x29: ffffffc080673cf0 x28: 0000000000000000 x27: ffffff8106188a28\n[ 55.008926] x26: ffffff8101e78040 x25: ffffff8101baa6c0 x24: ffffffd9d989f148\n[ 55.008947] x23: ffffffda1c2a4008 x22: 0000000000000002 x21: ffffffc080673d38\n[ 55.008968] x20: ffffff8101238000 x19: ffffff8104f83188 x18: 0000000000000000\n[ 55.008988] x17: 0000000000000000 x16: ffffffda1bd04d18 x15: 00000055bb08bc90\n[ 55.009715] x14: 0000000000000000 x13: 0000000000000000 x12: ffffffda1bd4cbb0\n[ 55.010433] x11: 00000000fa83b2da x10: 0000000000001a40 x9 : ffffffda1bd04d04\n[ 55.011162] x8 : ffffff8102097b80 x7 : 0000000000000000 x6 : 00000000030a5857\n[ 55.011880] x5 : 00ffffffffffffff x4 : 0300000005200470 x3 : 0300000005200470\n[ 55.012598] x2 : ffffff8101238000 x1 : 0000000000000021 x0 : 0300000005200470\n[ 55.013292] Call trace:\n[ 55.013959] __mutex_lock.constprop.0+0x90/0x608\n[ 55.014646] __mutex_lock_slowpath+0x1c/0x30\n[ 55.015317] mutex_lock+0x50/0x68\n[ 55.015961] v3d_perfmon_stop+0x40/0xe0 [v3d]\n[ 55.016627] v3d_bin_job_run+0x10c/0x2d8 [v3d]\n[ 55.017282] drm_sched_main+0x178/0x3f8 [gpu_sched]\n[ 55.017921] kthread+0x11c/0x128\n[ 55.018554] ret_from_fork+0x10/0x20\n[ 55.019168] Code: f9400260 f1001c1f 54001ea9 927df000 (b9403401)\n[ 55.019776] ---[ end trace 0000000000000000 ]---\n[ 55.020411] note: v3d_bin[166] exited with preempt_count 1\n\nThis issue arises because, upon closing the file descriptor (which happens\nwhen we interrupt `kmscube`), the active performance monitor is not\nstopped. Although all perfmons are destroyed in `v3d_perfmon_close_file()`,\nthe active performance monitor's pointer (`v3d->active_perfmon`) is still\nretained.\n\nIf `kmscube` is run again, the driver will attempt to stop the active\nperformance monitor using the stale pointer in `v3d->active_perfmon`.\nHowever, this pointer is no longer valid because the previous process has\nalready terminated, and all performance monitors associated with it have\nbeen destroyed and freed.\n\nTo fix this, when the active performance monitor belongs to a given\nprocess, explicitly stop it before destroying and freeing it.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

execute_filter_delta in archive_read_support_format_rar.c in libarchive before 3.7.5 allows out-of-bounds access via a crafted archive file because src can move beyond dst.

execute_filter_audio in archive_read_support_format_rar.c in libarchive before 3.7.5 allows out-of-bounds access via a crafted archive file because src can move beyond dst.

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

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

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

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

On Windows platforms, a "best fit" character encoding conversion of command line arguments to Subversion's executables (e.g., svn.exe, etc.) may lead to unexpected command line argument interpretation, including argument injection and execution of other programs, if a specially crafted command line argument string is processed.\n\nAll versions of Subversion up to and including Subversion 1.14.3 are affected on Windows platforms only. Users are recommended to upgrade to version Subversion 1.14.4, which fixes this issue.\n\nSubversion is not affected on UNIX-like platforms.

Buffer Overflow vulnerability in zlib-ng minizip-ng v.4.0.2 allows an attacker to execute arbitrary code via a crafted file to the mz_path_has_slash function in the mz_os.c file.

Buffer Overflow vulnerability in zlib-ng minizip-ng v.4.0.2 allows an attacker to execute arbitrary code via a crafted file to the mz_path_resolve function in the mz_os.c file.

aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. The HTTP parser in AIOHTTP has numerous problems with header parsing, which could lead to request smuggling. This parser is only used when AIOHTTP_NO_EXTENSIONS is enabled (or not using a prebuilt wheel). These bugs have been addressed in commit `d5c12ba89` which has been included in release version 3.8.6. Users are advised to upgrade. There are no known workarounds for these issues.