In the Linux kernel, the following vulnerability has been resolved:\n\nfgraph: Add READ_ONCE() when accessing fgraph_array[]\n\nIn __ftrace_return_to_handler(), a loop iterates over the fgraph_array[]\nelements, which are fgraph_ops. The loop checks if an element is a\nfgraph_stub to prevent using a fgraph_stub afterward.\n\nHowever, if the compiler reloads fgraph_array[] after this check, it might\nrace with an update to fgraph_array[] that introduces a fgraph_stub. This\ncould result in the stub being processed, but the stub contains a null\n"func_hash" field, leading to a NULL pointer dereference.\n\nTo ensure that the gops compared against the fgraph_stub matches the gops\nprocessed later, add a READ_ONCE(). A similar patch appears in commit\n63a8dfb ("function_graph: Add READ_ONCE() when accessing fgraph_array[]").

In the Linux kernel, the following vulnerability has been resolved:\n\ngve: guard XDP xmit NDO on existence of xdp queues\n\nIn GVE, dedicated XDP queues only exist when an XDP program is installed\nand the interface is up. As such, the NDO XDP XMIT callback should\nreturn early if either of these conditions are false.\n\nIn the case of no loaded XDP program, priv->num_xdp_queues=0 which can\ncause a divide-by-zero error, and in the case of interface down,\nnum_xdp_queues remains untouched to persist XDP queue count for the next\ninterface up, but the TX pointer itself would be NULL.\n\nThe XDP xmit callback also needs to synchronize with a device\ntransitioning from open to close. This synchronization will happen via\nthe GVE_PRIV_FLAGS_NAPI_ENABLED bit along with a synchronize_net() call,\nwhich waits for any RCU critical sections at call-time to complete.

In the Linux kernel, the following vulnerability has been resolved:\n\nselinux: ignore unknown extended permissions\n\nWhen evaluating extended permissions, ignore unknown permissions instead\nof calling BUG(). This commit ensures that future permissions can be\nadded without interfering with older kernels.

In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Have process_string() also allow arrays\n\nIn order to catch a common bug where a TRACE_EVENT() TP_fast_assign()\nassigns an address of an allocated string to the ring buffer and then\nreferences it in TP_printk(), which can be executed hours later when the\nstring is free, the function test_event_printk() runs on all events as\nthey are registered to make sure there's no unwanted dereferencing.\n\nIt calls process_string() to handle cases in TP_printk() format that has\n"%s". It returns whether or not the string is safe. But it can have some\nfalse positives.\n\nFor instance, xe_bo_move() has:\n\n TP_printk("move_lacks_source:%s, migrate object %p [size %zu] from %s to %s device_id:%s",\n __entry->move_lacks_source ? "yes" : "no", __entry->bo, __entry->size,\n xe_mem_type_to_name[__entry->old_placement],\n xe_mem_type_to_name[__entry->new_placement], __get_str(device_id))\n\nWhere the "%s" references into xe_mem_type_to_name[]. This is an array of\npointers that should be safe for the event to access. Instead of flagging\nthis as a bad reference, if a reference points to an array, where the\nrecord field is the index, consider it safe.

In the Linux kernel, the following vulnerability has been resolved:\n\nfs: relax assertions on failure to encode file handles\n\nEncoding file handles is usually performed by a filesystem >encode_fh()\nmethod that may fail for various reasons.\n\nThe legacy users of exportfs_encode_fh(), namely, nfsd and\nname_to_handle_at(2) syscall are ready to cope with the possibility\nof failure to encode a file handle.\n\nThere are a few other users of exportfs_encode_{fh,fid}() that\ncurrently have a WARN_ON() assertion when ->encode_fh() fails.\nRelax those assertions because they are wrong.\n\nThe second linked bug report states commit 16aac5ad1fa9 ("ovl: support\nencoding non-decodable file handles") in v6.6 as the regressing commit,\nbut this is not accurate.\n\nThe aforementioned commit only increases the chances of the assertion\nand allows triggering the assertion with the reproducer using overlayfs,\ninotify and drop_caches.\n\nTriggering this assertion was always possible with other filesystems and\nother reasons of ->encode_fh() failures and more particularly, it was\nalso possible with the exact same reproducer using overlayfs that is\nmounted with options index=on,nfs_export=on also on kernels < v6.6.\nTherefore, I am not listing the aforementioned commit as a Fixes commit.\n\nBackport hint: this patch will have a trivial conflict applying to\nv6.6.y, and other trivial conflicts applying to stable kernels < v6.6.

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: zlib: fix avail_in bytes for s390 zlib HW compression path\n\nSince the input data length passed to zlib_compress_folios() can be\narbitrary, always setting strm.avail_in to a multiple of PAGE_SIZE may\ncause read-in bytes to exceed the input range. Currently this triggers\nan assert in btrfs_compress_folios() on the debug kernel (see below).\nFix strm.avail_in calculation for S390 hardware acceleration path.\n\n assertion failed: *total_in <= orig_len, in fs/btrfs/compression.c:1041\n ------------[ cut here ]------------\n kernel BUG at fs/btrfs/compression.c:1041!\n monitor event: 0040 ilc:2 [#1] PREEMPT SMP\n CPU: 16 UID: 0 PID: 325 Comm: kworker/u273:3 Not tainted 6.13.0-20241204.rc1.git6.fae3b21430ca.300.fc41.s390x+debug #1\n Hardware name: IBM 3931 A01 703 (z/VM 7.4.0)\n Workqueue: btrfs-delalloc btrfs_work_helper\n Krnl PSW : 0704d00180000000 0000021761df6538 (btrfs_compress_folios+0x198/0x1a0)\n R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3\n Krnl GPRS: 0000000080000000 0000000000000001 0000000000000047 0000000000000000\n 0000000000000006 ffffff01757bb000 000001976232fcc0 000000000000130c\n 000001976232fcd0 000001976232fcc8 00000118ff4a0e30 0000000000000001\n 00000111821ab400 0000011100000000 0000021761df6534 000001976232fb58\n Krnl Code: 0000021761df6528: c020006f5ef4 larl %r2,0000021762be2310\n 0000021761df652e: c0e5ffbd09d5 brasl %r14,00000217615978d8\n #0000021761df6534: af000000 mc 0,0\n >0000021761df6538: 0707 bcr 0,%r7\n 0000021761df653a: 0707 bcr 0,%r7\n 0000021761df653c: 0707 bcr 0,%r7\n 0000021761df653e: 0707 bcr 0,%r7\n 0000021761df6540: c004004bb7ec brcl 0,000002176276d518\n Call Trace:\n [<0000021761df6538>] btrfs_compress_folios+0x198/0x1a0\n ([<0000021761df6534>] btrfs_compress_folios+0x194/0x1a0)\n [<0000021761d97788>] compress_file_range+0x3b8/0x6d0\n [<0000021761dcee7c>] btrfs_work_helper+0x10c/0x160\n [<0000021761645760>] process_one_work+0x2b0/0x5d0\n [<000002176164637e>] worker_thread+0x20e/0x3e0\n [<000002176165221a>] kthread+0x15a/0x170\n [<00000217615b859c>] __ret_from_fork+0x3c/0x60\n [<00000217626e72d2>] ret_from_fork+0xa/0x38\n INFO: lockdep is turned off.\n Last Breaking-Event-Address:\n [<0000021761597924>] _printk+0x4c/0x58\n Kernel panic - not syncing: Fatal exception: panic_on_oops

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Add a lock when accessing the buddy trim function\n\nWhen running YouTube videos and Steam games simultaneously,\nthe tester found a system hang / race condition issue with\nthe multi-display configuration setting. Adding a lock to\nthe buddy allocator's trim function would be the solution.\n\n<log snip>\n[ 7197.250436] general protection fault, probably for non-canonical address 0xdead000000000108\n[ 7197.250447] RIP: 0010:__alloc_range+0x8b/0x340 [amddrm_buddy]\n[ 7197.250470] Call Trace:\n[ 7197.250472] <TASK>\n[ 7197.250475] ? show_regs+0x6d/0x80\n[ 7197.250481] ? die_addr+0x37/0xa0\n[ 7197.250483] ? exc_general_protection+0x1db/0x480\n[ 7197.250488] ? drm_suballoc_new+0x13c/0x93d [drm_suballoc_helper]\n[ 7197.250493] ? asm_exc_general_protection+0x27/0x30\n[ 7197.250498] ? __alloc_range+0x8b/0x340 [amddrm_buddy]\n[ 7197.250501] ? __alloc_range+0x109/0x340 [amddrm_buddy]\n[ 7197.250506] amddrm_buddy_block_trim+0x1b5/0x260 [amddrm_buddy]\n[ 7197.250511] amdgpu_vram_mgr_new+0x4f5/0x590 [amdgpu]\n[ 7197.250682] amdttm_resource_alloc+0x46/0xb0 [amdttm]\n[ 7197.250689] ttm_bo_alloc_resource+0xe4/0x370 [amdttm]\n[ 7197.250696] amdttm_bo_validate+0x9d/0x180 [amdttm]\n[ 7197.250701] amdgpu_bo_pin+0x15a/0x2f0 [amdgpu]\n[ 7197.250831] amdgpu_dm_plane_helper_prepare_fb+0xb2/0x360 [amdgpu]\n[ 7197.251025] ? try_wait_for_completion+0x59/0x70\n[ 7197.251030] drm_atomic_helper_prepare_planes.part.0+0x2f/0x1e0\n[ 7197.251035] drm_atomic_helper_prepare_planes+0x5d/0x70\n[ 7197.251037] drm_atomic_helper_commit+0x84/0x160\n[ 7197.251040] drm_atomic_nonblocking_commit+0x59/0x70\n[ 7197.251043] drm_mode_atomic_ioctl+0x720/0x850\n[ 7197.251047] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10\n[ 7197.251049] drm_ioctl_kernel+0xb9/0x120\n[ 7197.251053] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 7197.251056] drm_ioctl+0x2d4/0x550\n[ 7197.251058] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10\n[ 7197.251063] amdgpu_drm_ioctl+0x4e/0x90 [amdgpu]\n[ 7197.251186] __x64_sys_ioctl+0xa0/0xf0\n[ 7197.251190] x64_sys_call+0x143b/0x25c0\n[ 7197.251193] do_syscall_64+0x7f/0x180\n[ 7197.251197] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 7197.251199] ? amdgpu_display_user_framebuffer_create+0x215/0x320 [amdgpu]\n[ 7197.251329] ? drm_internal_framebuffer_create+0xb7/0x1a0\n[ 7197.251332] ? srso_alias_return_thunk+0x5/0xfbef5\n\n(cherry picked from commit 3318ba94e56b9183d0304577c74b33b6b01ce516)

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: fix divide error in DM plane scale calcs\n\ndm_get_plane_scale doesn't take into account plane scaled size equal to\nzero, leading to a kernel oops due to division by zero. Fix by setting\nout-scale size as zero when the dst size is zero, similar to what is\ndone by drm_calc_scale(). This issue started with the introduction of\ncursor ovelay mode that uses this function to assess cursor mode changes\nvia dm_crtc_get_cursor_mode() before checking plane state.\n\n[Dec17 17:14] Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI\n[ +0.000018] CPU: 5 PID: 1660 Comm: surface-DP-1 Not tainted 6.10.0+ #231\n[ +0.000007] Hardware name: Valve Jupiter/Jupiter, BIOS F7A0131 01/30/2024\n[ +0.000004] RIP: 0010:dm_get_plane_scale+0x3f/0x60 [amdgpu]\n[ +0.000553] Code: 44 0f b7 41 3a 44 0f b7 49 3e 83 e0 0f 48 0f a3 c2 73 21 69 41 28 e8 03 00 00 31 d2 41 f7 f1 31 d2 89 06 69 41 2c e8 03 00 00 <41> f7 f0 89 07 e9 d7 d8 7e e9 44 89 c8 45 89 c1 41 89 c0 eb d4 66\n[ +0.000005] RSP: 0018:ffffa8df0de6b8a0 EFLAGS: 00010246\n[ +0.000006] RAX: 00000000000003e8 RBX: ffff9ac65c1f6e00 RCX: ffff9ac65d055500\n[ +0.000003] RDX: 0000000000000000 RSI: ffffa8df0de6b8b0 RDI: ffffa8df0de6b8b4\n[ +0.000004] RBP: ffff9ac64e7a5800 R08: 0000000000000000 R09: 0000000000000a00\n[ +0.000003] R10: 00000000000000ff R11: 0000000000000054 R12: ffff9ac6d0700010\n[ +0.000003] R13: ffff9ac65d054f00 R14: ffff9ac65d055500 R15: ffff9ac64e7a60a0\n[ +0.000004] FS: 00007f869ea00640(0000) GS:ffff9ac970080000(0000) knlGS:0000000000000000\n[ +0.000004] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ +0.000003] CR2: 000055ca701becd0 CR3: 000000010e7f2000 CR4: 0000000000350ef0\n[ +0.000004] Call Trace:\n[ +0.000007] <TASK>\n[ +0.000006] ? __die_body.cold+0x19/0x27\n[ +0.000009] ? die+0x2e/0x50\n[ +0.000007] ? do_trap+0xca/0x110\n[ +0.000007] ? do_error_trap+0x6a/0x90\n[ +0.000006] ? dm_get_plane_scale+0x3f/0x60 [amdgpu]\n[ +0.000504] ? exc_divide_error+0x38/0x50\n[ +0.000005] ? dm_get_plane_scale+0x3f/0x60 [amdgpu]\n[ +0.000488] ? asm_exc_divide_error+0x1a/0x20\n[ +0.000011] ? dm_get_plane_scale+0x3f/0x60 [amdgpu]\n[ +0.000593] dm_crtc_get_cursor_mode+0x33f/0x430 [amdgpu]\n[ +0.000562] amdgpu_dm_atomic_check+0x2ef/0x1770 [amdgpu]\n[ +0.000501] drm_atomic_check_only+0x5e1/0xa30 [drm]\n[ +0.000047] drm_mode_atomic_ioctl+0x832/0xcb0 [drm]\n[ +0.000050] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 [drm]\n[ +0.000047] drm_ioctl_kernel+0xb3/0x100 [drm]\n[ +0.000062] drm_ioctl+0x27a/0x4f0 [drm]\n[ +0.000049] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 [drm]\n[ +0.000055] amdgpu_drm_ioctl+0x4e/0x90 [amdgpu]\n[ +0.000360] __x64_sys_ioctl+0x97/0xd0\n[ +0.000010] do_syscall_64+0x82/0x190\n[ +0.000008] ? __pfx_drm_mode_createblob_ioctl+0x10/0x10 [drm]\n[ +0.000044] ? srso_return_thunk+0x5/0x5f\n[ +0.000006] ? drm_ioctl_kernel+0xb3/0x100 [drm]\n[ +0.000040] ? srso_return_thunk+0x5/0x5f\n[ +0.000005] ? __check_object_size+0x50/0x220\n[ +0.000007] ? srso_return_thunk+0x5/0x5f\n[ +0.000005] ? srso_return_thunk+0x5/0x5f\n[ +0.000005] ? drm_ioctl+0x2a4/0x4f0 [drm]\n[ +0.000039] ? __pfx_drm_mode_createblob_ioctl+0x10/0x10 [drm]\n[ +0.000043] ? srso_return_thunk+0x5/0x5f\n[ +0.000005] ? srso_return_thunk+0x5/0x5f\n[ +0.000005] ? __pm_runtime_suspend+0x69/0xc0\n[ +0.000006] ? srso_return_thunk+0x5/0x5f\n[ +0.000005] ? amdgpu_drm_ioctl+0x71/0x90 [amdgpu]\n[ +0.000366] ? srso_return_thunk+0x5/0x5f\n[ +0.000006] ? syscall_exit_to_user_mode+0x77/0x210\n[ +0.000007] ? srso_return_thunk+0x5/0x5f\n[ +0.000005] ? do_syscall_64+0x8e/0x190\n[ +0.000006] ? srso_return_thunk+0x5/0x5f\n[ +0.000006] ? do_syscall_64+0x8e/0x190\n[ +0.000006] ? srso_return_thunk+0x5/0x5f\n[ +0.000007] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[ +0.000008] RIP: 0033:0x55bb7cd962bc\n[ +0.000007] Code: 4c 89 6c 24 18 4c 89 64 24 20 4c 89 74 24 28 0f 57 c0 0f 11 44 24 30 89 c7 48 8d 54 24 08 b8 10 00 00 00 be bc 64 38 c0 0f 05 <49> 89 c7 48 83 3b 00 74 09 4c 89 c7 ff 15 62 64 99 00 48 83 7b 18\n[ +0.000005] RSP: 002b:00007f869e9f4da0 EFLAGS: 00000217 ORIG_RAX: 0000000000000010\n[ +0.000007] RAX: ffffffffffffffda RBX: 00007f869e9f4fb8 RCX: 000055bb7cd962bc\n[ +0.000004] RDX: 00007f869e9f4da8 RSI: 00000000c03864bc RDI: 000000000000003b\n[ +0.000003] RBP: 000055bb9ddcbcc0 R08: 00007f86541b9920 R09: 0000000000000009\n[ +0.000004] R10: 0000000000000004 R11: 0000000000000217 R12: 00007f865406c6b0\n[ +0.000003] R13: 00007f86541b5290 R14: 00007f865410b700 R15: 000055bb9ddcbc18\n[ +0.000009] </TASK>\n\n(cherry picked from commit ab75a0d2e07942ae15d32c0a5092fd336451378c)

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: fix page fault due to max surface definition mismatch\n\nDC driver is using two different values to define the maximum number of\nsurfaces: MAX_SURFACES and MAX_SURFACE_NUM. Consolidate MAX_SURFACES as\nthe unique definition for surface updates across DC.\n\nIt fixes page fault faced by Cosmic users on AMD display versions that\nsupport two overlay planes, since the introduction of cursor overlay\nmode.\n\n[Nov26 21:33] BUG: unable to handle page fault for address: 0000000051d0f08b\n[ +0.000015] #PF: supervisor read access in kernel mode\n[ +0.000006] #PF: error_code(0x0000) - not-present page\n[ +0.000005] PGD 0 P4D 0\n[ +0.000007] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI\n[ +0.000006] CPU: 4 PID: 71 Comm: kworker/u32:6 Not tainted 6.10.0+ #300\n[ +0.000006] Hardware name: Valve Jupiter/Jupiter, BIOS F7A0131 01/30/2024\n[ +0.000007] Workqueue: events_unbound commit_work [drm_kms_helper]\n[ +0.000040] RIP: 0010:copy_stream_update_to_stream.isra.0+0x30d/0x750 [amdgpu]\n[ +0.000847] Code: 8b 10 49 89 94 24 f8 00 00 00 48 8b 50 08 49 89 94 24 00 01 00 00 8b 40 10 41 89 84 24 08 01 00 00 49 8b 45 78 48 85 c0 74 0b <0f> b6 00 41 88 84 24 90 64 00 00 49 8b 45 60 48 85 c0 74 3b 48 8b\n[ +0.000010] RSP: 0018:ffffc203802f79a0 EFLAGS: 00010206\n[ +0.000009] RAX: 0000000051d0f08b RBX: 0000000000000004 RCX: ffff9f964f0a8070\n[ +0.000004] RDX: ffff9f9710f90e40 RSI: ffff9f96600c8000 RDI: ffff9f964f000000\n[ +0.000004] RBP: ffffc203802f79f8 R08: 0000000000000000 R09: 0000000000000000\n[ +0.000005] R10: 0000000000000000 R11: 0000000000000000 R12: ffff9f96600c8000\n[ +0.000004] R13: ffff9f9710f90e40 R14: ffff9f964f000000 R15: ffff9f96600c8000\n[ +0.000004] FS: 0000000000000000(0000) GS:ffff9f9970000000(0000) knlGS:0000000000000000\n[ +0.000005] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ +0.000005] CR2: 0000000051d0f08b CR3: 00000002e6a20000 CR4: 0000000000350ef0\n[ +0.000005] Call Trace:\n[ +0.000011] <TASK>\n[ +0.000010] ? __die_body.cold+0x19/0x27\n[ +0.000012] ? page_fault_oops+0x15a/0x2d0\n[ +0.000014] ? exc_page_fault+0x7e/0x180\n[ +0.000009] ? asm_exc_page_fault+0x26/0x30\n[ +0.000013] ? copy_stream_update_to_stream.isra.0+0x30d/0x750 [amdgpu]\n[ +0.000739] ? dc_commit_state_no_check+0xd6c/0xe70 [amdgpu]\n[ +0.000470] update_planes_and_stream_state+0x49b/0x4f0 [amdgpu]\n[ +0.000450] ? srso_return_thunk+0x5/0x5f\n[ +0.000009] ? commit_minimal_transition_state+0x239/0x3d0 [amdgpu]\n[ +0.000446] update_planes_and_stream_v2+0x24a/0x590 [amdgpu]\n[ +0.000464] ? srso_return_thunk+0x5/0x5f\n[ +0.000009] ? sort+0x31/0x50\n[ +0.000007] ? amdgpu_dm_atomic_commit_tail+0x159f/0x3a30 [amdgpu]\n[ +0.000508] ? srso_return_thunk+0x5/0x5f\n[ +0.000009] ? amdgpu_crtc_get_scanout_position+0x28/0x40 [amdgpu]\n[ +0.000377] ? srso_return_thunk+0x5/0x5f\n[ +0.000009] ? drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x160/0x390 [drm]\n[ +0.000058] ? srso_return_thunk+0x5/0x5f\n[ +0.000005] ? dma_fence_default_wait+0x8c/0x260\n[ +0.000010] ? srso_return_thunk+0x5/0x5f\n[ +0.000005] ? wait_for_completion_timeout+0x13b/0x170\n[ +0.000006] ? srso_return_thunk+0x5/0x5f\n[ +0.000005] ? dma_fence_wait_timeout+0x108/0x140\n[ +0.000010] ? commit_tail+0x94/0x130 [drm_kms_helper]\n[ +0.000024] ? process_one_work+0x177/0x330\n[ +0.000008] ? worker_thread+0x266/0x3a0\n[ +0.000006] ? __pfx_worker_thread+0x10/0x10\n[ +0.000004] ? kthread+0xd2/0x100\n[ +0.000006] ? __pfx_kthread+0x10/0x10\n[ +0.000006] ? ret_from_fork+0x34/0x50\n[ +0.000004] ? __pfx_kthread+0x10/0x10\n[ +0.000005] ? ret_from_fork_asm+0x1a/0x30\n[ +0.000011] </TASK>\n\n(cherry picked from commit 1c86c81a86c60f9b15d3e3f43af0363cf56063e7)

In the Linux kernel, the following vulnerability has been resolved:\n\nmisc: microchip: pci1xxxx: Resolve kernel panic during GPIO IRQ handling\n\nResolve kernel panic caused by improper handling of IRQs while\naccessing GPIO values. This is done by replacing generic_handle_irq with\nhandle_nested_irq.

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: tcpci: fix NULL pointer issue on shared irq case\n\nThe tcpci_irq() may meet below NULL pointer dereference issue:\n\n[ 2.641851] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010\n[ 2.641951] status 0x1, 0x37f\n[ 2.650659] Mem abort info:\n[ 2.656490] ESR = 0x0000000096000004\n[ 2.660230] EC = 0x25: DABT (current EL), IL = 32 bits\n[ 2.665532] SET = 0, FnV = 0\n[ 2.668579] EA = 0, S1PTW = 0\n[ 2.671715] FSC = 0x04: level 0 translation fault\n[ 2.676584] Data abort info:\n[ 2.679459] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n[ 2.684936] CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[ 2.689980] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[ 2.695284] [0000000000000010] user address but active_mm is swapper\n[ 2.701632] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n[ 2.707883] Modules linked in:\n[ 2.710936] CPU: 1 UID: 0 PID: 87 Comm: irq/111-2-0051 Not tainted 6.12.0-rc6-06316-g7f63786ad3d1-dirty #4\n[ 2.720570] Hardware name: NXP i.MX93 11X11 EVK board (DT)\n[ 2.726040] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 2.732989] pc : tcpci_irq+0x38/0x318\n[ 2.736647] lr : _tcpci_irq+0x14/0x20\n[ 2.740295] sp : ffff80008324bd30\n[ 2.743597] x29: ffff80008324bd70 x28: ffff800080107894 x27: ffff800082198f70\n[ 2.750721] x26: ffff0000050e6680 x25: ffff000004d172ac x24: ffff0000050f0000\n[ 2.757845] x23: ffff000004d17200 x22: 0000000000000001 x21: ffff0000050f0000\n[ 2.764969] x20: ffff000004d17200 x19: 0000000000000000 x18: 0000000000000001\n[ 2.772093] x17: 0000000000000000 x16: ffff80008183d8a0 x15: ffff00007fbab040\n[ 2.779217] x14: ffff00007fb918c0 x13: 0000000000000000 x12: 000000000000017a\n[ 2.786341] x11: 0000000000000001 x10: 0000000000000a90 x9 : ffff80008324bd00\n[ 2.793465] x8 : ffff0000050f0af0 x7 : ffff00007fbaa840 x6 : 0000000000000031\n[ 2.800589] x5 : 000000000000017a x4 : 0000000000000002 x3 : 0000000000000002\n[ 2.807713] x2 : ffff80008324bd3a x1 : 0000000000000010 x0 : 0000000000000000\n[ 2.814838] Call trace:\n[ 2.817273] tcpci_irq+0x38/0x318\n[ 2.820583] _tcpci_irq+0x14/0x20\n[ 2.823885] irq_thread_fn+0x2c/0xa8\n[ 2.827456] irq_thread+0x16c/0x2f4\n[ 2.830940] kthread+0x110/0x114\n[ 2.834164] ret_from_fork+0x10/0x20\n[ 2.837738] Code: f9426420 f9001fe0 d2800000 52800201 (f9400a60)\n\nThis may happen on shared irq case. Such as two Type-C ports share one\nirq. After the first port finished tcpci_register_port(), it may trigger\ninterrupt. However, if the interrupt comes by chance the 2nd port finishes\ndevm_request_threaded_irq(), the 2nd port interrupt handler will run at\nfirst. Then the above issue happens due to tcpci is still a NULL pointer\nin tcpci_irq() when dereference to regmap.\n\n devm_request_threaded_irq()\n <-- port1 irq comes\n disable_irq(client->irq);\n tcpci_register_port()\n\nThis will restore the logic to the state before commit (77e85107a771 "usb:\ntypec: tcpci: support edge irq").\n\nHowever, moving tcpci_register_port() earlier creates a problem when use\nedge irq because tcpci_init() will be called before\ndevm_request_threaded_irq(). The tcpci_init() writes the ALERT_MASK to\nthe hardware to tell it to start generating interrupts but we're not ready\nto deal with them yet, then the ALERT events may be missed and ALERT line\nwill not recover to high level forever. To avoid the issue, this will also\nset ALERT_MASK register after devm_request_threaded_irq() return.

In the Linux kernel, the following vulnerability has been resolved:\n\niio: adc: ti-ads1119: fix information leak in triggered buffer\n\nThe 'scan' local struct is used to push data to user space from a\ntriggered buffer, but it has a hole between the sample (unsigned int)\nand the timestamp. This hole is never initialized.\n\nInitialize the struct to zero before using it to avoid pushing\nuninitialized information to userspace.

漏洞存在于Linux内核的clocksource模块，漏洞成因是使用了不合适的组合EXPORT_SYMBOL和__init，导致初始化后释放的符号被访问。影响版本5.3<=版本<5.19

漏洞存在于Linux内核的块设备（block）模块，漏洞成因是在处理离线队列时，`blk_mq_alloc_request_hctx()`函数中存在索引越界问题。影响版本4.16<=版本<5.19

漏洞存在于Linux内核的dm-log模块，漏洞成因是bitset_size向上取整时未充分考虑unsignedlong指针在64位架构下的访问范围。影响版本2.6.18<=版本<5.19

In the Linux kernel, the following vulnerability has been resolved:\n\nsfc: fix use after free when disabling sriov\n\nUse after free is detected by kfence when disabling sriov. What was read\nafter being freed was vf->pci_dev: it was freed from pci_disable_sriov\nand later read in efx_ef10_sriov_free_vf_vports, called from\nefx_ef10_sriov_free_vf_vswitching.\n\nSet the pointer to NULL at release time to not trying to read it later.\n\nReproducer and dmesg log (note that kfence doesn't detect it every time):\n$ echo 1 > /sys/class/net/enp65s0f0np0/device/sriov_numvfs\n$ echo 0 > /sys/class/net/enp65s0f0np0/device/sriov_numvfs\n\n BUG: KFENCE: use-after-free read in efx_ef10_sriov_free_vf_vswitching+0x82/0x170 [sfc]\n\n Use-after-free read at 0x00000000ff3c1ba5 (in kfence-#224):\n efx_ef10_sriov_free_vf_vswitching+0x82/0x170 [sfc]\n efx_ef10_pci_sriov_disable+0x38/0x70 [sfc]\n efx_pci_sriov_configure+0x24/0x40 [sfc]\n sriov_numvfs_store+0xfe/0x140\n kernfs_fop_write_iter+0x11c/0x1b0\n new_sync_write+0x11f/0x1b0\n vfs_write+0x1eb/0x280\n ksys_write+0x5f/0xe0\n do_syscall_64+0x5c/0x80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\n kfence-#224: 0x00000000edb8ef95-0x00000000671f5ce1, size=2792, cache=kmalloc-4k\n\n allocated by task 6771 on cpu 10 at 3137.860196s:\n pci_alloc_dev+0x21/0x60\n pci_iov_add_virtfn+0x2a2/0x320\n sriov_enable+0x212/0x3e0\n efx_ef10_sriov_configure+0x67/0x80 [sfc]\n efx_pci_sriov_configure+0x24/0x40 [sfc]\n sriov_numvfs_store+0xba/0x140\n kernfs_fop_write_iter+0x11c/0x1b0\n new_sync_write+0x11f/0x1b0\n vfs_write+0x1eb/0x280\n ksys_write+0x5f/0xe0\n do_syscall_64+0x5c/0x80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\n freed by task 6771 on cpu 12 at 3170.991309s:\n device_release+0x34/0x90\n kobject_cleanup+0x3a/0x130\n pci_iov_remove_virtfn+0xd9/0x120\n sriov_disable+0x30/0xe0\n efx_ef10_pci_sriov_disable+0x57/0x70 [sfc]\n efx_pci_sriov_configure+0x24/0x40 [sfc]\n sriov_numvfs_store+0xfe/0x140\n kernfs_fop_write_iter+0x11c/0x1b0\n new_sync_write+0x11f/0x1b0\n vfs_write+0x1eb/0x280\n ksys_write+0x5f/0xe0\n do_syscall_64+0x5c/0x80\n entry_SYSCALL_64_after_hwframe+0x44/0xae

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/disp/dpu1: set vbif hw config to NULL to avoid use after memory free during pm runtime resume\n\nBUG: Unable to handle kernel paging request at virtual address 006b6b6b6b6b6be3\n\nCall trace:\n dpu_vbif_init_memtypes+0x40/0xb8\n dpu_runtime_resume+0xcc/0x1c0\n pm_generic_runtime_resume+0x30/0x44\n __genpd_runtime_resume+0x68/0x7c\n genpd_runtime_resume+0x134/0x258\n __rpm_callback+0x98/0x138\n rpm_callback+0x30/0x88\n rpm_resume+0x36c/0x49c\n __pm_runtime_resume+0x80/0xb0\n dpu_core_irq_uninstall+0x30/0xb0\n dpu_irq_uninstall+0x18/0x24\n msm_drm_uninit+0xd8/0x16c\n\nPatchwork: https://patchwork.freedesktop.org/patch/483255/\n[DB: fixed Fixes tag]

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: btmtksdio: fix use-after-free at btmtksdio_recv_event\n\nWe should not access skb buffer data anymore after hci_recv_frame was\ncalled.\n\n[ 39.634809] BUG: KASAN: use-after-free in btmtksdio_recv_event+0x1b0\n[ 39.634855] Read of size 1 at addr ffffff80cf28a60d by task kworker\n[ 39.634962] Call trace:\n[ 39.634974] dump_backtrace+0x0/0x3b8\n[ 39.634999] show_stack+0x20/0x2c\n[ 39.635016] dump_stack_lvl+0x60/0x78\n[ 39.635040] print_address_description+0x70/0x2f0\n[ 39.635062] kasan_report+0x154/0x194\n[ 39.635079] __asan_report_load1_noabort+0x44/0x50\n[ 39.635099] btmtksdio_recv_event+0x1b0/0x1c4\n[ 39.635129] btmtksdio_txrx_work+0x6cc/0xac4\n[ 39.635157] process_one_work+0x560/0xc5c\n[ 39.635177] worker_thread+0x7ec/0xcc0\n[ 39.635195] kthread+0x2d0/0x3d0\n[ 39.635215] ret_from_fork+0x10/0x20\n[ 39.635247] Allocated by task 0:\n[ 39.635260] (stack is not available)\n[ 39.635281] Freed by task 2392:\n[ 39.635295] kasan_save_stack+0x38/0x68\n[ 39.635319] kasan_set_track+0x28/0x3c\n[ 39.635338] kasan_set_free_info+0x28/0x4c\n[ 39.635357] ____kasan_slab_free+0x104/0x150\n[ 39.635374] __kasan_slab_free+0x18/0x28\n[ 39.635391] slab_free_freelist_hook+0x114/0x248\n[ 39.635410] kfree+0xf8/0x2b4\n[ 39.635427] skb_free_head+0x58/0x98\n[ 39.635447] skb_release_data+0x2f4/0x410\n[ 39.635464] skb_release_all+0x50/0x60\n[ 39.635481] kfree_skb+0xc8/0x25c\n[ 39.635498] hci_event_packet+0x894/0xca4 [bluetooth]\n[ 39.635721] hci_rx_work+0x1c8/0x68c [bluetooth]\n[ 39.635925] process_one_work+0x560/0xc5c\n[ 39.635951] worker_thread+0x7ec/0xcc0\n[ 39.635970] kthread+0x2d0/0x3d0\n[ 39.635990] ret_from_fork+0x10/0x20\n[ 39.636021] The buggy address belongs to the object at ffffff80cf28a600\n which belongs to the cache kmalloc-512 of size 512\n[ 39.636039] The buggy address is located 13 bytes inside of\n 512-byte region [ffffff80cf28a600, ffffff80cf28a800)

In the Linux kernel, the following vulnerability has been resolved:\n\nmisc: ocxl: fix possible double free in ocxl_file_register_afu\n\ninfo_release() will be called in device_unregister() when info->dev's\nreference count is 0. So there is no need to call ocxl_afu_put() and\nkfree() again.\n\nFix this by adding free_minor() and return to err_unregister error path.

In the Linux kernel, the following vulnerability has been resolved:\n\nbfq: Update cgroup information before merging bio\n\nWhen the process is migrated to a different cgroup (or in case of\nwriteback just starts submitting bios associated with a different\ncgroup) bfq_merge_bio() can operate with stale cgroup information in\nbic. Thus the bio can be merged to a request from a different cgroup or\nit can result in merging of bfqqs for different cgroups or bfqqs of\nalready dead cgroups and causing possible use-after-free issues. Fix the\nproblem by updating cgroup information in bfq_merge_bio().

In the Linux kernel, the following vulnerability has been resolved:\n\nbfq: Make sure bfqg for which we are queueing requests is online\n\nBios queued into BFQ IO scheduler can be associated with a cgroup that\nwas already offlined. This may then cause insertion of this bfq_group\ninto a service tree. But this bfq_group will get freed as soon as last\nbio associated with it is completed leading to use after free issues for\nservice tree users. Fix the problem by making sure we always operate on\nonline bfq_group. If the bfq_group associated with the bio is not\nonline, we pick the first online parent.

In the Linux kernel, the following vulnerability has been resolved:\n\num: Fix out-of-bounds read in LDT setup\n\nsyscall_stub_data() expects the data_count parameter to be the number of\nlongs, not bytes.\n\n ==================================================================\n BUG: KASAN: stack-out-of-bounds in syscall_stub_data+0x70/0xe0\n Read of size 128 at addr 000000006411f6f0 by task swapper/1\n\n CPU: 0 PID: 1 Comm: swapper Not tainted 5.18.0+ #18\n Call Trace:\n show_stack.cold+0x166/0x2a7\n __dump_stack+0x3a/0x43\n dump_stack_lvl+0x1f/0x27\n print_report.cold+0xdb/0xf81\n kasan_report+0x119/0x1f0\n kasan_check_range+0x3a3/0x440\n memcpy+0x52/0x140\n syscall_stub_data+0x70/0xe0\n write_ldt_entry+0xac/0x190\n init_new_ldt+0x515/0x960\n init_new_context+0x2c4/0x4d0\n mm_init.constprop.0+0x5ed/0x760\n mm_alloc+0x118/0x170\n 0x60033f48\n do_one_initcall+0x1d7/0x860\n 0x60003e7b\n kernel_init+0x6e/0x3d4\n new_thread_handler+0x1e7/0x2c0\n\n The buggy address belongs to stack of task swapper/1\n and is located at offset 64 in frame:\n init_new_ldt+0x0/0x960\n\n This frame has 2 objects:\n [32, 40) 'addr'\n [64, 80) 'desc'\n ==================================================================

In the Linux kernel, the following vulnerability has been resolved:\n\nubi: ubi_create_volume: Fix use-after-free when volume creation failed\n\nThere is an use-after-free problem for 'eba_tbl' in ubi_create_volume()'s\nerror handling path:\n\n ubi_eba_replace_table(vol, eba_tbl)\n vol->eba_tbl = tbl\nout_mapping:\n ubi_eba_destroy_table(eba_tbl) // Free 'eba_tbl'\nout_unlock:\n put_device(&vol->dev)\n vol_release\n kfree(tbl->entries) // UAF\n\nFix it by removing redundant 'eba_tbl' releasing.\nFetch a reproducer in [Link].

In the Linux kernel, the following vulnerability has been resolved:\n\ndriver: base: fix UAF when driver_attach failed\n\nWhen driver_attach(drv); failed, the driver_private will be freed.\nBut it has been added to the bus, which caused a UAF.\n\nTo fix it, we need to delete it from the bus when failed.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ethernet: mtk_eth_soc: out of bounds read in mtk_hwlro_get_fdir_entry()\n\nThe "fsp->location" variable comes from user via ethtool_get_rxnfc().\nCheck that it is valid to prevent an out of bounds read.

In the Linux kernel, the following vulnerability has been resolved:\n\nSUNRPC: Trap RDMA segment overflows\n\nPrevent svc_rdma_build_writes() from walking off the end of a Write\nchunk's segment array. Caught with KASAN.\n\nThe test that this fix replaces is invalid, and might have been left\nover from an earlier prototype of the PCL work.

In the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: prevent underflow in nfssvc_decode_writeargs()\n\nSmatch complains:\n\n fs/nfsd/nfsxdr.c:341 nfssvc_decode_writeargs()\n warn: no lower bound on 'args->len'\n\nChange the type to unsigned to prevent this issue.

In the Linux kernel, the following vulnerability has been resolved:\n\ncan: m_can: m_can_tx_handler(): fix use after free of skb\n\ncan_put_echo_skb() will clone skb then free the skb. Move the\ncan_put_echo_skb() for the m_can version 3.0.x directly before the\nstart of the xmit in hardware, similar to the 3.1.x branch.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/gem: add missing boundary check in vm_access\n\nA missing bounds check in vm_access() can lead to an out-of-bounds read\nor write in the adjacent memory area, since the len attribute is not\nvalidated before the memcpy later in the function, potentially hitting:\n\n[ 183.637831] BUG: unable to handle page fault for address: ffffc90000c86000\n[ 183.637934] #PF: supervisor read access in kernel mode\n[ 183.637997] #PF: error_code(0x0000) - not-present page\n[ 183.638059] PGD 100000067 P4D 100000067 PUD 100258067 PMD 106341067 PTE 0\n[ 183.638144] Oops: 0000 [#2] PREEMPT SMP NOPTI\n[ 183.638201] CPU: 3 PID: 1790 Comm: poc Tainted: G D 5.17.0-rc6-ci-drm-11296+ #1\n[ 183.638298] Hardware name: Intel Corporation CoffeeLake Client Platform/CoffeeLake H DDR4 RVP, BIOS CNLSFWR1.R00.X208.B00.1905301319 05/30/2019\n[ 183.638430] RIP: 0010:memcpy_erms+0x6/0x10\n[ 183.640213] RSP: 0018:ffffc90001763d48 EFLAGS: 00010246\n[ 183.641117] RAX: ffff888109c14000 RBX: ffff888111bece40 RCX: 0000000000000ffc\n[ 183.642029] RDX: 0000000000001000 RSI: ffffc90000c86000 RDI: ffff888109c14004\n[ 183.642946] RBP: 0000000000000ffc R08: 800000000000016b R09: 0000000000000000\n[ 183.643848] R10: ffffc90000c85000 R11: 0000000000000048 R12: 0000000000001000\n[ 183.644742] R13: ffff888111bed190 R14: ffff888109c14000 R15: 0000000000001000\n[ 183.645653] FS: 00007fe5ef807540(0000) GS:ffff88845b380000(0000) knlGS:0000000000000000\n[ 183.646570] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 183.647481] CR2: ffffc90000c86000 CR3: 000000010ff02006 CR4: 00000000003706e0\n[ 183.648384] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 183.649271] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 183.650142] Call Trace:\n[ 183.650988] <TASK>\n[ 183.651793] vm_access+0x1f0/0x2a0 [i915]\n[ 183.652726] __access_remote_vm+0x224/0x380\n[ 183.653561] mem_rw.isra.0+0xf9/0x190\n[ 183.654402] vfs_read+0x9d/0x1b0\n[ 183.655238] ksys_read+0x63/0xe0\n[ 183.656065] do_syscall_64+0x38/0xc0\n[ 183.656882] entry_SYSCALL_64_after_hwframe+0x44/0xae\n[ 183.657663] RIP: 0033:0x7fe5ef725142\n[ 183.659351] RSP: 002b:00007ffe1e81c7e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000\n[ 183.660227] RAX: ffffffffffffffda RBX: 0000557055dfb780 RCX: 00007fe5ef725142\n[ 183.661104] RDX: 0000000000001000 RSI: 00007ffe1e81d880 RDI: 0000000000000005\n[ 183.661972] RBP: 00007ffe1e81e890 R08: 0000000000000030 R09: 0000000000000046\n[ 183.662832] R10: 0000557055dfc2e0 R11: 0000000000000246 R12: 0000557055dfb1c0\n[ 183.663691] R13: 00007ffe1e81e980 R14: 0000000000000000 R15: 0000000000000000\n\nChanges since v1:\n - Updated if condition with range_overflows_t [Chris Wilson]\n\n[mauld: tidy up the commit message and add Cc: stable]\n(cherry picked from commit 661412e301e2ca86799aa4f400d1cf0bd38c57c6)

In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: ccree - Fix use after free in cc_cipher_exit()\n\nkfree_sensitive(ctx_p->user.key) will free the ctx_p->user.key. But\nctx_p->user.key is still used in the next line, which will lead to a\nuse after free.\n\nWe can call kfree_sensitive() after dev_dbg() to avoid the uaf.

In the Linux kernel, the following vulnerability has been resolved:\n\nmt76: mt7921: fix crash when startup fails.\n\nIf the nic fails to start, it is possible that the\nreset_work has already been scheduled. Ensure the\nwork item is canceled so we do not have use-after-free\ncrash in case cleanup is called before the work item\nis executed.\n\nThis fixes crash on my x86_64 apu2 when mt7921k radio\nfails to work. Radio still fails, but OS does not\ncrash.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: mpt3sas: Fix use after free in _scsih_expander_node_remove()\n\nThe function mpt3sas_transport_port_remove() called in\n_scsih_expander_node_remove() frees the port field of the sas_expander\nstructure, leading to the following use-after-free splat from KASAN when\nthe ioc_info() call following that function is executed (e.g. when doing\nrmmod of the driver module):\n\n[ 3479.371167] ==================================================================\n[ 3479.378496] BUG: KASAN: use-after-free in _scsih_expander_node_remove+0x710/0x750 [mpt3sas]\n[ 3479.386936] Read of size 1 at addr ffff8881c037691c by task rmmod/1531\n[ 3479.393524]\n[ 3479.395035] CPU: 18 PID: 1531 Comm: rmmod Not tainted 5.17.0-rc8+ #1436\n[ 3479.401712] Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.1 06/02/2021\n[ 3479.409263] Call Trace:\n[ 3479.411743] <TASK>\n[ 3479.413875] dump_stack_lvl+0x45/0x59\n[ 3479.417582] print_address_description.constprop.0+0x1f/0x120\n[ 3479.423389] ? _scsih_expander_node_remove+0x710/0x750 [mpt3sas]\n[ 3479.429469] kasan_report.cold+0x83/0xdf\n[ 3479.433438] ? _scsih_expander_node_remove+0x710/0x750 [mpt3sas]\n[ 3479.439514] _scsih_expander_node_remove+0x710/0x750 [mpt3sas]\n[ 3479.445411] ? _raw_spin_unlock_irqrestore+0x2d/0x40\n[ 3479.452032] scsih_remove+0x525/0xc90 [mpt3sas]\n[ 3479.458212] ? mpt3sas_expander_remove+0x1d0/0x1d0 [mpt3sas]\n[ 3479.465529] ? down_write+0xde/0x150\n[ 3479.470746] ? up_write+0x14d/0x460\n[ 3479.475840] ? kernfs_find_ns+0x137/0x310\n[ 3479.481438] pci_device_remove+0x65/0x110\n[ 3479.487013] __device_release_driver+0x316/0x680\n[ 3479.493180] driver_detach+0x1ec/0x2d0\n[ 3479.498499] bus_remove_driver+0xe7/0x2d0\n[ 3479.504081] pci_unregister_driver+0x26/0x250\n[ 3479.510033] _mpt3sas_exit+0x2b/0x6cf [mpt3sas]\n[ 3479.516144] __x64_sys_delete_module+0x2fd/0x510\n[ 3479.522315] ? free_module+0xaa0/0xaa0\n[ 3479.527593] ? __cond_resched+0x1c/0x90\n[ 3479.532951] ? lockdep_hardirqs_on_prepare+0x273/0x3e0\n[ 3479.539607] ? syscall_enter_from_user_mode+0x21/0x70\n[ 3479.546161] ? trace_hardirqs_on+0x1c/0x110\n[ 3479.551828] do_syscall_64+0x35/0x80\n[ 3479.556884] entry_SYSCALL_64_after_hwframe+0x44/0xae\n[ 3479.563402] RIP: 0033:0x7f1fc482483b\n...\n[ 3479.943087] ==================================================================\n\nFix this by introducing the local variable port_id to store the port ID\nvalue before executing mpt3sas_transport_port_remove(). This local variable\nis then used in the call to ioc_info() instead of dereferencing the freed\nport structure.

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/hfi1: Fix use-after-free bug for mm struct\n\nUnder certain conditions, such as MPI_Abort, the hfi1 cleanup code may\nrepresent the last reference held on the task mm.\nhfi1_mmu_rb_unregister() then drops the last reference and the mm is freed\nbefore the final use in hfi1_release_user_pages(). A new task may\nallocate the mm structure while it is still being used, resulting in\nproblems. One manifestation is corruption of the mmap_sem counter leading\nto a hang in down_write(). Another is corruption of an mm struct that is\nin use by another task.

In the Linux kernel, the following vulnerability has been resolved:\n\nubifs: rename_whiteout: Fix double free for whiteout_ui->data\n\n'whiteout_ui->data' will be freed twice if space budget fail for\nrename whiteout operation as following process:\n\nrename_whiteout\n dev = kmalloc\n whiteout_ui->data = dev\n kfree(whiteout_ui->data) // Free first time\n iput(whiteout)\n ubifs_free_inode\n kfree(ui->data) // Double free!\n\nKASAN reports:\n==================================================================\nBUG: KASAN: double-free or invalid-free in ubifs_free_inode+0x4f/0x70\nCall Trace:\n kfree+0x117/0x490\n ubifs_free_inode+0x4f/0x70 [ubifs]\n i_callback+0x30/0x60\n rcu_do_batch+0x366/0xac0\n __do_softirq+0x133/0x57f\n\nAllocated by task 1506:\n kmem_cache_alloc_trace+0x3c2/0x7a0\n do_rename+0x9b7/0x1150 [ubifs]\n ubifs_rename+0x106/0x1f0 [ubifs]\n do_syscall_64+0x35/0x80\n\nFreed by task 1506:\n kfree+0x117/0x490\n do_rename.cold+0x53/0x8a [ubifs]\n ubifs_rename+0x106/0x1f0 [ubifs]\n do_syscall_64+0x35/0x80\n\nThe buggy address belongs to the object at ffff88810238bed8 which\nbelongs to the cache kmalloc-8 of size 8\n==================================================================\n\nLet ubifs_free_inode() free 'whiteout_ui->data'. BTW, delete unused\nassignment 'whiteout_ui->data_len = 0', process 'ubifs_evict_inode()\n-> ubifs_jnl_delete_inode() -> ubifs_jnl_write_inode()' doesn't need it\n(because 'inc_nlink(whiteout)' won't be excuted by 'goto out_release',\n and the nlink of whiteout inode is 0).

A flaw was found in PostgreSQL. Due to improper neutralization of quoting syntax, affected versions potentially allow a database input provider to achieve SQL injection in certain usage patterns. Specifically, SQL injection requires the application to use the affected function's result to construct input to psql, the PostgreSQL interactive terminal. Similarly, improper neutralization of quoting syntax in PostgreSQL command line utility programs allows a source of command line arguments to achieve SQL injection when `client_encoding` is `BIG5` and `server_encoding` is one of `EUC_TW` or `MULE_INTERNAL`.

libcurl's ASN1 parser code has the `GTime2str()` function, used for parsing an\nASN.1 Generalized Time field. If given an syntactically incorrect field, the\nparser might end up using -1 for the length of the *time fraction*, leading to\na `strlen()` getting performed on a pointer to a heap buffer area that is not\n(purposely) null terminated.\nThis flaw most likely leads to a crash, but can also lead to heap contents\ngetting returned to the application when\n[CURLINFO_CERTINFO](https://curl.se/libcurl/c/CURLINFO_CERTINFO.html) is used.

On Darwin, building a Go module which contains CGO can trigger arbitrary code execution when using the Apple version of ld, due to usage of the @executable_path, @loader_path, or @rpath special values in a "#cgo LDFLAGS" directive. This issue only affected go1.24rc2.

Due to the usage of a variable time instruction in the assembly implementation of an internal function, a small number of bits of secret scalars are leaked on the ppc64le architecture. Due to the way this function is used, we do not believe this leakage is enough to allow recovery of the private key when P-256 is used in any well known protocols.

Using ParsePKCS1PrivateKey to parse a RSA key that is missing the CRT values would panic when verifying that the key is well formed.

A vulnerability was found in GNU Binutils 2.43 and classified as problematic. Affected by this issue is the function link_order_scan of the file ld/ldelfgen.c of the component ld. The manipulation leads to memory leak. The attack may be launched remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."

The z-order of the browser windows could be manipulated to hide the fullscreen notification. This could potentially be leveraged to perform a spoofing attack. This vulnerability affects Firefox < 135 and Thunderbird < 135.

The Python standard library functions `urllib.parse.urlsplit` and `urlparse` accepted domain names that included square brackets which isn't valid according to RFC 3986. Square brackets are only meant to be used as delimiters for specifying IPv6 and IPvFuture hosts in URLs. This could result in differential parsing across the Python URL parser and other specification-compliant URL parsers..

A vulnerability, which was classified as problematic, was found in GNU Binutils up to 2.43. This affects the function disassemble_bytes of the file binutils/objdump.c. The manipulation of the argument buf leads to stack-based buffer overflow. It is possible to initiate the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. Upgrading to version 2.44 is able to address this issue. The identifier of the patch is baac6c221e9d69335bf41366a1c7d87d8ab2f893. It is recommended to upgrade the affected component.

When libcurl is asked to perform automatic gzip decompression of\ncontent-encoded HTTP responses with the `CURLOPT_ACCEPT_ENCODING` option,\n**using zlib 1.2.0.3 or older**, an attacker-controlled integer overflow would\nmake libcurl perform a buffer overflow.

An insufficient entropy vulnerability was found in glibc. The getrandom and arc4random family of functions may return predictable randomness if these functions are called again after the fork, which happens concurrently with a call to any of these functions..

When asked to use a `.netrc` file for credentials **and** to follow HTTP\nredirects, curl could leak the password used for the first host to the\nfollowed-to host under certain circumstances.\n\nThis flaw only manifests itself if the netrc file has a `default` entry that\nomits both login and password. A rare circumstance.

GNU GRUB (aka GRUB2) through 2.12 does not use a constant-time algorithm for grub_crypto_memcmp and thus allows side-channel attacks.

Git is a source code management tool. When cloning from a server (or fetching, or pushing), informational or error messages are transported from the remote Git process to the client via the so-called "sideband channel". These messages will be prefixed with "remote:" and printed directly to the standard error output. Typically, this standard error output is connected to a terminal that understands ANSI escape sequences, which Git did not protect against. Most modern terminals support control sequences that can be used by a malicious actor to hide and misrepresent information, or to mislead the user into executing untrusted scripts. As requested on the git-security mailing list, the patches are under discussion on the public mailing list. Users are advised to update as soon as possible. Users unable to upgrade should avoid recursive clones unless they are from trusted sources.

Due to the improper handling of batch files in child_process.spawn / child_process.spawnSync, a malicious command line argument can inject arbitrary commands and achieve code execution even if the shell option is not enabled..

Issue summary: A timing side-channel which could potentially allow recovering\nthe private key exists in the ECDSA signature computation.\n\nImpact summary: A timing side-channel in ECDSA signature computations\ncould allow recovering the private key by an attacker. However, measuring\nthe timing would require either local access to the signing application or\na very fast network connection with low latency.\n\nThere is a timing signal of around 300 nanoseconds when the top word of\nthe inverted ECDSA nonce value is zero. This can happen with significant\nprobability only for some of the supported elliptic curves. In particular\nthe NIST P-521 curve is affected. To be able to measure this leak, the attacker\nprocess must either be located in the same physical computer or must\nhave a very fast network connection with low latency. For that reason\nthe severity of this vulnerability is Low.

A flaw was found in rsync. This vulnerability arises from a race condition during rsync's handling of symbolic links. Rsync's default behavior when encountering symbolic links is to skip them. If an attacker replaced a regular file with a symbolic link at the right time, it was possible to bypass the default behavior and traverse symbolic links. Depending on the privileges of the rsync process, an attacker could leak sensitive information, potentially leading to privilege escalation..

Clients using DNS-over-HTTPS (DoH) can exhaust a DNS resolver's CPU and/or memory by flooding it with crafted valid or invalid HTTP/2 traffic.\nThis issue affects BIND 9 versions 9.18.0 through 9.18.32, 9.20.0 through 9.20.4, 9.21.0 through 9.21.3, and 9.18.11-S1 through 9.18.32-S1..

A flaw was found in rsync. When using the `--safe-links` option, the rsync client fails to properly verify if a symbolic link destination sent from the server contains another symbolic link within it. This results in a path traversal vulnerability, which may lead to arbitrary file write outside the desired directory.

A path traversal vulnerability exists in rsync. It stems from behavior enabled by the `--inc-recursive` option, a default-enabled option for many client options and can be enabled by the server even if not explicitly enabled by the client. When using the `--inc-recursive` option, a lack of proper symlink verification coupled with deduplication checks occurring on a per-file-list basis could allow a server to write files outside of the client's intended destination directory. A malicious server could write malicious files to arbitrary locations named after valid directories/paths on the client..

A flaw was found in rsync. It could allow a server to enumerate the contents of an arbitrary file from the client's machine. This issue occurs when files are being copied from a client to a server. During this process, the rsync server will send checksums of local data to the client to compare with in order to determine what data needs to be sent to the server. By sending specially constructed checksum values for arbitrary files, an attacker may be able to reconstruct the data of those files byte-by-byte based on the responses from the client..

It is possible to construct a zone such that some queries to it will generate responses containing numerous records in the Additional section. An attacker sending many such queries can cause either the authoritative server itself or an independent resolver to use disproportionate resources processing the queries. Zones will usually need to have been deliberately crafted to attack this exposure.\nThis issue affects BIND 9 versions 9.11.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.32, 9.20.0 through 9.20.4, 9.21.0 through 9.21.3, 9.11.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.32-S1.

NVIDIA Container Toolkit contains an improper isolation vulnerability where a specially crafted container image could lead to modification of a host binary. A successful exploit of this vulnerability may lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering.

A flaw was found in libxml2 where improper handling of memory allocation failures in `libxml2` can lead to crashes, memory leaks, or inconsistent states. While an attacker cannot directly control allocation failures, they may trigger denial-of-service conditions under extreme system stress.

A flaw in Mozilla's embedded certificate code might allow web sites to install root certificates on devices without user approval.

In the Linux kernel, the following vulnerability has been resolved:\nnet: sched: fix ets qdisc OOB Indexing\nHaowei Yan found that ets_class_from_arg() can\nindex an Out-Of-Bound class in ets_class_from_arg() when passed clid of\n0. The overflow may cause local privilege escalation.\n[ 18.852298] ------------[ cut here ]------------\n[ 18.853271] UBSAN: array-index-out-of-bounds in net/sched/sch_ets.c:93:20\n[ 18.853743] index 18446744073709551615 is out of range for type 'ets_class [16]'\n[ 18.854254] CPU: 0 UID: 0 PID: 1275 Comm: poc Not tainted 6.12.6-dirty #17\n[ 18.854821] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n[ 18.856532] Call Trace:\n[ 18.857441] \n[ 18.858227] dump_stack_lvl+0xc2/0xf0\n[ 18.859607] dump_stack+0x10/0x20\n[ 18.860908] __ubsan_handle_out_of_bounds+0xa7/0xf0\n[ 18.864022] ets_class_change+0x3d6/0x3f0\n[ 18.864322] tc_ctl_tclass+0x251/0x910\n[ 18.864587] ? lock_acquire+0x5e/0x140\n[ 18.865113] ? __mutex_lock+0x9c/0xe70\n[ 18.866009] ? __mutex_lock+0xa34/0xe70\n[ 18.866401] rtnetlink_rcv_msg+0x170/0x6f0\n[ 18.866806] ? __lock_acquire+0x578/0xc10\n[ 18.867184] ? __pfx_rtnetlink_rcv_msg+0x10/0x10\n[ 18.867503] netlink_rcv_skb+0x59/0x110\n[ 18.867776] rtnetlink_rcv+0x15/0x30\n[ 18.868159] netlink_unicast+0x1c3/0x2b0\n[ 18.868440] netlink_sendmsg+0x239/0x4b0\n[ 18.868721] ____sys_sendmsg+0x3e2/0x410\n[ 18.869012] ___sys_sendmsg+0x88/0xe0\n[ 18.869276] ? rseq_ip_fixup+0x198/0x260\n[ 18.869563] ? rseq_update_cpu_node_id+0x10a/0x190\n[ 18.869900] ? trace_hardirqs_off+0x5a/0xd0\n[ 18.870196] ? syscall_exit_to_user_mode+0xcc/0x220\n[ 18.870547] ? do_syscall_64+0x93/0x150\n[ 18.870821] ? __memcg_slab_free_hook+0x69/0x290\n[ 18.871157] __sys_sendmsg+0x69/0xd0\n[ 18.871416] __x64_sys_sendmsg+0x1d/0x30\n[ 18.871699] x64_sys_call+0x9e2/0x2670\n[ 18.871979] do_syscall_64+0x87/0x150\n[ 18.873280] ? do_syscall_64+0x93/0x150\n[ 18.874742] ? lock_release+0x7b/0x160\n[ 18.876157] ? do_user_addr_fault+0x5ce/0x8f0\n[ 18.877833] ? irqentry_exit_to_user_mode+0xc2/0x210\n[ 18.879608] ? irqentry_exit+0x77/0xb0\n[ 18.879808] ? clear_bhb_loop+0x15/0x70\n[ 18.880023] ? clear_bhb_loop+0x15/0x70\n[ 18.880223] ? clear_bhb_loop+0x15/0x70\n[ 18.880426] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[ 18.880683] RIP: 0033:0x44a957\n[ 18.880851] Code: ff ff e8 fc 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 8974 24 10\n[ 18.881766] RSP: 002b:00007ffcdd00fad8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\n[ 18.882149] RAX: ffffffffffffffda RBX: 00007ffcdd010db8 RCX: 000000000044a957\n[ 18.882507] RDX: 0000000000000000 RSI: 00007ffcdd00fb70 RDI: 0000000000000003\n[ 18.885037] RBP: 00007ffcdd010bc0 R08: 000000000703c770 R09: 000000000703c7c0\n[ 18.887203] R10: 0000000000000080 R11: 0000000000000246 R12: 0000000000000001\n[ 18.888026] R13: 00007ffcdd010da8 R14: 00000000004ca7d0 R15: 0000000000000001\n[ 18.888395] \n[ 18.888610] ---[ end trace ]---

Memory safety bugs present in Firefox 134, Thunderbird 134, Firefox ESR 115.19, Firefox ESR 128.6, Thunderbird 115.19, and Thunderbird 128.6. 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 < 135, Firefox ESR < 115.20, Firefox ESR < 128.7, Thunderbird < 128.7, and Thunderbird < 135.

Certificate length was not properly checked when added to a certificate store. In practice only trusted data was processed. This vulnerability affects Firefox < 135, Firefox ESR < 128.7, Thunderbird < 128.7, and Thunderbird < 135.

A race condition could have led to private browsing tabs being opened in normal browsing windows. This could have resulted in a potential privacy leak. This vulnerability affects Firefox < 135, Firefox ESR < 128.7, Thunderbird < 128.7, and Thunderbird < 135.

A flaw was found in Firefox. The Mozilla Foundation's Security Advisory describes the following issue: A race during concurrent delazification could have led to a use-after-free.

A bug in WebAssembly code generation could have lead to a crash. It may have been possible for an attacker to leverage this to achieve code execution. This vulnerability affects Firefox < 135, Firefox ESR < 128.7, Thunderbird < 128.7, and Thunderbird < 135.

An attacker could have caused a use-after-free via the Custom Highlight API, leading to a potentially exploitable crash. This vulnerability affects Firefox < 135, Firefox ESR < 115.20, Firefox ESR < 128.7, Thunderbird < 128.7, and Thunderbird < 135.

A flaw was found in Firefox. The Mozilla Foundation's Security Advisory describes the following issue: An attacker could have caused a use-after-free via crafted XSLT data, leading to a potentially exploitable crash.

A vulnerability has been found in GNU Binutils 2.43 and classified as problematic. Affected by this vulnerability is the function __sanitizer::internal_strlen of the file binutils/nm.c of the component nm. The manipulation of the argument const leads to buffer overflow. The attack can be launched remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used.

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

Memory safety bugs present in Firefox 134, Thunderbird 134, Firefox ESR 128.6, and Thunderbird 128.6. 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 < 135, Firefox ESR < 128.7, Thunderbird < 128.7, and Thunderbird < 135.

A flaw was found in the Git LFS git extension. When Git LFS requests credentials from Git for a remote host, it passes portions of the host's URL to the `git-credential(1)` command without checking for embedded line-ending control characters and then sends any credentials it receives back from the Git credential helper to the remote host. By inserting URL-encoded control characters such as line feed (LF) or carriage return (CR) characters into the URL, an attacker may be able to retrieve a user's Git credentials.

In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/eventfd: ensure io_eventfd_signal() defers another RCU period\n\nio_eventfd_do_signal() is invoked from an RCU callback, but when\ndropping the reference to the io_ev_fd, it calls io_eventfd_free()\ndirectly if the refcount drops to zero. This isn't correct, as any\npotential freeing of the io_ev_fd should be deferred another RCU grace\nperiod.\n\nJust call io_eventfd_put() rather than open-code the dec-and-test and\nfree, which will correctly defer it another RCU grace period.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: adapt set backend to use GC transaction API\n\nUse the GC transaction API to replace the old and buggy gc API and the\nbusy mark approach.\n\nNo set elements are removed from async garbage collection anymore,\ninstead the _DEAD bit is set on so the set element is not visible from\nlookup path anymore. Async GC enqueues transaction work that might be\naborted and retried later.\n\nrbtree and pipapo set backends does not set on the _DEAD bit from the\nsync GC path since this runs in control plane path where mutex is held.\nIn this case, set elements are deactivated, removed and then released\nvia RCU callback, sync GC never fails.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: Fix enomem handling in buffered reads\n\nIf netfs_read_to_pagecache() gets an error from either ->prepare_read() or\nfrom netfs_prepare_read_iterator(), it needs to decrement ->nr_outstanding,\ncancel the subrequest and break out of the issuing loop. Currently, it\nonly does this for two of the cases, but there are two more that aren't\nhandled.\n\nFix this by moving the handling to a common place and jumping to it from\nall four places. This is in preference to inserting a wrapper around\nnetfs_prepare_read_iterator() as proposed by Dmitry Antipov[1].

In the Linux kernel, the following vulnerability has been resolved:\n\nnfs: Fix oops in nfs_netfs_init_request() when copying to cache\n\nWhen netfslib wants to copy some data that has just been read on behalf of\nnfs, it creates a new write request and calls nfs_netfs_init_request() to\ninitialise it, but with a NULL file pointer. This causes\nnfs_file_open_context() to oops - however, we don't actually need the nfs\ncontext as we're only going to write to the cache.\n\nFix this by just returning if we aren't given a file pointer and emit a\nwarning if the request was for something other than copy-to-cache.\n\nFurther, fix nfs_netfs_free_request() so that it doesn't try to free the\ncontext if the pointer is NULL.

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: f_fs: Remove WARN_ON in functionfs_bind\n\nThis commit addresses an issue related to below kernel panic where\npanic_on_warn is enabled. It is caused by the unnecessary use of WARN_ON\nin functionsfs_bind, which easily leads to the following scenarios.\n\n1.adb_write in adbd 2. UDC write via configfs\n ================= =====================\n\n->usb_ffs_open_thread() ->UDC write\n ->open_functionfs() ->configfs_write_iter()\n ->adb_open() ->gadget_dev_desc_UDC_store()\n ->adb_write() ->usb_gadget_register_driver_owner\n ->driver_register()\n->StartMonitor() ->bus_add_driver()\n ->adb_read() ->gadget_bind_driver()\n ->configfs_composite_bind()\n ->usb_add_function()\n->open_functionfs() ->ffs_func_bind()\n ->adb_open() ->functionfs_bind()\n state !=FFS_ACTIVE>\n\nThe adb_open, adb_read, and adb_write operations are invoked from the\ndaemon, but trying to bind the function is a process that is invoked by\nUDC write through configfs, which opens up the possibility of a race\ncondition between the two paths. In this race scenario, the kernel panic\noccurs due to the WARN_ON from functionfs_bind when panic_on_warn is\nenabled. This commit fixes the kernel panic by removing the unnecessary\nWARN_ON.\n\nKernel panic - not syncing: kernel: panic_on_warn set ...\n[ 14.542395] Call trace:\n[ 14.542464] ffs_func_bind+0x1c8/0x14a8\n[ 14.542468] usb_add_function+0xcc/0x1f0\n[ 14.542473] configfs_composite_bind+0x468/0x588\n[ 14.542478] gadget_bind_driver+0x108/0x27c\n[ 14.542483] really_probe+0x190/0x374\n[ 14.542488] __driver_probe_device+0xa0/0x12c\n[ 14.542492] driver_probe_device+0x3c/0x220\n[ 14.542498] __driver_attach+0x11c/0x1fc\n[ 14.542502] bus_for_each_dev+0x104/0x160\n[ 14.542506] driver_attach+0x24/0x34\n[ 14.542510] bus_add_driver+0x154/0x270\n[ 14.542514] driver_register+0x68/0x104\n[ 14.542518] usb_gadget_register_driver_owner+0x48/0xf4\n[ 14.542523] gadget_dev_desc_UDC_store+0xf8/0x144\n[ 14.542526] configfs_write_iter+0xf0/0x138

In the Linux kernel, the following vulnerability has been resolved:\n\niio: light: bh1745: fix information leak in triggered buffer\n\nThe 'scan' local struct is used to push data to user space from a\ntriggered buffer, but it does not set values for inactive channels, as\nit only uses iio_for_each_active_channel() to assign new values.\n\nInitialize the struct to zero before using it to avoid pushing\nuninitialized information to userspace.

A heap-based buffer overflow flaw was found in the rsync daemon. This issue is due to improper handling of attacker-controlled checksum lengths (s2length) in the code. When MAX_DIGEST_LEN exceeds the fixed SUM_LENGTH (16 bytes), an attacker can write out of bounds in the sum2 buffer.

A flaw was found in the rsync daemon which could be triggered when rsync compares file checksums. This flaw allows an attacker to manipulate the checksum length (s2length) to cause a comparison between a checksum and uninitialized memory and leak one byte of uninitialized stack data at a time.

When curl is asked to use HSTS, the expiry time for a subdomain might\noverwrite a parent domain's cache entry, making it end sooner or later than\notherwise intended.\n\nThis affects curl using applications that enable HSTS and use URLs with the\ninsecure `HTTP://` scheme and perform transfers with hosts like\n`x.example.com` as well as `example.com` where the first host is a subdomain\nof the second host.\n\n(The HSTS cache either needs to have been populated manually or there needs to\nhave been previous HTTPS accesses done as the cache needs to have entries for\nthe domains involved to trigger this problem.)\n\nWhen `x.example.com` responds with `Strict-Transport-Security:` headers, this\nbug can make the subdomain's expiry timeout *bleed over* and get set for the\nparent domain `example.com` in curl's HSTS cache.\n\nThe result of a triggered bug is that HTTP accesses to `example.com` get\nconverted to HTTPS for a different period of time than what was asked for by\nthe origin server. If `example.com` for example stops supporting HTTPS at its\nexpiry time, curl might then fail to access `http://example.com` until the\n(wrongly set) timeout expires. This bug can also expire the parent's entry\n*earlier*, thus making curl inadvertently switch back to insecure HTTP earlier\nthan otherwise intended.

VUL-0: CVE-2024-8805: bluez: BlueZ HID over GATT Profile Improper Access Control Remote Code Execution Vulnerability

An attacker could have caused a use-after-free in the JavaScript engine to read memory in the JavaScript string section of the heap. This vulnerability affects Firefox < 127.

HarfBuzz is a text shaping engine. Starting with 8.5.0 through 10.0.1, there is a heap-based buffer overflow in the hb_cairo_glyphs_from_buffer function.

Under certain circumstances, navigating to a webpage would result in the address missing from the location URL bar, making it unclear what the URL was for the loaded webpage. This vulnerability affects Firefox for iOS < 133.

Accessing a non-secure HTTP site that uses a non-existent port may cause the SSL padlock icon in the location URL bar to, misleadingly, appear secure. This vulnerability affects Firefox for iOS < 133.

A vulnerability in the Ceph Rados Gateway (RadosGW) OIDC provider allows attackers to bypass JWT signature verification by supplying a token with "none" as the algorithm (alg). This occurs because the implementation fails to enforce strict signature validation, enabling attackers to forge valid tokens without a signature.

GStreamer is a library for constructing graphs of media-handling components. An OOB-read vulnerability has been discovered in gst_wavparse_adtl_chunk within gstwavparse.c. This vulnerability arises due to insufficient validation of the size parameter, which can exceed the bounds of the data buffer. As a result, an OOB read occurs in the following while loop. This vulnerability can result in reading up to 4GB of process memory or potentially causing a segmentation fault (SEGV) when accessing invalid memory. This vulnerability is fixed in 1.24.10.

GStreamer is a library for constructing graphs of media-handling components. A null pointer dereference vulnerability has been discovered in the gst_matroska_demux_update_tracks function within matroska-demux.c. The vulnerability occurs when the gst_caps_is_equal function is called with invalid caps values. If this happen, then in the function gst_buffer_get_size the call to GST_BUFFER_MEM_PTR can return a null pointer. Attempting to dereference the size field of this null pointer results in a null pointer dereference. This vulnerability is fixed in 1.24.10.

GStreamer is a library for constructing graphs of media-handling components. A null pointer dereference vulnerability has been discovered in the gst_matroska_demux_add_wvpk_header function within matroska-demux.c. This function does not properly check the validity of the stream->codec_priv pointer in the following code. If stream->codec_priv is NULL, the call to GST_READ_UINT16_LE will attempt to dereference a null pointer, leading to a crash of the application. This vulnerability is fixed in 1.24.10.

GStreamer is a library for constructing graphs of media-handling components. A null pointer dereference vulnerability has been discovered in the gst_jpeg_dec_negotiate function in gstjpegdec.c. This function does not check for a NULL return value from gst_video_decoder_set_output_state. When this happens, dereferences of the outstate pointer will lead to a null pointer dereference. This vulnerability can result in a Denial of Service (DoS) by triggering a segmentation fault (SEGV). This vulnerability is fixed in 1.24.10.

GStreamer is a library for constructing graphs of media-handling components. An OOB-read has been discovered in the qtdemux_parse_svq3_stsd_data function within qtdemux.c. In the FOURCC_SMI_ case, seqh_size is read from the input file without proper validation. If seqh_size is greater than the remaining size of the data buffer, it can lead to an OOB-read in the following call to gst_buffer_fill, which internally uses memcpy. This vulnerability can result in reading up to 4GB of process memory or potentially causing a segmentation fault (SEGV) when accessing invalid memory. This vulnerability is fixed in 1.24.10.

GStreamer is a library for constructing graphs of media-handling components. An integer underflow has been detected in extract_cc_from_data function within qtdemux.c. In the FOURCC_c708 case, the subtraction atom_length - 8 may result in an underflow if atom_length is less than 8. When that subtraction underflows, *cclen ends up being a large number, and then cclen is passed to g_memdup2 leading to an out-of-bounds (OOB) read. This vulnerability is fixed in 1.24.10.

GStreamer is a library for constructing graphs of media-handling components. An integer underflow has been detected in qtdemux_parse_trak function within qtdemux.c. During the strf parsing case, the subtraction size -= 40 can lead to a negative integer overflow if it is less than 40. If this happens, the subsequent call to gst_buffer_fill will invoke memcpy with a large tocopy size, resulting in an OOB-read. This vulnerability is fixed in 1.24.10.

GStreamer is a library for constructing graphs of media-handling components. The function qtdemux_parse_sbgp in qtdemux.c is affected by a null dereference vulnerability. This vulnerability is fixed in 1.24.10.

GStreamer is a library for constructing graphs of media-handling components. An OOB-read vulnerability has been discovered in qtdemux_parse_container function within qtdemux.c. In the parent function qtdemux_parse_node, the value of length is not well checked. So, if length is big enough, it causes the pointer end to point beyond the boundaries of buffer. Subsequently, in the qtdemux_parse_container function, the while loop can trigger an OOB-read, accessing memory beyond the bounds of buf. This vulnerability can result in reading up to 4GB of process memory or potentially causing a segmentation fault (SEGV) when accessing invalid memory. This vulnerability is fixed in 1.24.10.

GStreamer is a library for constructing graphs of media-handling components. A null pointer dereference has been discovered in the id3v2_read_synch_uint function, located in id3v2.c. If id3v2_read_synch_uint is called with a null work->hdr.frame_data, the pointer guint8 *data is accessed without validation, resulting in a null pointer dereference. This vulnerability can result in a Denial of Service (DoS) by triggering a segmentation fault (SEGV). This vulnerability is fixed in 1.24.10.

GStreamer is a library for constructing graphs of media-handling components. An OOB-write vulnerability has been identified in the gst_ssa_parse_remove_override_codes function of the gstssaparse.c file. This function is responsible for parsing and removing SSA (SubStation Alpha) style override codes, which are enclosed in curly brackets ({}). The issue arises when a closing curly bracket "}" appears before an opening curly bracket "{" in the input string. In this case, memmove() incorrectly duplicates a substring. With each successive loop iteration, the size passed to memmove() becomes progressively larger (strlen(end+1)), leading to a write beyond the allocated memory bounds. This vulnerability is fixed in 1.24.10.

An issue was discovered in psi/zcolor.c in Artifex Ghostscript before 10.04.0. There is an out-of-bounds read when reading color in Indexed color space.