An off-by-one error flaw was found in the udevListInterfacesByStatus() function in libvirt when the number of interfaces exceeds the size of the `names` array. This issue can be reproduced by sending specially crafted data to the libvirt daemon, allowing an unprivileged client to perform a denial of service attack by causing the libvirt daemon to crash.

A stack based buffer overflow was found in the virtio-net device of QEMU. This issue occurs when flushing TX in the virtio_net_flush_tx function if guest features VIRTIO_NET_F_HASH_REPORT, VIRTIO_F_VERSION_1 and VIRTIO_NET_F_MRG_RXBUF are enabled. This could allow a malicious user to overwrite local variables allocated on the stack. Specifically, the `out_sg` variable could be used to read a part of process memory and send it to the wire, causing an information leak.

A flaw was found in the QEMU built-in VNC server while processing ClientCutText messages. The qemu_clipboard_request() function can be reached before vnc_server_cut_text_caps() was called and had the chance to initialize the clipboard peer, leading to a NULL pointer dereference. This could allow a malicious authenticated VNC client to crash QEMU and trigger a denial of service.

A remote code execution vulnerability was found in Shim. The Shim boot support trusts attacker-controlled values when parsing an HTTP response. This flaw allows an attacker to craft a specific malicious HTTP request, leading to a completely controlled out-of-bounds write primitive and complete system compromise. This flaw is only exploitable during the early boot phase, an attacker needs to perform a Man-in-the-Middle or compromise the boot server to be able to exploit this vulnerability successfully.

aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. In affected versions an attacker can send a specially crafted POST (multipart/form-data) request. When the aiohttp server processes it, the server will enter an infinite loop and be unable to process any further requests. An attacker can stop the application from serving requests after sending a single request. This issue has been addressed in version 3.9.4. Users are advised to upgrade. Users unable to upgrade may manually apply a patch to their systems. Please see the linked GHSA for instructions.

In the Linux kernel, the following vulnerability has been resolved:\nUSB: usb-storage: Prevent divide-by-0 error in isd200_ata_command\nThe isd200 sub-driver in usb-storage uses the HEADS and SECTORS values\nin the ATA ID information to calculate cylinder and head values when\ncreating a CDB for READ or WRITE commands. The calculation involves\ndivision and modulus operations, which will cause a crash if either of\nthese values is 0. While this never happens with a genuine device, it\ncould happen with a flawed or subversive emulation, as reported by the\nsyzbot fuzzer.\nProtect against this possibility by refusing to bind to the device if\neither the ATA_ID_HEADS or ATA_ID_SECTORS value in the device's ID\ninformation is 0. This requires isd200_Initialization() to return a\nnegative error code when initialization fails; currently it always\nreturns 0 (even when there is an error).

In the Linux kernel, the following vulnerability has been resolved:\nwifi: iwlwifi: mvm: ensure offloading TID queue exists\nThe resume code path assumes that the TX queue for the offloading TID\nhas been configured. At resume time it then tries to sync the write\npointer as it may have been updated by the firmware.\nIn the unusual event that no packets have been send on TID 0, the queue\nwill not have been allocated and this causes a crash. Fix this by\nensuring the queue exist at suspend time.

In the Linux kernel, the following vulnerability has been resolved:\nwifi: rtl8xxxu: add cancel_work_sync() for c2hcmd_work\nThe workqueue might still be running, when the driver is stopped. To\navoid a use-after-free, call cancel_work_sync() in rtl8xxxu_stop().

In the Linux kernel, the following vulnerability has been resolved:\nwifi: brcm80211: handle pmk_op allocation failure\nThe kzalloc() in brcmf_pmksa_v3_op() will return null if the\nphysical memory has run out. As a result, if we dereference\nthe null value, the null pointer dereference bug will happen.\nReturn -ENOMEM from brcmf_pmksa_v3_op() if kzalloc() fails\nfor pmk_op.

In the Linux kernel, the following vulnerability has been resolved:\nnet/mlx5e: Prevent deadlock while disabling aRFS\nWhen disabling aRFS under the `priv->state_lock`, any scheduled\naRFS works are canceled using the `cancel_work_sync` function,\nwhich waits for the work to end if it has already started.\nHowever, while waiting for the work handler, the handler will\ntry to acquire the `state_lock` which is already acquired.\nThe worker acquires the lock to delete the rules if the state\nis down, which is not the worker's responsibility since\ndisabling aRFS deletes the rules.\nAdd an aRFS state variable, which indicates whether the aRFS is\nenabled and prevent adding rules when the aRFS is disabled.\nKernel log:\n======================================================\nWARNING: possible circular locking dependency detected\n6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G I\n------------------------------------------------------\nethtool/386089 is trying to acquire lock:\nffff88810f21ce68 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0\nbut task is already holding lock:\nffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]\nwhich lock already depends on the new lock.\nthe existing dependency chain (in reverse order) is:\n-> #1 (&priv->state_lock){+.+.}-{3:3}:\n__mutex_lock+0x80/0xc90\narfs_handle_work+0x4b/0x3b0 [mlx5_core]\nprocess_one_work+0x1dc/0x4a0\nworker_thread+0x1bf/0x3c0\nkthread+0xd7/0x100\nret_from_fork+0x2d/0x50\nret_from_fork_asm+0x11/0x20\n-> #0 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}:\n__lock_acquire+0x17b4/0x2c80\nlock_acquire+0xd0/0x2b0\n__flush_work+0x7a/0x4e0\n__cancel_work_timer+0x131/0x1c0\narfs_del_rules+0x143/0x1e0 [mlx5_core]\nmlx5e_arfs_disable+0x1b/0x30 [mlx5_core]\nmlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]\nethnl_set_channels+0x28f/0x3b0\nethnl_default_set_doit+0xec/0x240\ngenl_family_rcv_msg_doit+0xd0/0x120\ngenl_rcv_msg+0x188/0x2c0\nnetlink_rcv_skb+0x54/0x100\ngenl_rcv+0x24/0x40\nnetlink_unicast+0x1a1/0x270\nnetlink_sendmsg+0x214/0x460\n__sock_sendmsg+0x38/0x60\n__sys_sendto+0x113/0x170\n__x64_sys_sendto+0x20/0x30\ndo_syscall_64+0x40/0xe0\nentry_SYSCALL_64_after_hwframe+0x46/0x4e\nother info that might help us debug this:\nPossible unsafe locking scenario:\nCPU0 CPU1\n---- ----\nlock(&priv->state_lock);\nlock((work_completion)(&rule->arfs_work));\nlock(&priv->state_lock);\nlock((work_completion)(&rule->arfs_work));\n*** DEADLOCK ***\n3 locks held by ethtool/386089:\n#0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40\n#1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240\n#2: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]\nstack backtrace:\nCPU: 15 PID: 386089 Comm: ethtool Tainted: G I 6.7.0-rc4_net_next_mlx5_5483eb2 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nCall Trace:\n\ndump_stack_lvl+0x60/0xa0\ncheck_noncircular+0x144/0x160\n__lock_acquire+0x17b4/0x2c80\nlock_acquire+0xd0/0x2b0\n? __flush_work+0x74/0x4e0\n? save_trace+0x3e/0x360\n? __flush_work+0x74/0x4e0\n__flush_work+0x7a/0x4e0\n? __flush_work+0x74/0x4e0\n? __lock_acquire+0xa78/0x2c80\n? lock_acquire+0xd0/0x2b0\n? mark_held_locks+0x49/0x70\n__cancel_work_timer+0x131/0x1c0\n? mark_held_locks+0x49/0x70\narfs_del_rules+0x143/0x1e0 [mlx5_core]\nmlx5e_arfs_disable+0x1b/0x30 [mlx5_core]\nmlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]\nethnl_set_channels+0x28f/0x3b0\nethnl_default_set_doit+0xec/0x240\ngenl_family_rcv_msg_doit+0xd0/0x120\ngenl_rcv_msg+0x188/0x2c0\n? ethn\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\nfs: sysfs: Fix reference leak in sysfs_break_active_protection()\nThe sysfs_break_active_protection() routine has an obvious reference\nleak in its error path. If the call to kernfs_find_and_get() fails then\nkn will be NULL, so the companion sysfs_unbreak_active_protection()\nroutine won't get called (and would only cause an access violation by\ntrying to dereference kn->parent if it was called). As a result, the\nreference to kobj acquired at the start of the function will never be\nreleased.\nFix the leak by adding an explicit kobject_put() call when kn is NULL.

In the Linux kernel, the following vulnerability has been resolved:\nfat: fix uninitialized field in nostale filehandles\nWhen fat_encode_fh_nostale() encodes file handle without a parent it\nstores only first 10 bytes of the file handle. However the length of the\nfile handle must be a multiple of 4 so the file handle is actually 12\nbytes long and the last two bytes remain uninitialized. This is not\ngreat at we potentially leak uninitialized information with the handle\nto userspace. Properly initialize the full handle length.

In the Linux kernel, the following vulnerability has been resolved:\nusb: xhci: Add error handling in xhci_map_urb_for_dma\nCurrently xhci_map_urb_for_dma() creates a temporary buffer and copies\nthe SG list to the new linear buffer. But if the kzalloc_node() fails,\nthen the following sg_pcopy_to_buffer() can lead to crash since it\ntries to memcpy to NULL pointer.\nSo return -ENOMEM if kzalloc returns null pointer.

In the Linux kernel, the following vulnerability has been resolved:\nUSB: core: Fix deadlock in usb_deauthorize_interface()\nAmong the attribute file callback routines in\ndrivers/usb/core/sysfs.c, the interface_authorized_store() function is\nthe only one which acquires a device lock on an ancestor device: It\ncalls usb_deauthorize_interface(), which locks the interface's parent\nUSB device.\nThe will lead to deadlock if another process already owns that lock\nand tries to remove the interface, whether through a configuration\nchange or because the device has been disconnected. As part of the\nremoval procedure, device_del() waits for all ongoing sysfs attribute\ncallbacks to complete. But usb_deauthorize_interface() can't complete\nuntil the device lock has been released, and the lock won't be\nreleased until the removal has finished.\nThe mechanism provided by sysfs to prevent this kind of deadlock is\nto use the sysfs_break_active_protection() function, which tells sysfs\nnot to wait for the attribute callback.\nReported-and-tested by: Yue Sun \nReported by: xingwei lee

In the Linux kernel, the following vulnerability has been resolved:\nUSB: core: Fix deadlock in port "disable" sysfs attribute\nThe show and store callback routines for the "disable" sysfs attribute\nfile in port.c acquire the device lock for the port's parent hub\ndevice. This can cause problems if another process has locked the hub\nto remove it or change its configuration:\nRemoving the hub or changing its configuration requires the\nhub interface to be removed, which requires the port device\nto be removed, and device_del() waits until all outstanding\nsysfs attribute callbacks for the ports have returned. The\nlock can't be released until then.\nBut the disable_show() or disable_store() routine can't return\nuntil after it has acquired the lock.\nThe resulting deadlock can be avoided by calling\nsysfs_break_active_protection(). This will cause the sysfs core not\nto wait for the attribute's callback routine to return, allowing the\nremoval to proceed. The disadvantage is that after making this call,\nthere is no guarantee that the hub structure won't be deallocated at\nany moment. To prevent this, we have to acquire a reference to it\nfirst by calling hub_get().

In the Linux kernel, the following vulnerability has been resolved:\nusb: ulpi: Fix debugfs directory leak\nThe ULPI per-device debugfs root is named after the ulpi device's\nparent, but ulpi_unregister_interface tries to remove a debugfs\ndirectory named after the ulpi device itself. This results in the\ndirectory sticking around and preventing subsequent (deferred) probes\nfrom succeeding. Change the directory name to match the ulpi device.

In the Linux kernel, the following vulnerability has been resolved:\ndo_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak\nsyzbot identified a kernel information leak vulnerability in\ndo_sys_name_to_handle() and issued the following report [1].\n[1]\n"BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]\nBUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40\ninstrument_copy_to_user include/linux/instrumented.h:114 [inline]\n_copy_to_user+0xbc/0x100 lib/usercopy.c:40\ncopy_to_user include/linux/uaccess.h:191 [inline]\ndo_sys_name_to_handle fs/fhandle.c:73 [inline]\n__do_sys_name_to_handle_at fs/fhandle.c:112 [inline]\n__se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94\n__x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94\n...\nUninit was created at:\nslab_post_alloc_hook+0x129/0xa70 mm/slab.h:768\nslab_alloc_node mm/slub.c:3478 [inline]\n__kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517\n__do_kmalloc_node mm/slab_common.c:1006 [inline]\n__kmalloc+0x121/0x3c0 mm/slab_common.c:1020\nkmalloc include/linux/slab.h:604 [inline]\ndo_sys_name_to_handle fs/fhandle.c:39 [inline]\n__do_sys_name_to_handle_at fs/fhandle.c:112 [inline]\n__se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94\n__x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94\n...\nBytes 18-19 of 20 are uninitialized\nMemory access of size 20 starts at ffff888128a46380\nData copied to user address 0000000020000240"\nPer Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to\nsolve the problem.

In the Linux kernel, the following vulnerability has been resolved:\nwifi: ath9k: delay all of ath9k_wmi_event_tasklet() until init is complete\nThe ath9k_wmi_event_tasklet() used in ath9k_htc assumes that all the data\nstructures have been fully initialised by the time it runs. However, because of\nthe order in which things are initialised, this is not guaranteed to be the\ncase, because the device is exposed to the USB subsystem before the ath9k driver\ninitialisation is completed.\nWe already committed a partial fix for this in commit:\n8b3046abc99e ("ath9k_htc: fix NULL pointer dereference at ath9k_htc_tx_get_packet()")\nHowever, that commit only aborted the WMI_TXSTATUS_EVENTID command in the event\ntasklet, pairing it with an "initialisation complete" bit in the TX struct. It\nseems syzbot managed to trigger the race for one of the other commands as well,\nso let's just move the existing synchronisation bit to cover the whole\ntasklet (setting it at the end of ath9k_htc_probe_device() instead of inside\nath9k_tx_init()).

In the Linux kernel, the following vulnerability has been resolved:\nwifi: mt76: mt7921e: fix use-after-free in free_irq()\nFrom commit a304e1b82808 ("[PATCH] Debug shared irqs"), there is a test\nto make sure the shared irq handler should be able to handle the unexpected\nevent after deregistration. For this case, let's apply MT76_REMOVED flag to\nindicate the device was removed and do not run into the resource access\nanymore.\nBUG: KASAN: use-after-free in mt7921_irq_handler+0xd8/0x100 [mt7921e]\nRead of size 8 at addr ffff88824a7d3b78 by task rmmod/11115\nCPU: 28 PID: 11115 Comm: rmmod Tainted: G W L 5.17.0 #10\nHardware name: Micro-Star International Co., Ltd. MS-7D73/MPG B650I\nEDGE WIFI (MS-7D73), BIOS 1.81 01/05/2024\nCall Trace:\n\ndump_stack_lvl+0x6f/0xa0\nprint_address_description.constprop.0+0x1f/0x190\n? mt7921_irq_handler+0xd8/0x100 [mt7921e]\n? mt7921_irq_handler+0xd8/0x100 [mt7921e]\nkasan_report.cold+0x7f/0x11b\n? mt7921_irq_handler+0xd8/0x100 [mt7921e]\nmt7921_irq_handler+0xd8/0x100 [mt7921e]\nfree_irq+0x627/0xaa0\ndevm_free_irq+0x94/0xd0\n? devm_request_any_context_irq+0x160/0x160\n? kobject_put+0x18d/0x4a0\nmt7921_pci_remove+0x153/0x190 [mt7921e]\npci_device_remove+0xa2/0x1d0\n__device_release_driver+0x346/0x6e0\ndriver_detach+0x1ef/0x2c0\nbus_remove_driver+0xe7/0x2d0\n? __check_object_size+0x57/0x310\npci_unregister_driver+0x26/0x250\n__do_sys_delete_module+0x307/0x510\n? free_module+0x6a0/0x6a0\n? fpregs_assert_state_consistent+0x4b/0xb0\n? rcu_read_lock_sched_held+0x10/0x70\n? syscall_enter_from_user_mode+0x20/0x70\n? trace_hardirqs_on+0x1c/0x130\ndo_syscall_64+0x5c/0x80\n? trace_hardirqs_on_prepare+0x72/0x160\n? do_syscall_64+0x68/0x80\n? trace_hardirqs_on_prepare+0x72/0x160\nentry_SYSCALL_64_after_hwframe+0x44/0xae

In the Linux kernel, the following vulnerability has been resolved:\nRDMA/srpt: Do not register event handler until srpt device is fully setup\nUpon rare occasions, KASAN reports a use-after-free Write\nin srpt_refresh_port().\nThis seems to be because an event handler is registered before the\nsrpt device is fully setup and a race condition upon error may leave a\npartially setup event handler in place.\nInstead, only register the event handler after srpt device initialization\nis complete.

In the Linux kernel, the following vulnerability has been resolved:\nwifi: mac80211: fix race condition on enabling fast-xmit\nfast-xmit must only be enabled after the sta has been uploaded to the driver,\notherwise it could end up passing the not-yet-uploaded sta via drv_tx calls\nto the driver, leading to potential crashes because of uninitialized drv_priv\ndata.\nAdd a missing sta->uploaded check and re-check fast xmit after inserting a sta.

In the Linux kernel, the following vulnerability has been resolved:\nRDMA/srpt: Support specifying the srpt_service_guid parameter\nMake loading ib_srpt with this parameter set work. The current behavior is\nthat setting that parameter while loading the ib_srpt kernel module\ntriggers the following kernel crash:\nBUG: kernel NULL pointer dereference, address: 0000000000000000\nCall Trace:\n\nparse_one+0x18c/0x1d0\nparse_args+0xe1/0x230\nload_module+0x8de/0xa60\ninit_module_from_file+0x8b/0xd0\nidempotent_init_module+0x181/0x240\n__x64_sys_finit_module+0x5a/0xb0\ndo_syscall_64+0x5f/0xe0\nentry_SYSCALL_64_after_hwframe+0x6e/0x76

In the Linux kernel, the following vulnerability has been resolved:\nRDMA/qedr: Fix qedr_create_user_qp error flow\nAvoid the following warning by making sure to free the allocated\nresources in case that qedr_init_user_queue() fail.\n-----------[ cut here ]-----------\nWARNING: CPU: 0 PID: 143192 at drivers/infiniband/core/rdma_core.c:874 uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]\nModules linked in: tls target_core_user uio target_core_pscsi target_core_file target_core_iblock ib_srpt ib_srp scsi_transport_srp nfsd nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs 8021q garp mrp stp llc ext4 mbcache jbd2 opa_vnic ib_umad ib_ipoib sunrpc rdma_ucm ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm hfi1 intel_rapl_msr intel_rapl_common mgag200 qedr sb_edac drm_shmem_helper rdmavt x86_pkg_temp_thermal drm_kms_helper intel_powerclamp ib_uverbs coretemp i2c_algo_bit kvm_intel dell_wmi_descriptor ipmi_ssif sparse_keymap kvm ib_core rfkill syscopyarea sysfillrect video sysimgblt irqbypass ipmi_si ipmi_devintf fb_sys_fops rapl iTCO_wdt mxm_wmi iTCO_vendor_support intel_cstate pcspkr dcdbas intel_uncore ipmi_msghandler lpc_ich acpi_power_meter mei_me mei fuse drm xfs libcrc32c qede sd_mod ahci libahci t10_pi sg crct10dif_pclmul crc32_pclmul crc32c_intel qed libata tg3\nghash_clmulni_intel megaraid_sas crc8 wmi [last unloaded: ib_srpt]\nCPU: 0 PID: 143192 Comm: fi_rdm_tagged_p Kdump: loaded Not tainted 5.14.0-408.el9.x86_64 #1\nHardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.14.0 01/25/2022\nRIP: 0010:uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]\nCode: 5d 41 5c 41 5d 41 5e e9 0f 26 1b dd 48 89 df e8 67 6a ff ff 49 8b 86 10 01 00 00 48 85 c0 74 9c 4c 89 e7 e8 83 c0 cb dd eb 92 <0f> 0b eb be 0f 0b be 04 00 00 00 48 89 df e8 8e f5 ff ff e9 6d ff\nRSP: 0018:ffffb7c6cadfbc60 EFLAGS: 00010286\nRAX: ffff8f0889ee3f60 RBX: ffff8f088c1a5200 RCX: 00000000802a0016\nRDX: 00000000802a0017 RSI: 0000000000000001 RDI: ffff8f0880042600\nRBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000\nR10: ffff8f11fffd5000 R11: 0000000000039000 R12: ffff8f0d5b36cd80\nR13: ffff8f088c1a5250 R14: ffff8f1206d91000 R15: 0000000000000000\nFS: 0000000000000000(0000) GS:ffff8f11d7c00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000147069200e20 CR3: 00000001c7210002 CR4: 00000000001706f0\nCall Trace:\n\n? show_trace_log_lvl+0x1c4/0x2df\n? show_trace_log_lvl+0x1c4/0x2df\n? ib_uverbs_close+0x1f/0xb0 [ib_uverbs]\n? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]\n? __warn+0x81/0x110\n? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]\n? report_bug+0x10a/0x140\n? handle_bug+0x3c/0x70\n? exc_invalid_op+0x14/0x70\n? asm_exc_invalid_op+0x16/0x20\n? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]\nib_uverbs_close+0x1f/0xb0 [ib_uverbs]\n__fput+0x94/0x250\ntask_work_run+0x5c/0x90\ndo_exit+0x270/0x4a0\ndo_group_exit+0x2d/0x90\nget_signal+0x87c/0x8c0\narch_do_signal_or_restart+0x25/0x100\n? ib_uverbs_ioctl+0xc2/0x110 [ib_uverbs]\nexit_to_user_mode_loop+0x9c/0x130\nexit_to_user_mode_prepare+0xb6/0x100\nsyscall_exit_to_user_mode+0x12/0x40\ndo_syscall_64+0x69/0x90\n? syscall_exit_work+0x103/0x130\n? syscall_exit_to_user_mode+0x22/0x40\n? do_syscall_64+0x69/0x90\n? syscall_exit_work+0x103/0x130\n? syscall_exit_to_user_mode+0x22/0x40\n? do_syscall_64+0x69/0x90\n? do_syscall_64+0x69/0x90\n? common_interrupt+0x43/0xa0\nentry_SYSCALL_64_after_hwframe+0x72/0xdc\nRIP: 0033:0x1470abe3ec6b\nCode: Unable to access opcode bytes at RIP 0x1470abe3ec41.\nRSP: 002b:00007fff13ce9108 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\nRAX: fffffffffffffffc RBX: 00007fff13ce9218 RCX: 00001470abe3ec6b\nRDX: 00007fff13ce9200 RSI: 00000000c0181b01 RDI: 0000000000000004\nRBP: 00007fff13ce91e0 R08: 0000558d9655da10 R09: 0000558d9655dd00\nR10: 00007fff13ce95c0 R11: 0000000000000246 R12: 00007fff13ce9358\nR13: 0000000000000013 R14: 0000558d9655db50 R15: 00007fff13ce9470\n\n--[ end trace 888a9b92e04c5c97 ]--

In the Linux kernel, the following vulnerability has been resolved:\nwifi: iwlwifi: fix double-free bug\nThe storage for the TLV PC register data wasn't done like all\nthe other storage in the drv->fw area, which is cleared at the\nend of deallocation. Therefore, the freeing must also be done\ndifferently, explicitly NULL'ing it out after the free, since\notherwise there's a nasty double-free bug here if a file fails\nto load after this has been parsed, and we get another free\nlater (e.g. because no other file exists.) Fix that by adding\nthe missing NULL assignment.

In the Linux kernel, the following vulnerability has been resolved:\nwifi: iwlwifi: mvm: fix a crash when we run out of stations\nA DoS tool that injects loads of authentication frames made our AP\ncrash. The iwl_mvm_is_dup() function couldn't find the per-queue\ndup_data which was not allocated.\nThe root cause for that is that we ran out of stations in the firmware\nand we didn't really add the station to the firmware, yet we didn't\nreturn an error to mac80211.\nMac80211 was thinking that we have the station and because of that,\nsta_info::uploaded was set to 1. This allowed\nieee80211_find_sta_by_ifaddr() to return a valid station object, but\nthat ieee80211_sta didn't have any iwl_mvm_sta object initialized and\nthat caused the crash mentioned earlier when we got Rx on that station.

In the Linux kernel, the following vulnerability has been resolved:\nhwmon: (coretemp) Fix out-of-bounds memory access\nFix a bug that pdata->cpu_map[] is set before out-of-bounds check.\nThe problem might be triggered on systems with more than 128 cores per\npackage.

In the Linux kernel, the following vulnerability has been resolved:\nxhci: handle isoc Babble and Buffer Overrun events properly\nxHCI 4.9 explicitly forbids assuming that the xHC has released its\nownership of a multi-TRB TD when it reports an error on one of the\nearly TRBs. Yet the driver makes such assumption and releases the TD,\nallowing the remaining TRBs to be freed or overwritten by new TDs.\nThe xHC should also report completion of the final TRB due to its IOC\nflag being set by us, regardless of prior errors. This event cannot\nbe recognized if the TD has already been freed earlier, resulting in\n"Transfer event TRB DMA ptr not part of current TD" error message.\nFix this by reusing the logic for processing isoc Transaction Errors.\nThis also handles hosts which fail to report the final completion.\nFix transfer length reporting on Babble errors. They may be caused by\ndevice malfunction, no guarantee that the buffer has been filled.

In the Linux kernel, the following vulnerability has been resolved:\nnetfilter: nf_tables: mark set as dead when unbinding anonymous set with timeout\nWhile the rhashtable set gc runs asynchronously, a race allows it to\ncollect elements from anonymous sets with timeouts while it is being\nreleased from the commit path.\nMingi Cho originally reported this issue in a different path in 6.1.x\nwith a pipapo set with low timeouts which is not possible upstream since\n7395dfacfff6 ("netfilter: nf_tables: use timestamp to check for set\nelement timeout").\nFix this by setting on the dead flag for anonymous sets to skip async gc\nin this case.\nAccording to 08e4c8c5919f ("netfilter: nf_tables: mark newset as dead on\ntransaction abort"), Florian plans to accelerate abort path by releasing\nobjects via workqueue, therefore, this sets on the dead flag for abort\npath too.

In the Linux kernel, the following vulnerability has been resolved:\nnetfilter: nf_tables: disallow anonymous set with timeout flag\nAnonymous sets are never used with timeout from userspace, reject this.\nException to this rule is NFT_SET_EVAL to ensure legacy meters still work.

In the Linux kernel, the following vulnerability has been resolved:\nnet/smc: fix illegal rmb_desc access in SMC-D connection dump\nA crash was found when dumping SMC-D connections. It can be reproduced\nby following steps:\n- run nginx/wrk test:\nsmc_run nginx\nsmc_run wrk -t 16 -c 1000 -d -H 'Connection: Close' \n- continuously dump SMC-D connections in parallel:\nwatch -n 1 'smcss -D'\nBUG: kernel NULL pointer dereference, address: 0000000000000030\nCPU: 2 PID: 7204 Comm: smcss Kdump: loaded Tainted: GE 6.7.0+ #55\nRIP: 0010:__smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag]\nCall Trace:\n\n? __die+0x24/0x70\n? page_fault_oops+0x66/0x150\n? exc_page_fault+0x69/0x140\n? asm_exc_page_fault+0x26/0x30\n? __smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag]\n? __kmalloc_node_track_caller+0x35d/0x430\n? __alloc_skb+0x77/0x170\nsmc_diag_dump_proto+0xd0/0xf0 [smc_diag]\nsmc_diag_dump+0x26/0x60 [smc_diag]\nnetlink_dump+0x19f/0x320\n__netlink_dump_start+0x1dc/0x300\nsmc_diag_handler_dump+0x6a/0x80 [smc_diag]\n? __pfx_smc_diag_dump+0x10/0x10 [smc_diag]\nsock_diag_rcv_msg+0x121/0x140\n? __pfx_sock_diag_rcv_msg+0x10/0x10\nnetlink_rcv_skb+0x5a/0x110\nsock_diag_rcv+0x28/0x40\nnetlink_unicast+0x22a/0x330\nnetlink_sendmsg+0x1f8/0x420\n__sock_sendmsg+0xb0/0xc0\n____sys_sendmsg+0x24e/0x300\n? copy_msghdr_from_user+0x62/0x80\n___sys_sendmsg+0x7c/0xd0\n? __do_fault+0x34/0x160\n? do_read_fault+0x5f/0x100\n? do_fault+0xb0/0x110\n? __handle_mm_fault+0x2b0/0x6c0\n__sys_sendmsg+0x4d/0x80\ndo_syscall_64+0x69/0x180\nentry_SYSCALL_64_after_hwframe+0x6e/0x76\nIt is possible that the connection is in process of being established\nwhen we dump it. Assumed that the connection has been registered in a\nlink group by smc_conn_create() but the rmb_desc has not yet been\ninitialized by smc_buf_create(), thus causing the illegal access to\nconn->rmb_desc. So fix it by checking before dump.

In the Linux kernel, the following vulnerability has been resolved:\nwifi: iwlwifi: fix a memory corruption\niwl_fw_ini_trigger_tlv::data is a pointer to a __le32, which means that\nif we copy to iwl_fw_ini_trigger_tlv::data + offset while offset is in\nbytes, we'll write past the buffer.

This CVE ID has been rejected or withdrawn by its CVE Numbering Authority for the following reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:\nx86/fpu: Stop relying on userspace for info to fault in xsave buffer\nBefore this change, the expected size of the user space buffer was\ntaken from fx_sw->xstate_size. fx_sw->xstate_size can be changed\nfrom user-space, so it is possible construct a sigreturn frame where:\n* fx_sw->xstate_size is smaller than the size required by valid bits in\nfx_sw->xfeatures.\n* user-space unmaps parts of the sigrame fpu buffer so that not all of\nthe buffer required by xrstor is accessible.\nIn this case, xrstor tries to restore and accesses the unmapped area\nwhich results in a fault. But fault_in_readable succeeds because buf +\nfx_sw->xstate_size is within the still mapped area, so it goes back and\ntries xrstor again. It will spin in this loop forever.\nInstead, fault in the maximum size which can be touched by XRSTOR (taken\nfrom fpstate->user_size).\n[ dhansen: tweak subject / changelog ]

In the Linux kernel, the following vulnerability has been resolved:\ni2c: i801: Fix block process call transactions\nAccording to the Intel datasheets, software must reset the block\nbuffer index twice for block process call transactions: once before\nwriting the outgoing data to the buffer, and once again before\nreading the incoming data from the buffer.\nThe driver is currently missing the second reset, causing the wrong\nportion of the block buffer to be read.

cryptography is a package designed to expose cryptographic primitives and recipes to Python developers. Starting in version 38.0.0 and prior to version 42.0.4, if `pkcs12.serialize_key_and_certificates` is called with both a certificate whose public key did not match the provided private key and an `encryption_algorithm` with `hmac_hash` set (via `PrivateFormat.PKCS12.encryption_builder().hmac_hash(...)`, then a NULL pointer dereference would occur, crashing the Python process. This has been resolved in version 42.0.4, the first version in which a `ValueError` is properly raised.

In the Linux kernel before 6.6.7, an untrusted VMM can trigger int80 syscall handling at any given point. This is related to arch/x86/coco/tdx/tdx.c and arch/x86/mm/mem_encrypt_amd.c.

In the Linux kernel through 6.9, an untrusted hypervisor can inject virtual interrupts 0 and 14 at any point in time and can trigger the SIGFPE signal handler in userspace applications. This affects AMD SEV-SNP and AMD SEV-ES.

In the Linux kernel before 6.9, an untrusted hypervisor can inject virtual interrupt 29 (#VC) at any point in time and can trigger its handler. This affects AMD SEV-SNP and AMD SEV-ES.

A null pointer dereference flaw was found in the hugetlbfs_fill_super function in the Linux kernel hugetlbfs (HugeTLB pages) functionality. This issue may allow a local user to crash the system or potentially escalate their privileges on the system.

Issue summary: Processing a maliciously formatted PKCS12 file may lead OpenSSL\nto crash leading to a potential Denial of Service attack\nImpact summary: Applications loading files in the PKCS12 format from untrusted\nsources might terminate abruptly.\nA file in PKCS12 format can contain certificates and keys and may come from an\nuntrusted source. The PKCS12 specification allows certain fields to be NULL, but\nOpenSSL does not correctly check for this case. This can lead to a NULL pointer\ndereference that results in OpenSSL crashing. If an application processes PKCS12\nfiles from an untrusted source using the OpenSSL APIs then that application will\nbe vulnerable to this issue.\nOpenSSL APIs that are vulnerable to this are: PKCS12_parse(),\nPKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes()\nand PKCS12_newpass().\nWe have also fixed a similar issue in SMIME_write_PKCS7(). However since this\nfunction is related to writing data we do not consider it security significant.\nThe FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue.

A vulnerability was found in vhost_new_msg in drivers/vhost/vhost.c in the Linux kernel, which does not properly initialize memory in messages passed between virtual guests and the host operating system in the vhost/vhost.c:vhost_new_msg() function. This issue can allow local privileged users to read some kernel memory contents when reading from the /dev/vhost-net device file.

A null pointer dereference vulnerability was found in nft_dynset_init() in net/netfilter/nft_dynset.c in nf_tables in the Linux kernel. This issue may allow a local attacker with CAP_NET_ADMIN user privilege to trigger a denial of service.

A Marvin vulnerability side-channel leakage was found in the RSA decryption operation in the Linux Kernel. This issue may allow a network attacker to decrypt ciphertexts or forge signatures, limiting the services that use that private key.

An out-of-bounds read vulnerability was found in the NVMe-oF/TCP subsystem in the Linux kernel. This issue may allow a remote attacker to send a crafted TCP packet, triggering a heap-based buffer overflow that results in kmalloc data being printed and potentially leaked to the kernel ring buffer (dmesg).

In the Linux kernel, the following vulnerability has been resolved:\nnetfilter: nf_tables: disallow timeout for anonymous sets\nNever used from userspace, disallow these parameters.

In the Linux kernel, the following vulnerability has been resolved:\nnet/sched: act_ct: fix skb leak and crash on ooo frags\nact_ct adds skb->users before defragmentation. If frags arrive in order,\nthe last frag's reference is reset in:\ninet_frag_reasm_prepare\nskb_morph\nwhich is not straightforward.\nHowever when frags arrive out of order, nobody unref the last frag, and\nall frags are leaked. The situation is even worse, as initiating packet\ncapture can lead to a crash[0] when skb has been cloned and shared at the\nsame time.\nFix the issue by removing skb_get() before defragmentation. act_ct\nreturns TC_ACT_CONSUMED when defrag failed or in progress.\n[0]:\n[ 843.804823] ------------[ cut here ]------------\n[ 843.809659] kernel BUG at net/core/skbuff.c:2091!\n[ 843.814516] invalid opcode: 0000 [#1] PREEMPT SMP\n[ 843.819296] CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G S 6.7.0-rc3 #2\n[ 843.824107] Hardware name: XFUSION 1288H V6/BC13MBSBD, BIOS 1.29 11/25/2022\n[ 843.828953] RIP: 0010:pskb_expand_head+0x2ac/0x300\n[ 843.833805] Code: 8b 70 28 48 85 f6 74 82 48 83 c6 08 bf 01 00 00 00 e8 38 bd ff ff 8b 83 c0 00 00 00 48 03 83 c8 00 00 00 e9 62 ff ff ff 0f 0b <0f> 0b e8 8d d0 ff ff e9 b3 fd ff ff 81 7c 24 14 40 01 00 00 4c 89\n[ 843.843698] RSP: 0018:ffffc9000cce07c0 EFLAGS: 00010202\n[ 843.848524] RAX: 0000000000000002 RBX: ffff88811a211d00 RCX: 0000000000000820\n[ 843.853299] RDX: 0000000000000640 RSI: 0000000000000000 RDI: ffff88811a211d00\n[ 843.857974] RBP: ffff888127d39518 R08: 00000000bee97314 R09: 0000000000000000\n[ 843.862584] R10: 0000000000000000 R11: ffff8881109f0000 R12: 0000000000000880\n[ 843.867147] R13: ffff888127d39580 R14: 0000000000000640 R15: ffff888170f7b900\n[ 843.871680] FS: 0000000000000000(0000) GS:ffff889ffffc0000(0000) knlGS:0000000000000000\n[ 843.876242] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 843.880778] CR2: 00007fa42affcfb8 CR3: 000000011433a002 CR4: 0000000000770ef0\n[ 843.885336] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 843.889809] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 843.894229] PKRU: 55555554\n[ 843.898539] Call Trace:\n[ 843.902772] \n[ 843.906922] ? __die_body+0x1e/0x60\n[ 843.911032] ? die+0x3c/0x60\n[ 843.915037] ? do_trap+0xe2/0x110\n[ 843.918911] ? pskb_expand_head+0x2ac/0x300\n[ 843.922687] ? do_error_trap+0x65/0x80\n[ 843.926342] ? pskb_expand_head+0x2ac/0x300\n[ 843.929905] ? exc_invalid_op+0x50/0x60\n[ 843.933398] ? pskb_expand_head+0x2ac/0x300\n[ 843.936835] ? asm_exc_invalid_op+0x1a/0x20\n[ 843.940226] ? pskb_expand_head+0x2ac/0x300\n[ 843.943580] inet_frag_reasm_prepare+0xd1/0x240\n[ 843.946904] ip_defrag+0x5d4/0x870\n[ 843.950132] nf_ct_handle_fragments+0xec/0x130 [nf_conntrack]\n[ 843.953334] tcf_ct_act+0x252/0xd90 [act_ct]\n[ 843.956473] ? tcf_mirred_act+0x516/0x5a0 [act_mirred]\n[ 843.959657] tcf_action_exec+0xa1/0x160\n[ 843.962823] fl_classify+0x1db/0x1f0 [cls_flower]\n[ 843.966010] ? skb_clone+0x53/0xc0\n[ 843.969173] tcf_classify+0x24d/0x420\n[ 843.972333] tc_run+0x8f/0xf0\n[ 843.975465] __netif_receive_skb_core+0x67a/0x1080\n[ 843.978634] ? dev_gro_receive+0x249/0x730\n[ 843.981759] __netif_receive_skb_list_core+0x12d/0x260\n[ 843.984869] netif_receive_skb_list_internal+0x1cb/0x2f0\n[ 843.987957] ? mlx5e_handle_rx_cqe_mpwrq_rep+0xfa/0x1a0 [mlx5_core]\n[ 843.991170] napi_complete_done+0x72/0x1a0\n[ 843.994305] mlx5e_napi_poll+0x28c/0x6d0 [mlx5_core]\n[ 843.997501] __napi_poll+0x25/0x1b0\n[ 844.000627] net_rx_action+0x256/0x330\n[ 844.003705] __do_softirq+0xb3/0x29b\n[ 844.006718] irq_exit_rcu+0x9e/0xc0\n[ 844.009672] common_interrupt+0x86/0xa0\n[ 844.012537] \n[ 844.015285] \n[ 844.017937] asm_common_interrupt+0x26/0x40\n[ 844.020591] RIP: 0010:acpi_safe_halt+0x1b/0x20\n[ 844.023247] Code: ff 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 65 48 8b 04 25 00 18 03 00 48 8b 00 a8 08 75 0c 66 90 0f 00 2d 81 d0 44 00 fb\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\npowerpc/mm: Fix null-pointer dereference in pgtable_cache_add\nkasprintf() returns a pointer to dynamically allocated memory\nwhich can be NULL upon failure. Ensure the allocation was successful\nby checking the pointer validity.

In the Linux kernel, the following vulnerability has been resolved:\npowerpc/lib: Validate size for vector operations\nSome of the fp/vmx code in sstep.c assume a certain maximum size for the\ninstructions being emulated. The size of those operations however is\ndetermined separately in analyse_instr().\nAdd a check to validate the assumption on the maximum size of the\noperations, so as to prevent any unintended kernel stack corruption.

In the Linux kernel, the following vulnerability has been resolved:\ns390/ptrace: handle setting of fpc register correctly\nIf the content of the floating point control (fpc) register of a traced\nprocess is modified with the ptrace interface the new value is tested for\nvalidity by temporarily loading it into the fpc register.\nThis may lead to corruption of the fpc register of the tracing process:\nif an interrupt happens while the value is temporarily loaded into the\nfpc register, and within interrupt context floating point or vector\nregisters are used, the current fp/vx registers are saved with\nsave_fpu_regs() assuming they belong to user space and will be loaded into\nfp/vx registers when returning to user space.\ntest_fp_ctl() restores the original user space fpc register value, however\nit will be discarded, when returning to user space.\nIn result the tracer will incorrectly continue to run with the value that\nwas supposed to be used for the traced process.\nFix this by saving fpu register contents with save_fpu_regs() before using\ntest_fp_ctl().

In the Linux kernel, the following vulnerability has been resolved:\nKVM: s390: fix setting of fpc register\nkvm_arch_vcpu_ioctl_set_fpu() allows to set the floating point control\n(fpc) register of a guest cpu. The new value is tested for validity by\ntemporarily loading it into the fpc register.\nThis may lead to corruption of the fpc register of the host process:\nif an interrupt happens while the value is temporarily loaded into the fpc\nregister, and within interrupt context floating point or vector registers\nare used, the current fp/vx registers are saved with save_fpu_regs()\nassuming they belong to user space and will be loaded into fp/vx registers\nwhen returning to user space.\ntest_fp_ctl() restores the original user space / host process fpc register\nvalue, however it will be discarded, when returning to user space.\nIn result the host process will incorrectly continue to run with the value\nthat was supposed to be used for a guest cpu.\nFix this by simply removing the test. There is another test right before\nthe SIE context is entered which will handles invalid values.\nThis results in a change of behaviour: invalid values will now be accepted\ninstead of that the ioctl fails with -EINVAL. This seems to be acceptable,\ngiven that this interface is most likely not used anymore, and this is in\naddition the same behaviour implemented with the memory mapped interface\n(replace invalid values with zero) - see sync_regs() in kvm-s390.c.

In the Linux kernel, the following vulnerability has been resolved:\nwifi: rt2x00: restart beacon queue when hardware reset\nWhen a hardware reset is triggered, all registers are reset, so all\nqueues are forced to stop in hardware interface. However, mac80211\nwill not automatically stop the queue. If we don't manually stop the\nbeacon queue, the queue will be deadlocked and unable to start again.\nThis patch fixes the issue where Apple devices cannot connect to the\nAP after calling ieee80211_restart_hw().

In the Linux kernel, the following vulnerability has been resolved:\nwifi: ath9k: Fix potential array-index-out-of-bounds read in ath9k_htc_txstatus()\nFix an array-index-out-of-bounds read in ath9k_htc_txstatus(). The bug\noccurs when txs->cnt, data from a URB provided by a USB device, is\nbigger than the size of the array txs->txstatus, which is\nHTC_MAX_TX_STATUS. WARN_ON() already checks it, but there is no bug\nhandling code after the check. Make the function return if that is the\ncase.\nFound by a modified version of syzkaller.\nUBSAN: array-index-out-of-bounds in htc_drv_txrx.c\nindex 13 is out of range for type '__wmi_event_txstatus [12]'\nCall Trace:\nath9k_htc_txstatus\nath9k_wmi_event_tasklet\ntasklet_action_common\n__do_softirq\nirq_exit_rxu\nsysvec_apic_timer_interrupt

In the Linux kernel, the following vulnerability has been resolved:\nnetfilter: nf_tables: fix memleak when more than 255 elements expired\nWhen more than 255 elements expired we're supposed to switch to a new gc\ncontainer structure.\nThis never happens: u8 type will wrap before reaching the boundary\nand nft_trans_gc_space() always returns true.\nThis means we recycle the initial gc container structure and\nlose track of the elements that came before.\nWhile at it, don't deref 'gc' after we've passed it to call_rcu.

In the Linux kernel, the following vulnerability has been resolved:\nnet/core: Fix ETH_P_1588 flow dissector\nWhen a PTP ethernet raw frame with a size of more than 256 bytes followed\nby a 0xff pattern is sent to __skb_flow_dissect, nhoff value calculation\nis wrong. For example: hdr->message_length takes the wrong value (0xffff)\nand it does not replicate real header length. In this case, 'nhoff' value\nwas overridden and the PTP header was badly dissected. This leads to a\nkernel crash.\nnet/core: flow_dissector\nnet/core flow dissector nhoff = 0x0000000e\nnet/core flow dissector hdr->message_length = 0x0000ffff\nnet/core flow dissector nhoff = 0x0001000d (u16 overflow)\n...\nskb linear: 00000000: 00 a0 c9 00 00 00 00 a0 c9 00 00 00 88\nskb frag: 00000000: f7 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\nUsing the size of the ptp_header struct will allow the corrected\ncalculation of the nhoff value.\nnet/core flow dissector nhoff = 0x0000000e\nnet/core flow dissector nhoff = 0x00000030 (sizeof ptp_header)\n...\nskb linear: 00000000: 00 a0 c9 00 00 00 00 a0 c9 00 00 00 88 f7 ff ff\nskb linear: 00000010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\nskb linear: 00000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\nskb frag: 00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\nKernel trace:\n[ 74.984279] ------------[ cut here ]------------\n[ 74.989471] kernel BUG at include/linux/skbuff.h:2440!\n[ 74.995237] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\n[ 75.001098] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G U 5.15.85-intel-ese-standard-lts #1\n[ 75.011629] Hardware name: Intel Corporation A-Island (CPU:AlderLake)/A-Island (ID:06), BIOS SB_ADLP.01.01.00.01.03.008.D-6A9D9E73-dirty Mar 30 2023\n[ 75.026507] RIP: 0010:eth_type_trans+0xd0/0x130\n[ 75.031594] Code: 03 88 47 78 eb c7 8b 47 68 2b 47 6c 48 8b 97 c0 00 00 00 83 f8 01 7e 1b 48 85 d2 74 06 66 83 3a ff 74 09 b8 00 04 00 00 eb ab <0f> 0b b8 00 01 00 00 eb a2 48 85 ff 74 eb 48 8d 54 24 06 31 f6 b9\n[ 75.052612] RSP: 0018:ffff9948c0228de0 EFLAGS: 00010297\n[ 75.058473] RAX: 00000000000003f2 RBX: ffff8e47047dc300 RCX: 0000000000001003\n[ 75.066462] RDX: ffff8e4e8c9ea040 RSI: ffff8e4704e0a000 RDI: ffff8e47047dc300\n[ 75.074458] RBP: ffff8e4704e2acc0 R08: 00000000000003f3 R09: 0000000000000800\n[ 75.082466] R10: 000000000000000d R11: ffff9948c0228dec R12: ffff8e4715e4e010\n[ 75.090461] R13: ffff9948c0545018 R14: 0000000000000001 R15: 0000000000000800\n[ 75.098464] FS: 0000000000000000(0000) GS:ffff8e4e8fb00000(0000) knlGS:0000000000000000\n[ 75.107530] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 75.113982] CR2: 00007f5eb35934a0 CR3: 0000000150e0a002 CR4: 0000000000770ee0\n[ 75.121980] PKRU: 55555554\n[ 75.125035] Call Trace:\n[ 75.127792] \n[ 75.130063] ? eth_get_headlen+0xa4/0xc0\n[ 75.134472] igc_process_skb_fields+0xcd/0x150\n[ 75.139461] igc_poll+0xc80/0x17b0\n[ 75.143272] __napi_poll+0x27/0x170\n[ 75.147192] net_rx_action+0x234/0x280\n[ 75.151409] __do_softirq+0xef/0x2f4\n[ 75.155424] irq_exit_rcu+0xc7/0x110\n[ 75.159432] common_interrupt+0xb8/0xd0\n[ 75.163748] \n[ 75.166112] \n[ 75.168473] asm_common_interrupt+0x22/0x40\n[ 75.173175] RIP: 0010:cpuidle_enter_state+0xe2/0x350\n[ 75.178749] Code: 85 c0 0f 8f 04 02 00 00 31 ff e8 39 6c 67 ff 45 84 ff 74 12 9c 58 f6 c4 02 0f 85 50 02 00 00 31 ff e8 52 b0 6d ff fb 45 85 f6 <0f> 88 b1 00 00 00 49 63 ce 4c 2b 2c 24 48 89 c8 48 6b d1 68 48 c1\n[ 75.199757] RSP: 0018:ffff9948c013bea8 EFLAGS: 00000202\n[ 75.205614] RAX: ffff8e4e8fb00000 RBX: ffffb948bfd23900 RCX: 000000000000001f\n[ 75.213619] RDX: 0000000000000004 RSI: ffffffff94206161 RDI: ffffffff94212e20\n[ 75.221620] RBP: 0000000000000004 R08: 000000117568973a R09: 0000000000000001\n[ 75.229622] R10: 000000000000afc8 R11: ffff8e4e8fb29ce4 R12: ffffffff945ae980\n[ 75.237628] R13: 000000117568973a R14: 0000000000000004 R15: 0000000000000000\n[ 75.245635] ? \n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\nnet: bridge: use DEV_STATS_INC()\nsyzbot/KCSAN reported data-races in br_handle_frame_finish() [1]\nThis function can run from multiple cpus without mutual exclusion.\nAdopt SMP safe DEV_STATS_INC() to update dev->stats fields.\nHandles updates to dev->stats.tx_dropped while we are at it.\n[1]\nBUG: KCSAN: data-race in br_handle_frame_finish / br_handle_frame_finish\nread-write to 0xffff8881374b2178 of 8 bytes by interrupt on cpu 1:\nbr_handle_frame_finish+0xd4f/0xef0 net/bridge/br_input.c:189\nbr_nf_hook_thresh+0x1ed/0x220\nbr_nf_pre_routing_finish_ipv6+0x50f/0x540\nNF_HOOK include/linux/netfilter.h:304 [inline]\nbr_nf_pre_routing_ipv6+0x1e3/0x2a0 net/bridge/br_netfilter_ipv6.c:178\nbr_nf_pre_routing+0x526/0xba0 net/bridge/br_netfilter_hooks.c:508\nnf_hook_entry_hookfn include/linux/netfilter.h:144 [inline]\nnf_hook_bridge_pre net/bridge/br_input.c:272 [inline]\nbr_handle_frame+0x4c9/0x940 net/bridge/br_input.c:417\n__netif_receive_skb_core+0xa8a/0x21e0 net/core/dev.c:5417\n__netif_receive_skb_one_core net/core/dev.c:5521 [inline]\n__netif_receive_skb+0x57/0x1b0 net/core/dev.c:5637\nprocess_backlog+0x21f/0x380 net/core/dev.c:5965\n__napi_poll+0x60/0x3b0 net/core/dev.c:6527\nnapi_poll net/core/dev.c:6594 [inline]\nnet_rx_action+0x32b/0x750 net/core/dev.c:6727\n__do_softirq+0xc1/0x265 kernel/softirq.c:553\nrun_ksoftirqd+0x17/0x20 kernel/softirq.c:921\nsmpboot_thread_fn+0x30a/0x4a0 kernel/smpboot.c:164\nkthread+0x1d7/0x210 kernel/kthread.c:388\nret_from_fork+0x48/0x60 arch/x86/kernel/process.c:147\nret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304\nread-write to 0xffff8881374b2178 of 8 bytes by interrupt on cpu 0:\nbr_handle_frame_finish+0xd4f/0xef0 net/bridge/br_input.c:189\nbr_nf_hook_thresh+0x1ed/0x220\nbr_nf_pre_routing_finish_ipv6+0x50f/0x540\nNF_HOOK include/linux/netfilter.h:304 [inline]\nbr_nf_pre_routing_ipv6+0x1e3/0x2a0 net/bridge/br_netfilter_ipv6.c:178\nbr_nf_pre_routing+0x526/0xba0 net/bridge/br_netfilter_hooks.c:508\nnf_hook_entry_hookfn include/linux/netfilter.h:144 [inline]\nnf_hook_bridge_pre net/bridge/br_input.c:272 [inline]\nbr_handle_frame+0x4c9/0x940 net/bridge/br_input.c:417\n__netif_receive_skb_core+0xa8a/0x21e0 net/core/dev.c:5417\n__netif_receive_skb_one_core net/core/dev.c:5521 [inline]\n__netif_receive_skb+0x57/0x1b0 net/core/dev.c:5637\nprocess_backlog+0x21f/0x380 net/core/dev.c:5965\n__napi_poll+0x60/0x3b0 net/core/dev.c:6527\nnapi_poll net/core/dev.c:6594 [inline]\nnet_rx_action+0x32b/0x750 net/core/dev.c:6727\n__do_softirq+0xc1/0x265 kernel/softirq.c:553\ndo_softirq+0x5e/0x90 kernel/softirq.c:454\n__local_bh_enable_ip+0x64/0x70 kernel/softirq.c:381\n__raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline]\n_raw_spin_unlock_bh+0x36/0x40 kernel/locking/spinlock.c:210\nspin_unlock_bh include/linux/spinlock.h:396 [inline]\nbatadv_tt_local_purge+0x1a8/0x1f0 net/batman-adv/translation-table.c:1356\nbatadv_tt_purge+0x2b/0x630 net/batman-adv/translation-table.c:3560\nprocess_one_work kernel/workqueue.c:2630 [inline]\nprocess_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2703\nworker_thread+0x525/0x730 kernel/workqueue.c:2784\nkthread+0x1d7/0x210 kernel/kthread.c:388\nret_from_fork+0x48/0x60 arch/x86/kernel/process.c:147\nret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304\nvalue changed: 0x00000000000d7190 -> 0x00000000000d7191\nReported by Kernel Concurrency Sanitizer on:\nCPU: 0 PID: 14848 Comm: kworker/u4:11 Not tainted 6.6.0-rc1-syzkaller-00236-gad8a69f361b9 #0

In the Linux kernel, the following vulnerability has been resolved:\nteam: fix null-ptr-deref when team device type is changed\nGet a null-ptr-deref bug as follows with reproducer [1].\nBUG: kernel NULL pointer dereference, address: 0000000000000228\n...\nRIP: 0010:vlan_dev_hard_header+0x35/0x140 [8021q]\n...\nCall Trace:\n\n? __die+0x24/0x70\n? page_fault_oops+0x82/0x150\n? exc_page_fault+0x69/0x150\n? asm_exc_page_fault+0x26/0x30\n? vlan_dev_hard_header+0x35/0x140 [8021q]\n? vlan_dev_hard_header+0x8e/0x140 [8021q]\nneigh_connected_output+0xb2/0x100\nip6_finish_output2+0x1cb/0x520\n? nf_hook_slow+0x43/0xc0\n? ip6_mtu+0x46/0x80\nip6_finish_output+0x2a/0xb0\nmld_sendpack+0x18f/0x250\nmld_ifc_work+0x39/0x160\nprocess_one_work+0x1e6/0x3f0\nworker_thread+0x4d/0x2f0\n? __pfx_worker_thread+0x10/0x10\nkthread+0xe5/0x120\n? __pfx_kthread+0x10/0x10\nret_from_fork+0x34/0x50\n? __pfx_kthread+0x10/0x10\nret_from_fork_asm+0x1b/0x30\n[1]\n$ teamd -t team0 -d -c '{"runner": {"name": "loadbalance"}}'\n$ ip link add name t-dummy type dummy\n$ ip link add link t-dummy name t-dummy.100 type vlan id 100\n$ ip link add name t-nlmon type nlmon\n$ ip link set t-nlmon master team0\n$ ip link set t-nlmon nomaster\n$ ip link set t-dummy up\n$ ip link set team0 up\n$ ip link set t-dummy.100 down\n$ ip link set t-dummy.100 master team0\nWhen enslave a vlan device to team device and team device type is changed\nfrom non-ether to ether, header_ops of team device is changed to\nvlan_header_ops. That is incorrect and will trigger null-ptr-deref\nfor vlan->real_dev in vlan_dev_hard_header() because team device is not\na vlan device.\nCache eth_header_ops in team_setup(), then assign cached header_ops to\nheader_ops of team net device when its type is changed from non-ether\nto ether to fix the bug.

In the Linux kernel, the following vulnerability has been resolved:\nmedia: uvcvideo: Fix OOB read\nIf the index provided by the user is bigger than the mask size, we might do\nan out of bound read.

In the Linux kernel, the following vulnerability has been resolved:\nnet: usb: smsc75xx: Fix uninit-value access in __smsc75xx_read_reg\nsyzbot reported the following uninit-value access issue:\n=====================================================\nBUG: KMSAN: uninit-value in smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]\nBUG: KMSAN: uninit-value in smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482\nCPU: 0 PID: 8696 Comm: kworker/0:3 Not tainted 5.8.0-rc5-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nWorkqueue: usb_hub_wq hub_event\nCall Trace:\n__dump_stack lib/dump_stack.c:77 [inline]\ndump_stack+0x21c/0x280 lib/dump_stack.c:118\nkmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121\n__msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215\nsmsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]\nsmsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482\nusbnet_probe+0x1152/0x3f90 drivers/net/usb/usbnet.c:1737\nusb_probe_interface+0xece/0x1550 drivers/usb/core/driver.c:374\nreally_probe+0xf20/0x20b0 drivers/base/dd.c:529\ndriver_probe_device+0x293/0x390 drivers/base/dd.c:701\n__device_attach_driver+0x63f/0x830 drivers/base/dd.c:807\nbus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431\n__device_attach+0x4e2/0x7f0 drivers/base/dd.c:873\ndevice_initial_probe+0x4a/0x60 drivers/base/dd.c:920\nbus_probe_device+0x177/0x3d0 drivers/base/bus.c:491\ndevice_add+0x3b0e/0x40d0 drivers/base/core.c:2680\nusb_set_configuration+0x380f/0x3f10 drivers/usb/core/message.c:2032\nusb_generic_driver_probe+0x138/0x300 drivers/usb/core/generic.c:241\nusb_probe_device+0x311/0x490 drivers/usb/core/driver.c:272\nreally_probe+0xf20/0x20b0 drivers/base/dd.c:529\ndriver_probe_device+0x293/0x390 drivers/base/dd.c:701\n__device_attach_driver+0x63f/0x830 drivers/base/dd.c:807\nbus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431\n__device_attach+0x4e2/0x7f0 drivers/base/dd.c:873\ndevice_initial_probe+0x4a/0x60 drivers/base/dd.c:920\nbus_probe_device+0x177/0x3d0 drivers/base/bus.c:491\ndevice_add+0x3b0e/0x40d0 drivers/base/core.c:2680\nusb_new_device+0x1bd4/0x2a30 drivers/usb/core/hub.c:2554\nhub_port_connect drivers/usb/core/hub.c:5208 [inline]\nhub_port_connect_change drivers/usb/core/hub.c:5348 [inline]\nport_event drivers/usb/core/hub.c:5494 [inline]\nhub_event+0x5e7b/0x8a70 drivers/usb/core/hub.c:5576\nprocess_one_work+0x1688/0x2140 kernel/workqueue.c:2269\nworker_thread+0x10bc/0x2730 kernel/workqueue.c:2415\nkthread+0x551/0x590 kernel/kthread.c:292\nret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293\nLocal variable ----buf.i87@smsc75xx_bind created at:\n__smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]\nsmsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]\nsmsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482\n__smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]\nsmsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]\nsmsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482\nThis issue is caused because usbnet_read_cmd() reads less bytes than requested\n(zero byte in the reproducer). In this case, 'buf' is not properly filled.\nThis patch fixes the issue by returning -ENODATA if usbnet_read_cmd() reads\nless bytes than requested.

In the Linux kernel, the following vulnerability has been resolved:\nplatform/x86: think-lmi: Fix reference leak\nIf a duplicate attribute is found using kset_find_obj(), a reference\nto that attribute is returned which needs to be disposed accordingly\nusing kobject_put(). Move the setting name validation into a separate\nfunction to allow for this change without having to duplicate the\ncleanup code for this setting.\nAs a side note, a very similar bug was fixed in\ncommit 7295a996fdab ("platform/x86: dell-sysman: Fix reference leak"),\nso it seems that the bug was copied from that driver.\nCompile-tested only.

In the Linux kernel, the following vulnerability has been resolved:\nRDMA/siw: Fix connection failure handling\nIn case immediate MPA request processing fails, the newly\ncreated endpoint unlinks the listening endpoint and is\nready to be dropped. This special case was not handled\ncorrectly by the code handling the later TCP socket close,\ncausing a NULL dereference crash in siw_cm_work_handler()\nwhen dereferencing a NULL listener. We now also cancel\nthe useless MPA timeout, if immediate MPA request\nprocessing fails.\nThis patch furthermore simplifies MPA processing in general:\nScheduling a useless TCP socket read in sk_data_ready() upcall\nis now surpressed, if the socket is already moved out of\nTCP_ESTABLISHED state.

In the Linux kernel, the following vulnerability has been resolved:\nmm/sparsemem: fix race in accessing memory_section->usage\nThe below race is observed on a PFN which falls into the device memory\nregion with the system memory configuration where PFN's are such that\n[ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL]. Since normal zone start and end\npfn contains the device memory PFN's as well, the compaction triggered\nwill try on the device memory PFN's too though they end up in NOP(because\npfn_to_online_page() returns NULL for ZONE_DEVICE memory sections). When\nfrom other core, the section mappings are being removed for the\nZONE_DEVICE region, that the PFN in question belongs to, on which\ncompaction is currently being operated is resulting into the kernel crash\nwith CONFIG_SPASEMEM_VMEMAP enabled. The crash logs can be seen at [1].\ncompact_zone()memunmap_pages\n----------------------------\n__pageblock_pfn_to_page\n......\n(a)pfn_valid():\nvalid_section()//return true\n(b)__remove_pages()->\nsparse_remove_section()->\nsection_deactivate():\n[Free the array ms->usage and set\nms->usage = NULL]\npfn_section_valid()\n[Access ms->usage which\nis NULL]\nNOTE: From the above it can be said that the race is reduced to between\nthe pfn_valid()/pfn_section_valid() and the section deactivate with\nSPASEMEM_VMEMAP enabled.\nThe commit b943f045a9af("mm/sparse: fix kernel crash with\npfn_section_valid check") tried to address the same problem by clearing\nthe SECTION_HAS_MEM_MAP with the expectation of valid_section() returns\nfalse thus ms->usage is not accessed.\nFix this issue by the below steps:\na) Clear SECTION_HAS_MEM_MAP before freeing the ->usage.\nb) RCU protected read side critical section will either return NULL\nwhen SECTION_HAS_MEM_MAP is cleared or can successfully access ->usage.\nc) Free the ->usage with kfree_rcu() and set ms->usage = NULL. No\nattempt will be made to access ->usage after this as the\nSECTION_HAS_MEM_MAP is cleared thus valid_section() return false.\nThanks to David/Pavan for their inputs on this patch.\n[1] https://lore.kernel.org/linux-mm/994410bb-89aa-d987-1f50-f514903c55aa@quicinc.com/\nOn Snapdragon SoC, with the mentioned memory configuration of PFN's as\n[ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL], we are able to see bunch of\nissues daily while testing on a device farm.\nFor this particular issue below is the log. Though the below log is\nnot directly pointing to the pfn_section_valid(){ ms->usage;}, when we\nloaded this dump on T32 lauterbach tool, it is pointing.\n[ 540.578056] Unable to handle kernel NULL pointer dereference at\nvirtual address 0000000000000000\n[ 540.578068] Mem abort info:\n[ 540.578070] ESR = 0x0000000096000005\n[ 540.578073] EC = 0x25: DABT (current EL), IL = 32 bits\n[ 540.578077] SET = 0, FnV = 0\n[ 540.578080] EA = 0, S1PTW = 0\n[ 540.578082] FSC = 0x05: level 1 translation fault\n[ 540.578085] Data abort info:\n[ 540.578086] ISV = 0, ISS = 0x00000005\n[ 540.578088] CM = 0, WnR = 0\n[ 540.579431] pstate: 82400005 (Nzcv daif +PAN -UAO +TCO -DIT -SSBSBTYPE=--)\n[ 540.579436] pc : __pageblock_pfn_to_page+0x6c/0x14c\n[ 540.579454] lr : compact_zone+0x994/0x1058\n[ 540.579460] sp : ffffffc03579b510\n[ 540.579463] x29: ffffffc03579b510 x28: 0000000000235800 x27:000000000000000c\n[ 540.579470] x26: 0000000000235c00 x25: 0000000000000068 x24:ffffffc03579b640\n[ 540.579477] x23: 0000000000000001 x22: ffffffc03579b660 x21:0000000000000000\n[ 540.579483] x20: 0000000000235bff x19: ffffffdebf7e3940 x18:ffffffdebf66d140\n[ 540.579489] x17: 00000000739ba063 x16: 00000000739ba063 x15:00000000009f4bff\n[ 540.579495] x14: 0000008000000000 x13: 0000000000000000 x12:0000000000000001\n[ 540.579501] x11: 0000000000000000 x10: 0000000000000000 x9 :ffffff897d2cd440\n[ 540.579507] x8 : 0000000000000000 x7 : 0000000000000000 x6 :ffffffc03579b5b4\n[ 540.579512] x5 : 0000000000027f25 x4 : ffffffc03579b5b8 x3 :0000000000000\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\nusb: hub: Guard against accesses to uninitialized BOS descriptors\nMany functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h\naccess fields inside udev->bos without checking if it was allocated and\ninitialized. If usb_get_bos_descriptor() fails for whatever\nreason, udev->bos will be NULL and those accesses will result in a\ncrash:\nBUG: kernel NULL pointer dereference, address: 0000000000000018\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 \nHardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021\nWorkqueue: usb_hub_wq hub_event\nRIP: 0010:hub_port_reset+0x193/0x788\nCode: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9\nRSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310\nRDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840\nRBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060\nR10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000\nR13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000\nFS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0\nCall Trace:\nhub_event+0x73f/0x156e\n? hub_activate+0x5b7/0x68f\nprocess_one_work+0x1a2/0x487\nworker_thread+0x11a/0x288\nkthread+0x13a/0x152\n? process_one_work+0x487/0x487\n? kthread_associate_blkcg+0x70/0x70\nret_from_fork+0x1f/0x30\nFall back to a default behavior if the BOS descriptor isn't accessible\nand skip all the functionalities that depend on it: LPM support checks,\nSuper Speed capabilitiy checks, U1/U2 states setup.

In the Linux kernel, the following vulnerability has been resolved:\ngfs2: Fix kernel NULL pointer dereference in gfs2_rgrp_dump\nSyzkaller has reported a NULL pointer dereference when accessing\nrgd->rd_rgl in gfs2_rgrp_dump(). This can happen when creating\nrgd->rd_gl fails in read_rindex_entry(). Add a NULL pointer check in\ngfs2_rgrp_dump() to prevent that.

In the Linux kernel, the following vulnerability has been resolved:\nuio: Fix use-after-free in uio_open\ncore-1core-2\n-------------------------------------------------------\nuio_unregister_deviceuio_open\nidev = idr_find()\ndevice_unregister(&idev->dev)\nput_device(&idev->dev)\nuio_device_release\nget_device(&idev->dev)\nkfree(idev)\nuio_free_minor(minor)\nuio_release\nput_device(&idev->dev)\nkfree(idev)\n-------------------------------------------------------\nIn the core-1 uio_unregister_device(), the device_unregister will kfree\nidev when the idev->dev kobject ref is 1. But after core-1\ndevice_unregister, put_device and before doing kfree, the core-2 may\nget_device. Then:\n1. After core-1 kfree idev, the core-2 will do use-after-free for idev.\n2. When core-2 do uio_release and put_device, the idev will be double\nfreed.\nTo address this issue, we can get idev atomic & inc idev reference with\nminor_lock.

In the Linux kernel, the following vulnerability has been resolved:\nsmb: client: fix potential OOBs in smb2_parse_contexts()\nValidate offsets and lengths before dereferencing create contexts in\nsmb2_parse_contexts().\nThis fixes following oops when accessing invalid create contexts from\nserver:\nBUG: unable to handle page fault for address: ffff8881178d8cc3\n#PF: supervisor read access in kernel mode\n#PF: error_code(0x0000) - not-present page\nPGD 4a01067 P4D 4a01067 PUD 0\nOops: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 3 PID: 1736 Comm: mount.cifs Not tainted 6.7.0-rc4 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS\nrel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014\nRIP: 0010:smb2_parse_contexts+0xa0/0x3a0 [cifs]\nCode: f8 10 75 13 48 b8 93 ad 25 50 9c b4 11 e7 49 39 06 0f 84 d2 00\n00 00 8b 45 00 85 c0 74 61 41 29 c5 48 01 c5 41 83 fd 0f 76 55 <0f> b7\n7d 04 0f b7 45 06 4c 8d 74 3d 00 66 83 f8 04 75 bc ba 04 00\nRSP: 0018:ffffc900007939e0 EFLAGS: 00010216\nRAX: ffffc90000793c78 RBX: ffff8880180cc000 RCX: ffffc90000793c90\nRDX: ffffc90000793cc0 RSI: ffff8880178d8cc0 RDI: ffff8880180cc000\nRBP: ffff8881178d8cbf R08: ffffc90000793c22 R09: 0000000000000000\nR10: ffff8880180cc000 R11: 0000000000000024 R12: 0000000000000000\nR13: 0000000000000020 R14: 0000000000000000 R15: ffffc90000793c22\nFS: 00007f873753cbc0(0000) GS:ffff88806bc00000(0000)\nknlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffff8881178d8cc3 CR3: 00000000181ca000 CR4: 0000000000750ef0\nPKRU: 55555554\nCall Trace:\n\n? __die+0x23/0x70\n? page_fault_oops+0x181/0x480\n? search_module_extables+0x19/0x60\n? srso_alias_return_thunk+0x5/0xfbef5\n? exc_page_fault+0x1b6/0x1c0\n? asm_exc_page_fault+0x26/0x30\n? smb2_parse_contexts+0xa0/0x3a0 [cifs]\nSMB2_open+0x38d/0x5f0 [cifs]\n? smb2_is_path_accessible+0x138/0x260 [cifs]\nsmb2_is_path_accessible+0x138/0x260 [cifs]\ncifs_is_path_remote+0x8d/0x230 [cifs]\ncifs_mount+0x7e/0x350 [cifs]\ncifs_smb3_do_mount+0x128/0x780 [cifs]\nsmb3_get_tree+0xd9/0x290 [cifs]\nvfs_get_tree+0x2c/0x100\n? capable+0x37/0x70\npath_mount+0x2d7/0xb80\n? srso_alias_return_thunk+0x5/0xfbef5\n? _raw_spin_unlock_irqrestore+0x44/0x60\n__x64_sys_mount+0x11a/0x150\ndo_syscall_64+0x47/0xf0\nentry_SYSCALL_64_after_hwframe+0x6f/0x77\nRIP: 0033:0x7f8737657b1e

A flaw in the routing table size was found in the ICMPv6 handling of "Packet Too Big". The size of the routing table is regulated by periodic garbage collection. However, with "Packet Too Big Messages" it is possible to exceed the routing table size and garbage collector threshold. A user located in the local network or with a high bandwidth connection can increase the CPU usage of the server that accepts IPV6 connections up to 95%.

An issue was discovered in the Linux kernel before 6.6.8. do_vcc_ioctl in net/atm/ioctl.c has a use-after-free because of a vcc_recvmsg race condition.

A race condition was found in the QXL driver in the Linux kernel. The qxl_mode_dumb_create() function dereferences the qobj returned by the qxl_gem_object_create_with_handle(), but the handle is the only one holding a reference to it. This flaw allows an attacker to guess the returned handle value and trigger a use-after-free issue, potentially leading to a denial of service or privilege escalation.

A flaw was found in the XFRM subsystem in the Linux kernel. The specific flaw exists within the processing of state filters, which can result in a read past the end of an allocated buffer. This flaw allows a local privileged (CAP_NET_ADMIN) attacker to trigger an out-of-bounds read, potentially leading to an information disclosure.

A flaw was found in the Netfilter subsystem in the Linux kernel. The sctp_mt_check did not validate the flag_count field. This flaw allows a local privileged (CAP_NET_ADMIN) attacker to trigger an out-of-bounds read, leading to a crash or information disclosure.

A flaw was found in the Netfilter subsystem in the Linux kernel. The nfnl_osf_add_callback function did not validate the user mode controlled opt_num field. This flaw allows a local privileged (CAP_NET_ADMIN) attacker to trigger an out-of-bounds read, leading to a crash or information disclosure.

Bluetooth BR/EDR devices with Secure Simple Pairing and Secure Connections pairing in Bluetooth Core Specification 4.2 through 5.4 allow certain man-in-the-middle attacks that force a short key length, and might lead to discovery of the encryption key and live injection, aka BLUFFS.

In the Linux kernel, the following vulnerability has been resolved:\npowerpc/pseries: Fix potential memleak in papr_get_attr()\n`buf` is allocated in papr_get_attr(), and krealloc() of `buf`\ncould fail. We need to free the original `buf` in the case of failure.

In the Linux kernel, the following vulnerability has been resolved:\nvt: fix memory overlapping when deleting chars in the buffer\nA memory overlapping copy occurs when deleting a long line. This memory\noverlapping copy can cause data corruption when scr_memcpyw is optimized\nto memcpy because memcpy does not ensure its behavior if the destination\nbuffer overlaps with the source buffer. The line buffer is not always\nbroken, because the memcpy utilizes the hardware acceleration, whose\nresult is not deterministic.\nFix this problem by using replacing the scr_memcpyw with scr_memmovew.

In the Linux kernel, the following vulnerability has been resolved:\ntty: tty_buffer: Fix the softlockup issue in flush_to_ldisc\nWhen running ltp testcase(ltp/testcases/kernel/pty/pty04.c) with arm64, there is a soft lockup,\nwhich look like this one:\nWorkqueue: events_unbound flush_to_ldisc\nCall trace:\ndump_backtrace+0x0/0x1ec\nshow_stack+0x24/0x30\ndump_stack+0xd0/0x128\npanic+0x15c/0x374\nwatchdog_timer_fn+0x2b8/0x304\n__run_hrtimer+0x88/0x2c0\n__hrtimer_run_queues+0xa4/0x120\nhrtimer_interrupt+0xfc/0x270\narch_timer_handler_phys+0x40/0x50\nhandle_percpu_devid_irq+0x94/0x220\n__handle_domain_irq+0x88/0xf0\ngic_handle_irq+0x84/0xfc\nel1_irq+0xc8/0x180\nslip_unesc+0x80/0x214 [slip]\ntty_ldisc_receive_buf+0x64/0x80\ntty_port_default_receive_buf+0x50/0x90\nflush_to_ldisc+0xbc/0x110\nprocess_one_work+0x1d4/0x4b0\nworker_thread+0x180/0x430\nkthread+0x11c/0x120\nIn the testcase pty04, The first process call the write syscall to send\ndata to the pty master. At the same time, the workqueue will do the\nflush_to_ldisc to pop data in a loop until there is no more data left.\nWhen the sender and workqueue running in different core, the sender sends\ndata fastly in full time which will result in workqueue doing work in loop\nfor a long time and occuring softlockup in flush_to_ldisc with kernel\nconfigured without preempt. So I add need_resched check and cond_resched\nin the flush_to_ldisc loop to avoid it.

In the Linux kernel, the following vulnerability has been resolved:\nnet: usb: fix memory leak in smsc75xx_bind\nSyzbot reported memory leak in smsc75xx_bind().\nThe problem was is non-freed memory in case of\nerrors after memory allocation.\nbacktrace:\n[] kmalloc include/linux/slab.h:556 [inline]\n[] kzalloc include/linux/slab.h:686 [inline]\n[] smsc75xx_bind+0x7a/0x334 drivers/net/usb/smsc75xx.c:1460\n[] usbnet_probe+0x3b6/0xc30 drivers/net/usb/usbnet.c:1728

In the Linux kernel, the following vulnerability has been resolved:\ni2c: i801: Don't generate an interrupt on bus reset\nNow that the i2c-i801 driver supports interrupts, setting the KILL bit\nin a attempt to recover from a timed out transaction triggers an\ninterrupt. Unfortunately, the interrupt handler (i801_isr) is not\nprepared for this situation and will try to process the interrupt as\nif it was signaling the end of a successful transaction. In the case\nof a block transaction, this can result in an out-of-range memory\naccess.\nThis condition was reproduced several times by syzbot:\nhttps://syzkaller.appspot.com/bug?extid=ed71512d469895b5b34e\nhttps://syzkaller.appspot.com/bug?extid=8c8dedc0ba9e03f6c79e\nhttps://syzkaller.appspot.com/bug?extid=c8ff0b6d6c73d81b610e\nhttps://syzkaller.appspot.com/bug?extid=33f6c360821c399d69eb\nhttps://syzkaller.appspot.com/bug?extid=be15dc0b1933f04b043a\nhttps://syzkaller.appspot.com/bug?extid=b4d3fd1dfd53e90afd79\nSo disable interrupts while trying to reset the bus. Interrupts will\nbe enabled again for the following transaction.

In the Linux kernel, the following vulnerability has been resolved:\npid: take a reference when initializing `cad_pid`\nDuring boot, kernel_init_freeable() initializes `cad_pid` to the init\ntask's struct pid. Later on, we may change `cad_pid` via a sysctl, and\nwhen this happens proc_do_cad_pid() will increment the refcount on the\nnew pid via get_pid(), and will decrement the refcount on the old pid\nvia put_pid(). As we never called get_pid() when we initialized\n`cad_pid`, we decrement a reference we never incremented, can therefore\nfree the init task's struct pid early. As there can be dangling\nreferences to the struct pid, we can later encounter a use-after-free\n(e.g. when delivering signals).\nThis was spotted when fuzzing v5.13-rc3 with Syzkaller, but seems to\nhave been around since the conversion of `cad_pid` to struct pid in\ncommit 9ec52099e4b8 ("[PATCH] replace cad_pid by a struct pid") from the\npre-KASAN stone age of v2.6.19.\nFix this by getting a reference to the init task's struct pid when we\nassign it to `cad_pid`.\nFull KASAN splat below.\n==================================================================\nBUG: KASAN: use-after-free in ns_of_pid include/linux/pid.h:153 [inline]\nBUG: KASAN: use-after-free in task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509\nRead of size 4 at addr ffff23794dda0004 by task syz-executor.0/273\nCPU: 1 PID: 273 Comm: syz-executor.0 Not tainted 5.12.0-00001-g9aef892b2d15 #1\nHardware name: linux,dummy-virt (DT)\nCall trace:\nns_of_pid include/linux/pid.h:153 [inline]\ntask_active_pid_ns+0xc0/0xc8 kernel/pid.c:509\ndo_notify_parent+0x308/0xe60 kernel/signal.c:1950\nexit_notify kernel/exit.c:682 [inline]\ndo_exit+0x2334/0x2bd0 kernel/exit.c:845\ndo_group_exit+0x108/0x2c8 kernel/exit.c:922\nget_signal+0x4e4/0x2a88 kernel/signal.c:2781\ndo_signal arch/arm64/kernel/signal.c:882 [inline]\ndo_notify_resume+0x300/0x970 arch/arm64/kernel/signal.c:936\nwork_pending+0xc/0x2dc\nAllocated by task 0:\nslab_post_alloc_hook+0x50/0x5c0 mm/slab.h:516\nslab_alloc_node mm/slub.c:2907 [inline]\nslab_alloc mm/slub.c:2915 [inline]\nkmem_cache_alloc+0x1f4/0x4c0 mm/slub.c:2920\nalloc_pid+0xdc/0xc00 kernel/pid.c:180\ncopy_process+0x2794/0x5e18 kernel/fork.c:2129\nkernel_clone+0x194/0x13c8 kernel/fork.c:2500\nkernel_thread+0xd4/0x110 kernel/fork.c:2552\nrest_init+0x44/0x4a0 init/main.c:687\narch_call_rest_init+0x1c/0x28\nstart_kernel+0x520/0x554 init/main.c:1064\n0x0\nFreed by task 270:\nslab_free_hook mm/slub.c:1562 [inline]\nslab_free_freelist_hook+0x98/0x260 mm/slub.c:1600\nslab_free mm/slub.c:3161 [inline]\nkmem_cache_free+0x224/0x8e0 mm/slub.c:3177\nput_pid.part.4+0xe0/0x1a8 kernel/pid.c:114\nput_pid+0x30/0x48 kernel/pid.c:109\nproc_do_cad_pid+0x190/0x1b0 kernel/sysctl.c:1401\nproc_sys_call_handler+0x338/0x4b0 fs/proc/proc_sysctl.c:591\nproc_sys_write+0x34/0x48 fs/proc/proc_sysctl.c:617\ncall_write_iter include/linux/fs.h:1977 [inline]\nnew_sync_write+0x3ac/0x510 fs/read_write.c:518\nvfs_write fs/read_write.c:605 [inline]\nvfs_write+0x9c4/0x1018 fs/read_write.c:585\nksys_write+0x124/0x240 fs/read_write.c:658\n__do_sys_write fs/read_write.c:670 [inline]\n__se_sys_write fs/read_write.c:667 [inline]\n__arm64_sys_write+0x78/0xb0 fs/read_write.c:667\n__invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]\ninvoke_syscall arch/arm64/kernel/syscall.c:49 [inline]\nel0_svc_common.constprop.1+0x16c/0x388 arch/arm64/kernel/syscall.c:129\ndo_el0_svc+0xf8/0x150 arch/arm64/kernel/syscall.c:168\nel0_svc+0x28/0x38 arch/arm64/kernel/entry-common.c:416\nel0_sync_handler+0x134/0x180 arch/arm64/kernel/entry-common.c:432\nel0_sync+0x154/0x180 arch/arm64/kernel/entry.S:701\nThe buggy address belongs to the object at ffff23794dda0000\nwhich belongs to the cache pid of size 224\nThe buggy address is located 4 bytes inside of\n224-byte region [ff\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\nnet:emac/emac-mac: Fix a use after free in emac_mac_tx_buf_send\nIn emac_mac_tx_buf_send, it calls emac_tx_fill_tpd(..,skb,..).\nIf some error happens in emac_tx_fill_tpd(), the skb will be freed via\ndev_kfree_skb(skb) in error branch of emac_tx_fill_tpd().\nBut the freed skb is still used via skb->len by netdev_sent_queue(,skb->len).\nAs i observed that emac_tx_fill_tpd() haven't modified the value of skb->len,\nthus my patch assigns skb->len to 'len' before the possible free and\nuse 'len' instead of skb->len later.

In the Linux kernel, the following vulnerability has been resolved:\ni2c: validate user data in compat ioctl\nWrong user data may cause warning in i2c_transfer(), ex: zero msgs.\nUserspace should not be able to trigger warnings, so this patch adds\nvalidation checks for user data in compact ioctl to prevent reported\nwarnings

In the Linux kernel, the following vulnerability has been resolved:\nmedia: dvbdev: Fix memory leak in dvb_media_device_free()\ndvb_media_device_free() is leaking memory. Free `dvbdev->adapter->conn`\nbefore setting it to NULL, as documented in include/media/media-device.h:\n"The media_entity instance itself must be freed explicitly by the driver\nif required."

In the Linux kernel, the following vulnerability has been resolved:\ni2c: Fix a potential use after free\nFree the adap structure only after we are done using it.\nThis patch just moves the put_device() down a bit to avoid the\nuse after free.\n[wsa: added comment to the code, added Fixes tag]

less through 653 allows OS command execution via a newline character in the name of a file, because quoting is mishandled in filename.c. Exploitation typically requires use with attacker-controlled file names, such as the files extracted from an untrusted archive. Exploitation also requires the LESSOPEN environment variable, but this is set by default in many common cases.

Flatpak is a system for building, distributing, and running sandboxed desktop applications on Linux. in versions before 1.10.9, 1.12.9, 1.14.6, and 1.15.8, a malicious or compromised Flatpak app could execute arbitrary code outside its sandbox. Normally, the `--command` argument of `flatpak run` expects to be given a command to run in the specified Flatpak app, optionally along with some arguments. However it is possible to instead pass `bwrap` arguments to `--command=`, such as `--bind`. It's possible to pass an arbitrary `commandline` to the portal interface `org.freedesktop.portal.Background.RequestBackground` from within a Flatpak app. When this is converted into a `--command` and arguments, it achieves the same effect of passing arguments directly to `bwrap`, and thus can be used for a sandbox escape. The solution is to pass the `--` argument to `bwrap`, which makes it stop processing options. This has been supported since bubblewrap 0.3.0. All supported versions of Flatpak require at least that version of bubblewrap. xdg-desktop-portal version 1.18.4 will mitigate this vulnerability by only allowing Flatpak apps to create .desktop files for commands that do not start with --. The vulnerability is patched in 1.15.8, 1.10.9, 1.12.9, and 1.14.6.

A heap-based buffer over-read vulnerability was found in the X.org server's ProcAppleDRICreatePixmap() function. This issue occurs when byte-swapped length values are used in replies, potentially leading to memory leakage and segmentation faults, particularly when triggered by a client with a different endianness. This vulnerability could be exploited by an attacker to cause the X server to read heap memory values and then transmit them back to the client until encountering an unmapped page, resulting in a crash. Despite the attacker's inability to control the specific memory copied into the replies, the small length values typically stored in a 32-bit integer can result in significant attempted out-of-bounds reads.

An issue was discovered in Django 3.2 before 3.2.24, 4.2 before 4.2.10, and Django 5.0 before 5.0.2. The intcomma template filter was subject to a potential denial-of-service attack when used with very long strings.

libgit2 is a portable C implementation of the Git core methods provided as a linkable library with a solid API, allowing to build Git functionality into your application. Using well-crafted inputs to `git_revparse_single` can cause the function to enter an infinite loop, potentially causing a Denial of Service attack in the calling application. The revparse function in `src/libgit2/revparse.c` uses a loop to parse the user-provided spec string. There is an edge-case during parsing that allows a bad actor to force the loop conditions to access arbitrary memory. Potentially, this could also leak memory if the extracted rev spec is reflected back to the attacker. As such, libgit2 versions before 1.4.0 are not affected. Users should upgrade to version 1.6.5 or 1.7.2.

Denial of Service due to improper input validation vulnerability for HTTP/2 requests in Apache Tomcat. When processing an HTTP/2 request, if the request exceeded any of the configured limits for headers, the associated HTTP/2 stream was not reset until after all of the headers had been processed.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M16, from 10.1.0-M1 through 10.1.18, from 9.0.0-M1 through 9.0.85, from 8.5.0 through 8.5.98.\nUsers are recommended to upgrade to version 11.0.0-M17, 10.1.19, 9.0.86 or 8.5.99 which fix the issue.

Denial of Service via incomplete cleanup vulnerability in Apache Tomcat. It was possible for WebSocket clients to keep WebSocket connections open leading to increased resource consumption.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M16, from 10.1.0-M1 through 10.1.18, from 9.0.0-M1 through 9.0.85, from 8.5.0 through 8.5.98.\nUsers are recommended to upgrade to version 11.0.0-M17, 10.1.19, 9.0.86 or 8.5.99 which fix the issue.

BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner. In addition to running containers as build steps, BuildKit also provides APIs for running interactive containers based on built images. It was possible to use these APIs to ask BuildKit to run a container with elevated privileges. Normally, running such containers is only allowed if special `security.insecure` entitlement is enabled both by buildkitd configuration and allowed by the user initializing the build request. The issue has been fixed in v0.12.5 . Avoid using BuildKit frontends from untrusted sources.

BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner. A malicious BuildKit frontend or Dockerfile using RUN --mount could trick the feature that removes empty files created for the mountpoints into removing a file outside the container, from the host system. The issue has been fixed in v0.12.5. Workarounds include avoiding using BuildKit frontends from an untrusted source or building an untrusted Dockerfile containing RUN --mount feature.

BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner. Two malicious build steps running in parallel sharing the same cache mounts with subpaths could cause a race condition that can lead to files from the host system being accessible to the build container. The issue has been fixed in v0.12.5. Workarounds include, avoiding using BuildKit frontend from an untrusted source or building an untrusted Dockerfile containing cache mounts with --mount=type=cache,source=... options.

Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure.

EDK2's Network Package is susceptible to a predictable TCP Initial Sequence Number. This\nvulnerability can be exploited by an attacker to gain unauthorized \naccess and potentially lead to a loss of Confidentiality.

EDK2's Network Package is susceptible to a predictable TCP Initial Sequence Number. This\nvulnerability can be exploited by an attacker to gain unauthorized \naccess and potentially lead to a loss of Confidentiality.

A use after free issue was addressed with improved memory management. This issue is fixed in Safari 17.2, iOS 17.2 and iPadOS 17.2, tvOS 17.2, watchOS 10.2, macOS Sonoma 14.2. Processing maliciously crafted web content may lead to arbitrary code execution.

A flaw was found in Open vSwitch where multiple versions are vulnerable to crafted Geneve packets, which may result in a denial of service and invalid memory accesses. Triggering this issue requires that hardware offloading via the netlink path is enabled.

BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner. In affected versions when the user sends a build request that contains a Git URL that contains credentials and the build creates a provenance attestation describing that build, these credentials could be visible from the provenance attestation. Git URL can be passed in two ways: 1) Invoking build directly from a URL with credentials. 2) If the client sends additional version control system (VCS) info hint parameters on builds from a local source. Usually, that would mean reading the origin URL from `.git/config` file. When a build is performed under specific conditions where credentials were passed to BuildKit they may be visible to everyone who has access to provenance attestation. Provenance attestations and VCS info hints were added in version v0.11.0. Previous versions are not vulnerable. In v0.10, when building directly from Git URL, the same URL could be visible in `BuildInfo` structure that is a predecessor of Provenance attestations. Previous versions are not vulnerable. This bug has been fixed in v0.11.4. Users are advised to upgrade. Users unable to upgrade may disable VCS info hints by setting `BUILDX_GIT_INFO=0`. `buildctl` does not set VCS hints based on `.git` directory, and values would need to be passed manually with `--opt`.