In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: prevent opcode speculation\n\nsqe->opcode is used for different tables, make sure we santitise it\nagainst speculations.

JSON is a JSON implementation for Ruby. Starting in version 2.10.0 and prior to version 2.10.2, a specially crafted document could cause an out of bound read, most likely resulting in a crash. Versions prior to 2.10.0 are not vulnerable. Version 2.10.2 fixes the problem. No known workarounds are available.

OpenSSH 9.5 through 9.7 before 9.8 sometimes allows timing attacks against echo-off password entry (e.g., for su and Sudo) because of an ObscureKeystrokeTiming logic error. Similarly, other timing attacks against keystroke entry could occur.

Certifi is a curated collection of Root Certificates for validating the trustworthiness of SSL certificates while verifying the identity of TLS hosts. Certifi starting in 2021.05.30 and prior to 2024.07.4 recognized root certificates from `GLOBALTRUST`. Certifi 2024.07.04 removes root certificates from `GLOBALTRUST` from the root store. These are in the process of being removed from Mozilla's trust store. `GLOBALTRUST`'s root certificates are being removed pursuant to an investigation which identified "long-running and unresolved compliance issues."

When a protocol selection parameter option disables all protocols without adding any then the default set of protocols would remain in the allowed set due to an error in the logic for removing protocols. The below command would perform a request to curl.se with a plaintext protocol which has been explicitly disabled. curl --proto -all,-http http://curl.se The flaw is only present if the set of selected protocols disables the entire set of available protocols, in itself a command with no practical use and therefore unlikely to be encountered in real situations. The curl security team has thus assessed this to be low severity bug.

A flaw was found in djvulibre-3.5.28 and earlier. A heap buffer overflow in function DJVU::GBitmap::decode() via crafted djvu file may lead to application crash and other consequences.

A flaw was found in djvulibre-3.5.28 and earlier. An integer overflow in function render() in tools/ddjvu via crafted djvu file may lead to application crash and other consequences.

A flaw was found in djvulibre-3.5.28 and earlier. An out of bounds write in function DJVU::filter_bv() via crafted djvu file may lead to application crash and other consequences.

PostgreSQL before 9.0.19, 9.1.x before 9.1.15, 9.2.x before 9.2.10, 9.3.x before 9.3.6, and 9.4.x before 9.4.1 allows remote authenticated users to obtain sensitive column values by triggering constraint violation and then reading the error message.

When curl is told to use the Certificate Status Request TLS extension, often referred to as OCSP stapling, to verify that the server certificate is valid, it might fail to detect some OCSP problems and instead wrongly consider the response as fine. If the returned status reports another error than 'revoked' (like for example 'unauthorized') it is not treated as a bad certficate.

Improper signature verification in AMD CPU ROM microcode patch loader may allow an attacker with local administrator privilege to load malicious CPU microcode resulting in loss of confidentiality and integrity of a confidential guest running under AMD SEV-SNP.

Improper input validation in XmlCli feature for UEFI firmware for some Intel(R) processors may allow privileged user to potentially enable escalation of privilege via local access.

An out of bounds write exists in FreeType versions 2.13.0 and below when attempting to parse font subglyph structures related to TrueType GX and variable font files. The vulnerable code assigns a signed short value to an unsigned long and then adds a static value causing it to wrap around and allocate too small of a heap buffer. The code then writes up to 6 signed long integers out of bounds relative to this buffer. This may result in arbitrary code execution. This vulnerability may have been exploited in the wild.

Issue summary: Use of the low-level GF(2^m) elliptic curve APIs with untrusted\nexplicit values for the field polynomial can lead to out-of-bounds memory reads\nor writes.\n\nImpact summary: Out of bound memory writes can lead to an application crash or\neven a possibility of a remote code execution, however, in all the protocols\ninvolving Elliptic Curve Cryptography that we're aware of, either only "named\ncurves" are supported, or, if explicit curve parameters are supported, they\nspecify an X9.62 encoding of binary (GF(2^m)) curves that can't represent\nproblematic input values. Thus the likelihood of existence of a vulnerable\napplication is low.\n\nIn particular, the X9.62 encoding is used for ECC keys in X.509 certificates,\nso problematic inputs cannot occur in the context of processing X.509\ncertificates. Any problematic use-cases would have to be using an "exotic"\ncurve encoding.\n\nThe affected APIs include: EC_GROUP_new_curve_GF2m(), EC_GROUP_new_from_params(),\nand various supporting BN_GF2m_*() functions.\n\nApplications working with "exotic" explicit binary (GF(2^m)) curve parameters,\nthat make it possible to represent invalid field polynomials with a zero\nconstant term, via the above or similar APIs, may terminate abruptly as a\nresult of reading or writing outside of array bounds. Remote code execution\ncannot easily be ruled out.\n\nThe FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.

LLVM 15.0.0 has a NULL pointer dereference in the parseOneMetadata() function via a crafted pdflatex.fmt file (or perhaps a crafted .o file) to llvm-lto. NOTE: this is disputed because the relationship between pdflatex.fmt and any LLVM language front end is not explained, and because a crash of the llvm-lto application should be categorized as a usability problem.

WebExtensions with the correct permissions were able to create and install ServiceWorkers for third-party websites that would not have been uninstalled with the extension. This vulnerability affects Firefox < 95.

An assertion failure issue was found in the Network Block Device(NBD) Server in all QEMU versions before QEMU 5.0.1. This flaw occurs when an nbd-client sends a spec-compliant request that is near the boundary of maximum permitted request length. A remote nbd-client could use this flaw to crash the qemu-nbd server resulting in a denial of service.

MariaDB Server 10.4 through 10.5.*, 10.6 through 10.6.*, 10.7 through 10.11.*, 11.0 through 11.0.*, and 11.1 through 11.4.* crashes in Item_direct_view_ref::derived_field_transformer_for_where.

In the Linux kernel, the following vulnerability has been resolved:\n\ns390/cpum_sf: Handle CPU hotplug remove during sampling\n\nCPU hotplug remove handling triggers the following function\ncall sequence:\n\n CPUHP_AP_PERF_S390_SF_ONLINE --> s390_pmu_sf_offline_cpu()\n ...\n CPUHP_AP_PERF_ONLINE --> perf_event_exit_cpu()\n\nThe s390 CPUMF sampling CPU hotplug handler invokes:\n\n s390_pmu_sf_offline_cpu()\n +--> cpusf_pmu_setup()\n +--> setup_pmc_cpu()\n +--> deallocate_buffers()\n\nThis function de-allocates all sampling data buffers (SDBs) allocated\nfor that CPU at event initialization. It also clears the\nPMU_F_RESERVED bit. The CPU is gone and can not be sampled.\n\nWith the event still being active on the removed CPU, the CPU event\nhotplug support in kernel performance subsystem triggers the\nfollowing function calls on the removed CPU:\n\n perf_event_exit_cpu()\n +--> perf_event_exit_cpu_context()\n +--> __perf_event_exit_context()\n\t +--> __perf_remove_from_context()\n\t +--> event_sched_out()\n\t +--> cpumsf_pmu_del()\n\t +--> cpumsf_pmu_stop()\n +--> hw_perf_event_update()\n\nto stop and remove the event. During removal of the event, the\nsampling device driver tries to read out the remaining samples from\nthe sample data buffers (SDBs). But they have already been freed\n(and may have been re-assigned). This may lead to a use after free\nsituation in which case the samples are most likely invalid. In the\nbest case the memory has not been reassigned and still contains\nvalid data.\n\nRemedy this situation and check if the CPU is still in reserved\nstate (bit PMU_F_RESERVED set). In this case the SDBs have not been\nreleased an contain valid data. This is always the case when\nthe event is removed (and no CPU hotplug off occured).\nIf the PMU_F_RESERVED bit is not set, the SDB buffers are gone.

A use-after-free flaw was found in X.Org and Xwayland. When changing an alarm, the values of the change mask are evaluated one after the other, changing the trigger values as requested, and eventually, SyncInitTrigger() is called. If one of the changes triggers an error, the function will return early, not adding the new sync object, possibly causing a use-after-free when the alarm eventually triggers.

A use-after-free flaw was found in X.Org and Xwayland. When a device is removed while still frozen, the events queued for that device remain while the device is freed. Replaying the events will cause a use-after-free.

An access to an uninitialized pointer flaw was found in X.Org and Xwayland. The function compCheckRedirect() may fail if it cannot allocate the backing pixmap. In that case, compRedirectWindow() will return a BadAlloc error without validating the window tree marked just before, which leaves the validated data partly initialized and the use of an uninitialized pointer later.

An out-of-bounds write flaw was found in X.Org and Xwayland. The function GetBarrierDevice() searches for the pointer device based on its device ID and returns the matching value, or supposedly NULL, if no match was found. However, the code will return the last element of the list if no matching device ID is found, which can lead to out-of-bounds memory access.

A buffer overflow flaw was found in X.Org and Xwayland. If XkbChangeTypesOfKey() is called with a 0 group, it will resize the key symbols table to 0 but leave the key actions unchanged. If the same function is later called with a non-zero value of groups, this will cause a buffer overflow because the key actions are of the wrong size.

A heap overflow flaw was found in X.Org and Xwayland. The computation of the length in XkbSizeKeySyms() differs from what is written in XkbWriteKeySyms(), which may lead to a heap-based buffer overflow.

A buffer overflow flaw was found in X.Org and Xwayland. The code in XkbVModMaskText() allocates a fixed-sized buffer on the stack and copies the names of the virtual modifiers to that buffer. The code fails to check the bounds of the buffer and would copy the data regardless of the size.

A use-after-free flaw was found in X.Org and Xwayland. The root cursor is referenced in the X server as a global variable. If a client frees the root cursor, the internal reference points to freed memory and causes a use-after-free.

libxml2 before 2.12.10 and 2.13.x before 2.13.6 has a stack-based buffer overflow in xmlSnprintfElements in valid.c. To exploit this, DTD validation must occur for an untrusted document or untrusted DTD. NOTE: this is similar to CVE-2017-9047.

With the aid of the diagnostics_channel utility, an event can be hooked into whenever a worker thread is created. This is not limited only to workers\n but also exposes internal workers, where an instance of them can be fetched, and its constructor can be grabbed and reinstated for malicious usage.\n\nThis vulnerability affects Permission Model users (--permission) on Node.js v20, v22, and v23.

Memory safety bugs present in Firefox 135 and Thunderbird 135. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 136 and Thunderbird < 136.

When String.toUpperCase() caused a string to get longer it was possible for uninitialized memory to be incorporated into the result string This vulnerability affects Firefox < 136 and Thunderbird < 136.

No description is available for this CVE.

Memory safety bugs present in Firefox 135, Thunderbird 135, Firefox ESR 115.20, Firefox ESR 128.7, and Thunderbird 128.7. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 136, Firefox ESR < 115.21, Firefox ESR < 128.8, Thunderbird < 136, and Thunderbird < 128.8.

No description is available for this CVE.

No description is available for this CVE.

A flaw was found in Firefox. The Mozilla Foundation's Security Advisory describes the following issue: It was possible to interrupt the processing of a RegExp bailout and run additional JavaScript, potentially triggering garbage collection when the engine was not expecting it.

On 64-bit CPUs, when the JIT compiles WASM i32 return values they can pick up bits from left over memory. This can potentially cause them to be treated as a different type. This vulnerability affects Firefox < 136, Firefox ESR < 115.21, Firefox ESR < 128.8, Thunderbird < 136, and Thunderbird < 128.8.

A flaw was found in Firefox. The Mozilla Foundation's Security Advisory describes the following issue: An inconsistent comparator in xslt/txNodeSorter could have resulted in potentially exploitable out-of-bounds access.

It was possible to cause a use-after-free in the content process side of a WebTransport connection, leading to a potentially exploitable crash. This vulnerability affects Firefox < 136, Firefox ESR < 115.21, Firefox ESR < 128.8, Thunderbird < 136, and Thunderbird < 128.8.

On Windows, a compromised content process could use bad StreamData sent over AudioIPC to trigger a use-after-free in the Browser process. This could have led to a sandbox escape. This vulnerability affects Firefox < 136, Firefox ESR < 115.21, Firefox ESR < 128.8, Thunderbird < 136, and Thunderbird < 128.8.

Bundle Protocol and CBOR dissector crashes in Wireshark 4.4.0 to 4.4.3 and 4.2.0 to 4.2.10 allows denial of service via packet injection or crafted capture file

Memory safety bugs present in Firefox 135. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 135.0.1.

Versions of the package cockpit-hq/cockpit before 2.4.1 are vulnerable to Arbitrary File Upload where an attacker can use different extension to bypass the upload filter.

When the assert() function in the GNU C Library versions 2.13 to 2.40 fails, it does not allocate enough space for the assertion failure message string and size information, which may lead to a buffer overflow if the message string size aligns to page size.

A vulnerability was found in Ruby. The Ruby interpreter is vulnerable to the Marvin Attack. This attack allows the attacker to decrypt previously encrypted messages or forge signatures by exchanging a large number of messages with the vulnerable service.

Memory safety bugs present in Firefox 133 and Thunderbird 133. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 134 and Thunderbird < 134..

When manipulating the selection node cache, an attacker may have been able to cause unexpected behavior, potentially leading to an exploitable crash. This vulnerability affects Firefox < 131.0.3.

libxml2 before 2.12.10 and 2.13.x before 2.13.6 has a use-after-free in xmlSchemaIDCFillNodeTables and xmlSchemaBubbleIDCNodeTables in xmlschemas.c. To exploit this, a crafted XML document must be validated against an XML schema with certain identity constraints, or a crafted XML schema must be used.

decNumberCopy in decNumber.c in jq through 1.7.1 does not properly consider that NaN is interpreted as numeric, which has a resultant stack-based buffer overflow and out-of-bounds write, as demonstrated by use of --slurp with subtraction, such as a filter of .-. when the input has a certain form of digit string with NaN (e.g., "1 NaN123" immediately followed by many more digits).

When logs are written to a widely-writable directory (the default), an unprivileged attacker may predict a privileged process's log file path and pre-create a symbolic link to a sensitive file in its place. When that privileged process runs, it will follow the planted symlink and overwrite that sensitive file. To fix that, glog now causes the program to exit (with status code 2) when it finds that the configured log file already exists.

Improper input validation in UEFI firmware CseVariableStorageSmm for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access.

Improper input validation in UEFI firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access.

A malicious website could have included an iframe with an malformed URI resulting in a non-exploitable browser crash. This vulnerability affects Firefox < 126.

Improper input validation in UEFI firmware for some Intel(R) processors may allow a privileged user to potentially enable escalation of privilege via local access.

Improper input validation in UEFI firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access.

An issue was discovered in GNOME gnome-desktop 3.26, 3.28, and 3.30 prior to 3.30.2.2, and 3.32 prior to 3.32.1.1. A compromised thumbnailer may escape the bubblewrap sandbox used to confine thumbnailers by using the TIOCSTI ioctl to push characters into the input buffer of the thumbnailer's controlling terminal, allowing an attacker to escape the sandbox if the thumbnailer has a controlling terminal. This is due to improper filtering of the TIOCSTI ioctl on 64-bit systems, similar to CVE-2019-10063.

A flaw was found in WebKitGTK. Processing malicious web content can cause an unexpected process crash due to improper state management.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/dp_mst: Fix resetting msg rx state after topology removal\n\nIf the MST topology is removed during the reception of an MST down reply\nor MST up request sideband message, the\ndrm_dp_mst_topology_mgr::up_req_recv/down_rep_recv states could be reset\nfrom one thread via drm_dp_mst_topology_mgr_set_mst(false), racing with\nthe reading/parsing of the message from another thread via\ndrm_dp_mst_handle_down_rep() or drm_dp_mst_handle_up_req(). The race is\npossible since the reader/parser doesn't hold any lock while accessing\nthe reception state. This in turn can lead to a memory corruption in the\nreader/parser as described by commit bd2fccac61b4 ("drm/dp_mst: Fix MST\nsideband message body length check").\n\nFix the above by resetting the message reception state if needed before\nreading/parsing a message. Another solution would be to hold the\ndrm_dp_mst_topology_mgr::lock for the whole duration of the message\nreception/parsing in drm_dp_mst_handle_down_rep() and\ndrm_dp_mst_handle_up_req(), however this would require a bigger change.\nSince the fix is also needed for stable, opting for the simpler solution\nin this patch.

A flaw was found in WebKitGTK. Processing malicious web content can cause memory corruption due to improper memory handling.

A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation.\n\nThe nft_setelem_catchall_deactivate() function checks whether the catch-all set element is active in the current generation instead of the next generation before freeing it, but only flags it inactive in the next generation, making it possible to free the element multiple times, leading to a double free vulnerability.\n\nWe recommend upgrading past commit b1db244ffd041a49ecc9618e8feb6b5c1afcdaa7.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm/slub: actually fix freelist pointer vs redzoning\n\nIt turns out that SLUB redzoning ("slub_debug=Z") checks from\ns->object_size rather than from s->inuse (which is normally bumped to\nmake room for the freelist pointer), so a cache created with an object\nsize less than 24 would have the freelist pointer written beyond\ns->object_size, causing the redzone to be corrupted by the freelist\npointer. This was very visible with "slub_debug=ZF":\n\n BUG test (Tainted: G B ): Right Redzone overwritten\n -----------------------------------------------------------------------------\n\n INFO: 0xffff957ead1c05de-0xffff957ead1c05df @offset=1502. First byte 0x1a instead of 0xbb\n INFO: Slab 0xffffef3950b47000 objects=170 used=170 fp=0x0000000000000000 flags=0x8000000000000200\n INFO: Object 0xffff957ead1c05d8 @offset=1496 fp=0xffff957ead1c0620\n\n Redzone (____ptrval____): bb bb bb bb bb bb bb bb ........\n Object (____ptrval____): 00 00 00 00 00 f6 f4 a5 ........\n Redzone (____ptrval____): 40 1d e8 1a aa @....\n Padding (____ptrval____): 00 00 00 00 00 00 00 00 ........\n\nAdjust the offset to stay within s->object_size.\n\n(Note that no caches of in this size range are known to exist in the\nkernel currently.)

Cross-site scripting (XSS) vulnerability in Mozilla Firefox before 3.6.24 and 4.x through 7 allows remote attackers to inject arbitrary web script or HTML via vectors involving HTTP 0.9 errors, non-default ports, and content-sniffing.

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdc-acm: Check control transfer buffer size before access\n\nIf the first fragment is shorter than struct usb_cdc_notification, we can't\ncalculate an expected_size. Log an error and discard the notification\ninstead of reading lengths from memory outside the received data, which can\nlead to memory corruption when the expected_size decreases between\nfragments, causing `expected_size - acm->nb_index` to wrap.\n\nThis issue has been present since the beginning of git history; however,\nit only leads to memory corruption since commit ea2583529cd1\n("cdc-acm: reassemble fragmented notifications").\n\nA mitigating factor is that acm_ctrl_irq() can only execute after userspace\nhas opened /dev/ttyACM*; but if ModemManager is running, ModemManager will\ndo that automatically depending on the USB device's vendor/product IDs and\nits other interfaces.

In the Linux kernel, the following vulnerability has been resolved:\n\ndm thin: make get_first_thin use rcu-safe list first function\n\nThe documentation in rculist.h explains the absence of list_empty_rcu()\nand cautions programmers against relying on a list_empty() ->\nlist_first() sequence in RCU safe code. This is because each of these\nfunctions performs its own READ_ONCE() of the list head. This can lead\nto a situation where the list_empty() sees a valid list entry, but the\nsubsequent list_first() sees a different view of list head state after a\nmodification.\n\nIn the case of dm-thin, this author had a production box crash from a GP\nfault in the process_deferred_bios path. This function saw a valid list\nhead in get_first_thin() but when it subsequently dereferenced that and\nturned it into a thin_c, it got the inside of the struct pool, since the\nlist was now empty and referring to itself. The kernel on which this\noccurred printed both a warning about a refcount_t being saturated, and\na UBSAN error for an out-of-bounds cpuid access in the queued spinlock,\nprior to the fault itself. When the resulting kdump was examined, it\nwas possible to see another thread patiently waiting in thin_dtr's\nsynchronize_rcu.\n\nThe thin_dtr call managed to pull the thin_c out of the active thins\nlist (and have it be the last entry in the active_thins list) at just\nthe wrong moment which lead to this crash.\n\nFortunately, the fix here is straight forward. Switch get_first_thin()\nfunction to use list_first_or_null_rcu() which performs just a single\nREAD_ONCE() and returns NULL if the list is already empty.\n\nThis was run against the devicemapper test suite's thin-provisioning\nsuites for delete and suspend and no regressions were observed.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: dwmac-tegra: Read iommu stream id from device tree\n\nNvidia's Tegra MGBE controllers require the IOMMU "Stream ID" (SID) to be\nwritten to the MGBE_WRAP_AXI_ASID0_CTRL register.\n\nThe current driver is hard coded to use MGBE0's SID for all controllers.\nThis causes softirq time outs and kernel panics when using controllers\nother than MGBE0.\n\nExample dmesg errors when an ethernet cable is connected to MGBE1:\n\n[ 116.133290] tegra-mgbe 6910000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx\n[ 121.851283] tegra-mgbe 6910000.ethernet eth1: NETDEV WATCHDOG: CPU: 5: transmit queue 0 timed out 5690 ms\n[ 121.851782] tegra-mgbe 6910000.ethernet eth1: Reset adapter.\n[ 121.892464] tegra-mgbe 6910000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-0\n[ 121.905920] tegra-mgbe 6910000.ethernet eth1: PHY [stmmac-1:00] driver [Aquantia AQR113] (irq=171)\n[ 121.907356] tegra-mgbe 6910000.ethernet eth1: Enabling Safety Features\n[ 121.907578] tegra-mgbe 6910000.ethernet eth1: IEEE 1588-2008 Advanced Timestamp supported\n[ 121.908399] tegra-mgbe 6910000.ethernet eth1: registered PTP clock\n[ 121.908582] tegra-mgbe 6910000.ethernet eth1: configuring for phy/10gbase-r link mode\n[ 125.961292] tegra-mgbe 6910000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx\n[ 181.921198] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:\n[ 181.921404] rcu: 7-....: (1 GPs behind) idle=540c/1/0x4000000000000002 softirq=1748/1749 fqs=2337\n[ 181.921684] rcu: (detected by 4, t=6002 jiffies, g=1357, q=1254 ncpus=8)\n[ 181.921878] Sending NMI from CPU 4 to CPUs 7:\n[ 181.921886] NMI backtrace for cpu 7\n[ 181.922131] CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Kdump: loaded Not tainted 6.13.0-rc3+ #6\n[ 181.922390] Hardware name: NVIDIA CTI Forge + Orin AGX/Jetson, BIOS 202402.1-Unknown 10/28/2024\n[ 181.922658] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 181.922847] pc : handle_softirqs+0x98/0x368\n[ 181.922978] lr : __do_softirq+0x18/0x20\n[ 181.923095] sp : ffff80008003bf50\n[ 181.923189] x29: ffff80008003bf50 x28: 0000000000000008 x27: 0000000000000000\n[ 181.923379] x26: ffffce78ea277000 x25: 0000000000000000 x24: 0000001c61befda0\n[ 181.924486] x23: 0000000060400009 x22: ffffce78e99918bc x21: ffff80008018bd70\n[ 181.925568] x20: ffffce78e8bb00d8 x19: ffff80008018bc20 x18: 0000000000000000\n[ 181.926655] x17: ffff318ebe7d3000 x16: ffff800080038000 x15: 0000000000000000\n[ 181.931455] x14: ffff000080816680 x13: ffff318ebe7d3000 x12: 000000003464d91d\n[ 181.938628] x11: 0000000000000040 x10: ffff000080165a70 x9 : ffffce78e8bb0160\n[ 181.945804] x8 : ffff8000827b3160 x7 : f9157b241586f343 x6 : eeb6502a01c81c74\n[ 181.953068] x5 : a4acfcdd2e8096bb x4 : ffffce78ea277340 x3 : 00000000ffffd1e1\n[ 181.960329] x2 : 0000000000000101 x1 : ffffce78ea277340 x0 : ffff318ebe7d3000\n[ 181.967591] Call trace:\n[ 181.970043] handle_softirqs+0x98/0x368 (P)\n[ 181.974240] __do_softirq+0x18/0x20\n[ 181.977743] ____do_softirq+0x14/0x28\n[ 181.981415] call_on_irq_stack+0x24/0x30\n[ 181.985180] do_softirq_own_stack+0x20/0x30\n[ 181.989379] __irq_exit_rcu+0x114/0x140\n[ 181.993142] irq_exit_rcu+0x14/0x28\n[ 181.996816] el1_interrupt+0x44/0xb8\n[ 182.000316] el1h_64_irq_handler+0x14/0x20\n[ 182.004343] el1h_64_irq+0x80/0x88\n[ 182.007755] cpuidle_enter_state+0xc4/0x4a8 (P)\n[ 182.012305] cpuidle_enter+0x3c/0x58\n[ 182.015980] cpuidle_idle_call+0x128/0x1c0\n[ 182.020005] do_idle+0xe0/0xf0\n[ 182.023155] cpu_startup_entry+0x3c/0x48\n[ 182.026917] secondary_start_kernel+0xdc/0x120\n[ 182.031379] __secondary_switched+0x74/0x78\n[ 212.971162] rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 7-.... } 6103 jiffies s: 417 root: 0x80/.\n[ 212.985935] rcu: blocking rcu_node structures (internal RCU debug):\n[ 212.992758] Sending NMI from CPU 0 to CPUs 7:\n[ 212.998539] NMI backtrace for cpu 7\n[ 213.004304] CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Kdump: loaded Not tainted 6.13.0-rc3+ #6\n[ 213.016116] Hardware name: NVIDIA CTI Forge + Orin AGX/Jetson, BIOS 202402.1-Unknown 10/28/2024\n[ 213.030817] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 213.040528] pc : handle_softirqs+0x98/0x368\n[ 213.046563] lr : __do_softirq+0x18/0x20\n[ 213.051293] sp : ffff80008003bf50\n[ 213.055839] x29: ffff80008003bf50 x28: 0000000000000008 x27: 0000000000000000\n[ 213.067304] x26: ffffce78ea277000 x25: 0000000000000000 x24: 0000001c61befda0\n[ 213.077014] x23: 0000000060400009 x22: ffffce78e99918bc x21: ffff80008018bd70\n[ 213.087339] x20: ffffce78e8bb00d8 x19: ffff80008018bc20 x18: 0000000000000000\n[ 213.097313] x17: ffff318ebe7d3000 x16: ffff800080038000 x15: 0000000000000000\n[ 213.107201] x14: ffff000080816680 x13: ffff318ebe7d3000 x12: 000000003464d91d\n[ 213.116651] x11: 0000000000000040 x10: ffff000080165a70 x9 : ffffce78e8bb0160\n[ 213.127500] x8 : ffff8000827b3160 x7 : 0a37b344852820af x6 : 3f049caedd1ff608\n[ 213.138002] x5 : cff7cfdbfaf31291 x4 : ffffce78ea277340 x3 : 00000000ffffde04\n[ 213.150428] x2 : 0000000000000101 x1 : ffffce78ea277340 x0 : ffff318ebe7d3000\n[ 213.162063] Call trace:\n[ 213.165494] handle_softirqs+0x98/0x368 (P)\n[ 213.171256] __do_softirq+0x18/0x20\n[ 213.177291] ____do_softirq+0x14/0x28\n[ 213.182017] call_on_irq_stack+0x24/0x30\n[ 213.186565] do_softirq_own_stack+0x20/0x30\n[ 213.191815] __irq_exit_rcu+0x114/0x140\n[ 213.196891] irq_exit_rcu+0x14/0x28\n[ 213.202401] el1_interrupt+0x44/0xb8\n[ 213.207741] el1h_64_irq_handler+0x14/0x20\n[ 213.213519] el1h_64_irq+0x80/0x88\n[ 213.217541] cpuidle_enter_state+0xc4/0x4a8 (P)\n[ 213.224364] cpuidle_enter+0x3c/0x58\n[ 213.228653] cpuidle_idle_call+0x128/0x1c0\n[ 213.233993] do_idle+0xe0/0xf0\n[ 213.237928] cpu_startup_entry+0x3c/0x48\n[ 213.243791] secondary_start_kernel+0xdc/0x120\n[ 213.249830] __secondary_switched+0x74/0x78\n\nThis bug has existed since the dwmac-tegra driver was added in Dec 2022\n(See Fixes tag below for commit hash).\n\nThe Tegra234 SOC has 4 MGBE controllers, however Nvidia's Developer Kit\nonly uses MGBE0 which is why the bug was not found previously. Connect Tech\nhas many products that use 2 (or more) MGBE controllers.\n\nThe solution is to read the controller's SID from the existing "iommus"\ndevice tree property. The 2nd field of the "iommus" device tree property\nis the controller's SID.\n\nDevice tree snippet from tegra234.dtsi showing MGBE1's "iommus" property:\n\nsmmu_niso0: iommu@12000000 {\n compatible = "nvidia,tegra234-smmu", "nvidia,smmu-500";\n...\n}\n\n/* MGBE1 */\nethernet@6900000 {\n compatible = "nvidia,tegra234-mgbe";\n...\n iommus = <&smmu_niso0 TEGRA234_SID_MGBE_VF1>;\n...\n}\n\nNvidia's arm-smmu driver reads the "iommus" property and stores the SID in\nthe MGBE device's "fwspec" struct. The dwmac-tegra driver can access the\nSID using the tegra_dev_iommu_get_stream_id() helper function found in\nlinux/iommu.h.\n\nCalling tegra_dev_iommu_get_stream_id() should not fail unless the "iommus"\nproperty is removed from the device tree or the IOMMU is disabled.\n\nWhile the Tegra234 SOC technically supports bypassing the IOMMU, it is not\nsupported by the current firmware, has not been tested and not recommended.\nMore detailed discussion with Thierry Reding from Nvidia linked below.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Fix variable not being completed when function returns\n\nWhen cmd_alloc_index(), fails cmd_work_handler() needs\nto complete ent->slotted before returning early.\nOtherwise the task which issued the command may hang:\n\n mlx5_core 0000:01:00.0: cmd_work_handler:877:(pid 3880418): failed to allocate command entry\n INFO: task kworker/13:2:4055883 blocked for more than 120 seconds.\n Not tainted 4.19.90-25.44.v2101.ky10.aarch64 #1\n "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.\n kworker/13:2 D 0 4055883 2 0x00000228\n Workqueue: events mlx5e_tx_dim_work [mlx5_core]\n Call trace:\n __switch_to+0xe8/0x150\n __schedule+0x2a8/0x9b8\n schedule+0x2c/0x88\n schedule_timeout+0x204/0x478\n wait_for_common+0x154/0x250\n wait_for_completion+0x28/0x38\n cmd_exec+0x7a0/0xa00 [mlx5_core]\n mlx5_cmd_exec+0x54/0x80 [mlx5_core]\n mlx5_core_modify_cq+0x6c/0x80 [mlx5_core]\n mlx5_core_modify_cq_moderation+0xa0/0xb8 [mlx5_core]\n mlx5e_tx_dim_work+0x54/0x68 [mlx5_core]\n process_one_work+0x1b0/0x448\n worker_thread+0x54/0x468\n kthread+0x134/0x138\n ret_from_fork+0x10/0x18

In the Linux kernel, the following vulnerability has been resolved:\n\ngpio: virtuser: fix missing lookup table cleanups\n\nWhen a virtuser device is created via configfs and the probe fails due\nto an incorrect lookup table, the table is not removed. This prevents\nsubsequent probe attempts from succeeding, even if the issue is\ncorrected, unless the device is released. Additionally, cleanup is also\nneeded in the less likely case of platform_device_register_full()\nfailure.\n\nBesides, a consistent memory leak in lookup_table->dev_id was spotted\nusing kmemleak by toggling the live state between 0 and 1 with a correct\nlookup table.\n\nIntroduce gpio_virtuser_remove_lookup_table() as the counterpart to the\nexisting gpio_virtuser_make_lookup_table() and call it from all\nnecessary points to ensure proper cleanup.

In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix unexpectedly changed path in ksmbd_vfs_kern_path_locked\n\nWhen `ksmbd_vfs_kern_path_locked` met an error and it is not the last\nentry, it will exit without restoring changed path buffer. But later this\nbuffer may be used as the filename for creation.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetdev: prevent accessing NAPI instances from another namespace\n\nThe NAPI IDs were not fully exposed to user space prior to the netlink\nAPI, so they were never namespaced. The netlink API must ensure that\nat the very least NAPI instance belongs to the same netns as the owner\nof the genl sock.\n\nnapi_by_id() can become static now, but it needs to move because of\ndev_get_by_napi_id().

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: avoid NULL pointer dereference if no valid extent tree\n\n[BUG]\nSyzbot reported a crash with the following call trace:\n\n BTRFS info (device loop0): scrub: started on devid 1\n BUG: kernel NULL pointer dereference, address: 0000000000000208\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 106e70067 P4D 106e70067 PUD 107143067 PMD 0\n Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI\n CPU: 1 UID: 0 PID: 689 Comm: repro Kdump: loaded Tainted: G O 6.13.0-rc4-custom+ #206\n Tainted: [O]=OOT_MODULE\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022\n RIP: 0010:find_first_extent_item+0x26/0x1f0 [btrfs]\n Call Trace:\n <TASK>\n scrub_find_fill_first_stripe+0x13d/0x3b0 [btrfs]\n scrub_simple_mirror+0x175/0x260 [btrfs]\n scrub_stripe+0x5d4/0x6c0 [btrfs]\n scrub_chunk+0xbb/0x170 [btrfs]\n scrub_enumerate_chunks+0x2f4/0x5f0 [btrfs]\n btrfs_scrub_dev+0x240/0x600 [btrfs]\n btrfs_ioctl+0x1dc8/0x2fa0 [btrfs]\n ? do_sys_openat2+0xa5/0xf0\n __x64_sys_ioctl+0x97/0xc0\n do_syscall_64+0x4f/0x120\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n </TASK>\n\n[CAUSE]\nThe reproducer is using a corrupted image where extent tree root is\ncorrupted, thus forcing to use "rescue=all,ro" mount option to mount the\nimage.\n\nThen it triggered a scrub, but since scrub relies on extent tree to find\nwhere the data/metadata extents are, scrub_find_fill_first_stripe()\nrelies on an non-empty extent root.\n\nBut unfortunately scrub_find_fill_first_stripe() doesn't really expect\nan NULL pointer for extent root, it use extent_root to grab fs_info and\ntriggered a NULL pointer dereference.\n\n[FIX]\nAdd an extra check for a valid extent root at the beginning of\nscrub_find_fill_first_stripe().\n\nThe new error path is introduced by 42437a6386ff ("btrfs: introduce\nmount option rescue=ignorebadroots"), but that's pretty old, and later\ncommit b979547513ff ("btrfs: scrub: introduce helper to find and fill\nsector info for a scrub_stripe") changed how we do scrub.\n\nSo for kernels older than 6.6, the fix will need manual backport.

In the Linux kernel, the following vulnerability has been resolved:\n\nsched_ext: Replace rq_lock() to raw_spin_rq_lock() in scx_ops_bypass()\n\nscx_ops_bypass() iterates all CPUs to re-enqueue all the scx tasks.\nFor each CPU, it acquires a lock using rq_lock() regardless of whether\na CPU is offline or the CPU is currently running a task in a higher\nscheduler class (e.g., deadline). The rq_lock() is supposed to be used\nfor online CPUs, and the use of rq_lock() may trigger an unnecessary\nwarning in rq_pin_lock(). Therefore, replace rq_lock() to\nraw_spin_rq_lock() in scx_ops_bypass().\n\nWithout this change, we observe the following warning:\n\n===== START =====\n[ 6.615205] rq->balance_callback && rq->balance_callback != &balance_push_callback\n[ 6.615208] WARNING: CPU: 2 PID: 0 at kernel/sched/sched.h:1730 __schedule+0x1130/0x1c90\n===== END =====

In the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (drivetemp) Fix driver producing garbage data when SCSI errors occur\n\nscsi_execute_cmd() function can return both negative (linux codes) and\npositive (scsi_cmnd result field) error codes.\n\nCurrently the driver just passes error codes of scsi_execute_cmd() to\nhwmon core, which is incorrect because hwmon only checks for negative\nerror codes. This leads to hwmon reporting uninitialized data to\nuserspace in case of SCSI errors (for example if the disk drive was\ndisconnected).\n\nThis patch checks scsi_execute_cmd() output and returns -EIO if it's\nerror code is positive.\n\n[groeck: Avoid inline variable declaration for portability]

In the Linux kernel, the following vulnerability has been resolved:\n\novl: support encoding fid from inode with no alias\n\nDmitry Safonov reported that a WARN_ON() assertion can be trigered by\nuserspace when calling inotify_show_fdinfo() for an overlayfs watched\ninode, whose dentry aliases were discarded with drop_caches.\n\nThe WARN_ON() assertion in inotify_show_fdinfo() was removed, because\nit is possible for encoding file handle to fail for other reason, but\nthe impact of failing to encode an overlayfs file handle goes beyond\nthis assertion.\n\nAs shown in the LTP test case mentioned in the link below, failure to\nencode an overlayfs file handle from a non-aliased inode also leads to\nfailure to report an fid with FAN_DELETE_SELF fanotify events.\n\nAs Dmitry notes in his analyzis of the problem, ovl_encode_fh() fails\nif it cannot find an alias for the inode, but this failure can be fixed.\novl_encode_fh() seldom uses the alias and in the case of non-decodable\nfile handles, as is often the case with fanotify fid info,\novl_encode_fh() never needs to use the alias to encode a file handle.\n\nDefer finding an alias until it is actually needed so ovl_encode_fh()\nwill not fail in the common case of FAN_DELETE_SELF fanotify events.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: cls_flow: validate TCA_FLOW_RSHIFT attribute\n\nsyzbot found that TCA_FLOW_RSHIFT attribute was not validated.\nRight shitfing a 32bit integer is undefined for large shift values.\n\nUBSAN: shift-out-of-bounds in net/sched/cls_flow.c:329:23\nshift exponent 9445 is too large for 32-bit type 'u32' (aka 'unsigned int')\nCPU: 1 UID: 0 PID: 54 Comm: kworker/u8:3 Not tainted 6.13.0-rc3-syzkaller-00180-g4f619d518db9 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nWorkqueue: ipv6_addrconf addrconf_dad_work\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n ubsan_epilogue lib/ubsan.c:231 [inline]\n __ubsan_handle_shift_out_of_bounds+0x3c8/0x420 lib/ubsan.c:468\n flow_classify+0x24d5/0x25b0 net/sched/cls_flow.c:329\n tc_classify include/net/tc_wrapper.h:197 [inline]\n __tcf_classify net/sched/cls_api.c:1771 [inline]\n tcf_classify+0x420/0x1160 net/sched/cls_api.c:1867\n sfb_classify net/sched/sch_sfb.c:260 [inline]\n sfb_enqueue+0x3ad/0x18b0 net/sched/sch_sfb.c:318\n dev_qdisc_enqueue+0x4b/0x290 net/core/dev.c:3793\n __dev_xmit_skb net/core/dev.c:3889 [inline]\n __dev_queue_xmit+0xf0e/0x3f50 net/core/dev.c:4400\n dev_queue_xmit include/linux/netdevice.h:3168 [inline]\n neigh_hh_output include/net/neighbour.h:523 [inline]\n neigh_output include/net/neighbour.h:537 [inline]\n ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236\n iptunnel_xmit+0x55d/0x9b0 net/ipv4/ip_tunnel_core.c:82\n udp_tunnel_xmit_skb+0x262/0x3b0 net/ipv4/udp_tunnel_core.c:173\n geneve_xmit_skb drivers/net/geneve.c:916 [inline]\n geneve_xmit+0x21dc/0x2d00 drivers/net/geneve.c:1039\n __netdev_start_xmit include/linux/netdevice.h:5002 [inline]\n netdev_start_xmit include/linux/netdevice.h:5011 [inline]\n xmit_one net/core/dev.c:3590 [inline]\n dev_hard_start_xmit+0x27a/0x7d0 net/core/dev.c:3606\n __dev_queue_xmit+0x1b73/0x3f50 net/core/dev.c:4434

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: fixed hclge_fetch_pf_reg accesses bar space out of bounds issue\n\nThe TQP BAR space is divided into two segments. TQPs 0-1023 and TQPs\n1024-1279 are in different BAR space addresses. However,\nhclge_fetch_pf_reg does not distinguish the tqp space information when\nreading the tqp space information. When the number of TQPs is greater\nthan 1024, access bar space overwriting occurs.\nThe problem of different segments has been considered during the\ninitialization of tqp.io_base. Therefore, tqp.io_base is directly used\nwhen the queue is read in hclge_fetch_pf_reg.\n\nThe error message:\n\nUnable to handle kernel paging request at virtual address ffff800037200000\npc : hclge_fetch_pf_reg+0x138/0x250 [hclge]\nlr : hclge_get_regs+0x84/0x1d0 [hclge]\nCall trace:\n hclge_fetch_pf_reg+0x138/0x250 [hclge]\n hclge_get_regs+0x84/0x1d0 [hclge]\n hns3_get_regs+0x2c/0x50 [hns3]\n ethtool_get_regs+0xf4/0x270\n dev_ethtool+0x674/0x8a0\n dev_ioctl+0x270/0x36c\n sock_do_ioctl+0x110/0x2a0\n sock_ioctl+0x2ac/0x530\n __arm64_sys_ioctl+0xa8/0x100\n invoke_syscall+0x4c/0x124\n el0_svc_common.constprop.0+0x140/0x15c\n do_el0_svc+0x30/0xd0\n el0_svc+0x1c/0x2c\n el0_sync_handler+0xb0/0xb4\n el0_sync+0x168/0x180

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: fix kernel crash when 1588 is sent on HIP08 devices\n\nCurrently, HIP08 devices does not register the ptp devices, so the\nhdev->ptp is NULL. But the tx process would still try to set hardware time\nstamp info with SKBTX_HW_TSTAMP flag and cause a kernel crash.\n\n[ 128.087798] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018\n...\n[ 128.280251] pc : hclge_ptp_set_tx_info+0x2c/0x140 [hclge]\n[ 128.286600] lr : hclge_ptp_set_tx_info+0x20/0x140 [hclge]\n[ 128.292938] sp : ffff800059b93140\n[ 128.297200] x29: ffff800059b93140 x28: 0000000000003280\n[ 128.303455] x27: ffff800020d48280 x26: ffff0cb9dc814080\n[ 128.309715] x25: ffff0cb9cde93fa0 x24: 0000000000000001\n[ 128.315969] x23: 0000000000000000 x22: 0000000000000194\n[ 128.322219] x21: ffff0cd94f986000 x20: 0000000000000000\n[ 128.328462] x19: ffff0cb9d2a166c0 x18: 0000000000000000\n[ 128.334698] x17: 0000000000000000 x16: ffffcf1fc523ed24\n[ 128.340934] x15: 0000ffffd530a518 x14: 0000000000000000\n[ 128.347162] x13: ffff0cd6bdb31310 x12: 0000000000000368\n[ 128.353388] x11: ffff0cb9cfbc7070 x10: ffff2cf55dd11e02\n[ 128.359606] x9 : ffffcf1f85a212b4 x8 : ffff0cd7cf27dab0\n[ 128.365831] x7 : 0000000000000a20 x6 : ffff0cd7cf27d000\n[ 128.372040] x5 : 0000000000000000 x4 : 000000000000ffff\n[ 128.378243] x3 : 0000000000000400 x2 : ffffcf1f85a21294\n[ 128.384437] x1 : ffff0cb9db520080 x0 : ffff0cb9db500080\n[ 128.390626] Call trace:\n[ 128.393964] hclge_ptp_set_tx_info+0x2c/0x140 [hclge]\n[ 128.399893] hns3_nic_net_xmit+0x39c/0x4c4 [hns3]\n[ 128.405468] xmit_one.constprop.0+0xc4/0x200\n[ 128.410600] dev_hard_start_xmit+0x54/0xf0\n[ 128.415556] sch_direct_xmit+0xe8/0x634\n[ 128.420246] __dev_queue_xmit+0x224/0xc70\n[ 128.425101] dev_queue_xmit+0x1c/0x40\n[ 128.429608] ovs_vport_send+0xac/0x1a0 [openvswitch]\n[ 128.435409] do_output+0x60/0x17c [openvswitch]\n[ 128.440770] do_execute_actions+0x898/0x8c4 [openvswitch]\n[ 128.446993] ovs_execute_actions+0x64/0xf0 [openvswitch]\n[ 128.453129] ovs_dp_process_packet+0xa0/0x224 [openvswitch]\n[ 128.459530] ovs_vport_receive+0x7c/0xfc [openvswitch]\n[ 128.465497] internal_dev_xmit+0x34/0xb0 [openvswitch]\n[ 128.471460] xmit_one.constprop.0+0xc4/0x200\n[ 128.476561] dev_hard_start_xmit+0x54/0xf0\n[ 128.481489] __dev_queue_xmit+0x968/0xc70\n[ 128.486330] dev_queue_xmit+0x1c/0x40\n[ 128.490856] ip_finish_output2+0x250/0x570\n[ 128.495810] __ip_finish_output+0x170/0x1e0\n[ 128.500832] ip_finish_output+0x3c/0xf0\n[ 128.505504] ip_output+0xbc/0x160\n[ 128.509654] ip_send_skb+0x58/0xd4\n[ 128.513892] udp_send_skb+0x12c/0x354\n[ 128.518387] udp_sendmsg+0x7a8/0x9c0\n[ 128.522793] inet_sendmsg+0x4c/0x8c\n[ 128.527116] __sock_sendmsg+0x48/0x80\n[ 128.531609] __sys_sendto+0x124/0x164\n[ 128.536099] __arm64_sys_sendto+0x30/0x5c\n[ 128.540935] invoke_syscall+0x50/0x130\n[ 128.545508] el0_svc_common.constprop.0+0x10c/0x124\n[ 128.551205] do_el0_svc+0x34/0xdc\n[ 128.555347] el0_svc+0x20/0x30\n[ 128.559227] el0_sync_handler+0xb8/0xc0\n[ 128.563883] el0_sync+0x160/0x180

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: conntrack: clamp maximum hashtable size to INT_MAX\n\nUse INT_MAX as maximum size for the conntrack hashtable. Otherwise, it\nis possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof() when\nresizing hashtable because __GFP_NOWARN is unset. See:\n\n 0708a0afe291 ("mm: Consider __GFP_NOWARN flag for oversized kvmalloc() calls")\n\nNote: hashtable resize is only possible from init_netns.

In the Linux kernel, the following vulnerability has been resolved:\n\nsched: sch_cake: add bounds checks to host bulk flow fairness counts\n\nEven though we fixed a logic error in the commit cited below, syzbot\nstill managed to trigger an underflow of the per-host bulk flow\ncounters, leading to an out of bounds memory access.\n\nTo avoid any such logic errors causing out of bounds memory accesses,\nthis commit factors out all accesses to the per-host bulk flow counters\nto a series of helpers that perform bounds-checking before any\nincrements and decrements. This also has the benefit of improving\nreadability by moving the conditional checks for the flow mode into\nthese helpers, instead of having them spread out throughout the\ncode (which was the cause of the original logic error).\n\nAs part of this change, the flow quantum calculation is consolidated\ninto a helper function, which means that the dithering applied to the\nost load scaling is now applied both in the DRR rotation and when a\nsparse flow's quantum is first initiated. The only user-visible effect\nof this is that the maximum packet size that can be sent while a flow\nstays sparse will now vary with +/- one byte in some cases. This should\nnot make a noticeable difference in practice, and thus it's not worth\ncomplicating the code to preserve the old behaviour.

In the Linux kernel, the following vulnerability has been resolved:\n\nafs: Fix the maximum cell name length\n\nThe kafs filesystem limits the maximum length of a cell to 256 bytes, but a\nproblem occurs if someone actually does that: kafs tries to create a\ndirectory under /proc/net/afs/ with the name of the cell, but that fails\nwith a warning:\n\n WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:405\n\nbecause procfs limits the maximum filename length to 255.\n\nHowever, the DNS limits the maximum lookup length and, by extension, the\nmaximum cell name, to 255 less two (length count and trailing NUL).\n\nFix this by limiting the maximum acceptable cellname length to 253. This\nalso allows us to be sure we can create the "/afs/.<cell>/" mountpoint too.\n\nFurther, split the YFS VL record cell name maximum to be the 256 allowed by\nthe protocol and ignore the record retrieved by YFSVL.GetCellName if it\nexceeds 253.

In the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86/amd/pmc: Only disable IRQ1 wakeup where i8042 actually enabled it\n\nWakeup for IRQ1 should be disabled only in cases where i8042 had\nactually enabled it, otherwise "wake_depth" for this IRQ will try to\ndrop below zero and there will be an unpleasant WARN() logged:\n\nkernel: atkbd serio0: Disabling IRQ1 wakeup source to avoid platform firmware bug\nkernel: ------------[ cut here ]------------\nkernel: Unbalanced IRQ 1 wake disable\nkernel: WARNING: CPU: 10 PID: 6431 at kernel/irq/manage.c:920 irq_set_irq_wake+0x147/0x1a0\n\nThe PMC driver uses DEFINE_SIMPLE_DEV_PM_OPS() to define its dev_pm_ops\nwhich sets amd_pmc_suspend_handler() to the .suspend, .freeze, and\n.poweroff handlers. i8042_pm_suspend(), however, is only set as\nthe .suspend handler.\n\nFix the issue by call PMC suspend handler only from the same set of\ndev_pm_ops handlers as i8042_pm_suspend(), which currently means just\nthe .suspend handler.\n\nTo reproduce this issue try hibernating (S4) the machine after a fresh boot\nwithout putting it into s2idle first.\n\n[ij: edited the commit message.]

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe: Fix tlb invalidation when wedging\n\nIf GuC fails to load, the driver wedges, but in the process it tries to\ndo stuff that may not be initialized yet. This moves the\nxe_gt_tlb_invalidation_init() to be done earlier: as its own doc says,\nit's a software-only initialization and should had been named with the\n_early() suffix.\n\nMove it to be called by xe_gt_init_early(), so the locks and seqno are\ninitialized, avoiding a NULL ptr deref when wedging:\n\n xe 0000:03:00.0: [drm] *ERROR* GT0: load failed: status: Reset = 0, BootROM = 0x50, UKernel = 0x00, MIA = 0x00, Auth = 0x01\n xe 0000:03:00.0: [drm] *ERROR* GT0: firmware signature verification failed\n xe 0000:03:00.0: [drm] *ERROR* CRITICAL: Xe has declared device 0000:03:00.0 as wedged.\n ...\n BUG: kernel NULL pointer dereference, address: 0000000000000000\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI\n CPU: 9 UID: 0 PID: 3908 Comm: modprobe Tainted: G U W 6.13.0-rc4-xe+ #3\n Tainted: [U]=USER, [W]=WARN\n Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-S ADP-S DDR5 UDIMM CRB, BIOS ADLSFWI1.R00.3275.A00.2207010640 07/01/2022\n RIP: 0010:xe_gt_tlb_invalidation_reset+0x75/0x110 [xe]\n\nThis can be easily triggered by poking the GuC binary to force a\nsignature failure. There will still be an extra message,\n\n xe 0000:03:00.0: [drm] *ERROR* GT0: GuC mmio request 0x4100: no reply 0x4100\n\nbut that's better than a NULL ptr deref.\n\n(cherry picked from commit 5001ef3af8f2c972d6fd9c5221a8457556f8bea6)

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: Fix kernel async DIO\n\nNetfslib needs to be able to handle kernel-initiated asynchronous DIO that\nis supplied with a bio_vec[] array. Currently, because of the async flag,\nthis gets passed to netfs_extract_user_iter() which throws a warning and\nfails because it only handles IOVEC and UBUF iterators. This can be\ntriggered through a combination of cifs and a loopback blockdev with\nsomething like:\n\n mount //my/cifs/share /foo\n dd if=/dev/zero of=/foo/m0 bs=4K count=1K\n losetup --sector-size 4096 --direct-io=on /dev/loop2046 /foo/m0\n echo hello >/dev/loop2046\n\nThis causes the following to appear in syslog:\n\n WARNING: CPU: 2 PID: 109 at fs/netfs/iterator.c:50 netfs_extract_user_iter+0x170/0x250 [netfs]\n\nand the write to fail.\n\nFix this by removing the check in netfs_unbuffered_write_iter_locked() that\ncauses async kernel DIO writes to be handled as userspace writes. Note\nthat this change relies on the kernel caller maintaining the existence of\nthe bio_vec array (or kvec[] or folio_queue) until the op is complete.

In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: sysctl: sched: avoid using current->nsproxy\n\nUsing the 'net' structure via 'current' is not recommended for different\nreasons.\n\nFirst, if the goal is to use it to read or write per-netns data, this is\ninconsistent with how the "generic" sysctl entries are doing: directly\nby only using pointers set to the table entry, e.g. table->data. Linked\nto that, the per-netns data should always be obtained from the table\nlinked to the netns it had been created for, which may not coincide with\nthe reader's or writer's netns.\n\nAnother reason is that access to current->nsproxy->netns can oops if\nattempted when current->nsproxy had been dropped when the current task\nis exiting. This is what syzbot found, when using acct(2):\n\n Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN PTI\n KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]\n CPU: 1 UID: 0 PID: 5924 Comm: syz-executor Not tainted 6.13.0-rc5-syzkaller-00004-gccb98ccef0e5 #0\n Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\n RIP: 0010:proc_scheduler+0xc6/0x3c0 net/mptcp/ctrl.c:125\n Code: 03 42 80 3c 38 00 0f 85 fe 02 00 00 4d 8b a4 24 08 09 00 00 48 b8 00 00 00 00 00 fc ff df 49 8d 7c 24 28 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 cc 02 00 00 4d 8b 7c 24 28 48 8d 84 24 c8 00 00\n RSP: 0018:ffffc900034774e8 EFLAGS: 00010206\n\n RAX: dffffc0000000000 RBX: 1ffff9200068ee9e RCX: ffffc90003477620\n RDX: 0000000000000005 RSI: ffffffff8b08f91e RDI: 0000000000000028\n RBP: 0000000000000001 R08: ffffc90003477710 R09: 0000000000000040\n R10: 0000000000000040 R11: 00000000726f7475 R12: 0000000000000000\n R13: ffffc90003477620 R14: ffffc90003477710 R15: dffffc0000000000\n FS: 0000000000000000(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007fee3cd452d8 CR3: 000000007d116000 CR4: 00000000003526f0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n <TASK>\n proc_sys_call_handler+0x403/0x5d0 fs/proc/proc_sysctl.c:601\n __kernel_write_iter+0x318/0xa80 fs/read_write.c:612\n __kernel_write+0xf6/0x140 fs/read_write.c:632\n do_acct_process+0xcb0/0x14a0 kernel/acct.c:539\n acct_pin_kill+0x2d/0x100 kernel/acct.c:192\n pin_kill+0x194/0x7c0 fs/fs_pin.c:44\n mnt_pin_kill+0x61/0x1e0 fs/fs_pin.c:81\n cleanup_mnt+0x3ac/0x450 fs/namespace.c:1366\n task_work_run+0x14e/0x250 kernel/task_work.c:239\n exit_task_work include/linux/task_work.h:43 [inline]\n do_exit+0xad8/0x2d70 kernel/exit.c:938\n do_group_exit+0xd3/0x2a0 kernel/exit.c:1087\n get_signal+0x2576/0x2610 kernel/signal.c:3017\n arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337\n exit_to_user_mode_loop kernel/entry/common.c:111 [inline]\n exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline]\n __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]\n syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218\n do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n RIP: 0033:0x7fee3cb87a6a\n Code: Unable to access opcode bytes at 0x7fee3cb87a40.\n RSP: 002b:00007fffcccac688 EFLAGS: 00000202 ORIG_RAX: 0000000000000037\n RAX: 0000000000000000 RBX: 00007fffcccac710 RCX: 00007fee3cb87a6a\n RDX: 0000000000000041 RSI: 0000000000000000 RDI: 0000000000000003\n RBP: 0000000000000003 R08: 00007fffcccac6ac R09: 00007fffcccacac7\n R10: 00007fffcccac710 R11: 0000000000000202 R12: 00007fee3cd49500\n R13: 00007fffcccac6ac R14: 0000000000000000 R15: 00007fee3cd4b000\n </TASK>\n Modules linked in:\n ---[ end trace 0000000000000000 ]---\n RIP: 0010:proc_scheduler+0xc6/0x3c0 net/mptcp/ctrl.c:125\n Code: 03 42 80 3c 38 00 0f 85 fe 02 00 00 4d 8b a4 24 08 09 00 00 48 b8 00 00 00 00 00 fc ff df 49 8d 7c 24 28 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 cc 02 00 00 4d 8b 7c 24 28 48 8d 84 24 c8 00 00\n RSP: 0018:ffffc900034774e8 EFLAGS: 00010206\n RAX: dffffc0000000000 RBX: 1ffff9200068ee9e RCX: ffffc90003477620\n RDX: 0000000000000005 RSI: ffffffff8b08f91e RDI: 0000000000000028\n RBP: 0000000000000001 R08: ffffc90003477710 R09: 0000000000000040\n R10: 0000000000000040 R11: 00000000726f7475 R12: 0000000000000000\n R13: ffffc90003477620 R14: ffffc90003477710 R15: dffffc0000000000\n FS: 0000000000000000(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007fee3cd452d8 CR3: 000000007d116000 CR4: 00000000003526f0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n ----------------\n Code disassembly (best guess), 1 bytes skipped:\n 0: 42 80 3c 38 00 cmpb $0x0,(%rax,%r15,1)\n 5: 0f 85 fe 02 00 00 jne 0x309\n b: 4d 8b a4 24 08 09 00 mov 0x908(%r12),%r12\n 12: 00\n 13: 48 b8 00 00 00 00 00 movabs $0xdffffc0000000000,%rax\n 1a: fc ff df\n 1d: 49 8d 7c 24 28 lea 0x28(%r12),%rdi\n 22: 48 89 fa mov %rdi,%rdx\n 25: 48 c1 ea 03 shr $0x3,%rdx\n * 29: 80 3c 02 00 cmpb $0x0,(%rdx,%rax,1) <-- trapping instruction\n 2d: 0f 85 cc 02 00 00 jne 0x2ff\n 33: 4d 8b 7c 24 28 mov 0x28(%r12),%r15\n 38: 48 rex.W\n 39: 8d .byte 0x8d\n 3a: 84 24 c8 test %ah,(%rax,%rcx,8)\n\nHere with 'net.mptcp.scheduler', the 'net' structure is not really\nneeded, because the table->data already has a pointer to the current\nscheduler, the only thing needed from the per-netns data.\nSimply use 'data', instead of getting (most of the time) the same thing,\nbut from a longer and indirect way.

In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: sysctl: blackhole timeout: avoid using current->nsproxy\n\nAs mentioned in the previous commit, using the 'net' structure via\n'current' is not recommended for different reasons:\n\n- Inconsistency: getting info from the reader's/writer's netns vs only\n from the opener's netns.\n\n- current->nsproxy can be NULL in some cases, resulting in an 'Oops'\n (null-ptr-deref), e.g. when the current task is exiting, as spotted by\n syzbot [1] using acct(2).\n\nThe 'pernet' structure can be obtained from the table->data using\ncontainer_of().

In the Linux kernel, the following vulnerability has been resolved:\n\nx86/fpu: Ensure shadow stack is active before "getting" registers\n\nThe x86 shadow stack support has its own set of registers. Those registers\nare XSAVE-managed, but they are "supervisor state components" which means\nthat userspace can not touch them with XSAVE/XRSTOR. It also means that\nthey are not accessible from the existing ptrace ABI for XSAVE state.\nThus, there is a new ptrace get/set interface for it.\n\nThe regset code that ptrace uses provides an ->active() handler in\naddition to the get/set ones. For shadow stack this ->active() handler\nverifies that shadow stack is enabled via the ARCH_SHSTK_SHSTK bit in the\nthread struct. The ->active() handler is checked from some call sites of\nthe regset get/set handlers, but not the ptrace ones. This was not\nunderstood when shadow stack support was put in place.\n\nAs a result, both the set/get handlers can be called with\nXFEATURE_CET_USER in its init state, which would cause get_xsave_addr() to\nreturn NULL and trigger a WARN_ON(). The ssp_set() handler luckily has an\nssp_active() check to avoid surprising the kernel with shadow stack\nbehavior when the kernel is not ready for it (ARCH_SHSTK_SHSTK==0). That\ncheck just happened to avoid the warning.\n\nBut the ->get() side wasn't so lucky. It can be called with shadow stacks\ndisabled, triggering the warning in practice, as reported by Christina\nSchimpe:\n\nWARNING: CPU: 5 PID: 1773 at arch/x86/kernel/fpu/regset.c:198 ssp_get+0x89/0xa0\n[...]\nCall Trace:\n<TASK>\n? show_regs+0x6e/0x80\n? ssp_get+0x89/0xa0\n? __warn+0x91/0x150\n? ssp_get+0x89/0xa0\n? report_bug+0x19d/0x1b0\n? handle_bug+0x46/0x80\n? exc_invalid_op+0x1d/0x80\n? asm_exc_invalid_op+0x1f/0x30\n? __pfx_ssp_get+0x10/0x10\n? ssp_get+0x89/0xa0\n? ssp_get+0x52/0xa0\n__regset_get+0xad/0xf0\ncopy_regset_to_user+0x52/0xc0\nptrace_regset+0x119/0x140\nptrace_request+0x13c/0x850\n? wait_task_inactive+0x142/0x1d0\n? do_syscall_64+0x6d/0x90\narch_ptrace+0x102/0x300\n[...]\n\nEnsure that shadow stacks are active in a thread before looking them up\nin the XSAVE buffer. Since ARCH_SHSTK_SHSTK and user_ssp[SHSTK_EN] are\nset at the same time, the active check ensures that there will be\nsomething to find in the XSAVE buffer.\n\n[ dhansen: changelog/subject tweaks ]

In the Linux kernel, the following vulnerability has been resolved:\n\nblock, bfq: fix waker_bfqq UAF after bfq_split_bfqq()\n\nOur syzkaller report a following UAF for v6.6:\n\nBUG: KASAN: slab-use-after-free in bfq_init_rq+0x175d/0x17a0 block/bfq-iosched.c:6958\nRead of size 8 at addr ffff8881b57147d8 by task fsstress/232726\n\nCPU: 2 PID: 232726 Comm: fsstress Not tainted 6.6.0-g3629d1885222 #39\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106\n print_address_description.constprop.0+0x66/0x300 mm/kasan/report.c:364\n print_report+0x3e/0x70 mm/kasan/report.c:475\n kasan_report+0xb8/0xf0 mm/kasan/report.c:588\n hlist_add_head include/linux/list.h:1023 [inline]\n bfq_init_rq+0x175d/0x17a0 block/bfq-iosched.c:6958\n bfq_insert_request.isra.0+0xe8/0xa20 block/bfq-iosched.c:6271\n bfq_insert_requests+0x27f/0x390 block/bfq-iosched.c:6323\n blk_mq_insert_request+0x290/0x8f0 block/blk-mq.c:2660\n blk_mq_submit_bio+0x1021/0x15e0 block/blk-mq.c:3143\n __submit_bio+0xa0/0x6b0 block/blk-core.c:639\n __submit_bio_noacct_mq block/blk-core.c:718 [inline]\n submit_bio_noacct_nocheck+0x5b7/0x810 block/blk-core.c:747\n submit_bio_noacct+0xca0/0x1990 block/blk-core.c:847\n __ext4_read_bh fs/ext4/super.c:205 [inline]\n ext4_read_bh+0x15e/0x2e0 fs/ext4/super.c:230\n __read_extent_tree_block+0x304/0x6f0 fs/ext4/extents.c:567\n ext4_find_extent+0x479/0xd20 fs/ext4/extents.c:947\n ext4_ext_map_blocks+0x1a3/0x2680 fs/ext4/extents.c:4182\n ext4_map_blocks+0x929/0x15a0 fs/ext4/inode.c:660\n ext4_iomap_begin_report+0x298/0x480 fs/ext4/inode.c:3569\n iomap_iter+0x3dd/0x1010 fs/iomap/iter.c:91\n iomap_fiemap+0x1f4/0x360 fs/iomap/fiemap.c:80\n ext4_fiemap+0x181/0x210 fs/ext4/extents.c:5051\n ioctl_fiemap.isra.0+0x1b4/0x290 fs/ioctl.c:220\n do_vfs_ioctl+0x31c/0x11a0 fs/ioctl.c:811\n __do_sys_ioctl fs/ioctl.c:869 [inline]\n __se_sys_ioctl+0xae/0x190 fs/ioctl.c:857\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x70/0x120 arch/x86/entry/common.c:81\n entry_SYSCALL_64_after_hwframe+0x78/0xe2\n\nAllocated by task 232719:\n kasan_save_stack+0x22/0x50 mm/kasan/common.c:45\n kasan_set_track+0x25/0x30 mm/kasan/common.c:52\n __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328\n kasan_slab_alloc include/linux/kasan.h:188 [inline]\n slab_post_alloc_hook mm/slab.h:768 [inline]\n slab_alloc_node mm/slub.c:3492 [inline]\n kmem_cache_alloc_node+0x1b8/0x6f0 mm/slub.c:3537\n bfq_get_queue+0x215/0x1f00 block/bfq-iosched.c:5869\n bfq_get_bfqq_handle_split+0x167/0x5f0 block/bfq-iosched.c:6776\n bfq_init_rq+0x13a4/0x17a0 block/bfq-iosched.c:6938\n bfq_insert_request.isra.0+0xe8/0xa20 block/bfq-iosched.c:6271\n bfq_insert_requests+0x27f/0x390 block/bfq-iosched.c:6323\n blk_mq_insert_request+0x290/0x8f0 block/blk-mq.c:2660\n blk_mq_submit_bio+0x1021/0x15e0 block/blk-mq.c:3143\n __submit_bio+0xa0/0x6b0 block/blk-core.c:639\n __submit_bio_noacct_mq block/blk-core.c:718 [inline]\n submit_bio_noacct_nocheck+0x5b7/0x810 block/blk-core.c:747\n submit_bio_noacct+0xca0/0x1990 block/blk-core.c:847\n __ext4_read_bh fs/ext4/super.c:205 [inline]\n ext4_read_bh_nowait+0x15a/0x240 fs/ext4/super.c:217\n ext4_read_bh_lock+0xac/0xd0 fs/ext4/super.c:242\n ext4_bread_batch+0x268/0x500 fs/ext4/inode.c:958\n __ext4_find_entry+0x448/0x10f0 fs/ext4/namei.c:1671\n ext4_lookup_entry fs/ext4/namei.c:1774 [inline]\n ext4_lookup.part.0+0x359/0x6f0 fs/ext4/namei.c:1842\n ext4_lookup+0x72/0x90 fs/ext4/namei.c:1839\n __lookup_slow+0x257/0x480 fs/namei.c:1696\n lookup_slow fs/namei.c:1713 [inline]\n walk_component+0x454/0x5c0 fs/namei.c:2004\n link_path_walk.part.0+0x773/0xda0 fs/namei.c:2331\n link_path_walk fs/namei.c:3826 [inline]\n path_openat+0x1b9/0x520 fs/namei.c:3826\n do_filp_open+0x1b7/0x400 fs/namei.c:3857\n do_sys_openat2+0x5dc/0x6e0 fs/open.c:1428\n do_sys_open fs/open.c:1443 [inline]\n __do_sys_openat fs/open.c:1459 [inline]\n __se_sys_openat fs/open.c:1454 [inline]\n __x64_sys_openat+0x148/0x200 fs/open.c:1454\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x70/0x120 arch/x86/entry/common.c:81\n entry_SYSCALL_64_after_hwframe+0x78/0xe2\n\nFreed by task 232726:\n kasan_save_stack+0x22/0x50 mm/kasan/common.c:45\n kasan_set_track+0x25/0x30 mm/kasan/common.c:52\n kasan_save_free_info+0x2b/0x50 mm/kasan/generic.c:522\n ____kasan_slab_free mm/kasan/common.c:236 [inline]\n __kasan_slab_free+0x12a/0x1b0 mm/kasan/common.c:244\n kasan_slab_free include/linux/kasan.h:164 [inline]\n slab_free_hook mm/slub.c:1827 [inline]\n slab_free_freelist_hook mm/slub.c:1853 [inline]\n slab_free mm/slub.c:3820 [inline]\n kmem_cache_free+0x110/0x760 mm/slub.c:3842\n bfq_put_queue+0x6a7/0xfb0 block/bfq-iosched.c:5428\n bfq_forget_entity block/bfq-wf2q.c:634 [inline]\n bfq_put_idle_entity+0x142/0x240 block/bfq-wf2q.c:645\n bfq_forget_idle+0x189/0x1e0 block/bfq-wf2q.c:671\n bfq_update_vtime block/bfq-wf2q.c:1280 [inline]\n __bfq_lookup_next_entity block/bfq-wf2q.c:1374 [inline]\n bfq_lookup_next_entity+0x350/0x480 block/bfq-wf2q.c:1433\n bfq_update_next_in_service+0x1c0/0x4f0 block/bfq-wf2q.c:128\n bfq_deactivate_entity+0x10a/0x240 block/bfq-wf2q.c:1188\n bfq_deactivate_bfqq block/bfq-wf2q.c:1592 [inline]\n bfq_del_bfqq_busy+0x2e8/0xad0 block/bfq-wf2q.c:1659\n bfq_release_process_ref+0x1cc/0x220 block/bfq-iosched.c:3139\n bfq_split_bfqq+0x481/0xdf0 block/bfq-iosched.c:6754\n bfq_init_rq+0xf29/0x17a0 block/bfq-iosched.c:6934\n bfq_insert_request.isra.0+0xe8/0xa20 block/bfq-iosched.c:6271\n bfq_insert_requests+0x27f/0x390 block/bfq-iosched.c:6323\n blk_mq_insert_request+0x290/0x8f0 block/blk-mq.c:2660\n blk_mq_submit_bio+0x1021/0x15e0 block/blk-mq.c:3143\n __submit_bio+0xa0/0x6b0 block/blk-core.c:639\n __submit_bio_noacct_mq block/blk-core.c:718 [inline]\n submit_bio_noacct_nocheck+0x5b7/0x810 block/blk-core.c:747\n submit_bio_noacct+0xca0/0x1990 block/blk-core.c:847\n __ext4_read_bh fs/ext4/super.c:205 [inline]\n ext4_read_bh+0x15e/0x2e0 fs/ext4/super.c:230\n __read_extent_tree_block+0x304/0x6f0 fs/ext4/extents.c:567\n ext4_find_extent+0x479/0xd20 fs/ext4/extents.c:947\n ext4_ext_map_blocks+0x1a3/0x2680 fs/ext4/extents.c:4182\n ext4_map_blocks+0x929/0x15a0 fs/ext4/inode.c:660\n ext4_iomap_begin_report+0x298/0x480 fs/ext4/inode.c:3569\n iomap_iter+0x3dd/0x1010 fs/iomap/iter.c:91\n iomap_fiemap+0x1f4/0x360 fs/iomap/fiemap.c:80\n ext4_fiemap+0x181/0x210 fs/ext4/extents.c:5051\n ioctl_fiemap.isra.0+0x1b4/0x290 fs/ioctl.c:220\n do_vfs_ioctl+0x31c/0x11a0 fs/ioctl.c:811\n __do_sys_ioctl fs/ioctl.c:869 [inline]\n __se_sys_ioctl+0xae/0x190 fs/ioctl.c:857\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x70/0x120 arch/x86/entry/common.c:81\n entry_SYSCALL_64_after_hwframe+0x78/0xe2\n\ncommit 1ba0403ac644 ("block, bfq: fix uaf for accessing waker_bfqq after\nsplitting") fix the problem that if waker_bfqq is in the merge chain,\nand current is the only procress, waker_bfqq can be freed from\nbfq_split_bfqq(). However, the case that waker_bfqq is not in the merge\nchain is missed, and if the procress reference of waker_bfqq is 0,\nwaker_bfqq can be freed as well.\n\nFix the problem by checking procress reference if waker_bfqq is not in\nthe merge_chain.

A command injection flaw was found in the text editor Emacs. It could allow a remote, unauthenticated attacker to execute arbitrary shell commands on a vulnerable system. Exploitation is possible by tricking users into visiting a specially crafted website or an HTTP URL with a redirect.

In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio-blk: don't keep queue frozen during system suspend\n\nCommit 4ce6e2db00de ("virtio-blk: Ensure no requests in virtqueues before\ndeleting vqs.") replaces queue quiesce with queue freeze in virtio-blk's\nPM callbacks. And the motivation is to drain inflight IOs before suspending.\n\nblock layer's queue freeze looks very handy, but it is also easy to cause\ndeadlock, such as, any attempt to call into bio_queue_enter() may run into\ndeadlock if the queue is frozen in current context. There are all kinds\nof ->suspend() called in suspend context, so keeping queue frozen in the\nwhole suspend context isn't one good idea. And Marek reported lockdep\nwarning[1] caused by virtio-blk's freeze queue in virtblk_freeze().\n\n[1] https://lore.kernel.org/linux-block/ca16370e-d646-4eee-b9cc-87277c89c43c@samsung.com/\n\nGiven the motivation is to drain in-flight IOs, it can be done by calling\nfreeze & unfreeze, meantime restore to previous behavior by keeping queue\nquiesced during suspend.

In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: mm: Fix the out of bound issue of vmemmap address\n\nIn sparse vmemmap model, the virtual address of vmemmap is calculated as:\n((struct page *)VMEMMAP_START - (phys_ram_base >> PAGE_SHIFT)).\nAnd the struct page's va can be calculated with an offset:\n(vmemmap + (pfn)).\n\nHowever, when initializing struct pages, kernel actually starts from the\nfirst page from the same section that phys_ram_base belongs to. If the\nfirst page's physical address is not (phys_ram_base >> PAGE_SHIFT), then\nwe get an va below VMEMMAP_START when calculating va for it's struct page.\n\nFor example, if phys_ram_base starts from 0x82000000 with pfn 0x82000, the\nfirst page in the same section is actually pfn 0x80000. During\ninit_unavailable_range(), we will initialize struct page for pfn 0x80000\nwith virtual address ((struct page *)VMEMMAP_START - 0x2000), which is\nbelow VMEMMAP_START as well as PCI_IO_END.\n\nThis commit fixes this bug by introducing a new variable\n'vmemmap_start_pfn' which is aligned with memory section size and using\nit to calculate vmemmap address instead of phys_ram_base.

In the Linux kernel, the following vulnerability has been resolved:\n\niio: adc: ti-ads1298: Add NULL check in ads1298_init\n\ndevm_kasprintf() can return a NULL pointer on failure. A check on the\nreturn value of such a call in ads1298_init() is missing. Add it.

In the Linux kernel, the following vulnerability has been resolved:\n\nexfat: fix the new buffer was not zeroed before writing\n\nBefore writing, if a buffer_head marked as new, its data must\nbe zeroed, otherwise uninitialized data in the page cache will\nbe written.\n\nSo this commit uses folio_zero_new_buffers() to zero the new\nbuffers before ->write_end().

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: Fix ceph copy to cache on write-begin\n\nAt the end of netfs_unlock_read_folio() in which folios are marked\nappropriately for copying to the cache (either with by being marked dirty\nand having their private data set or by having PG_private_2 set) and then\nunlocked, the folio_queue struct has the entry pointing to the folio\ncleared. This presents a problem for netfs_pgpriv2_write_to_the_cache(),\nwhich is used to write folios marked with PG_private_2 to the cache as it\nexpects to be able to trawl the folio_queue list thereafter to find the\nrelevant folios, leading to a hang.\n\nFix this by not clearing the folio_queue entry if we're going to do the\ndeprecated copy-to-cache. The clearance will be done instead as the folios\nare written to the cache.\n\nThis can be reproduced by starting cachefiles, mounting a ceph filesystem\nwith "-o fsc" and writing to it.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: Fix the (non-)cancellation of copy when cache is temporarily disabled\n\nWhen the caching for a cookie is temporarily disabled (e.g. due to a DIO\nwrite on that file), future copying to the cache for that file is disabled\nuntil all fds open on that file are closed. However, if netfslib is using\nthe deprecated PG_private_2 method (such as is currently used by ceph), and\ndecides it wants to copy to the cache, netfs_advance_write() will just bail\nat the first check seeing that the cache stream is unavailable, and\nindicate that it dealt with all the content.\n\nThis means that we have no subrequests to provide notifications to drive\nthe state machine or even to pin the request and the request just gets\ndiscarded, leaving the folios with PG_private_2 set.\n\nFix this by jumping directly to cancel the request if the cache is not\navailable. That way, we don't remove mark3 from the folio_queue list and\nnetfs_pgpriv2_cancel() will clean up the folios.\n\nThis was found by running the generic/013 xfstest against ceph with an\nactive cache and the "-o fsc" option passed to ceph. That would usually\nhang

In the Linux kernel, the following vulnerability has been resolved:\n\nexfat: fix the infinite loop in exfat_readdir()\n\nIf the file system is corrupted so that a cluster is linked to\nitself in the cluster chain, and there is an unused directory\nentry in the cluster, 'dentry' will not be incremented, causing\ncondition 'dentry < max_dentries' unable to prevent an infinite\nloop.\n\nThis infinite loop causes s_lock not to be released, and other\ntasks will hang, such as exfat_sync_fs().\n\nThis commit stops traversing the cluster chain when there is unused\ndirectory entry in the cluster to avoid this infinite loop.

In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: Fix sleeping in invalid context in die()\n\ndie() can be called in exception handler, and therefore cannot sleep.\nHowever, die() takes spinlock_t which can sleep with PREEMPT_RT enabled.\nThat causes the following warning:\n\nBUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\nin_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 285, name: mutex\npreempt_count: 110001, expected: 0\nRCU nest depth: 0, expected: 0\nCPU: 0 UID: 0 PID: 285 Comm: mutex Not tainted 6.12.0-rc7-00022-ge19049cf7d56-dirty #234\nHardware name: riscv-virtio,qemu (DT)\nCall Trace:\n dump_backtrace+0x1c/0x24\n show_stack+0x2c/0x38\n dump_stack_lvl+0x5a/0x72\n dump_stack+0x14/0x1c\n __might_resched+0x130/0x13a\n rt_spin_lock+0x2a/0x5c\n die+0x24/0x112\n do_trap_insn_illegal+0xa0/0xea\n _new_vmalloc_restore_context_a0+0xcc/0xd8\nOops - illegal instruction [#1]\n\nSwitch to use raw_spinlock_t, which does not sleep even with PREEMPT_RT\nenabled.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sctp: Prevent autoclose integer overflow in sctp_association_init()\n\nWhile by default max_autoclose equals to INT_MAX / HZ, one may set\nnet.sctp.max_autoclose to UINT_MAX. There is code in\nsctp_association_init() that can consequently trigger overflow.

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/bnxt_re: Fix max SGEs for the Work Request\n\nGen P7 supports up to 13 SGEs for now. WQE software structure\ncan hold only 6 now. Since the max send sge is reported as\n13, the stack can give requests up to 13 SGEs. This is causing\ntraffic failures and system crashes.\n\nUse the define for max SGE supported for variable size. This\nwill work for both static and variable WQEs.

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/hns: Fix accessing invalid dip_ctx during destroying QP\n\nIf it fails to modify QP to RTR, dip_ctx will not be attached. And\nduring detroying QP, the invalid dip_ctx pointer will be accessed.