In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: don't access invalid sched\n\nSince 2320c9e6a768 ("drm/sched: memset() 'job' in drm_sched_job_init()")\naccessing job->base.sched can produce unexpected results as the initialisation\nof (*job)->base.sched done in amdgpu_job_alloc is overwritten by the\nmemset.\n\nThis commit fixes an issue when a CS would fail validation and would\nbe rejected after job->num_ibs is incremented. In this case,\namdgpu_ib_free(ring->adev, ...) will be called, which would crash the\nmachine because the ring value is bogus.\n\nTo fix this, pass a NULL pointer to amdgpu_ib_free(): we can do this\nbecause the device is actually not used in this function.\n\nThe next commit will remove the ring argument completely.\n\n(cherry picked from commit 2ae520cb12831d264ceb97c61f72c59d33c0dbd7)

In the Linux kernel, the following vulnerability has been resolved:\n\nx86/hyperv: fix kexec crash due to VP assist page corruption\n\ncommit 9636be85cc5b ("x86/hyperv: Fix hyperv_pcpu_input_arg handling when\nCPUs go online/offline") introduces a new cpuhp state for hyperv\ninitialization.\n\ncpuhp_setup_state() returns the state number if state is\nCPUHP_AP_ONLINE_DYN or CPUHP_BP_PREPARE_DYN and 0 for all other states.\nFor the hyperv case, since a new cpuhp state was introduced it would\nreturn 0. However, in hv_machine_shutdown(), the cpuhp_remove_state() call\nis conditioned upon "hyperv_init_cpuhp > 0". This will never be true and\nso hv_cpu_die() won't be called on all CPUs. This means the VP assist page\nwon't be reset. When the kexec kernel tries to setup the VP assist page\nagain, the hypervisor corrupts the memory region of the old VP assist page\ncausing a panic in case the kexec kernel is using that memory elsewhere.\nThis was originally fixed in commit dfe94d4086e4 ("x86/hyperv: Fix kexec\npanic/hang issues").\n\nGet rid of hyperv_init_cpuhp entirely since we are no longer using a\ndynamic cpuhp state and use CPUHP_AP_HYPERV_ONLINE directly with\ncpuhp_remove_state().

In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: Intel: soc-acpi-intel-lnl-match: add missing empty item\n\nThere is no links_num in struct snd_soc_acpi_mach {}, and we test\n!link->num_adr as a condition to end the loop in hda_sdw_machine_select().\nSo an empty item in struct snd_soc_acpi_link_adr array is required.

In the Linux kernel, the following vulnerability has been resolved:\n\nspi: rockchip: Resolve unbalanced runtime PM / system PM handling\n\nCommit e882575efc77 ("spi: rockchip: Suspend and resume the bus during\nNOIRQ_SYSTEM_SLEEP_PM ops") stopped respecting runtime PM status and\nsimply disabled clocks unconditionally when suspending the system. This\ncauses problems when the device is already runtime suspended when we go\nto sleep -- in which case we double-disable clocks and produce a\nWARNing.\n\nSwitch back to pm_runtime_force_{suspend,resume}(), because that still\nseems like the right thing to do, and the aforementioned commit makes no\nexplanation why it stopped using it.\n\nAlso, refactor some of the resume() error handling, because it's not\nactually a good idea to re-disable clocks on failure.

In the Linux kernel, the following vulnerability has been resolved:\n\ni3c: mipi-i3c-hci: Mask ring interrupts before ring stop request\n\nBus cleanup path in DMA mode may trigger a RING_OP_STAT interrupt when\nthe ring is being stopped. Depending on timing between ring stop request\ncompletion, interrupt handler removal and code execution this may lead\nto a NULL pointer dereference in hci_dma_irq_handler() if it gets to run\nafter the io_data pointer is set to NULL in hci_dma_cleanup().\n\nPrevent this my masking the ring interrupts before ring stop request.

body-parser is Node.js body parsing middleware. body-parser <1.20.3 is vulnerable to denial of service when url encoding is enabled. A malicious actor using a specially crafted payload could flood the server with a large number of requests, resulting in denial of service. This issue is patched in 1.20.3.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe: Fix opregion leak\n\nBeing part o the display, ideally the setup and cleanup would be done by\ndisplay itself. However this is a bigger refactor that needs to be done\non both i915 and xe. For now, just fix the leak:\n\nunreferenced object 0xffff8881a0300008 (size 192):\n comm "modprobe", pid 4354, jiffies 4295647021\n hex dump (first 32 bytes):\n 00 00 87 27 81 88 ff ff 18 80 9b 00 00 c9 ff ff ...'............\n 18 81 9b 00 00 c9 ff ff 00 00 00 00 00 00 00 00 ................\n backtrace (crc 99260e31):\n [<ffffffff823ce65b>] kmemleak_alloc+0x4b/0x80\n [<ffffffff81493be2>] kmalloc_trace_noprof+0x312/0x3d0\n [<ffffffffa1345679>] intel_opregion_setup+0x89/0x700 [xe]\n [<ffffffffa125bfaf>] xe_display_init_noirq+0x2f/0x90 [xe]\n [<ffffffffa1199ec3>] xe_device_probe+0x7a3/0xbf0 [xe]\n [<ffffffffa11f3713>] xe_pci_probe+0x333/0x5b0 [xe]\n [<ffffffff81af6be8>] local_pci_probe+0x48/0xb0\n [<ffffffff81af8778>] pci_device_probe+0xc8/0x280\n [<ffffffff81d09048>] really_probe+0xf8/0x390\n [<ffffffff81d0937a>] __driver_probe_device+0x8a/0x170\n [<ffffffff81d09503>] driver_probe_device+0x23/0xb0\n [<ffffffff81d097b7>] __driver_attach+0xc7/0x190\n [<ffffffff81d0628d>] bus_for_each_dev+0x7d/0xd0\n [<ffffffff81d0851e>] driver_attach+0x1e/0x30\n [<ffffffff81d07ac7>] bus_add_driver+0x117/0x250\n\n(cherry picked from commit 6f4e43a2f771b737d991142ec4f6d4b7ff31fbb4)

In the Linux kernel, the following vulnerability has been resolved:\n\npower: supply: rt5033: Bring back i2c_set_clientdata\n\nCommit 3a93da231c12 ("power: supply: rt5033: Use devm_power_supply_register() helper")\nreworked the driver to use devm. While at it, the i2c_set_clientdata\nwas dropped along with the remove callback. Unfortunately other parts\nof the driver also rely on i2c clientdata so this causes kernel oops.\n\nBring the call back to fix the driver.

In the Linux kernel, the following vulnerability has been resolved:\n\ns390/fpu: Re-add exception handling in load_fpu_state()\n\nWith the recent rewrite of the fpu code exception handling for the\nlfpc instruction within load_fpu_state() was erroneously removed.\n\nAdd it again to prevent that loading invalid floating point register\nvalues cause an unhandled specification exception.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: lpfc: Revise lpfc_prep_embed_io routine with proper endian macro usages\n\nOn big endian architectures, it is possible to run into a memory out of\nbounds pointer dereference when FCP targets are zoned.\n\nIn lpfc_prep_embed_io, the memcpy(ptr, fcp_cmnd, sgl->sge_len) is\nreferencing a little endian formatted sgl->sge_len value. So, the memcpy\ncan cause big endian systems to crash.\n\nRedefine the *sgl ptr as a struct sli4_sge_le to make it clear that we are\nreferring to a little endian formatted data structure. And, update the\nroutine with proper le32_to_cpu macro usages.

The contextual menu for links could provide an opportunity for cross-site scripting attacks This vulnerability affects Firefox for iOS < 129.

Long pressing on a download link could potentially provide a means for cross-site scripting This vulnerability affects Firefox for iOS < 129.

Long pressing on a download link could potentially allow Javascript commands to be executed within the browser This vulnerability affects Firefox for iOS < 129.

In the Elliptic package 6.5.6 for Node.js, EDDSA signature malleability occurs because there is a missing signature length check, and thus zero-valued bytes can be removed or appended.

In the Linux kernel, the following vulnerability has been resolved:\n\nlandlock: Don't lose track of restrictions on cred_transfer\n\nWhen a process' cred struct is replaced, this _almost_ always invokes\nthe cred_prepare LSM hook; but in one special case (when\nKEYCTL_SESSION_TO_PARENT updates the parent's credentials), the\ncred_transfer LSM hook is used instead. Landlock only implements the\ncred_prepare hook, not cred_transfer, so KEYCTL_SESSION_TO_PARENT causes\nall information on Landlock restrictions to be lost.\n\nThis basically means that a process with the ability to use the fork()\nand keyctl() syscalls can get rid of all Landlock restrictions on\nitself.\n\nFix it by adding a cred_transfer hook that does the same thing as the\nexisting cred_prepare hook. (Implemented by having hook_cred_prepare()\ncall hook_cred_transfer() so that the two functions are less likely to\naccidentally diverge in the future.)

In the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86: x86-android-tablets: Unregister devices in reverse order\n\nNot all subsystems support a device getting removed while there are\nstill consumers of the device with a reference to the device.\n\nOne example of this is the regulator subsystem. If a regulator gets\nunregistered while there are still drivers holding a reference\na WARN() at drivers/regulator/core.c:5829 triggers, e.g.:\n\n WARNING: CPU: 1 PID: 1587 at drivers/regulator/core.c:5829 regulator_unregister\n Hardware name: Intel Corp. VALLEYVIEW C0 PLATFORM/BYT-T FFD8, BIOS BLADE_21.X64.0005.R00.1504101516 FFD8_X64_R_2015_04_10_1516 04/10/2015\n RIP: 0010:regulator_unregister\n Call Trace:\n <TASK>\n regulator_unregister\n devres_release_group\n i2c_device_remove\n device_release_driver_internal\n bus_remove_device\n device_del\n device_unregister\n x86_android_tablet_remove\n\nOn the Lenovo Yoga Tablet 2 series the bq24190 charger chip also provides\na 5V boost converter output for powering USB devices connected to the micro\nUSB port, the bq24190-charger driver exports this as a Vbus regulator.\n\nOn the 830 (8") and 1050 ("10") models this regulator is controlled by\na platform_device and x86_android_tablet_remove() removes platform_device-s\nbefore i2c_clients so the consumer gets removed first.\n\nBut on the 1380 (13") model there is a lc824206xa micro-USB switch\nconnected over I2C and the extcon driver for that controls the regulator.\nThe bq24190 i2c-client *must* be registered first, because that creates\nthe regulator with the lc824206xa listed as its consumer. If the regulator\nhas not been registered yet the lc824206xa driver will end up getting\na dummy regulator.\n\nSince in this case both the regulator provider and consumer are I2C\ndevices, the only way to ensure that the consumer is unregistered first\nis to unregister the I2C devices in reverse order of in which they were\ncreated.\n\nFor consistency and to avoid similar problems in the future change\nx86_android_tablet_remove() to unregister all device types in reverse\norder.

This issue was addressed with improved checks. This issue is fixed in iOS 16.7.9 and iPadOS 16.7.9, Safari 17.6, iOS 17.6 and iPadOS 17.6, watchOS 10.6, tvOS 17.6, visionOS 1.3, macOS Sonoma 14.6. Processing maliciously crafted web content may lead to a cross site scripting attack.

The TCP protocol in RFC 9293 has a timing side channel that makes it easier for remote attackers to infer the content of one TCP connection from a client system (to any server), when that client system is concurrently obtaining TCP data at a slow rate from an attacker-controlled server, aka the "SnailLoad" issue. For example, the attack can begin by measuring RTTs via the TCP segments whose role is to provide an ACK control bit and an Acknowledgment Number.

In the Linux kernel, the following vulnerability has been resolved:\n\nfuse: clear FR_SENT when re-adding requests into pending list\n\nThe following warning was reported by lee bruce:\n\n ------------[ cut here ]------------\n WARNING: CPU: 0 PID: 8264 at fs/fuse/dev.c:300\n fuse_request_end+0x685/0x7e0 fs/fuse/dev.c:300\n Modules linked in:\n CPU: 0 PID: 8264 Comm: ab2 Not tainted 6.9.0-rc7\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)\n RIP: 0010:fuse_request_end+0x685/0x7e0 fs/fuse/dev.c:300\n ......\n Call Trace:\n <TASK>\n fuse_dev_do_read.constprop.0+0xd36/0x1dd0 fs/fuse/dev.c:1334\n fuse_dev_read+0x166/0x200 fs/fuse/dev.c:1367\n call_read_iter include/linux/fs.h:2104 [inline]\n new_sync_read fs/read_write.c:395 [inline]\n vfs_read+0x85b/0xba0 fs/read_write.c:476\n ksys_read+0x12f/0x260 fs/read_write.c:619\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xce/0x260 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n ......\n </TASK>\n\nThe warning is due to the FUSE_NOTIFY_RESEND notify sent by the write()\nsyscall in the reproducer program and it happens as follows:\n\n(1) calls fuse_dev_read() to read the INIT request\nThe read succeeds. During the read, bit FR_SENT will be set on the\nrequest.\n(2) calls fuse_dev_write() to send an USE_NOTIFY_RESEND notify\nThe resend notify will resend all processing requests, so the INIT\nrequest is moved from processing list to pending list again.\n(3) calls fuse_dev_read() with an invalid output address\nfuse_dev_read() will try to copy the same INIT request to the output\naddress, but it will fail due to the invalid address, so the INIT\nrequest is ended and triggers the warning in fuse_request_end().\n\nFix it by clearing FR_SENT when re-adding requests into pending list.

The MarkStack assignment operator, part of the JavaScript engine, could access uninitialized memory if it were used in a self-assignment. This vulnerability affects Firefox < 125.

When browsing private tabs, some data related to location history or webpage thumbnails could be persisted incorrectly within the sandboxed app bundle after app termination This vulnerability affects Firefox for iOS < 127.

A flaw was found in AMD processors. This flaw allows an attacker with system administration privileges to exploit an issue in the signature verification in the AMD CPU ROM microcode patch loader, allowing the load of malicious microcode. This issue could impact the integrity of x86 instruction execution, confidentiality, and data integrity in x86 CPU-privileged context and compromise the SMM execution environment.

A flaw was found in QEMU. An assertion failure was present in the update_sctp_checksum() function in hw/net/net_tx_pkt.c when trying to calculate the checksum of a short-sized fragmented packet. This flaw allows a malicious guest to crash QEMU and cause a denial of service condition.

Prior to versions 7.1.0, 6.1.2, and 5.3.4, the webpack-dev-middleware development middleware for devpack does not validate the supplied URL address sufficiently before returning the local file. It is possible to access any file on the developer's machine. The middleware can either work with the physical filesystem when reading the files or it can use a virtualized in-memory `memfs` filesystem. If `writeToDisk` configuration option is set to `true`, the physical filesystem is used. The `getFilenameFromUrl` method is used to parse URL and build the local file path. The public path prefix is stripped from the URL, and the `unsecaped` path suffix is appended to the `outputPath`. As the URL is not unescaped and normalized automatically before calling the midlleware, it is possible to use `%2e` and `%2f` sequences to perform path traversal attack.\nDevelopers using `webpack-dev-server` or `webpack-dev-middleware` are affected by the issue. When the project is started, an attacker might access any file on the developer's machine and exfiltrate the content. If the development server is listening on a public IP address (or `0.0.0.0`), an attacker on the local network can access the local files without any interaction from the victim (direct connection to the port). If the server allows access from third-party domains, an attacker can send a malicious link to the victim. When visited, the client side script can connect to the local server and exfiltrate the local files. Starting with fixed versions 7.1.0, 6.1.2, and 5.3.4, the URL is unescaped and normalized before any further processing.

Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution for some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.

follow-redirects is an open source, drop-in replacement for Node's `http` and `https` modules that automatically follows redirects. In affected versions follow-redirects only clears authorization header during cross-domain redirect, but keep the proxy-authentication header which contains credentials too. This vulnerability may lead to credentials leak, but has been addressed in version 1.15.6. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Buffer Overflow vulnerability in open source FreeImage v.3.19.0 [r1909] allows a local attacker to execute arbitrary code via the readLine() function when reading images in XPM format.

Buffer Overflow vulnerability in open source FreeImage v.3.19.0 [r1909] allows a local attacker to execute arbitrary code via the rgbe_RGBEToFloat() function when reading images in HDR format.

Buffer Overflow vulnerability in open source FreeImage v.3.19.0 [r1909] allows a local attacker to execute arbitrary code via the _assignPixel<>() function when reading images in TARGA format.

Buffer Overflow vulnerability in open source FreeImage v.3.19.0 [r1909] allows a local attacker to execute arbitrary code via the ReadData() function when reading images in RAS format.

Buffer Overflow vulnerability in open source FreeImage v.3.19.0 [r1909] allows a local attacker to execute arbitrary code via the Load() function when reading images in RAS format.

Buffer Overflow vulnerability in open source FreeImage v.3.19.0 [r1909] allows a local attacker to execute arbitrary code via the Imf_2_2::Xdr::read() function when reading images in EXR format.

Buffer Overflow vulnerability in open source FreeImage v.3.19.0 [r1909] allows a local attacker to execute arbitrary code via the AssignPixel() function when reading images in TIFF format.

In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: fix potential "struct net" leak in inet6_rtm_getaddr()\n\nIt seems that if userspace provides a correct IFA_TARGET_NETNSID value\nbut no IFA_ADDRESS and IFA_LOCAL attributes, inet6_rtm_getaddr()\nreturns -EINVAL with an elevated "struct net" refcount.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm: nv04: Fix out of bounds access\n\nWhen Output Resource (dcb->or) value is assigned in\nfabricate_dcb_output(), there may be out of bounds access to\ndac_users array in case dcb->or is zero because ffs(dcb->or) is\nused as index there.\nThe 'or' argument of fabricate_dcb_output() must be interpreted as a\nnumber of bit to set, not value.\n\nUtilize macros from 'enum nouveau_or' in calls instead of hardcoding.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: validate the parameters of bo mapping operations more clearly\n\nVerify the parameters of\namdgpu_vm_bo_(map/replace_map/clearing_mappings) in one common place.

In the Linux kernel, the following vulnerability has been resolved:\n\ntracing/trigger: Fix to return error if failed to alloc snapshot\n\nFix register_snapshot_trigger() to return error code if it failed to\nallocate a snapshot instead of 0 (success). Unless that, it will register\nsnapshot trigger without an error.

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_security\n\nDuring our fuzz testing of the connection and disconnection process at the\nRFCOMM layer, we discovered this bug. By comparing the packets from a\nnormal connection and disconnection process with the testcase that\ntriggered a KASAN report. We analyzed the cause of this bug as follows:\n\n1. In the packets captured during a normal connection, the host sends a\n`Read Encryption Key Size` type of `HCI_CMD` packet\n(Command Opcode: 0x1408) to the controller to inquire the length of\nencryption key.After receiving this packet, the controller immediately\nreplies with a Command Completepacket (Event Code: 0x0e) to return the\nEncryption Key Size.\n\n2. In our fuzz test case, the timing of the controller's response to this\npacket was delayed to an unexpected point: after the RFCOMM and L2CAP\nlayers had disconnected but before the HCI layer had disconnected.\n\n3. After receiving the Encryption Key Size Response at the time described\nin point 2, the host still called the rfcomm_check_security function.\nHowever, by this time `struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;`\nhad already been released, and when the function executed\n`return hci_conn_security(conn->hcon, d->sec_level, auth_type, d->out);`,\nspecifically when accessing `conn->hcon`, a null-ptr-deref error occurred.\n\nTo fix this bug, check if `sk->sk_state` is BT_CLOSED before calling\nrfcomm_recv_frame in rfcomm_process_rx.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_set_pipapo: release elements in clone only from destroy path\n\nClone already always provides a current view of the lookup table, use it\nto destroy the set, otherwise it is possible to destroy elements twice.\n\nThis fix requires:\n\n 212ed75dc5fb ("netfilter: nf_tables: integrate pipapo into commit protocol")\n\nwhich came after:\n\n 9827a0e6e23b ("netfilter: nft_set_pipapo: release elements in clone from abort path").

In the Linux kernel, the following vulnerability has been resolved:\n\nspi: cadence-qspi: fix pointer reference in runtime PM hooks\n\ndev_get_drvdata() gets used to acquire the pointer to cqspi and the SPI\ncontroller. Neither embed the other; this lead to memory corruption.\n\nOn a given platform (Mobileye EyeQ5) the memory corruption is hidden\ninside cqspi->f_pdata. Also, this uninitialised memory is used as a\nmutex (ctlr->bus_lock_mutex) by spi_controller_suspend().

In the Linux kernel, the following vulnerability has been resolved:\n\nspi: cadence-qspi: remove system-wide suspend helper calls from runtime PM hooks\n\nThe ->runtime_suspend() and ->runtime_resume() callbacks are not\nexpected to call spi_controller_suspend() and spi_controller_resume().\nRemove calls to those in the cadence-qspi driver.\n\nThose helpers have two roles currently:\n - They stop/start the queue, including dealing with the kworker.\n - They toggle the SPI controller SPI_CONTROLLER_SUSPENDED flag. It\n requires acquiring ctlr->bus_lock_mutex.\n\nStep one is irrelevant because cadence-qspi is not queued. Step two\nhowever has two implications:\n - A deadlock occurs, because ->runtime_resume() is called in a context\n where the lock is already taken (in the ->exec_op() callback, where\n the usage count is incremented).\n - It would disallow all operations once the device is auto-suspended.\n\nHere is a brief call tree highlighting the mutex deadlock:\n\nspi_mem_exec_op()\n ...\n spi_mem_access_start()\n mutex_lock(&ctlr->bus_lock_mutex)\n\n cqspi_exec_mem_op()\n pm_runtime_resume_and_get()\n cqspi_resume()\n spi_controller_resume()\n mutex_lock(&ctlr->bus_lock_mutex)\n ...\n\n spi_mem_access_end()\n mutex_unlock(&ctlr->bus_lock_mutex)\n ...

In the Linux kernel, the following vulnerability has been resolved:\n\ntls: fix use-after-free on failed backlog decryption\n\nWhen the decrypt request goes to the backlog and crypto_aead_decrypt\nreturns -EBUSY, tls_do_decryption will wait until all async\ndecryptions have completed. If one of them fails, tls_do_decryption\nwill return -EBADMSG and tls_decrypt_sg jumps to the error path,\nreleasing all the pages. But the pages have been passed to the async\ncallback, and have already been released by tls_decrypt_done.\n\nThe only true async case is when crypto_aead_decrypt returns\n -EINPROGRESS. With -EBUSY, we already waited so we can tell\ntls_sw_recvmsg that the data is available for immediate copy, but we\nneed to notify tls_decrypt_sg (via the new ->async_done flag) that the\nmemory has already been released.

In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: qcom: Fix uninitialized pointer dmactl\n\nIn the case where __lpass_get_dmactl_handle is called and the driver\nid dai_id is invalid the pointer dmactl is not being assigned a value,\nand dmactl contains a garbage value since it has not been initialized\nand so the null check may not work. Fix this to initialize dmactl to\nNULL. One could argue that modern compilers will set this to zero, but\nit is useful to keep this initialized as per the same way in functions\n__lpass_platform_codec_intf_init and lpass_cdc_dma_daiops_hw_params.\n\nCleans up clang scan build warning:\nsound/soc/qcom/lpass-cdc-dma.c:275:7: warning: Branch condition\nevaluates to a garbage value [core.uninitialized.Branch]

In the Linux kernel, the following vulnerability has been resolved:\n\nfbcon: always restore the old font data in fbcon_do_set_font()\n\nCommit a5a923038d70 (fbdev: fbcon: Properly revert changes when\nvc_resize() failed) started restoring old font data upon failure (of\nvc_resize()). But it performs so only for user fonts. It means that the\n"system"/internal fonts are not restored at all. So in result, the very\nfirst call to fbcon_do_set_font() performs no restore at all upon\nfailing vc_resize().\n\nThis can be reproduced by Syzkaller to crash the system on the next\ninvocation of font_get(). It's rather hard to hit the allocation failure\nin vc_resize() on the first font_set(), but not impossible. Esp. if\nfault injection is used to aid the execution/failure. It was\ndemonstrated by Sirius:\n BUG: unable to handle page fault for address: fffffffffffffff8\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD cb7b067 P4D cb7b067 PUD cb7d067 PMD 0\n Oops: 0000 [#1] PREEMPT SMP KASAN\n CPU: 1 PID: 8007 Comm: poc Not tainted 6.7.0-g9d1694dc91ce #20\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n RIP: 0010:fbcon_get_font+0x229/0x800 drivers/video/fbdev/core/fbcon.c:2286\n Call Trace:\n \n con_font_get drivers/tty/vt/vt.c:4558 [inline]\n con_font_op+0x1fc/0xf20 drivers/tty/vt/vt.c:4673\n vt_k_ioctl drivers/tty/vt/vt_ioctl.c:474 [inline]\n vt_ioctl+0x632/0x2ec0 drivers/tty/vt/vt_ioctl.c:752\n tty_ioctl+0x6f8/0x1570 drivers/tty/tty_io.c:2803\n vfs_ioctl fs/ioctl.c:51 [inline]\n ...\n\nSo restore the font data in any case, not only for user fonts. Note the\nlater 'if' is now protected by 'old_userfont' and not 'old_data' as the\nlatter is always set now. (And it is supposed to be non-NULL. Otherwise\nwe would see the bug above again.)

In the Linux kernel, the following vulnerability has been resolved:\n\ndrivers: perf: ctr_get_width function for legacy is not defined\n\nWith parameters CONFIG_RISCV_PMU_LEGACY=y and CONFIG_RISCV_PMU_SBI=n\nlinux kernel crashes when you try perf record:\n\n$ perf record ls\n[ 46.749286] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n[ 46.750199] Oops [#1]\n[ 46.750342] Modules linked in:\n[ 46.750608] CPU: 0 PID: 107 Comm: perf-exec Not tainted 6.6.0 #2\n[ 46.750906] Hardware name: riscv-virtio,qemu (DT)\n[ 46.751184] epc : 0x0\n[ 46.751430] ra : arch_perf_update_userpage+0x54/0x13e\n[ 46.751680] epc : 0000000000000000 ra : ffffffff8072ee52 sp : ff2000000022b8f0\n[ 46.751958] gp : ffffffff81505988 tp : ff6000000290d400 t0 : ff2000000022b9c0\n[ 46.752229] t1 : 0000000000000001 t2 : 0000000000000003 s0 : ff2000000022b930\n[ 46.752451] s1 : ff600000028fb000 a0 : 0000000000000000 a1 : ff600000028fb000\n[ 46.752673] a2 : 0000000ae2751268 a3 : 00000000004fb708 a4 : 0000000000000004\n[ 46.752895] a5 : 0000000000000000 a6 : 000000000017ffe3 a7 : 00000000000000d2\n[ 46.753117] s2 : ff600000028fb000 s3 : 0000000ae2751268 s4 : 0000000000000000\n[ 46.753338] s5 : ffffffff8153e290 s6 : ff600000863b9000 s7 : ff60000002961078\n[ 46.753562] s8 : ff60000002961048 s9 : ff60000002961058 s10: 0000000000000001\n[ 46.753783] s11: 0000000000000018 t3 : ffffffffffffffff t4 : ffffffffffffffff\n[ 46.754005] t5 : ff6000000292270c t6 : ff2000000022bb30\n[ 46.754179] status: 0000000200000100 badaddr: 0000000000000000 cause: 000000000000000c\n[ 46.754653] Code: Unable to access instruction at 0xffffffffffffffec.\n[ 46.754939] ---[ end trace 0000000000000000 ]---\n[ 46.755131] note: perf-exec[107] exited with irqs disabled\n[ 46.755546] note: perf-exec[107] exited with preempt_count 4\n\nThis happens because in the legacy case the ctr_get_width function was not\ndefined, but it is used in arch_perf_update_userpage.\n\nAlso remove extra check in riscv_pmu_ctr_get_width_mask

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix race between ordered extent completion and fiemap\n\nFor fiemap we recently stopped locking the target extent range for the\nwhole duration of the fiemap call, in order to avoid a deadlock in a\nscenario where the fiemap buffer happens to be a memory mapped range of\nthe same file. This use case is very unlikely to be useful in practice but\nit may be triggered by fuzz testing (syzbot, etc).\n\nHowever by not locking the target extent range for the whole duration of\nthe fiemap call we can race with an ordered extent. This happens like\nthis:\n\n1) The fiemap task finishes processing a file extent item that covers\n the file range [512K, 1M[, and that file extent item is the last item\n in the leaf currently being processed;\n\n2) And ordered extent for the file range [768K, 2M[, in COW mode,\n completes (btrfs_finish_one_ordered()) and the file extent item\n covering the range [512K, 1M[ is trimmed to cover the range\n [512K, 768K[ and then a new file extent item for the range [768K, 2M[\n is inserted in the inode's subvolume tree;\n\n3) The fiemap task calls fiemap_next_leaf_item(), which then calls\n btrfs_next_leaf() to find the next leaf / item. This finds that the\n the next key following the one we previously processed (its type is\n BTRFS_EXTENT_DATA_KEY and its offset is 512K), is the key corresponding\n to the new file extent item inserted by the ordered extent, which has\n a type of BTRFS_EXTENT_DATA_KEY and an offset of 768K;\n\n4) Later the fiemap code ends up at emit_fiemap_extent() and triggers\n the warning:\n\n if (cache->offset + cache->len > offset) \{\n WARN_ON(1);\n return -EINVAL;\n \}\n\n Since we get 1M > 768K, because the previously emitted entry for the\n old extent covering the file range [512K, 1M[ ends at an offset that\n is greater than the new extent's start offset (768K). This makes fiemap\n fail with -EINVAL besides triggering the warning that produces a stack\n trace like the following:\n\n [1621.677651] ------------[ cut here ]------------\n [1621.677656] WARNING: CPU: 1 PID: 204366 at fs/btrfs/extent_io.c:2492 emit_fiemap_extent+0x84/0x90 [btrfs]\n [1621.677899] Modules linked in: btrfs blake2b_generic (...)\n [1621.677951] CPU: 1 PID: 204366 Comm: pool Not tainted 6.8.0-rc5-btrfs-next-151+ #1\n [1621.677954] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014\n [1621.677956] RIP: 0010:emit_fiemap_extent+0x84/0x90 [btrfs]\n [1621.678033] Code: 2b 4c 89 63 (...)\n [1621.678035] RSP: 0018:ffffab16089ffd20 EFLAGS: 00010206\n [1621.678037] RAX: 00000000004fa000 RBX: ffffab16089ffe08 RCX: 0000000000009000\n [1621.678039] RDX: 00000000004f9000 RSI: 00000000004f1000 RDI: ffffab16089ffe90\n [1621.678040] RBP: 00000000004f9000 R08: 0000000000001000 R09: 0000000000000000\n [1621.678041] R10: 0000000000000000 R11: 0000000000001000 R12: 0000000041d78000\n [1621.678043] R13: 0000000000001000 R14: 0000000000000000 R15: ffff9434f0b17850\n [1621.678044] FS: 00007fa6e20006c0(0000) GS:ffff943bdfa40000(0000) knlGS:0000000000000000\n [1621.678046] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n [1621.678048] CR2: 00007fa6b0801000 CR3: 000000012d404002 CR4: 0000000000370ef0\n [1621.678053] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n [1621.678055] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n [1621.678056] Call Trace:\n [1621.678074] \n [1621.678076] ? __warn+0x80/0x130\n [1621.678082] ? emit_fiemap_extent+0x84/0x90 [btrfs]\n [1621.678159] ? report_bug+0x1f4/0x200\n [1621.678164] ? handle_bug+0x42/0x70\n [1621.678167] ? exc_invalid_op+0x14/0x70\n [1621.678170] ? asm_exc_invalid_op+0x16/0x20\n [1621.678178] ? emit_fiemap_extent+0x84/0x90 [btrfs]\n [1621.678253] extent_fiemap+0x766\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\ngtp: fix use-after-free and null-ptr-deref in gtp_newlink()\n\nThe gtp_link_ops operations structure for the subsystem must be\nregistered after registering the gtp_net_ops pernet operations structure.\n\nSyzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug:\n\n[ 1010.702740] gtp: GTP module unloaded\n[ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI\n[ 1010.715888] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\n[ 1010.715895] CPU: 1 PID: 128616 Comm: a.out Not tainted 6.8.0-rc6-std-def-alt1 #1\n[ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014\n[ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp]\n[ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00\n[ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203\n[ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000000\n[ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282\n[ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000\n[ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80\n[ 1010.715947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000400\n[ 1010.715953] FS: 00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000\n[ 1010.715958] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0\n[ 1010.715968] PKRU: 55555554\n[ 1010.715972] Call Trace:\n[ 1010.715985] ? \_\_die_body.cold+0x1a/0x1f\n[ 1010.715995] ? die_addr+0x43/0x70\n[ 1010.716002] ? exc_general_protection+0x199/0x2f0\n[ 1010.716016] ? asm_exc_general_protection+0x1e/0x30\n[ 1010.716026] ? gtp_newlink+0x4d7/0x9c0 [gtp]\n[ 1010.716034] ? gtp_net_exit+0x150/0x150 [gtp]\n[ 1010.716042] \_\_rtnl_newlink+0x1063/0x1700\n[ 1010.716051] ? rtnl_setlink+0x3c0/0x3c0\n[ 1010.716063] ? is_bpf_text_address+0xc0/0x1f0\n[ 1010.716070] ? kernel_text_address.part.0+0xbb/0xd0\n[ 1010.716076] ? \_\_kernel_text_address+0x56/0xa0\n[ 1010.716084] ? unwind_get_return_address+0x5a/0xa0\n[ 1010.716091] ? create_prof_cpu_mask+0x30/0x30\n[ 1010.716098] ? arch_stack_walk+0x9e/0xf0\n[ 1010.716106] ? stack_trace_save+0x91/0xd0\n[ 1010.716113] ? stack_trace_consume_entry+0x170/0x170\n[ 1010.716121] ? \__lock_acquire+0x15c5/0x5380\n[ 1010.716139] ? mark_held_locks+0x9e/0xe0\n[ 1010.716148] ? kmem_cache_alloc_trace+0x35f/0x3c0\n[ 1010.716155] ? \__rtnl_newlink+0x1700/0x1700\n[ 1010.716160] rtnl_newlink+0x69/0xa0\n[ 1010.716166] rtnetlink_rcv_msg+0x43b/0xc50\n[ 1010.716172] ? rtnl_fdb_dump+0x9f0/0x9f0\n[ 1010.716179] ? lock_acquire+0x1fe/0x560\n[ 1010.716188] ? netlink_deliver_tap+0x12f/0xd50\n[ 1010.716196] netlink_rcv_skb+0x14d/0x440\n[ 1010.716202] ? rtnl_fdb_dump+0x9f0/0x9f0\n[ 1010.716208] ? netlink_ack+0xab0/0xab0\n[ 1010.716213] ? netlink_deliver_tap+0x202/0xd50\n[ 1010.716220] ? netlink_deliver_tap+0x218/0xd50\n[ 1010.716226] ? __virt_addr_valid+0x30b/0x590\n[ 1010.716233] netlink_unicast+0x54b/0x800\n[ 1010.716240] ? netlink_attachskb+0x870/0x870\n[ 1010.716248] ? __check_object_size+0x2de/0x3b0\n[ 1010.716254] netlink_sendmsg+0x938/0xe40\n[ 1010.716261] ? netlink_unicast+0x800/0x800\n[ 1010.716269] ? __import_iovec+0x292/0x510\n[ 1010.716276] ? netlink_unicast+0x800/0x800\n[ 1010.716284] __sock_sendmsg+0x159/0x190\n[ 1010.716290] ____sys_sendmsg+0x712/0x880\n[ 1010.716297] ? sock_write_iter+0x3d0/0x3d0\n[ 1010.716304] ? __ia32_sys_recvmmsg+0x270/0x270\n[ 1010.716309] ? lock_acquire+0x1fe/0x560\n[ 1010.716315] ? drain_array_locked+0x90/0x90\n[ 1010.716324] ___sys_sendmsg+0xf8/0x170\n[ 1010.716331] ? sendmsg_copy_msghdr+0x170/0x170\n[ 1010.716337] ? lockdep_init_map\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix double free of anonymous device after snapshot creation failure\n\nWhen creating a snapshot we may do a double free of an anonymous device\nin case there's an error committing the transaction. The second free may\nresult in freeing an anonymous device number that was allocated by some\nother subsystem in the kernel or another btrfs filesystem.\n\nThe steps that lead to this:\n\n1) At ioctl.c:create_snapshot() we allocate an anonymous device number\n and assign it to pending_snapshot->anon_dev;\n\n2) Then we call btrfs_commit_transaction() and end up at\n transaction.c:create_pending_snapshot();\n\n3) There we call btrfs_get_new_fs_root() and pass it the anonymous device\n number stored in pending_snapshot->anon_dev;\n\n4) btrfs_get_new_fs_root() frees that anonymous device number because\n btrfs_lookup_fs_root() returned a root - someone else did a lookup\n of the new root already, which could some task doing backref walking;\n\n5) After that some error happens in the transaction commit path, and at\n ioctl.c:create_snapshot() we jump to the 'fail' label, and after\n that we free again the same anonymous device number, which in the\n meanwhile may have been reallocated somewhere else, because\n pending_snapshot->anon_dev still has the same value as in step 1.\n\nRecently syzbot ran into this and reported the following trace:\n\n ------------[ cut here ]------------\n ida_free called for id=51 which is not allocated.\n WARNING: CPU: 1 PID: 31038 at lib/idr.c:525 ida_free+0x370/0x420 lib/idr.c:525\n Modules linked in:\n CPU: 1 PID: 31038 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-00410-gc02197fc9076 #0\n Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024\n RIP: 0010:ida_free+0x370/0x420 lib/idr.c:525\n Code: 10 42 80 3c 28 (...)\n RSP: 0018:ffffc90015a67300 EFLAGS: 00010246\n RAX: be5130472f5dd000 RBX: 0000000000000033 RCX: 0000000000040000\n RDX: ffffc90009a7a000 RSI: 000000000003ffff RDI: 0000000000040000\n RBP: ffffc90015a673f0 R08: ffffffff81577992 R09: 1ffff92002b4cdb4\n R10: dffffc0000000000 R11: fffff52002b4cdb5 R12: 0000000000000246\n R13: dffffc0000000000 R14: ffffffff8e256b80 R15: 0000000000000246\n FS: 00007fca3f4b46c0(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f167a17b978 CR3: 000000001ed26000 CR4: 0000000000350ef0\n Call Trace:\n \n btrfs_get_root_ref+0xa48/0xaf0 fs/btrfs/disk-io.c:1346\n create_pending_snapshot+0xff2/0x2bc0 fs/btrfs/transaction.c:1837\n create_pending_snapshots+0x195/0x1d0 fs/btrfs/transaction.c:1931\n btrfs_commit_transaction+0xf1c/0x3740 fs/btrfs/transaction.c:2404\n create_snapshot+0x507/0x880 fs/btrfs/ioctl.c:848\n btrfs_mksubvol+0x5d0/0x750 fs/btrfs/ioctl.c:998\n btrfs_mksnapshot+0xb5/0xf0 fs/btrfs/ioctl.c:1044\n __btrfs_ioctl_snap_create+0x387/0x4b0 fs/btrfs/ioctl.c:1306\n btrfs_ioctl_snap_create_v2+0x1ca/0x400 fs/btrfs/ioctl.c:1393\n btrfs_ioctl+0xa74/0xd40\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:871 [inline]\n __se_sys_ioctl+0xfe/0x170 fs/ioctl.c:857\n do_syscall_64+0xfb/0x240\n entry_SYSCALL_64_after_hwframe+0x6f/0x77\n RIP: 0033:0x7fca3e67dda9\n Code: 28 00 00 00 (...)\n RSP: 002b:00007fca3f4b40c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\n RAX: ffffffffffffffda RBX: 00007fca3e7abf80 RCX: 00007fca3e67dda9\n RDX: 00000000200005c0 RSI: 0000000050009417 RDI: 0000000000000003\n RBP: 00007fca3e6ca47a R08: 0000000000000000 R09: 0000000000000000\n R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\n R13: 000000000000000b R14: 00007fca3e7abf80 R15: 00007fff6bf95658\n \n\nWhere we get an explicit message where we attempt to free an anonymous\ndevice number that is not currently allocated. It happens in a different\ncode path from the example below, at btrfs_get_root_ref(), so this change\nmay not fix the case triggered by sy\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nspi: hisi-sfc-v3xx: Return IRQ_NONE if no interrupts were detected\n\nReturn IRQ_NONE from the interrupt handler when no interrupt was\ndetected. Because an empty interrupt will cause a null pointer error:\n\n Unable to handle kernel NULL pointer dereference at virtual\n address 0000000000000008\n Call trace:\n complete+0x54/0x100\n hisi_sfc_v3xx_isr+0x2c/0x40 [spi_hisi_sfc_v3xx]\n _\_handle_irq_event_percpu+0x64/0x1e0\n handle_irq_event+0x7c/0x1cc

In the Linux kernel, the following vulnerability has been resolved:\n\nIB/hfi1: Fix sdma.h tx->num_descs off-by-one error\n\nUnfortunately the commit `fd8958efe877` introduced another error\ncausing the `descs` array to overflow. This reults in further crashes\neasily reproducible by `sendmsg` system call.\n\n[ 1080.836473] general protection fault, probably for non-canonical address 0x400300015528b00a: 0000 [#1] PREEMPT SMP PTI\n[ 1080.869326] RIP: 0010:hfi1_ipoib_build_ib_tx_headers.constprop.0+0xe1/0x2b0 [hfi1]\n--\n[ 1080.974535] Call Trace:\n[ 1080.976990] \n[ 1081.021929] hfi1_ipoib_send_dma_common+0x7a/0x2e0 [hfi1]\n[ 1081.027364] hfi1_ipoib_send_dma_list+0x62/0x270 [hfi1]\n[ 1081.032633] hfi1_ipoib_send+0x112/0x300 [hfi1]\n[ 1081.042001] ipoib_start_xmit+0x2a9/0x2d0 [ib_ipoib]\n[ 1081.046978] dev_hard_start_xmit+0xc4/0x210\n--\n[ 1081.148347] _\_sys_sendmsg+0x59/0xa0\n\ncrash> ipoib_txreq 0xffff9cfeba229f00\nstruct ipoib_txreq {\n txreq = {\n list = {\n next = 0xffff9cfeba229f00,\n prev = 0xffff9cfeba229f00\n },\n descp = 0xffff9cfeba229f40,\n coalesce_buf = 0x0,\n wait = 0xffff9cfea4e69a48,\n complete = 0xffffffffc0fe0760 ,\n packet_len = 0x46d,\n tlen = 0x0,\n num_desc = 0x0,\n desc_limit = 0x6,\n next_descq_idx = 0x45c,\n coalesce_idx = 0x0,\n flags = 0x0,\n descs = \{\{\n qw = {0x8024000120dffb00, 0x4} # SDMA_DESC0_FIRST_DESC_FLAG (bit 63)\n \}, {\n qw = { 0x3800014231b108, 0x4}\n }, {\n qw = { 0x310000e4ee0fcf0, 0x8}\n }, {\n qw = { 0x3000012e9f8000, 0x8}\n }, {\n qw = { 0x59000dfb9d0000, 0x8}\n }, {\n qw = { 0x78000e02e40000, 0x8}\n }}\n \},\n sdma_hdr = 0x400300015528b000, <<< invalid pointer in the tx request structure\n sdma_status = 0x0, SDMA_DESC0_LAST_DESC_FLAG (bit 62)\n complete = 0x0,\n priv = 0x0,\n txq = 0xffff9cfea4e69880,\n skb = 0xffff9d099809f400\n}\n\nIf an SDMA send consists of exactly 6 descriptors and requires dword\npadding (in the 7th descriptor), the sdma_txreq descriptor array is not\nproperly expanded and the packet will overflow into the container\nstructure. This results in a panic when the send completion runs. The\nexact panic varies depending on what elements of the container structure\nget corrupted. The fix is to use the correct expression in\n_pad_sdma_tx_descs() to test the need to expand the descriptor array.\n\nWith this patch the crashes are no longer reproducible and the machine is\nstable.

In the Linux kernel, the following vulnerability has been resolved:\n\nl2tp: pass correct message length to ip6_append_data\n\nl2tp_ip6_sendmsg needs to avoid accounting for the transport header\ntwice when splicing more data into an already partially-occupied skbuff.\n\nTo manage this, we check whether the skbuff contains data using\nskb_queue_empty when deciding how much data to append using\nip6_append_data.\n\nHowever, the code which performed the calculation was incorrect:\n\n ulen = len + skb_queue_empty(&sk->sk_write_queue) ? transhdrlen : 0;\n\n...due to C operator precedence, this ends up setting ulen to\ntranshdrlen for messages with a non-zero length, which results in\ncorrupted packets on the wire.\n\nAdd parentheses to correct the calculation in line with the original\nintent.

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: fix memory double free when handle zero packet\n\n829 if (request->complete) {\n830 spin_unlock(&priv_dev->lock);\n831 usb_gadget_giveback_request(&priv_ep->endpoint,\n832 request);\n833 spin_lock(&priv_dev->lock);\n834 }\n835\n836 if (request->buf == priv_dev->zlp_buf)\n837 cdns3_gadget_ep_free_request(&priv_ep->endpoint, request);\n\nDriver append an additional zero packet request when queue a packet, which\nlength mod max packet size is 0. When transfer complete, run to line 831,\nusb_gadget_giveback_request() will free this requestion. 836 condition is\ntrue, so cdns3_gadget_ep_free_request() free this request again.\n\nLog:\n\n[ 1920.140696][ T150] BUG: KFENCE: use-after-free read in cdns3_gadget_giveback+0x134/0x2c0 [cdns3]\n[ 1920.140696][ T150]\n[ 1920.151837][ T150] Use-after-free read at 0x000000003d1cd10b (in kfence-#36):\n[ 1920.159082][ T150] cdns3_gadget_giveback+0x134/0x2c0 [cdns3]\n[ 1920.164988][ T150] cdns3_transfer_completed+0x438/0x5f8 [cdns3]\n\nAdd check at line 829, skip call usb_gadget_giveback_request() if it is\nadditional zero length packet request. Needn't call\nusb_gadget_giveback_request() because it is allocated in this driver.

In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/pseries/iommu: IOMMU table is not initialized for kdump over SR-IOV\n\nWhen kdump kernel tries to copy dump data over SR-IOV, LPAR panics due\nto NULL pointer exception:\n\n Kernel attempted to read user page (0) - exploit attempt? (uid: 0)\n BUG: Kernel NULL pointer dereference on read at 0x00000000\n Faulting instruction address: 0xc000000020847ad4\n Oops: Kernel access of bad area, sig: 11 [#1]\n LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries\n Modules linked in: mlx5_core(+) vmx_crypto pseries_wdt papr_scm libnvdimm mlxfw tls psample sunrpc fuse overlay squashfs loop\n CPU: 12 PID: 315 Comm: systemd-udevd Not tainted 6.4.0-Test102+ #12\n Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries\n NIP: c000000020847ad4 LR: c00000002083b2dc CTR: 00000000006cd18c\n REGS: c000000029162ca0 TRAP: 0300 Not tainted (6.4.0-Test102+)\n MSR: 800000000280b033 CR: 48288244 XER: 00000008\n CFAR: c00000002083b2d8 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 1\n ...\n NIP _find_next_zero_bit+0x24/0x110\n LR bitmap_find_next_zero_area_off+0x5c/0xe0\n Call Trace:\n dev_printk_emit+0x38/0x48 (unreliable)\n iommu_area_alloc+0xc4/0x180\n iommu_range_alloc+0x1e8/0x580\n iommu_alloc+0x60/0x130\n iommu_alloc_coherent+0x158/0x2b0\n dma_iommu_alloc_coherent+0x3c/0x50\n dma_alloc_attrs+0x170/0x1f0\n mlx5_cmd_init+0xc0/0x760 [mlx5_core]\n mlx5_function_setup+0xf0/0x510 [mlx5_core]\n mlx5_init_one+0x84/0x210 [mlx5_core]\n probe_one+0x118/0x2c0 [mlx5_core]\n local_pci_probe+0x68/0x110\n pci_call_probe+0x68/0x200\n pci_device_probe+0xbc/0x1a0\n really_probe+0x104/0x540\n __driver_probe_device+0xb4/0x230\n driver_probe_device+0x54/0x130\n __driver_attach+0x158/0x2b0\n bus_for_each_dev+0xa8/0x130\n driver_attach+0x34/0x50\n bus_add_driver+0x16c/0x300\n driver_register+0xa4/0x1b0\n __pci_register_driver+0x68/0x80\n mlx5_init+0xb8/0x100 [mlx5_core]\n do_one_initcall+0x60/0x300\n do_init_module+0x7c/0x2b0\n\nAt the time of LPAR dump, before kexec hands over control to kdump\nkernel, DDWs (Dynamic DMA Windows) are scanned and added to the FDT.\nFor the SR-IOV case, default DMA window "ibm,dma-window" is removed from\nthe FDT and DDW added, for the device.\n\nNow, kexec hands over control to the kdump kernel.\n\nWhen the kdump kernel initializes, PCI busses are scanned and IOMMU\ngroup/tables created, in pci_dma_bus_setup_pSeriesLP(). For the SR-IOV\ncase, there is no "ibm,dma-window". The original commit: b1fc44eaa9ba,\nfixes the path where memory is pre-mapped (direct mapped) to the DDW.\nWhen TCEs are direct mapped, there is no need to initialize IOMMU\ntables.\n\niommu_table_setparms_lpar() only considers "ibm,dma-window" property\nwhen initiallizing IOMMU table. In the scenario where TCEs are\ndynamically allocated for SR-IOV, newly created IOMMU table is not\ninitialized. Later, when the device driver tries to enter TCEs for the\nSR-IOV device, NULL pointer execption is thrown from iommu_area_alloc().\n\nThe fix is to initialize the IOMMU table with DDW property stored in the\nFDT. There are 2 points to remember:\n\n 1. For the dedicated adapter, kdump kernel would encounter both\n default and DDW in FDT. In this case, DDW property is used to\n initialize the IOMMU table.\n\n 2. A DDW could be direct or dynamic mapped. kdump kernel would\n initialize IOMMU table and mark the existing DDW as\n "dynamic". This works fine since, at the time of table\n initialization, iommu_table_clear() makes some space in the\n DDW, for some predefined number of TCEs which are needed for\n kdump to succeed.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: act_mirred: don't override retval if we already lost the skb\n\nIf we're redirecting the skb, and haven't called tcf_mirred_forward(),\nyet, we need to tell the core to drop the skb by setting the retcode\nto SHOT. If we have called tcf_mirred_forward(), however, the skb\nis out of our hands and returning SHOT will lead to UaF.\n\nMove the retval override to the error path which actually need it.

In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/pseries/iommu: DLPAR add doesn't completely initialize pci_controller\n\nWhen a PCI device is dynamically added, the kernel oopses with a NULL\npointer dereference:\n\n BUG: Kernel NULL pointer dereference on read at 0x00000030\n Faulting instruction address: 0xc0000000006bbe5c\n Oops: Kernel access of bad area, sig: 11 [#1]\n LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries\n Modules linked in: rpadlpar_io rpaphp rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs xsk_diag bonding nft_compat nf_tables nfnetlink rfkill binfmt_misc dm_multipath rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_umad ib_iser libiscsi scsi_transport_iscsi ib_ipoib rdma_cm iw_cm ib_cm mlx5_ib ib_uverbs ib_core pseries_rng drm drm_panel_orientation_quirks xfs libcrc32c mlx5_core mlxfw sd_mod t10_pi sg tls ibmvscsi ibmveth scsi_transport_srp vmx_crypto pseries_wdt psample dm_mirror dm_region_hash dm_log dm_mod fuse\n CPU: 17 PID: 2685 Comm: drmgr Not tainted 6.7.0-203405+ #66\n Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries\n NIP: c0000000006bbe5c LR: c000000000a13e68 CTR: c0000000000579f8\n REGS: c00000009924f240 TRAP: 0300 Not tainted (6.7.0-203405+)\n MSR: 8000000000009033 CR: 24002220 XER: 20040006\n CFAR: c000000000a13e64 DAR: 0000000000000030 DSISR: 40000000 IRQMASK: 0\n ...\n NIP sysfs_add_link_to_group+0x34/0x94\n LR iommu_device_link+0x5c/0x118\n Call Trace:\n iommu_init_device+0x26c/0x318 (unreliable)\n iommu_device_link+0x5c/0x118\n iommu_init_device+0xa8/0x318\n iommu_probe_device+0xc0/0x134\n iommu_bus_notifier+0x44/0x104\n notifier_call_chain+0xb8/0x19c\n blocking_notifier_call_chain+0x64/0x98\n bus_notify+0x50/0x7c\n device_add+0x640/0x918\n pci_device_add+0x23c/0x298\n of_create_pci_dev+0x400/0x884\n of_scan_pci_dev+0x124/0x1b0\n __of_scan_bus+0x78/0x18c\n pcibios_scan_phb+0x2a4/0x3b0\n init_phb_dynamic+0xb8/0x110\n dlpar_add_slot+0x170/0x3b8 [rpadlpar_io]\n add_slot_store.part.0+0xb4/0x130 [rpadlpar_io]\n kobj_attr_store+0x2c/0x48\n sysfs_kf_write+0x64/0x78\n kernfs_fop_write_iter+0x1b0/0x290\n vfs_write+0x350/0x4a0\n ksys_write+0x84/0x140\n system_call_exception+0x124/0x330\n system_call_vectored_common+0x15c/0x2ec\n\nCommit a940904443e4 ("powerpc/iommu: Add iommu_ops to report capabilities\nand allow blocking domains") broke DLPAR add of PCI devices.\n\nThe above added iommu_device structure to pci_controller. During\nsystem boot, PCI devices are discovered and this newly added iommu_device\nstructure is initialized by a call to iommu_device_register().\n\nDuring DLPAR add of a PCI device, a new pci_controller structure is\nallocated but there are no calls made to iommu_device_register()\ninterface.\n\nFix is to register the iommu device during DLPAR add as well.

In the Linux kernel, the following vulnerability has been resolved:\n\ndpll: fix possible deadlock during netlink dump operation\n\nRecently, I've been hitting following deadlock warning during dpll pin\ndump:\n\n[52804.637962] ======================================================\n[52804.638536] WARNING: possible circular locking dependency detected\n[52804.639111] 6.8.0-rc2jiri+ #1 Not tainted\n[52804.639529] ------------------------------------------------------\n[52804.640104] python3/2984 is trying to acquire lock:\n[52804.640581] ffff88810e642678 (nlk_cb_mutex-GENERIC){+.+.}-{3:3}, at: netlink_dump+0xb3/0x780\n[52804.641417]\n but task is already holding lock:\n[52804.642010] ffffffff83bde4c8 (dpll_lock){+.+.}-{3:3}, at: dpll_lock_dumpit+0x13/0x20\n[52804.642747]\n which lock already depends on the new lock.\n\n[52804.643551]\n the existing dependency chain (in reverse order) is:\n[52804.644259]\n -> #1 (dpll_lock){+.+.}-{3:3}:\n[52804.644836] lock_acquire+0x174/0x3e0\n[52804.645271] __mutex_lock+0x119/0x1150\n[52804.645723] dpll_lock_dumpit+0x13/0x20\n[52804.646169] genl_start+0x266/0x320\n[52804.646578] __netlink_dump_start+0x321/0x450\n[52804.647056] genl_family_rcv_msg_dumpit+0x155/0x1e0\n[52804.647575] genl_rcv_msg+0x1ed/0x3b0\n[52804.648001] netlink_rcv_skb+0xdc/0x210\n[52804.648440] genl_rcv+0x24/0x40\n[52804.648831] netlink_unicast+0x2f1/0x490\n[52804.649290] netlink_sendmsg+0x36d/0x660\n[52804.649742] __sock_sendmsg+0x73/0xc0\n[52804.650165] __sys_sendto+0x184/0x210\n[52804.650597] __x64_sys_sendto+0x72/0x80\n[52804.651045] do_syscall_64+0x6f/0x140\n[52804.651474] entry_SYSCALL_64_after_hwframe+0x46/0x4e\n[52804.652001]\n -> #0 (nlk_cb_mutex-GENERIC){+.+.}-{3:3}:\n[52804.652650] check_prev_add+0x1ae/0x1280\n[52804.653107] __lock_acquire+0x1ed3/0x29a0\n[52804.653559] lock_acquire+0x174/0x3e0\n[52804.653984] __mutex_lock+0x119/0x1150\n[52804.654423] netlink_dump+0xb3/0x780\n[52804.654845] __netlink_dump_start+0x389/0x450\n[52804.655321] genl_family_rcv_msg_dumpit+0x155/0x1e0\n[52804.655842] genl_rcv_msg+0x1ed/0x3b0\n[52804.656272] netlink_rcv_skb+0xdc/0x210\n[52804.656721] genl_rcv+0x24/0x40\n[52804.657119] netlink_unicast+0x2f1/0x490\n[52804.657570] netlink_sendmsg+0x36d/0x660\n[52804.658022] __sock_sendmsg+0x73/0xc0\n[52804.658450] __sys_sendto+0x184/0x210\n[52804.658877] __x64_sys_sendto+0x72/0x80\n[52804.659322] do_syscall_64+0x6f/0x140\n[52804.659752] entry_SYSCALL_64_after_hwframe+0x46/0x4e\n[52804.660281]\n other info that might help us debug this:\n\n[52804.661077] Possible unsafe locking scenario:\n\n[52804.661671] CPU0 CPU1\n[52804.662129] ---- ----\n[52804.662577] lock(dpll_lock);\n[52804.662924] lock(nlk_cb_mutex-GENERIC);\n[52804.663538] lock(dpll_lock);\n[52804.664073] lock(nlk_cb_mutex-GENERIC);\n[52804.664490]\n\nThe issue as follows: __netlink_dump_start() calls control->start(cb)\nwith nlk->cb_mutex held. In control->start(cb) the dpll_lock is taken.\nThen nlk->cb_mutex is released and taken again in netlink_dump(), while\ndpll_lock still being held. That leads to ABBA deadlock when another\nCPU races with the same operation.\n\nFix this by moving dpll_lock taking into dumpit() callback which ensures\ncorrect lock taking order.

In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: rt5645: Fix deadlock in rt5645_jack_detect_work()\n\nThere is a path in rt5645_jack_detect_work(), where rt5645->jd_mutex\nis left locked forever. That may lead to deadlock\nwhen rt5645_jack_detect_work() is called for the second time.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: core: Prevent null pointer dereference in update_port_device_state\n\nCurrently, the function update_port_device_state gets the usb_hub from\nudev->parent by calling usb_hub_to_struct_hub.\nHowever, in case the actconfig or the maxchild is 0, the usb_hub would\nbe NULL and upon further accessing to get port_dev would result in null\npointer dereference.\n\nFix this by introducing an if check after the usb_hub is populated.

In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: Fix circular locking dependency\n\nThe rule inside kvm enforces that the vcpu->mutex is taken *inside*\nkvm->lock. The rule is violated by the pkvm_create_hyp_vm() which acquires\nthe kvm->lock while already holding the vcpu->mutex lock from\nkvm_vcpu_ioctl(). Avoid the circular locking dependency altogether by\nprotecting the hyp vm handle with the config_lock, much like we already\ndo for other forms of VM-scoped data.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: detect stuck ECSA element in probe resp\n\nWe recently added some validation that we don't try to\nconnect to an AP that is currently in a channel switch\nprocess, since that might want the channel to be quiet\nor we might not be able to connect in time to hear the\nswitching in a beacon. This was in commit c09c4f31998b\n("wifi: mac80211: don't connect to an AP while it's in\na CSA process").\n\nHowever, we promptly got a report that this caused new\nconnection failures, and it turns out that the AP that\nwe now cannot connect to is permanently advertising an\nextended channel switch announcement, even with quiet.\nThe AP in question was an Asus RT-AC53, with firmware\n3.0.0.4.380_10760-g21a5898.\n\nAs a first step, attempt to detect that we're dealing\nwith such a situation, so mac80211 can use this later.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetdevsim: avoid potential loop in nsim_dev_trap_report_work()\n\nMany syzbot reports include the following trace [1]\n\nIf nsim_dev_trap_report_work() can not grab the mutex,\nit should rearm itself at least one jiffie later.\n\n[1]\nSending NMI from CPU 1 to CPUs 0:\nNMI backtrace for cpu 0\nCPU: 0 PID: 32383 Comm: kworker/0:2 Not tainted 6.8.0-rc2-syzkaller-00031-g861c0981648f #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023\nWorkqueue: events nsim_dev_trap_report_work\n RIP: 0010:bytes_is_nonzero mm/kasan/generic.c:89 [inline]\n RIP: 0010:memory_is_nonzero mm/kasan/generic.c:104 [inline]\n RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:129 [inline]\n RIP: 0010:memory_is_poisoned mm/kasan/generic.c:161 [inline]\n RIP: 0010:check_region_inline mm/kasan/generic.c:180 [inline]\n RIP: 0010:kasan_check_range+0x101/0x190 mm/kasan/generic.c:189\nCode: 07 49 39 d1 75 0a 45 3a 11 b8 01 00 00 00 7c 0b 44 89 c2 e8 21 ed ff ff 83 f0 01 5b 5d 41 5c c3 48 85 d2 74 4f 48 01 ea eb 09 <48> 83 c0 01 48 39 d0 74 41 80 38 00 74 f2 eb b6 41 bc 08 00 00 00\nRSP: 0018:ffffc90012dcf998 EFLAGS: 00000046\nRAX: fffffbfff258af1e RBX: fffffbfff258af1f RCX: ffffffff8168eda3\nRDX: fffffbfff258af1f RSI: 0000000000000004 RDI: ffffffff92c578f0\nRBP: fffffbfff258af1e R08: 0000000000000000 R09: fffffbfff258af1e\nR10: ffffffff92c578f3 R11: ffffffff8acbcbc0 R12: 0000000000000002\nR13: ffff88806db38400 R14: 1ffff920025b9f42 R15: ffffffff92c578e8\nFS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000c00994e078 CR3: 000000002c250000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \n \n \n instrument_atomic_read include/linux/instrumented.h:68 [inline]\n atomic_read include/linux/atomic/atomic-instrumented.h:32 [inline]\n queued_spin_is_locked include/asm-generic/qspinlock.h:57 [inline]\n debug_spin_unlock kernel/locking/spinlock_debug.c:101 [inline]\n do_raw_spin_unlock+0x53/0x230 kernel/locking/spinlock_debug.c:141\n __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:150 [inline]\n _raw_spin_unlock_irqrestore+0x22/0x70 kernel/locking/spinlock.c:194\n debug_object_activate+0x349/0x540 lib/debugobjects.c:726\n debug_work_activate kernel/workqueue.c:578 [inline]\n insert_work+0x30/0x230 kernel/workqueue.c:1650\n __queue_work+0x62e/0x11d0 kernel/workqueue.c:1802\n __queue_delayed_work+0x1bf/0x270 kernel/workqueue.c:1953\n queue_delayed_work_on+0x106/0x130 kernel/workqueue.c:1989\n queue_delayed_work include/linux/workqueue.h:563 [inline]\n schedule_delayed_work include/linux/workqueue.h:677 [inline]\n nsim_dev_trap_report_work+0x9c0/0xc80 drivers/net/netdevsim/dev.c:842\n process_one_work+0x886/0x15d0 kernel/workqueue.c:2633\n process_scheduled_works kernel/workqueue.c:2706 [inline]\n worker_thread+0x8b9/0x1290 kernel/workqueue.c:2787\n kthread+0x2c6/0x3a0 kernel/kthread.c:388\n ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242\n

In the Linux kernel, the following vulnerability has been resolved:\n\nx86/efistub: Use 1:1 file:memory mapping for PE/COFF .compat section\n\nThe .compat section is a dummy PE section that contains the address of\nthe 32-bit entrypoint of the 64-bit kernel image if it is bootable from\n32-bit firmware (i.e., CONFIG_EFI_MIXED=y)\n\nThis section is only 8 bytes in size and is only referenced from the\nloader, and so it is placed at the end of the memory view of the image,\nto avoid the need for padding it to 4k, which is required for sections\nappearing in the middle of the image.\n\nUnfortunately, this violates the PE/COFF spec, and even if most EFI\nloaders will work correctly (including the Tianocore reference\nimplementation), PE loaders do exist that reject such images, on the\nbasis that both the file and memory views of the file contents should be\ndescribed by the section headers in a monotonically increasing manner\nwithout leaving any gaps.\n\nSo reorganize the sections to avoid this issue. This results in a slight\npadding overhead (< 4k) which can be avoided if desired by disabling\nCONFIG_EFI_MIXED (which is only needed in rare cases these days)

In the Linux kernel, the following vulnerability has been resolved:\n\nrxrpc: Fix delayed ACKs to not set the reference serial number\n\nFix the construction of delayed ACKs to not set the reference serial number\nas they can't be used as an RTT reference.

In the Linux kernel, the following vulnerability has been resolved:\n\nbcachefs: grab s_umount only if snapshotting\n\nWhen I was testing mongodb over bcachefs with compression,\nthere is a lockdep warning when snapshotting mongodb data volume.\n\n$ cat test.sh\nprog=bcachefs\n\n$prog subvolume create /mnt/data\n$prog subvolume create /mnt/data/snapshots\n\nwhile true;do\n $prog subvolume snapshot /mnt/data /mnt/data/snapshots/$(date +%s)\n sleep 1s\ndone\n\n$ cat /etc/mongodb.conf\nsystemLog:\n destination: file\n logAppend: true\n path: /mnt/data/mongod.log\n\nstorage:\n dbPath: /mnt/data/\n\nlockdep reports:\n[ 3437.452330] ======================================================\n[ 3437.452750] WARNING: possible circular locking dependency detected\n[ 3437.453168] 6.7.0-rc7-custom+ #85 Tainted: G E\n[ 3437.453562] ------------------------------------------------------\n[ 3437.453981] bcachefs/35533 is trying to acquire lock:\n[ 3437.454325] ffffa0a02b2b1418 (sb_writers#10){.+.+}-{0:0}, at: filename_create+0x62/0x190\n[ 3437.454875]\n but task is already holding lock:\n[ 3437.455268] ffffa0a02b2b10e0 (&type->s_umount_key#48){.+.+}-{3:3}, at: bch2_fs_file_ioctl+0x232/0xc90 [bcachefs]\n[ 3437.456009]\n which lock already depends on the new lock.\n\n[ 3437.456553]\n the existing dependency chain (in reverse order) is:\n[ 3437.457054]\n -> #3 (&type->s_umount_key#48){.+.+}-{3:3}:\n[ 3437.457507] down_read+0x3e/0x170\n[ 3437.457772] bch2_fs_file_ioctl+0x232/0xc90 [bcachefs]\n[ 3437.458206] __x64_sys_ioctl+0x93/0xd0\n[ 3437.458498] do_syscall_64+0x42/0xf0\n[ 3437.458779] entry_SYSCALL_64_after_hwframe+0x6e/0x76\n[ 3437.459155]\n -> #2 (&c->snapshot_create_lock){++++}-{3:3}:\n[ 3437.459615] down_read+0x3e/0x170\n[ 3437.459878] bch2_truncate+0x82/0x110 [bcachefs]\n[ 3437.460276] bchfs_truncate+0x254/0x3c0 [bcachefs]\n[ 3437.460686] notify_change+0x1f1/0x4a0\n[ 3437.461283] do_truncate+0x7f/0xd0\n[ 3437.461555] path_openat+0xa57/0xce0\n[ 3437.461836] do_filp_open+0xb4/0x160\n[ 3437.462116] do_sys_openat2+0x91/0xc0\n[ 3437.462402] __x64_sys_openat+0x53/0xa0\n[ 3437.462701] do_syscall_64+0x42/0xf0\n[ 3437.462982] entry_SYSCALL_64_after_hwframe+0x6e/0x76\n[ 3437.463359]\n -> #1 (&sb->s_type->i_mutex_key#15){+.+.}-{3:3}:\n[ 3437.463843] down_write+0x3b/0xc0\n[ 3437.464223] bch2_write_iter+0x5b/0xcc0 [bcachefs]\n[ 3437.464493] vfs_write+0x21b/0x4c0\n[ 3437.464653] ksys_write+0x69/0xf0\n[ 3437.464839] do_syscall_64+0x42/0xf0\n[ 3437.465009] entry_SYSCALL_64_after_hwframe+0x6e/0x76\n[ 3437.465231]\n -> #0 (sb_writers#10){.+.+}-{0:0}:\n[ 3437.465471] __lock_acquire+0x1455/0x21b0\n[ 3437.465656] lock_acquire+0xc6/0x2b0\n[ 3437.465822] mnt_want_write+0x46/0x1a0\n[ 3437.465996] filename_create+0x62/0x190\n[ 3437.466175] user_path_create+0x2d/0x50\n[ 3437.466352] bch2_fs_file_ioctl+0x2ec/0xc90 [bcachefs]\n[ 3437.466617] __x64_sys_ioctl+0x93/0xd0\n[ 3437.466791] do_syscall_64+0x42/0xf0\n[ 3437.466957] entry_SYSCALL_64_after_hwframe+0x6e/0x76\n[ 3437.467180]\n other info that might help us debug this:\n\n[ 3437.469670] 2 locks held by bcachefs/35533:\n other info that might help us debug this:\n\n[ 3437.467507] Chain exists of:\n sb_writers#10 --> &c->snapshot_create_lock --> &type->s_umount_key#48\n\n[ 3437.467979] Possible unsafe locking scenario:\n\n[ 3437.468223] CPU0 CPU1\n[ 3437.468405] ---- ----\n[ 3437.468585] rlock(&type->s_umount_key#48);\n[ 3437.468758] lock(&c->snapshot_create_lock);\n[ 3437.469030] lock(&type->s_umount_key#48);\n[ 3437.469291] rlock(sb_writers#10);\n[ 3437.469434]\n *** DEADLOCK ***\n\n[ 3437.469\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nFix memory leak in posix_clock_open()\n\nIf the clk ops.open() function returns an error, we don't release the\npccontext we allocated for this clock.\n\nRe-organize the code slightly to make it all more obvious.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: pds_core: Fix possible double free in error handling path\n\nWhen auxiliary_device_add() returns error and then calls\nauxiliary_device_uninit(), Callback function pdsc_auxbus_dev_release\ncalls kfree(padev) to free memory. We shouldn't call kfree(padev)\nagain in the error handling path.\n\nFix this by cleaning up the redundant kfree() and putting\nthe error handling back to where the errors happened.

In the Linux kernel, the following vulnerability has been resolved:\n\nsr9800: Add check for usbnet_get_endpoints\n\nAdd check for usbnet_get_endpoints() and return the error if it fails\nin order to transfer the error.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath11k: rely on mac80211 debugfs handling for vif\n\nmac80211 started to delete debugfs entries in certain cases, causing a\nath11k to crash when it tried to delete the entries later. Fix this by\nrelying on mac80211 to delete the entries when appropriate and adding\nthem from the vif_add_debugfs handler.

In the Linux kernel, the following vulnerability has been resolved:\n\nllc: make llc_ui_sendmsg() more robust against bonding changes\n\nsyzbot was able to trick llc_ui_sendmsg(), allocating an skb with no\nheadroom, but subsequently trying to push 14 bytes of Ethernet header [1]\n\nLike some others, llc_ui_sendmsg() releases the socket lock before\ncalling sock_alloc_send_skb().\nThen it acquires it again, but does not redo all the sanity checks\nthat were performed.\n\nThis fix:\n\n- Uses LL_RESERVED_SPACE() to reserve space.\n- Check all conditions again after socket lock is held again.\n- Do not account Ethernet header for mtu limitation.\n\n[1]\n\nskbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0\n\n kernel BUG at net/core/skbuff.c:193 !\nInternal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP\nModules linked in:\nCPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023\npstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : skb_panic net/core/skbuff.c:189 [inline]\n pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203\n lr : skb_panic net/core/skbuff.c:189 [inline]\n lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203\nsp : ffff800096f97000\nx29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000\nx26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2\nx23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0\nx20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce\nx17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001\nx14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000\nx11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400\nx8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000\nx5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714\nx2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089\nCall trace:\n skb_panic net/core/skbuff.c:189 [inline]\n skb_under_panic+0x13c/0x140 net/core/skbuff.c:203\n skb_push+0xf0/0x108 net/core/skbuff.c:2451\n eth_header+0x44/0x1f8 net/ethernet/eth.c:83\n dev_hard_header include/linux/netdevice.h:3188 [inline]\n llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33\n llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85\n llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline]\n llc_sap_next_state net/llc/llc_sap.c:182 [inline]\n llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209\n llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270\n llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n sock_sendmsg+0x194/0x274 net/socket.c:767\n splice_to_socket+0x7cc/0xd58 fs/splice.c:881\n do_splice_from fs/splice.c:933 [inline]\n direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142\n splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088\n do_splice_direct+0x20c/0x348 fs/splice.c:1194\n do_sendfile+0x4bc/0xc70 fs/read_write.c:1254\n __do_sys_sendfile64 fs/read_write.c:1322 [inline]\n __se_sys_sendfile64 fs/read_write.c:1308 [inline]\n __arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308\n __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]\n invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51\n el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136\n do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155\n el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678\n el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696\n el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595\nCode: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000)

In the Linux kernel, the following vulnerability has been resolved:\n\nllc: Drop support for ETH_P_TR_802_2.\n\nsyzbot reported an uninit-value bug below. [0]\n\nllc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2\n(0x0011), and syzbot abused the latter to trigger the bug.\n\n write$tun(r0, &(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, ')', "90e5dd"}}}}, 0x16)\n\nllc_conn_handler() initialises local variables {saddr,daddr}.mac\nbased on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passes\nthem to __llc_lookup().\n\nHowever, the initialisation is done only when skb->protocol is\nhtons(ETH_P_802_2), otherwise, __llc_lookup_established() and\n__llc_lookup_listener() will read garbage.\n\nThe missing initialisation existed prior to commit 211ed865108e\n("net: delete all instances of special processing for token ring").\n\nIt removed the part to kick out the token ring stuff but forgot to\nclose the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv().\n\nLet's remove llc_tr_packet_type and complete the deprecation.\n\n[0]:\nBUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90\n __llc_lookup_established+0xe9d/0xf90\n __llc_lookup net/llc/llc_conn.c:611 [inline]\n llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791\n llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206\n __netif_receive_skb_one_core net/core/dev.c:5527 [inline]\n __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641\n netif_receive_skb_internal net/core/dev.c:5727 [inline]\n netif_receive_skb+0x58/0x660 net/core/dev.c:5786\n tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555\n tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002\n tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048\n call_write_iter include/linux/fs.h:2020 [inline]\n new_sync_write fs/read_write.c:491 [inline]\n vfs_write+0x8ef/0x1490 fs/read_write.c:584\n ksys_write+0x20f/0x4c0 fs/read_write.c:637\n __do_sys_write fs/read_write.c:649 [inline]\n __se_sys_write fs/read_write.c:646 [inline]\n __x64_sys_write+0x93/0xd0 fs/read_write.c:646\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\n\nLocal variable daddr created at:\n llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783\n llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206\n\nCPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: fix removing a namespace with conflicting altnames\n\nMark reports a BUG() when a net namespace is removed.\n\n kernel BUG at net/core/dev.c:11520!\n\nPhysical interfaces moved outside of init_net get "refunded"\nto init_net when that namespace disappears. The main interface\nname may get overwritten in the process if it would have\nconflicted. We need to also discard all conflicting altnames.\nRecent fixes addressed ensuring that altnames get moved\nwith the main interface, which surfaced this problem.

In the Linux kernel, the following vulnerability has been resolved:\n\nip6_tunnel: fix NEXTHDR_FRAGMENT handling in ip6_tnl_parse_tlv_enc_lim()\n\nsyzbot pointed out [1] that NEXTHDR_FRAGMENT handling is broken.\n\nReading frag_off can only be done if we pulled enough bytes\nto skb->head. Currently we might access garbage.\n\n[1]\nBUG: KMSAN: uninit-value in ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0\nip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0\nipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]\nip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432\n__netdev_start_xmit include/linux/netdevice.h:4940 [inline]\nnetdev_start_xmit include/linux/netdevice.h:4954 [inline]\nxmit_one net/core/dev.c:3548 [inline]\ndev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564\n__dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349\ndev_queue_xmit include/linux/netdevice.h:3134 [inline]\nneigh_connected_output+0x569/0x660 net/core/neighbour.c:1592\nneigh_output include/net/neighbour.h:542 [inline]\nip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137\nip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222\nNF_HOOK_COND include/linux/netfilter.h:303 [inline]\nip6_output+0x323/0x610 net/ipv6/ip6_output.c:243\ndst_output include/net/dst.h:451 [inline]\nip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155\nip6_send_skb net/ipv6/ip6_output.c:1952 [inline]\nip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972\nrawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582\nrawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920\ninet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847\nsock_sendmsg_nosec net/socket.c:730 [inline]\n__sock_sendmsg net/socket.c:745 [inline]\n____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584\n___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638\n__sys_sendmsg net/socket.c:2667 [inline]\n__do_sys_sendmsg net/socket.c:2676 [inline]\n__se_sys_sendmsg net/socket.c:2674 [inline]\n__x64_sys_sendmsg+0x307/0x490 net/socket.c:2674\ndo_syscall_x64 arch/x86/entry/common.c:52 [inline]\ndo_syscall_64+0x44/0x110 arch/x86/entry/common.c:83\nentry_SYSCALL_64_after_hwframe+0x63/0x6b\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_node_track_caller+0x118/0x3c0 mm/slab_common.c:1027\nkmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582\npskb_expand_head+0x226/0x1a00 net/core/skbuff.c:2098\n__pskb_pull_tail+0x13b/0x2310 net/core/skbuff.c:2655\npskb_may_pull_reason include/linux/skbuff.h:2673 [inline]\npskb_may_pull include/linux/skbuff.h:2681 [inline]\nip6_tnl_parse_tlv_enc_lim+0x901/0xbb0 net/ipv6/ip6_tunnel.c:408\nipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]\nip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432\n__netdev_start_xmit include/linux/netdevice.h:4940 [inline]\nnetdev_start_xmit include/linux/netdevice.h:4954 [inline]\nxmit_one net/core/dev.c:3548 [inline]\ndev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564\n__dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349\ndev_queue_xmit include/linux/netdevice.h:3134 [inline]\nneigh_connected_output+0x569/0x660 net/core/neighbour.c:1592\nneigh_output include/net/neighbour.h:542 [inline]\nip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137\nip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222\nNF_HOOK_COND include/linux/netfilter.h:303 [inline]\nip6_output+0x323/0x610 net/ipv6/ip6_output.c:243\ndst_output include/net/dst.h:451 [inline]\nip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155\nip6_send_skb net/ipv6/ip6_output.c:1952 [inline]\nip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972\nrawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582\nrawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920\ninet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847\nsock_sendmsg_nosec net/socket.c:730 [inline]\n__sock_sendmsg net/socket.c:745 [inline]\n____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584\n___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638\n__sys_sendmsg net/socket.c:2667 [inline]\n__do_sys_sendms\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: mcast: fix data-race in ipv6_mc_down / mld_ifc_work\n\nidev->mc_ifc_count can be written over without proper locking.\n\nOriginally found by syzbot [1], fix this issue by encapsulating calls\nto mld_ifc_stop_work() (and mld_gq_stop_work() for good measure) with\nmutex_lock() and mutex_unlock() accordingly as these functions\nshould only be called with mc_lock per their declarations.\n\n[1]\nBUG: KCSAN: data-race in ipv6_mc_down / mld_ifc_work\n\nwrite to 0xffff88813a80c832 of 1 bytes by task 3771 on cpu 0:\n mld_ifc_stop_work net/ipv6/mcast.c:1080 [inline]\n ipv6_mc_down+0x10a/0x280 net/ipv6/mcast.c:2725\n addrconf_ifdown+0xe32/0xf10 net/ipv6/addrconf.c:3949\n addrconf_notify+0x310/0x980\n notifier_call_chain kernel/notifier.c:93 [inline]\n raw_notifier_call_chain+0x6b/0x1c0 kernel/notifier.c:461\n __dev_notify_flags+0x205/0x3d0\n dev_change_flags+0xab/0xd0 net/core/dev.c:8685\n do_setlink+0x9f6/0x2430 net/core/rtnetlink.c:2916\n rtnl_group_changelink net/core/rtnetlink.c:3458 [inline]\n __rtnl_newlink net/core/rtnetlink.c:3717 [inline]\n rtnl_newlink+0xbb3/0x1670 net/core/rtnetlink.c:3754\n rtnetlink_rcv_msg+0x807/0x8c0 net/core/rtnetlink.c:6558\n netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2545\n rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:6576\n netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline]\n netlink_unicast+0x589/0x650 net/netlink/af_netlink.c:1368\n netlink_sendmsg+0x66e/0x770 net/netlink/af_netlink.c:1910\n ...\n\nwrite to 0xffff88813a80c832 of 1 bytes by task 22 on cpu 1:\n mld_ifc_work+0x54c/0x7b0 net/ipv6/mcast.c:2653\n process_one_work kernel/workqueue.c:2627 [inline]\n process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2700\n worker_thread+0x525/0x730 kernel/workqueue.c:2781\n ...

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: core: Move scsi_host_busy() out of host lock for waking up EH handler\n\nInside scsi_eh_wakeup(), scsi_host_busy() is called & checked with host\nlock every time for deciding if error handler kthread needs to be waken up.\n\nThis can be too heavy in case of recovery, such as:\n\n - N hardware queues\n\n - queue depth is M for each hardware queue\n\n - each scsi_host_busy() iterates over (N * M) tag/requests\n\nIf recovery is triggered in case that all requests are in-flight, each\nscsi_eh_wakeup() is strictly serialized, when scsi_eh_wakeup() is called\nfor the last in-flight request, scsi_host_busy() has been run for (N * M -\n1) times, and request has been iterated for (N*M - 1) * (N * M) times.\n\nIf both N and M are big enough, hard lockup can be triggered on acquiring\nhost lock, and it is observed on mpi3mr(128 hw queues, queue depth 8169).\n\nFix the issue by calling scsi_host_busy() outside the host lock. We don't\nneed the host lock for getting busy count because host the lock never\ncovers that.\n\n[mkp: Drop unnecessary 'busy' variables pointed out by Bart]

In the Linux kernel, the following vulnerability has been resolved:\n\nipmr: fix kernel panic when forwarding mcast packets\n\nThe stacktrace was:\n[ 86.305548] BUG: kernel NULL pointer dereference, address: 0000000000000092\n[ 86.306815] #PF: supervisor read access in kernel mode\n[ 86.307717] #PF: error_code(0x0000) - not-present page\n[ 86.308624] PGD 0 P4D 0\n[ 86.309091] Oops: 0000 [#1] PREEMPT SMP NOPTI\n[ 86.309883] CPU: 2 PID: 3139 Comm: pimd Tainted: G U 6.8.0-6wind-knet #1\n[ 86.311027] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.1-0-g0551a4be2c-prebuilt.qemu-project.org 04/01/2014\n[ 86.312728] RIP: 0010:ip_mr_forward (/build/work/knet/net/ipv4/ipmr.c:1985)\n[ 86.313399] Code: f9 1f 0f 87 85 03 00 00 48 8d 04 5b 48 8d 04 83 49 8d 44 c5 00 48 8b 40 70 48 39 c2 0f 84 d9 00 00 00 49 8b 46 58 48 83 e0 fe <80> b8 92 00 00 00 00 0f 84 55 ff ff ff 49 83 47 38 01 45 85 e4 0f\n[ 86.316565] RSP: 0018:ffffad21c0583ae0 EFLAGS: 00010246\n[ 86.317497] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000\n[ 86.318596] RDX: ffff9559cb46c000 RSI: 0000000000000000 RDI: 0000000000000000\n[ 86.319627] RBP: ffffad21c0583b30 R08: 0000000000000000 R09: 0000000000000000\n[ 86.320650] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001\n[ 86.321672] R13: ffff9559c093a000 R14: ffff9559cc00b800 R15: ffff9559c09c1d80\n[ 86.322873] FS: 00007f85db661980(0000) GS:ffff955a79d00000(0000) knlGS:0000000000000000\n[ 86.324291] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 86.325314] CR2: 0000000000000092 CR3: 000000002f13a000 CR4: 0000000000350ef0\n[ 86.326589] Call Trace:\n[ 86.327036] \n[ 86.327434] ? show_regs (/build/work/knet/arch/x86/kernel/dumpstack.c:479)\n[ 86.328049] ? __die (/build/work/knet/arch/x86/kernel/dumpstack.c:421 /build/work/knet/arch/x86/kernel/dumpstack.c:434)\n[ 86.328508] ? page_fault_oops (/build/work/knet/arch/x86/mm/fault.c:707)\n[ 86.329107] ? do_user_addr_fault (/build/work/knet/arch/x86/mm/fault.c:1264)\n[ 86.329756] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223)\n[ 86.330350] ? __irq_work_queue_local (/build/work/knet/kernel/irq_work.c:111 (discriminator 1))\n[ 86.331013] ? exc_page_fault (/build/work/knet/./arch/x86/include/asm/paravirt.h:693 /build/work/knet/arch/x86/mm/fault.c:1515 /build/work/knet/arch/x86/mm/fault.c:1563)\n[ 86.331702] ? asm_exc_page_fault (/build/work/knet/./arch/x86/include/asm/idtentry.h:570)\n[ 86.332468] ? ip_mr_forward (/build/work/knet/net/ipv4/ipmr.c:1985)\n[ 86.333183] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223)\n[ 86.333920] ipmr_mfc_add (/build/work/knet/./include/linux/rcupdate.h:782 /build/work/knet/net/ipv4/ipmr.c:1009 /build/work/knet/net/ipv4/ipmr.c:1273)\n[ 86.334583] ? __pfx_ipmr_hash_cmp (/build/work/knet/net/ipv4/ipmr.c:363)\n[ 86.335357] ip_mroute_setsockopt (/build/work/knet/net/ipv4/ipmr.c:1470)\n[ 86.336135] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223)\n[ 86.336854] ? ip_mroute_setsockopt (/build/work/knet/net/ipv4/ipmr.c:1470)\n[ 86.337679] do_ip_setsockopt (/build/work/knet/net/ipv4/ip_sockglue.c:944)\n[ 86.338408] ? __pfx_unix_stream_read_actor (/build/work/knet/net/unix/af_unix.c:2862)\n[ 86.339232] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223)\n[ 86.339809] ? aa_sk_perm (/build/work/knet/security/apparmor/include/cred.h:153 /build/work/knet/security/apparmor/net.c:181)\n[ 86.340342] ip_setsockopt (/build/work/knet/net/ipv4/ip_sockglue.c:1415)\n[ 86.340859] raw_setsockopt (/build/work/knet/net/ipv4/raw.c:836)\n[ 86.341408] ? security_socket_setsockopt (/build/work/knet/security/security.c:4561 (discriminator 13))\n[ 86.342116] sock_common_setsockopt (/build/work/knet/net/core/sock.c:3716)\n[ 86.342747] do_sock_setsockopt (/build/work/knet/net/socket.c:2313)\n[ 86.343363] __sys_setsockopt (/build/work/knet/./include/linux/file.h:32 /build/work/kn\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nllc: call sock_orphan() at release time\n\nsyzbot reported an interesting trace [1] caused by a stale sk->sk_wq\npointer in a closed llc socket.\n\nIn commit ff7b11aa481f ("net: socket: set sock->sk to NULL after\ncalling proto_ops::release()") Eric Biggers hinted that some protocols\nare missing a sock_orphan(), we need to perform a full audit.\n\nIn net-next, I plan to clear sock->sk from sock_orphan() and\namend Eric patch to add a warning.\n\n[1]\n BUG: KASAN: slab-use-after-free in list_empty include/linux/list.h:373 [inline]\n BUG: KASAN: slab-use-after-free in waitqueue_active include/linux/wait.h:127 [inline]\n BUG: KASAN: slab-use-after-free in sock_def_write_space_wfree net/core/sock.c:3384 [inline]\n BUG: KASAN: slab-use-after-free in sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468\nRead of size 8 at addr ffff88802f4fc880 by task ksoftirqd/1/27\n\nCPU: 1 PID: 27 Comm: ksoftirqd/1 Not tainted 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\nCall Trace:\n \n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0xc4/0x620 mm/kasan/report.c:488\n kasan_report+0xda/0x110 mm/kasan/report.c:601\n list_empty include/linux/list.h:373 [inline]\n waitqueue_active include/linux/wait.h:127 [inline]\n sock_def_write_space_wfree net/core/sock.c:3384 [inline]\n sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468\n skb_release_head_state+0xa3/0x2b0 net/core/skbuff.c:1080\n skb_release_all net/core/skbuff.c:1092 [inline]\n napi_consume_skb+0x119/0x2b0 net/core/skbuff.c:1404\n e1000_unmap_and_free_tx_resource+0x144/0x200 drivers/net/ethernet/intel/e1000/e1000_main.c:1970\n e1000_clean_tx_irq drivers/net/ethernet/intel/e1000/e1000_main.c:3860 [inline]\n e1000_clean+0x4a1/0x26e0 drivers/net/ethernet/intel/e1000/e1000_main.c:3801\n __napi_poll.constprop.0+0xb4/0x540 net/core/dev.c:6576\n napi_poll net/core/dev.c:6645 [inline]\n net_rx_action+0x956/0xe90 net/core/dev.c:6778\n __do_softirq+0x21a/0x8de kernel/softirq.c:553\n run_ksoftirqd kernel/softirq.c:921 [inline]\n run_ksoftirqd+0x31/0x60 kernel/softirq.c:913\n smpboot_thread_fn+0x660/0xa10 kernel/smpboot.c:164\n kthread+0x2c6/0x3a0 kernel/kthread.c:388\n ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242\n \n\nAllocated by task 5167:\n kasan_save_stack+0x33/0x50 mm/kasan/common.c:47\n kasan_save_track+0x14/0x30 mm/kasan/common.c:68\n unpoison_slab_object mm/kasan/common.c:314 [inline]\n __kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:340\n kasan_slab_alloc include/linux/kasan.h:201 [inline]\n slab_post_alloc_hook mm/slub.c:3813 [inline]\n slab_alloc_node mm/slub.c:3860 [inline]\n kmem_cache_alloc_lru+0x142/0x6f0 mm/slub.c:3879\n alloc_inode_sb include/linux/fs.h:3019 [inline]\n sock_alloc_inode+0x25/0x1c0 net/socket.c:308\n alloc_inode+0x5d/0x220 fs/inode.c:260\n new_inode_pseudo+0x16/0x80 fs/inode.c:1005\n sock_alloc+0x40/0x270 net/socket.c:634\n __sock_create+0xbc/0x800 net/socket.c:1535\n sock_create net/socket.c:1622 [inline]\n __sys_socket_create net/socket.c:1659 [inline]\n __sys_socket+0x14c/0x260 net/socket.c:1706\n __do_sys_socket net/socket.c:1720 [inline]\n __se_sys_socket net/socket.c:1718 [inline]\n __x64_sys_socket+0x72/0xb0 net/socket.c:1718\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\n\nFreed by task 0:\n kasan_save_stack+0x33/0x50 mm/kasan/common.c:47\n kasan_save_track+0x14/0x30 mm/kasan/common.c:68\n kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640\n poison_slab_object mm/kasan/common.c:241 [inline]\n __kasan_slab_free+0x121/0x1b0 mm/kasan/common.c:257\n kasan_slab_free include/linux/kasan.h:184 [inline]\n slab_free_hook mm/slub.c:2121 [inlin\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\npds_core: Prevent race issues involving the adminq\n\nThere are multiple paths that can result in using the pdsc's\nadminq.\n\n[1] pdsc_adminq_isr and the resulting work from queue_work(),\n i.e. pdsc_work_thread()->pdsc_process_adminq()\n\n[2] pdsc_adminq_post()\n\nWhen the device goes through reset via PCIe reset and/or\na fw_down/fw_up cycle due to bad PCIe state or bad device\nstate the adminq is destroyed and recreated.\n\nA NULL pointer dereference can happen if [1] or [2] happens\nafter the adminq is already destroyed.\n\nIn order to fix this, add some further state checks and\nimplement reference counting for adminq uses. Reference\ncounting was used because multiple threads can attempt to\naccess the adminq at the same time via [1] or [2]. Additionally,\nmultiple clients (i.e. pds-vfio-pci) can be using [2]\nat the same time.\n\nThe adminq_refcnt is initialized to 1 when the adminq has been\nallocated and is ready to use. Users/clients of the adminq\n(i.e. [1] and [2]) will increment the refcnt when they are using\nthe adminq. When the driver goes into a fw_down cycle it will\nset the PDSC_S_FW_DEAD bit and then wait for the adminq_refcnt\nto hit 1. Setting the PDSC_S_FW_DEAD before waiting will prevent\nany further adminq_refcnt increments. Waiting for the\nadminq_refcnt to hit 1 allows for any current users of the adminq\nto finish before the driver frees the adminq. Once the\nadminq_refcnt hits 1 the driver clears the refcnt to signify that\nthe adminq is deleted and cannot be used. On the fw_up cycle the\ndriver will once again initialize the adminq_refcnt to 1 allowing\nthe adminq to be used again.

In the Linux kernel, the following vulnerability has been resolved:\n\ntomoyo: fix UAF write bug in tomoyo_write_control()\n\nSince tomoyo_write_control() updates head->write_buf when write()\nof long lines is requested, we need to fetch head->write_buf after\nhead->io_sem is held. Otherwise, concurrent write() requests can\ncause use-after-free-write and double-free problems.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm: huge_memory: don't force huge page alignment on 32 bit\n\ncommit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP\nboundaries") caused two issues [1] [2] reported on 32 bit system or compat\nuserspace.\n\nIt doesn't make too much sense to force huge page alignment on 32 bit\nsystem due to the constrained virtual address space.\n\n[1] https://lore.kernel.org/linux-mm/d0a136a0-4a31-46bc-adf4-2db109a61672@kernel.org/\n[2] https://lore.kernel.org/linux-mm/CAJuCfpHXLdQy1a2B6xN2d7quTYwg2OoZseYPZTRpU0eHHKD-sQ@mail.gmail.com/

In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: Fix module loading free order\n\nReverse order of kfree calls to resolve use-after-free error.

In the Linux kernel, the following vulnerability has been resolved:\n\nfs/proc/task_mmu: move mmu notification mechanism inside mm lock\n\nMove mmu notification mechanism inside mm lock to prevent race condition\nin other components which depend on it. The notifier will invalidate\nmemory range. Depending upon the number of iterations, different memory\nranges would be invalidated.\n\nThe following warning would be removed by this patch:\nWARNING: CPU: 0 PID: 5067 at arch/x86/kvm/../../../virt/kvm/kvm_main.c:734 kvm_mmu_notifier_change_pte+0x860/0x960 arch/x86/kvm/../../../virt/kvm/kvm_main.c:734\n\nThere is no behavioural and performance change with this patch when\nthere is no component registered with the mmu notifier.\n\n[akpm@linux-foundation.org: narrow the scope of `range', per Sean]

In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix UAF issue in ksmbd_tcp_new_connection()\n\nThe race is between the handling of a new TCP connection and\nits disconnection. It leads to UAF on `struct tcp_transport` in\nksmbd_tcp_new_connection() function.

In the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: BPF: Prevent out-of-bounds memory access\n\nThe test_tag test triggers an unhandled page fault:\n\n # ./test_tag\n [ 130.640218] CPU 0 Unable to handle kernel paging request at virtual address ffff80001b898004, era == 9000000003137f7c, ra == 9000000003139e70\n [ 130.640501] Oops[#3]:\n [ 130.640553] CPU: 0 PID: 1326 Comm: test_tag Tainted: G D O 6.7.0-rc4-loong-devel-gb62ab1a397cf #47 61985c1d94084daa2432f771daa45b56b10d8d2a\n [ 130.640764] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022\n [ 130.640874] pc 9000000003137f7c ra 9000000003139e70 tp 9000000104cb4000 sp 9000000104cb7a40\n [ 130.641001] a0 ffff80001b894000 a1 ffff80001b897ff8 a2 000000006ba210be a3 0000000000000000\n [ 130.641128] a4 000000006ba210be a5 00000000000000f1 a6 00000000000000b3 a7 0000000000000000\n [ 130.641256] t0 0000000000000000 t1 00000000000007f6 t2 0000000000000000 t3 9000000004091b70\n [ 130.641387] t4 000000006ba210be t5 0000000000000004 t6 fffffffffffffff0 t7 90000000040913e0\n [ 130.641512] t8 0000000000000005 u0 0000000000000dc0 s9 0000000000000009 s0 9000000104cb7ae0\n [ 130.641641] s1 00000000000007f6 s2 0000000000000009 s3 0000000000000095 s4 0000000000000000\n [ 130.641771] s5 ffff80001b894000 s6 ffff80001b897fb0 s7 9000000004090c50 s8 0000000000000000\n [ 130.641900] ra: 9000000003139e70 build_body+0x1fcc/0x4988\n [ 130.642007] ERA: 9000000003137f7c build_body+0xd8/0x4988\n [ 130.642112] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)\n [ 130.642261] PRMD: 00000004 (PPLV0 +PIE -PWE)\n [ 130.642353] EUEN: 00000003 (+FPE +SXE -ASXE -BTE)\n [ 130.642458] ECFG: 00071c1c (LIE=2-4,10-12 VS=7)\n [ 130.642554] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)\n [ 130.642658] BADV: ffff80001b898004\n [ 130.642719] PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)\n [ 130.642815] Modules linked in: [last unloaded: bpf_testmod(O)]\n [ 130.642924] Process test_tag (pid: 1326, threadinfo=00000000f7f4015f, task=000000006499f9fd)\n [ 130.643062] Stack : 0000000000000000 9000000003380724 0000000000000000 0000000104cb7be8\n [ 130.643213] 0000000000000000 25af8d9b6e600558 9000000106250ea0 9000000104cb7ae0\n [ 130.643378] 0000000000000000 0000000000000000 9000000104cb7be8 90000000049f6000\n [ 130.643538] 0000000000000090 9000000106250ea0 ffff80001b894000 ffff80001b894000\n [ 130.643685] 00007ffffb917790 900000000313ca94 0000000000000000 0000000000000000\n [ 130.643831] ffff80001b894000 0000000000000ff7 0000000000000000 9000000100468000\n [ 130.643983] 0000000000000000 0000000000000000 0000000000000040 25af8d9b6e600558\n [ 130.644131] 0000000000000bb7 ffff80001b894048 0000000000000000 0000000000000000\n [ 130.644276] 9000000104cb7be8 90000000049f6000 0000000000000090 9000000104cb7bdc\n [ 130.644423] ffff80001b894000 0000000000000000 00007ffffb917790 90000000032acfb0\n [ 130.644572] ...\n [ 130.644629] Call Trace:\n [ 130.644641] [<9000000003137f7c>] build_body+0xd8/0x4988\n [ 130.644785] [<900000000313ca94>] bpf_int_jit_compile+0x228/0x4ec\n [ 130.644891] [<90000000032acfb0>] bpf_prog_select_runtime+0x158/0x1b0\n [ 130.645003] [<90000000032b3504>] bpf_prog_load+0x760/0xb44\n [ 130.645089] [<90000000032b6744>] __sys_bpf+0xbb8/0x2588\n [ 130.645175] [<90000000032b8388>] sys_bpf+0x20/0x2c\n [ 130.645259] [<9000000003f6ab38>] do_syscall+0x7c/0x94\n [ 130.645369] [<9000000003121c5c>] handle_syscall+0xbc/0x158\n [ 130.645507]\n [ 130.645539] Code: 380839f6 380831f9 28412bae <24000ca6> 004081ad 0014cb50 004083e8 02bff34c 58008e91\n [ 130.645729]\n [ 130.646418] ---[ end trace 0000000000000000 ]---\n\nOn my machine, which has CONFIG_PAGE_SIZE_16KB=y, the test failed at\nloading a BPF prog with 2039 instructions:\n\n prog = (struct bpf_prog *)ffff80001b894000\n insn = (struct bpf_insn *)(prog->insnsi)fff\n---truncated---

printer_write in drivers/usb/gadget/function/f_printer.c in the Linux kernel through 6.7.4 does not properly call usb_ep_queue, which might allow attackers to cause a denial of service or have unspecified other impact.

copy_params in drivers/md/dm-ioctl.c in the Linux kernel through 6.7.1 can attempt to allocate more than INT_MAX bytes, and crash, because of a missing param_kernel->data_size check. This is related to ctl_ioctl.

In btrfs_get_root_ref in fs/btrfs/disk-io.c in the Linux kernel through 6.7.1, there can be an assertion failure and crash because a subvolume can be read out too soon after its root item is inserted upon subvolume creation.

Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Compiler). Supported versions that are affected are Oracle Java SE: 23; Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23; Oracle GraalVM Enterprise Edition: 20.3.15 and 21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).

Vulnerability in the MySQL Connectors product of Oracle MySQL (component: Connector/Python). Supported versions that are affected are 8.3.0 and prior. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise MySQL Connectors. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Connectors. CVSS 3.1 Base Score 7.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).

Issue summary: Clients using RFC7250 Raw Public Keys (RPKs) to authenticate a\nserver may fail to notice that the server was not authenticated, because\nhandshakes don't abort as expected when the SSL_VERIFY_PEER verification mode\nis set.\n\nImpact summary: TLS and DTLS connections using raw public keys may be\nvulnerable to man-in-middle attacks when server authentication failure is not\ndetected by clients.\n\nRPKs are disabled by default in both TLS clients and TLS servers. The issue\nonly arises when TLS clients explicitly enable RPK use by the server, and the\nserver, likewise, enables sending of an RPK instead of an X.509 certificate\nchain. The affected clients are those that then rely on the handshake to\nfail when the server's RPK fails to match one of the expected public keys,\nby setting the verification mode to SSL_VERIFY_PEER.\n\nClients that enable server-side raw public keys can still find out that raw\npublic key verification failed by calling SSL_get_verify_result(), and those\nthat do, and take appropriate action, are not affected. This issue was\nintroduced in the initial implementation of RPK support in OpenSSL 3.2.\n\nThe FIPS modules in 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.

Starting in Python 3.12.0, the asyncio._SelectorSocketTransport.writelines()\n method would not "pause" writing and signal to the Protocol to drain \nthe buffer to the wire once the write buffer reached the "high-water \nmark". Because of this, Protocols would not periodically drain the write\n buffer potentially leading to memory exhaustion.\n\n\n\n\n\nThis\n vulnerability likely impacts a small number of users, you must be using\n Python 3.12.0 or later, on macOS or Linux, using the asyncio module \nwith protocols, and using .writelines() method which had new \nzero-copy-on-write behavior in Python 3.12.0 and later. If not all of \nthese factors are true then your usage of Python is unaffected.

A vulnerability was reported in the Open vSwitch sub-component in the Linux Kernel. The flaw occurs when a recursive operation of code push recursively calls into the code block. The OVS module does not validate the stack depth, pushing too many frames and causing a stack overflow. As a result, this can lead to a crash or other related issues.

A denial of service vulnerability was found in tipc_crypto_key_revoke in net/tipc/crypto.c in the Linux kernel’s TIPC subsystem. This flaw allows guests with local user privileges to trigger a deadlock and potentially crash the system.

A denial of service vulnerability due to a deadlock was found in sctp_auto_asconf_init in net/sctp/socket.c in the Linux kernel’s SCTP subsystem. This flaw allows guests with local user privileges to trigger a deadlock and potentially crash the system.

A null pointer dereference vulnerability was found in ath10k_wmi_tlv_op_pull_mgmt_tx_compl_ev() in drivers/net/wireless/ath/ath10k/wmi-tlv.c in the Linux kernel. This issue could be exploited to trigger a denial of service.

An out-of-bounds memory access flaw was found in the io_uring SQ/CQ rings functionality in the Linux kernel. This issue could allow a local user to crash the system.

A flaw was found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on `struct net_device`, and a use-after-free can be triggered by racing between the free on the struct and the access through the `skbtxq` global queue. This could lead to a denial of service condition or potential code execution.

When opening a page in reader mode, the redirect URL could have caused attacker-controlled script to execute in a reflected Cross-Site Scripting (XSS) attack. This vulnerability affects Firefox for iOS < 119.