An issue was discovered in QEMU 7.1.0 through 8.2.1. register_vfs in hw/pci/pcie_sriov.c mishandles the situation where a guest writes NumVFs greater than TotalVFs, leading to a buffer overflow in VF implementations.

An attacker could have leveraged the Windows Error Reporter to run arbitrary code on the system escaping the sandbox. *Note:* This issue only affected Windows operating systems. Other operating systems are unaffected. This vulnerability affects Firefox < 124, Firefox ESR < 115.9, and Thunderbird < 115.9.

libuv is a multi-platform support library with a focus on asynchronous I/O. The `uv_getaddrinfo` function in `src/unix/getaddrinfo.c` (and its windows counterpart `src/win/getaddrinfo.c`), truncates hostnames to 256 characters before calling `getaddrinfo`. This behavior can be exploited to create addresses like `0x00007f000001`, which are considered valid by `getaddrinfo` and could allow an attacker to craft payloads that resolve to unintended IP addresses, bypassing developer checks. The vulnerability arises due to how the `hostname_ascii` variable (with a length of 256 bytes) is handled in `uv_getaddrinfo` and subsequently in `uv__idna_toascii`. When the hostname exceeds 256 characters, it gets truncated without a terminating null byte. As a result attackers may be able to access internal APIs or for websites (similar to MySpace) that allows users to have `username.example.com` pages. Internal services that crawl or cache these user pages can be exposed to SSRF attacks if a malicious user chooses a long vulnerable username. This issue has been addressed in release version 1.48.0. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Jetty is a Java based web server and servlet engine. An HTTP/2 SSL connection that is established and TCP congested will be leaked when it times out. An attacker can cause many connections to end up in this state, and the server may run out of file descriptors, eventually causing the server to stop accepting new connections from valid clients. The vulnerability is patched in 9.4.54, 10.0.20, 11.0.20, and 12.0.6.

latchset jose through version 11 allows attackers to cause a denial of service (CPU consumption) via a large p2c (aka PBES2 Count) value.

Buffer Overflow vulnerability in GifLib Project GifLib v.5.2.1 allows a local attacker to obtain sensitive information via the DumpSCreen2RGB function in gif2rgb.c

The date picker could partially obscure security prompts. This could be used by a malicious site to trick a user into granting permissions. This vulnerability affects Firefox < 129, Firefox ESR < 115.14, Firefox ESR < 128.1, Thunderbird < 128.1, and Thunderbird < 115.14.

Incorrect garbage collection interaction in IndexedDB could have led to a use-after-free. This vulnerability affects Firefox < 129, Firefox ESR < 128.1, and Thunderbird < 128.1.

Unexpected marking work at the start of sweeping could have led to a use-after-free. This vulnerability affects Firefox < 129, Firefox ESR < 115.14, Firefox ESR < 128.1, Thunderbird < 128.1, and Thunderbird < 115.14.

ANGLE failed to initialize parameters which led to reading from uninitialized memory. This could be leveraged to leak sensitive data from memory. This vulnerability affects Firefox < 129, Firefox ESR < 115.14, Firefox ESR < 128.1, Thunderbird < 128.1, and Thunderbird < 115.14.

It was possible for a web extension with minimal permissions to create a `StreamFilter` which could be used to read and modify the response body of requests on any site. This vulnerability affects Firefox < 129, Firefox ESR < 115.14, Firefox ESR < 128.1, Thunderbird < 128.1, and Thunderbird < 115.14.

Firefox adds web-compatibility shims in place of some tracking scripts blocked by Enhanced Tracking Protection. On a site protected by Content Security Policy in "strict-dynamic" mode, an attacker able to inject an HTML element could have used a DOM Clobbering attack on some of the shims and achieved XSS, bypassing the CSP strict-dynamic protection. This vulnerability affects Firefox < 129, Firefox ESR < 115.14, and Firefox ESR < 128.1.

Editor code failed to check an attribute value. This could have led to an out-of-bounds read. This vulnerability affects Firefox < 129, Firefox ESR < 115.14, Firefox ESR < 128.1, Thunderbird < 128.1, and Thunderbird < 115.14.

Incomplete WebAssembly exception handing could have led to a use-after-free. This vulnerability affects Firefox < 129, Firefox ESR < 115.14, Firefox ESR < 128.1, Thunderbird < 128.1, and Thunderbird < 115.14.

A type confusion bug in WebAssembly could be leveraged by an attacker to potentially achieve code execution. This vulnerability affects Firefox < 129, Firefox ESR < 128.1, and Thunderbird < 128.1.

Insufficient checks when processing graphics shared memory could have led to memory corruption. This could be leveraged by an attacker to perform a sandbox escape. This vulnerability affects Firefox < 129, Firefox ESR < 115.14, Firefox ESR < 128.1, Thunderbird < 128.1, and Thunderbird < 115.14.

Select options could obscure the fullscreen notification dialog. This could be used by a malicious site to perform a spoofing attack. This vulnerability affects Firefox < 129, Firefox ESR < 128.1, and Thunderbird < 128.1.

Improper Handling of Exceptional Conditions, Uncontrolled Resource Consumption vulnerability in Apache Tomcat. When processing an HTTP/2 stream, Tomcat did not handle some cases of excessive HTTP headers correctly. This led to a miscounting of active HTTP/2 streams which in turn led to the use of an incorrect infinite timeout which allowed connections to remain open which should have been closed.\nThis issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M20, from 10.1.0-M1 through 10.1.24, from 9.0.0-M1 through 9.0.89.\nUsers are recommended to upgrade to version 11.0.0-M21, 10.1.25 or 9.0.90, which fixes the issue.

Due to a failure in validating the number of scanline samples of a OpenEXR file containing deep scanline data, Academy Software Foundation OpenEX image parsing library version 3.2.1 and prior is susceptible to a heap-based buffer overflow vulnerability. This issue was resolved as of versions v3.2.2 and v3.1.12 of the affected library.

Issue summary: Checking excessively long DSA keys or parameters may be very\nslow.\nImpact summary: Applications that use the functions EVP_PKEY_param_check()\nor EVP_PKEY_public_check() to check a DSA public key or DSA parameters may\nexperience long delays. Where the key or parameters that are being checked\nhave been obtained from an untrusted source this may lead to a Denial of\nService.\nThe functions EVP_PKEY_param_check() or EVP_PKEY_public_check() perform\nvarious checks on DSA parameters. Some of those computations take a long time\nif the modulus (`p` parameter) is too large.\nTrying to use a very large modulus is slow and OpenSSL will not allow using\npublic keys with a modulus which is over 10,000 bits in length for signature\nverification. However the key and parameter check functions do not limit\nthe modulus size when performing the checks.\nAn application that calls EVP_PKEY_param_check() or EVP_PKEY_public_check()\nand supplies a key or parameters obtained from an untrusted source could be\nvulnerable to a Denial of Service attack.\nThese functions are not called by OpenSSL itself on untrusted DSA keys so\nonly applications that directly call these functions may be vulnerable.\nAlso vulnerable are the OpenSSL pkey and pkeyparam command line applications\nwhen using the `-check` option.\nThe OpenSSL SSL/TLS implementation is not affected by this issue.\nThe OpenSSL 3.0 and 3.1 FIPS providers are affected by this issue.

Passing a heavily nested list to sqlparse.parse() leads to a Denial of Service due to RecursionError.

Werkzeug is a comprehensive WSGI web application library. The debugger in affected versions of Werkzeug can allow an attacker to execute code on a developer's machine under some circumstances. This requires the attacker to get the developer to interact with a domain and subdomain they control, and enter the debugger PIN, but if they are successful it allows access to the debugger even if it is only running on localhost. This also requires the attacker to guess a URL in the developer's application that will trigger the debugger. This vulnerability is fixed in 3.0.3.

An issue was discovered in Artifex Ghostscript before 10.03.1. There is path traversal (via a crafted PostScript document) to arbitrary files if the current directory is in the permitted paths. For example, there can be a transformation of ../../foo to ./../../foo and this will grant access if ./ is permitted.

An issue was discovered in Artifex Ghostscript before 10.03.1. Path traversal and command execution can occur (via a crafted PostScript document) because of path reduction in base/gpmisc.c. For example, restrictions on use of %pipe% can be bypassed via the aa/../%pipe%command# output filename.

If a server hosts a zone containing a "KEY" Resource Record, or a resolver DNSSEC-validates a "KEY" Resource Record from a DNSSEC-signed domain in cache, a client can exhaust resolver CPU resources by sending a stream of SIG(0) signed requests.\nThis issue affects BIND 9 versions 9.0.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.9.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.49-S1, and 9.18.11-S1 through 9.18.27-S1.

A segment fault (SEGV) flaw was found in libtiff that could be triggered by passing a crafted tiff file to the TIFFReadRGBATileExt() API. This flaw allows a remote attacker to cause a heap-buffer overflow, leading to a denial of service.

An out-of-memory flaw was found in libtiff that could be triggered by passing a crafted tiff file to the TIFFRasterScanlineSize64() API. This flaw allows a remote attacker to cause a denial of service via a crafted input with a size smaller than 379 KB.

A security issue was discovered in Kubernetes where a user\nthat can create pods on Windows nodes may be able to escalate to admin \nprivileges on those nodes. Kubernetes clusters are only affected if they\ninclude Windows nodes.

In GNOME GdkPixbuf (aka gdk-pixbuf) through 2.42.10, the ANI (Windows animated cursor) decoder encounters heap memory corruption (in ani_load_chunk in io-ani.c) when parsing chunks in a crafted .ani file. A crafted file could allow an attacker to overwrite heap metadata, leading to a denial of service or code execution attack. This occurs in gdk_pixbuf_set_option() in gdk-pixbuf.c.

Vulnerability in core of Apache HTTP Server 2.4.59 and earlier are vulnerably to information disclosure, SSRF or local script execution via backend applications whose response headers are malicious or exploitable.\nUsers are recommended to upgrade to version 2.4.60, which fixes this issue.

In the Linux kernel, the following vulnerability has been resolved:\nxhci: Handle TD clearing for multiple streams case\nWhen multiple streams are in use, multiple TDs might be in flight when\nan endpoint is stopped. We need to issue a Set TR Dequeue Pointer for\neach, to ensure everything is reset properly and the caches cleared.\nChange the logic so that any N>1 TDs found active for different streams\nare deferred until after the first one is processed, calling\nxhci_invalidate_cancelled_tds() again from xhci_handle_cmd_set_deq() to\nqueue another command until we are done with all of them. Also change\nthe error/"should never happen" paths to ensure we at least clear any\naffected TDs, even if we can't issue a command to clear the hardware\ncache, and complain loudly with an xhci_warn() if this ever happens.\nThis problem case dates back to commit e9df17eb1408 ("USB: xhci: Correct\nassumptions about number of rings per endpoint.") early on in the XHCI\ndriver's life, when stream support was first added.\nIt was then identified but not fixed nor made into a warning in commit\n674f8438c121 ("xhci: split handling halted endpoints into two steps"),\nwhich added a FIXME comment for the problem case (without materially\nchanging the behavior as far as I can tell, though the new logic made\nthe problem more obvious).\nThen later, in commit 94f339147fc3 ("xhci: Fix failure to give back some\ncached cancelled URBs."), it was acknowledged again.\n[Mathias: commit 94f339147fc3 ("xhci: Fix failure to give back some cached\ncancelled URBs.") was a targeted regression fix to the previously mentioned\npatch. Users reported issues with usb stuck after unmounting/disconnecting\nUAS devices. This rolled back the TD clearing of multiple streams to its\noriginal state.]\nApparently the commit author was aware of the problem (yet still chose\nto submit it): It was still mentioned as a FIXME, an xhci_dbg() was\nadded to log the problem condition, and the remaining issue was mentioned\nin the commit description. The choice of making the log type xhci_dbg()\nfor what is, at this point, a completely unhandled and known broken\ncondition is puzzling and unfortunate, as it guarantees that no actual\nusers would see the log in production, thereby making it nigh\nundebuggable (indeed, even if you turn on DEBUG, the message doesn't\nreally hint at there being a problem at all).\nIt took me *months* of random xHC crashes to finally find a reliable\nrepro and be able to do a deep dive debug session, which could all have\nbeen avoided had this unhandled, broken condition been actually reported\nwith a warning, as it should have been as a bug intentionally left in\nunfixed (never mind that it shouldn't have been left in at all).\n> Another fix to solve clearing the caches of all stream rings with\n> cancelled TDs is needed, but not as urgent.\n3 years after that statement and 14 years after the original bug was\nintroduced, I think it's finally time to fix it. And maybe next time\nlet's not leave bugs unfixed (that are actually worse than the original\nbug), and let's actually get people to review kernel commits please.\nFixes xHC crashes and IOMMU faults with UAS devices when handling\nerrors/faults. Easiest repro is to use `hdparm` to mark an early sector\n(e.g. 1024) on a disk as bad, then `cat /dev/sdX > /dev/null` in a loop.\nAt least in the case of JMicron controllers, the read errors end up\nhaving to cancel two TDs (for two queued requests to different streams)\nand the one that didn't get cleared properly ends up faulting the xHC\nentirely when it tries to access DMA pages that have since been unmapped,\nreferred to by the stale TDs. This normally happens quickly (after two\nor three loops). After this fix, I left the `cat` in a loop running\novernight and experienced no xHC failures, with all read errors\nrecovered properly. Repro'd and tested on an Apple M1 Mac Mini\n(dwc3 host).\nOn systems without an IOMMU, this bug would instead silently corrupt\nfreed memory, making this a\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\nionic: fix use after netif_napi_del()\nWhen queues are started, netif_napi_add() and napi_enable() are called.\nIf there are 4 queues and only 3 queues are used for the current\nconfiguration, only 3 queues' napi should be registered and enabled.\nThe ionic_qcq_enable() checks whether the .poll pointer is not NULL for\nenabling only the using queue' napi. Unused queues' napi will not be\nregistered by netif_napi_add(), so the .poll pointer indicates NULL.\nBut it couldn't distinguish whether the napi was unregistered or not\nbecause netif_napi_del() doesn't reset the .poll pointer to NULL.\nSo, ionic_qcq_enable() calls napi_enable() for the queue, which was\nunregistered by netif_napi_del().\nReproducer:\nethtool -L rx 1 tx 1 combined 0\nethtool -L rx 0 tx 0 combined 1\nethtool -L rx 0 tx 0 combined 4\nSplat looks like:\nkernel BUG at net/core/dev.c:6666!\nOops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 3 PID: 1057 Comm: kworker/3:3 Not tainted 6.10.0-rc2+ #16\nWorkqueue: events ionic_lif_deferred_work [ionic]\nRIP: 0010:napi_enable+0x3b/0x40\nCode: 48 89 c2 48 83 e2 f6 80 b9 61 09 00 00 00 74 0d 48 83 bf 60 01 00 00 00 74 03 80 ce 01 f0 4f\nRSP: 0018:ffffb6ed83227d48 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff97560cda0828 RCX: 0000000000000029\nRDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff97560cda0a28\nRBP: ffffb6ed83227d50 R08: 0000000000000400 R09: 0000000000000001\nR10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000\nR13: ffff97560ce3c1a0 R14: 0000000000000000 R15: ffff975613ba0a20\nFS: 0000000000000000(0000) GS:ffff975d5f780000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f8f734ee200 CR3: 0000000103e50000 CR4: 00000000007506f0\nPKRU: 55555554\nCall Trace:\n\n? die+0x33/0x90\n? do_trap+0xd9/0x100\n? napi_enable+0x3b/0x40\n? do_error_trap+0x83/0xb0\n? napi_enable+0x3b/0x40\n? napi_enable+0x3b/0x40\n? exc_invalid_op+0x4e/0x70\n? napi_enable+0x3b/0x40\n? asm_exc_invalid_op+0x16/0x20\n? napi_enable+0x3b/0x40\nionic_qcq_enable+0xb7/0x180 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]\nionic_start_queues+0xc4/0x290 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]\nionic_link_status_check+0x11c/0x170 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]\nionic_lif_deferred_work+0x129/0x280 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]\nprocess_one_work+0x145/0x360\nworker_thread+0x2bb/0x3d0\n? __pfx_worker_thread+0x10/0x10\nkthread+0xcc/0x100\n? __pfx_kthread+0x10/0x10\nret_from_fork+0x2d/0x50\n? __pfx_kthread+0x10/0x10\nret_from_fork_asm+0x1a/0x30

In the Linux kernel, the following vulnerability has been resolved:\nbonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()\nIn function bond_option_arp_ip_targets_set(), if newval->string is an\nempty string, newval->string+1 will point to the byte after the\nstring, causing an out-of-bound read.\nBUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418\nRead of size 1 at addr ffff8881119c4781 by task syz-executor665/8107\nCPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\nCall Trace:\n\n__dump_stack lib/dump_stack.c:88 [inline]\ndump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106\nprint_address_description mm/kasan/report.c:364 [inline]\nprint_report+0xc1/0x5e0 mm/kasan/report.c:475\nkasan_report+0xbe/0xf0 mm/kasan/report.c:588\nstrlen+0x7d/0xa0 lib/string.c:418\n__fortify_strlen include/linux/fortify-string.h:210 [inline]\nin4_pton+0xa3/0x3f0 net/core/utils.c:130\nbond_option_arp_ip_targets_set+0xc2/0x910\ndrivers/net/bonding/bond_options.c:1201\n__bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_options.c:767\n__bond_opt_set_notify+0x48/0x150 drivers/net/bonding/bond_options.c:792\nbond_opt_tryset_rtnl+0xda/0x160 drivers/net/bonding/bond_options.c:817\nbonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156\ndev_attr_store+0x54/0x80 drivers/base/core.c:2366\nsysfs_kf_write+0x114/0x170 fs/sysfs/file.c:136\nkernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334\ncall_write_iter include/linux/fs.h:2020 [inline]\nnew_sync_write fs/read_write.c:491 [inline]\nvfs_write+0x96a/0xd80 fs/read_write.c:584\nksys_write+0x122/0x250 fs/read_write.c:637\ndo_syscall_x64 arch/x86/entry/common.c:52 [inline]\ndo_syscall_64+0x40/0x110 arch/x86/entry/common.c:83\nentry_SYSCALL_64_after_hwframe+0x63/0x6b\n---[ end trace ]---\nFix it by adding a check of string length before using it.

In the Linux kernel, the following vulnerability has been resolved:\nmd/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING\nXiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with\nsmall possibility, the root cause is exactly the same as commit\nbed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"")\nHowever, Dan reported another hang after that, and junxiao investigated\nthe problem and found out that this is caused by plugged bio can't issue\nfrom raid5d().\nCurrent implementation in raid5d() has a weird dependence:\n1) md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear\nMD_SB_CHANGE_PENDING;\n2) raid5d() handles IO in a deadloop, until all IO are issued;\n3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;\nThis behaviour is introduce before v2.6, and for consequence, if other\ncontext hold 'reconfig_mutex', and md_check_recovery() can't update\nsuper_block, then raid5d() will waste one cpu 100% by the deadloop, until\n'reconfig_mutex' is released.\nRefer to the implementation from raid1 and raid10, fix this problem by\nskipping issue IO if MD_SB_CHANGE_PENDING is still set after\nmd_check_recovery(), daemon thread will be woken up when 'reconfig_mutex'\nis released. Meanwhile, the hang problem will be fixed as well.

In the Linux kernel, the following vulnerability has been resolved:\nxfs: fix log recovery buffer allocation for the legacy h_size fixup\nCommit a70f9fe52daa ("xfs: detect and handle invalid iclog size set by\nmkfs") added a fixup for incorrect h_size values used for the initial\numount record in old xfsprogs versions. Later commit 0c771b99d6c9\n("xfs: clean up calculation of LR header blocks") cleaned up the log\nreover buffer calculation, but stoped using the fixed up h_size value\nto size the log recovery buffer, which can lead to an out of bounds\naccess when the incorrect h_size does not come from the old mkfs\ntool, but a fuzzer.\nFix this by open coding xlog_logrec_hblks and taking the fixed h_size\ninto account for this calculation.

In the Linux kernel, the following vulnerability has been resolved:\next4: fix mb_cache_entry's e_refcnt leak in ext4_xattr_block_cache_find()\nSyzbot reports a warning as follows:\n============================================\nWARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mb_cache_destroy+0x224/0x290\nModules linked in:\nCPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7\nRIP: 0010:mb_cache_destroy+0x224/0x290 fs/mbcache.c:419\nCall Trace:\n\next4_put_super+0x6d4/0xcd0 fs/ext4/super.c:1375\ngeneric_shutdown_super+0x136/0x2d0 fs/super.c:641\nkill_block_super+0x44/0x90 fs/super.c:1675\next4_kill_sb+0x68/0xa0 fs/ext4/super.c:7327\n[...]\n============================================\nThis is because when finding an entry in ext4_xattr_block_cache_find(), if\next4_sb_bread() returns -ENOMEM, the ce's e_refcnt, which has already grown\nin the __entry_find(), won't be put away, and eventually trigger the above\nissue in mb_cache_destroy() due to reference count leakage.\nSo call mb_cache_entry_put() on the -ENOMEM error branch as a quick fix.

In the Linux kernel, the following vulnerability has been resolved:\nstm class: Fix a double free in stm_register_device()\nThe put_device(&stm->dev) call will trigger stm_device_release() which\nfrees "stm" so the vfree(stm) on the next line is a double free.

In the Linux kernel, the following vulnerability has been resolved:\ncpufreq: exit() callback is optional\nThe exit() callback is optional and shouldn't be called without checking\na valid pointer first.\nAlso, we must clear freq_table pointer even if the exit() callback isn't\npresent.

In the Linux kernel, the following vulnerability has been resolved:\nmd: fix resync softlockup when bitmap size is less than array size\nIs is reported that for dm-raid10, lvextend + lvchange --syncaction will\ntrigger following softlockup:\nkernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976]\nCPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1\nRIP: 0010:_raw_spin_unlock_irq+0x13/0x30\nCall Trace:\n\nmd_bitmap_start_sync+0x6b/0xf0\nraid10_sync_request+0x25c/0x1b40 [raid10]\nmd_do_sync+0x64b/0x1020\nmd_thread+0xa7/0x170\nkthread+0xcf/0x100\nret_from_fork+0x30/0x50\nret_from_fork_asm+0x1a/0x30\nAnd the detailed process is as follows:\nmd_do_sync\nj = mddev->resync_min\nwhile (j < max_sectors)\nsectors = raid10_sync_request(mddev, j, &skipped)\nif (!md_bitmap_start_sync(..., &sync_blocks))\n// md_bitmap_start_sync set sync_blocks to 0\nreturn sync_blocks + sectors_skippe;\n// sectors = 0;\nj += sectors;\n// j never change\nRoot cause is that commit 301867b1c168 ("md/raid10: check\nslab-out-of-bounds in md_bitmap_get_counter") return early from\nmd_bitmap_get_counter(), without setting returned blocks.\nFix this problem by always set returned blocks from\nmd_bitmap_get_counter"(), as it used to be.\nNoted that this patch just fix the softlockup problem in kernel, the\ncase that bitmap size doesn't match array size still need to be fixed.

In the Linux kernel, the following vulnerability has been resolved:\naf_unix: Fix data races in unix_release_sock/unix_stream_sendmsg\nA data-race condition has been identified in af_unix. In one data path,\nthe write function unix_release_sock() atomically writes to\nsk->sk_shutdown using WRITE_ONCE. However, on the reader side,\nunix_stream_sendmsg() does not read it atomically. Consequently, this\nissue is causing the following KCSAN splat to occur:\nBUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg\nwrite (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28:\nunix_release_sock (net/unix/af_unix.c:640)\nunix_release (net/unix/af_unix.c:1050)\nsock_close (net/socket.c:659 net/socket.c:1421)\n__fput (fs/file_table.c:422)\n__fput_sync (fs/file_table.c:508)\n__se_sys_close (fs/open.c:1559 fs/open.c:1541)\n__x64_sys_close (fs/open.c:1541)\nx64_sys_call (arch/x86/entry/syscall_64.c:33)\ndo_syscall_64 (arch/x86/entry/common.c:?)\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\nread to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14:\nunix_stream_sendmsg (net/unix/af_unix.c:2273)\n__sock_sendmsg (net/socket.c:730 net/socket.c:745)\n____sys_sendmsg (net/socket.c:2584)\n__sys_sendmmsg (net/socket.c:2638 net/socket.c:2724)\n__x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750)\nx64_sys_call (arch/x86/entry/syscall_64.c:33)\ndo_syscall_64 (arch/x86/entry/common.c:?)\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\nvalue changed: 0x01 -> 0x03\nThe line numbers are related to commit dd5a440a31fa ("Linux 6.9-rc7").\nCommit e1d09c2c2f57 ("af_unix: Fix data races around sk->sk_shutdown.")\naddressed a comparable issue in the past regarding sk->sk_shutdown.\nHowever, it overlooked resolving this particular data path.\nThis patch only offending unix_stream_sendmsg() function, since the\nother reads seem to be protected by unix_state_lock() as discussed in

In the Linux kernel, the following vulnerability has been resolved:\nwifi: brcmfmac: pcie: handle randbuf allocation failure\nThe kzalloc() in brcmf_pcie_download_fw_nvram() will return null\nif the physical memory has run out. As a result, if we use\nget_random_bytes() to generate random bytes in the randbuf, the\nnull pointer dereference bug will happen.\nIn order to prevent allocation failure, this patch adds a separate\nfunction using buffer on kernel stack to generate random bytes in\nthe randbuf, which could prevent the kernel stack from overflow.

In the Linux kernel, the following vulnerability has been resolved:\ncppc_cpufreq: Fix possible null pointer dereference\ncppc_cpufreq_get_rate() and hisi_cppc_cpufreq_get_rate() can be called from\ndifferent places with various parameters. So cpufreq_cpu_get() can return\nnull as 'policy' in some circumstances.\nFix this bug by adding null return check.\nFound by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:\nnet/mlx5: Discard command completions in internal error\nFix use after free when FW completion arrives while device is in\ninternal error state. Avoid calling completion handler in this case,\nsince the device will flush the command interface and trigger all\ncompletions manually.\nKernel log:\n------------[ cut here ]------------\nrefcount_t: underflow; use-after-free.\n...\nRIP: 0010:refcount_warn_saturate+0xd8/0xe0\n...\nCall Trace:\n\n? __warn+0x79/0x120\n? refcount_warn_saturate+0xd8/0xe0\n? report_bug+0x17c/0x190\n? handle_bug+0x3c/0x60\n? exc_invalid_op+0x14/0x70\n? asm_exc_invalid_op+0x16/0x20\n? refcount_warn_saturate+0xd8/0xe0\ncmd_ent_put+0x13b/0x160 [mlx5_core]\nmlx5_cmd_comp_handler+0x5f9/0x670 [mlx5_core]\ncmd_comp_notifier+0x1f/0x30 [mlx5_core]\nnotifier_call_chain+0x35/0xb0\natomic_notifier_call_chain+0x16/0x20\nmlx5_eq_async_int+0xf6/0x290 [mlx5_core]\nnotifier_call_chain+0x35/0xb0\natomic_notifier_call_chain+0x16/0x20\nirq_int_handler+0x19/0x30 [mlx5_core]\n__handle_irq_event_percpu+0x4b/0x160\nhandle_irq_event+0x2e/0x80\nhandle_edge_irq+0x98/0x230\n__common_interrupt+0x3b/0xa0\ncommon_interrupt+0x7b/0xa0\n\n\nasm_common_interrupt+0x22/0x40

In the Linux kernel, the following vulnerability has been resolved:\nnet: bridge: xmit: make sure we have at least eth header len bytes\nsyzbot triggered an uninit value[1] error in bridge device's xmit path\nby sending a short (less than ETH_HLEN bytes) skb. To fix it check if\nwe can actually pull that amount instead of assuming.\nTested with dropwatch:\ndrop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3)\norigin: software\ntimestamp: Mon May 13 11:31:53 2024 778214037 nsec\nprotocol: 0x88a8\nlength: 2\noriginal length: 2\ndrop reason: PKT_TOO_SMALL\n[1]\nBUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65\nbr_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65\n__netdev_start_xmit include/linux/netdevice.h:4903 [inline]\nnetdev_start_xmit include/linux/netdevice.h:4917 [inline]\nxmit_one net/core/dev.c:3531 [inline]\ndev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547\n__dev_queue_xmit+0x34db/0x5350 net/core/dev.c:4341\ndev_queue_xmit include/linux/netdevice.h:3091 [inline]\n__bpf_tx_skb net/core/filter.c:2136 [inline]\n__bpf_redirect_common net/core/filter.c:2180 [inline]\n__bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187\n____bpf_clone_redirect net/core/filter.c:2460 [inline]\nbpf_clone_redirect+0x328/0x470 net/core/filter.c:2432\n___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997\n__bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238\nbpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline]\n__bpf_prog_run include/linux/filter.h:657 [inline]\nbpf_prog_run include/linux/filter.h:664 [inline]\nbpf_test_run+0x499/0xc30 net/bpf/test_run.c:425\nbpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058\nbpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269\n__sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678\n__do_sys_bpf kernel/bpf/syscall.c:5767 [inline]\n__se_sys_bpf kernel/bpf/syscall.c:5765 [inline]\n__x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765\nx64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322\ndo_syscall_x64 arch/x86/entry/common.c:52 [inline]\ndo_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\nentry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:\nnet: bridge: mst: fix vlan use-after-free\nsyzbot reported a suspicious rcu usage[1] in bridge's mst code. While\nfixing it I noticed that nothing prevents a vlan to be freed while\nwalking the list from the same path (br forward delay timer). Fix the rcu\nusage and also make sure we are not accessing freed memory by making\nbr_mst_vlan_set_state use rcu read lock.\n[1]\nWARNING: suspicious RCU usage\n6.9.0-rc6-syzkaller #0 Not tainted\n-----------------------------\nnet/bridge/br_private.h:1599 suspicious rcu_dereference_protected() usage!\n...\nstack backtrace:\nCPU: 1 PID: 8017 Comm: syz-executor.1 Not tainted 6.9.0-rc6-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nCall Trace:\n\n__dump_stack lib/dump_stack.c:88 [inline]\ndump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\nlockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712\nnbp_vlan_group net/bridge/br_private.h:1599 [inline]\nbr_mst_set_state+0x1ea/0x650 net/bridge/br_mst.c:105\nbr_set_state+0x28a/0x7b0 net/bridge/br_stp.c:47\nbr_forward_delay_timer_expired+0x176/0x440 net/bridge/br_stp_timer.c:88\ncall_timer_fn+0x18e/0x650 kernel/time/timer.c:1793\nexpire_timers kernel/time/timer.c:1844 [inline]\n__run_timers kernel/time/timer.c:2418 [inline]\n__run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2429\nrun_timer_base kernel/time/timer.c:2438 [inline]\nrun_timer_softirq+0xb7/0x170 kernel/time/timer.c:2448\n__do_softirq+0x2c6/0x980 kernel/softirq.c:554\ninvoke_softirq kernel/softirq.c:428 [inline]\n__irq_exit_rcu+0xf2/0x1c0 kernel/softirq.c:633\nirq_exit_rcu+0x9/0x30 kernel/softirq.c:645\ninstr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline]\nsysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043\n\n\nasm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702\nRIP: 0010:lock_acquire+0x264/0x550 kernel/locking/lockdep.c:5758\nCode: 2b 00 74 08 4c 89 f7 e8 ba d1 84 00 f6 44 24 61 02 0f 85 85 01 00 00 41 f7 c7 00 02 00 00 74 01 fb 48 c7 44 24 40 0e 36 e0 45 <4b> c7 44 25 00 00 00 00 00 43 c7 44 25 09 00 00 00 00 43 c7 44 25\nRSP: 0018:ffffc90013657100 EFLAGS: 00000206\nRAX: 0000000000000001 RBX: 1ffff920026cae2c RCX: 0000000000000001\nRDX: dffffc0000000000 RSI: ffffffff8bcaca00 RDI: ffffffff8c1eaa60\nRBP: ffffc90013657260 R08: ffffffff92efe507 R09: 1ffffffff25dfca0\nR10: dffffc0000000000 R11: fffffbfff25dfca1 R12: 1ffff920026cae28\nR13: dffffc0000000000 R14: ffffc90013657160 R15: 0000000000000246

In the Linux kernel, the following vulnerability has been resolved:\nnet: sched: sch_multiq: fix possible OOB write in multiq_tune()\nq->bands will be assigned to qopt->bands to execute subsequent code logic\nafter kmalloc. So the old q->bands should not be used in kmalloc.\nOtherwise, an out-of-bounds write will occur.

In the Linux kernel, the following vulnerability has been resolved:\nnet: fix __dst_negative_advice() race\n__dst_negative_advice() does not enforce proper RCU rules when\nsk->dst_cache must be cleared, leading to possible UAF.\nRCU rules are that we must first clear sk->sk_dst_cache,\nthen call dst_release(old_dst).\nNote that sk_dst_reset(sk) is implementing this protocol correctly,\nwhile __dst_negative_advice() uses the wrong order.\nGiven that ip6_negative_advice() has special logic\nagainst RTF_CACHE, this means each of the three ->negative_advice()\nexisting methods must perform the sk_dst_reset() themselves.\nNote the check against NULL dst is centralized in\n__dst_negative_advice(), there is no need to duplicate\nit in various callbacks.\nMany thanks to Clement Lecigne for tracking this issue.\nThis old bug became visible after the blamed commit, using UDP sockets.

In the Linux kernel, the following vulnerability has been resolved:\ntipc: fix a possible memleak in tipc_buf_append\n__skb_linearize() doesn't free the skb when it fails, so move\n'*buf = NULL' after __skb_linearize(), so that the skb can be\nfreed on the err path.

In the Linux kernel, the following vulnerability has been resolved:\nfirewire: ohci: mask bus reset interrupts between ISR and bottom half\nIn the FireWire OHCI interrupt handler, if a bus reset interrupt has\noccurred, mask bus reset interrupts until bus_reset_work has serviced and\ncleared the interrupt.\nNormally, we always leave bus reset interrupts masked. We infer the bus\nreset from the self-ID interrupt that happens shortly thereafter. A\nscenario where we unmask bus reset interrupts was introduced in 2008 in\na007bb857e0b26f5d8b73c2ff90782d9c0972620: If\nOHCI_PARAM_DEBUG_BUSRESETS (8) is set in the debug parameter bitmask, we\nwill unmask bus reset interrupts so we can log them.\nirq_handler logs the bus reset interrupt. However, we can't clear the bus\nreset event flag in irq_handler, because we won't service the event until\nlater. irq_handler exits with the event flag still set. If the\ncorresponding interrupt is still unmasked, the first bus reset will\nusually freeze the system due to irq_handler being called again each\ntime it exits. This freeze can be reproduced by loading firewire_ohci\nwith "modprobe firewire_ohci debug=-1" (to enable all debugging output).\nApparently there are also some cases where bus_reset_work will get called\nsoon enough to clear the event, and operation will continue normally.\nThis freeze was first reported a few months after a007bb85 was committed,\nbut until now it was never fixed. The debug level could safely be set\nto -1 through sysfs after the module was loaded, but this would be\nineffectual in logging bus reset interrupts since they were only\nunmasked during initialization.\nirq_handler will now leave the event flag set but mask bus reset\ninterrupts, so irq_handler won't be called again and there will be no\nfreeze. If OHCI_PARAM_DEBUG_BUSRESETS is enabled, bus_reset_work will\nunmask the interrupt after servicing the event, so future interrupts\nwill be caught as desired.\nAs a side effect to this change, OHCI_PARAM_DEBUG_BUSRESETS can now be\nenabled through sysfs in addition to during initial module loading.\nHowever, when enabled through sysfs, logging of bus reset interrupts will\nbe effective only starting with the second bus reset, after\nbus_reset_work has executed.

In the Linux kernel, the following vulnerability has been resolved:\nnet/smc: fix neighbour and rtable leak in smc_ib_find_route()\nIn smc_ib_find_route(), the neighbour found by neigh_lookup() and rtable\nresolved by ip_route_output_flow() are not released or put before return.\nIt may cause the refcount leak, so fix it.

In the Linux kernel, the following vulnerability has been resolved:\nwifi: nl80211: don't free NULL coalescing rule\nIf the parsing fails, we can dereference a NULL pointer here.

In the Linux kernel, the following vulnerability has been resolved:\npinctrl: core: delete incorrect free in pinctrl_enable()\nThe "pctldev" struct is allocated in devm_pinctrl_register_and_init().\nIt's a devm_ managed pointer that is freed by devm_pinctrl_dev_release(),\nso freeing it in pinctrl_enable() will lead to a double free.\nThe devm_pinctrl_dev_release() function frees the pindescs and destroys\nthe mutex as well.

In the Linux kernel, the following vulnerability has been resolved:\nnsh: Restore skb->{protocol,data,mac_header} for outer header in nsh_gso_segment().\nsyzbot triggered various splats (see [0] and links) by a crafted GSO\npacket of VIRTIO_NET_HDR_GSO_UDP layering the following protocols:\nETH_P_8021AD + ETH_P_NSH + ETH_P_IPV6 + IPPROTO_UDP\nNSH can encapsulate IPv4, IPv6, Ethernet, NSH, and MPLS. As the inner\nprotocol can be Ethernet, NSH GSO handler, nsh_gso_segment(), calls\nskb_mac_gso_segment() to invoke inner protocol GSO handlers.\nnsh_gso_segment() does the following for the original skb before\ncalling skb_mac_gso_segment()\n1. reset skb->network_header\n2. save the original skb->{mac_heaeder,mac_len} in a local variable\n3. pull the NSH header\n4. resets skb->mac_header\n5. set up skb->mac_len and skb->protocol for the inner protocol.\nand does the following for the segmented skb\n6. set ntohs(ETH_P_NSH) to skb->protocol\n7. push the NSH header\n8. restore skb->mac_header\n9. set skb->mac_header + mac_len to skb->network_header\n10. restore skb->mac_len\nThere are two problems in 6-7 and 8-9.\n(a)\nAfter 6 & 7, skb->data points to the NSH header, so the outer header\n(ETH_P_8021AD in this case) is stripped when skb is sent out of netdev.\nAlso, if NSH is encapsulated by NSH + Ethernet (so NSH-Ethernet-NSH),\nskb_pull() in the first nsh_gso_segment() will make skb->data point\nto the middle of the outer NSH or Ethernet header because the Ethernet\nheader is not pulled by the second nsh_gso_segment().\n(b)\nWhile restoring skb->{mac_header,network_header} in 8 & 9,\nnsh_gso_segment() does not assume that the data in the linear\nbuffer is shifted.\nHowever, udp6_ufo_fragment() could shift the data and change\nskb->mac_header accordingly as demonstrated by syzbot.\nIf this happens, even the restored skb->mac_header points to\nthe middle of the outer header.\nIt seems nsh_gso_segment() has never worked with outer headers so far.\nAt the end of nsh_gso_segment(), the outer header must be restored for\nthe segmented skb, instead of the NSH header.\nTo do that, let's calculate the outer header position relatively from\nthe inner header and set skb->{data,mac_header,protocol} properly.\n[0]:\nBUG: KMSAN: uninit-value in ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline]\nBUG: KMSAN: uninit-value in ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]\nBUG: KMSAN: uninit-value in ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668\nipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline]\nipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]\nipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668\nipvlan_start_xmit+0x5c/0x1a0 drivers/net/ipvlan/ipvlan_main.c:222\n__netdev_start_xmit include/linux/netdevice.h:4989 [inline]\nnetdev_start_xmit include/linux/netdevice.h:5003 [inline]\nxmit_one net/core/dev.c:3547 [inline]\ndev_hard_start_xmit+0x244/0xa10 net/core/dev.c:3563\n__dev_queue_xmit+0x33ed/0x51c0 net/core/dev.c:4351\ndev_queue_xmit include/linux/netdevice.h:3171 [inline]\npacket_xmit+0x9c/0x6b0 net/packet/af_packet.c:276\npacket_snd net/packet/af_packet.c:3081 [inline]\npacket_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113\nsock_sendmsg_nosec net/socket.c:730 [inline]\n__sock_sendmsg net/socket.c:745 [inline]\n__sys_sendto+0x735/0xa10 net/socket.c:2191\n__do_sys_sendto net/socket.c:2203 [inline]\n__se_sys_sendto net/socket.c:2199 [inline]\n__x64_sys_sendto+0x125/0x1c0 net/socket.c:2199\ndo_syscall_x64 arch/x86/entry/common.c:52 [inline]\ndo_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\nentry_SYSCALL_64_after_hwframe+0x63/0x6b\nUninit was created at:\nslab_post_alloc_hook mm/slub.c:3819 [inline]\nslab_alloc_node mm/slub.c:3860 [inline]\n__do_kmalloc_node mm/slub.c:3980 [inline]\n__kmalloc_node_track_caller+0x705/0x1000 mm/slub.c:4001\nkmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582\n__\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\nnet: core: reject skb_copy(_expand) for fraglist GSO skbs\nSKB_GSO_FRAGLIST skbs must not be linearized, otherwise they become\ninvalid. Return NULL if such an skb is passed to skb_copy or\nskb_copy_expand, in order to prevent a crash on a potential later\ncall to skb_gso_segment.

In the Linux kernel, the following vulnerability has been resolved:\nipv4: Fix uninit-value access in __ip_make_skb()\nKMSAN reported uninit-value access in __ip_make_skb() [1]. __ip_make_skb()\ntests HDRINCL to know if the skb has icmphdr. However, HDRINCL can cause a\nrace condition. If calling setsockopt(2) with IP_HDRINCL changes HDRINCL\nwhile __ip_make_skb() is running, the function will access icmphdr in the\nskb even if it is not included. This causes the issue reported by KMSAN.\nCheck FLOWI_FLAG_KNOWN_NH on fl4->flowi4_flags instead of testing HDRINCL\non the socket.\nAlso, fl4->fl4_icmp_type and fl4->fl4_icmp_code are not initialized. These\nare union in struct flowi4 and are implicitly initialized by\nflowi4_init_output(), but we should not rely on specific union layout.\nInitialize these explicitly in raw_sendmsg().\n[1]\nBUG: KMSAN: uninit-value in __ip_make_skb+0x2b74/0x2d20 net/ipv4/ip_output.c:1481\n__ip_make_skb+0x2b74/0x2d20 net/ipv4/ip_output.c:1481\nip_finish_skb include/net/ip.h:243 [inline]\nip_push_pending_frames+0x4c/0x5c0 net/ipv4/ip_output.c:1508\nraw_sendmsg+0x2381/0x2690 net/ipv4/raw.c:654\ninet_sendmsg+0x27b/0x2a0 net/ipv4/af_inet.c:851\nsock_sendmsg_nosec net/socket.c:730 [inline]\n__sock_sendmsg+0x274/0x3c0 net/socket.c:745\n__sys_sendto+0x62c/0x7b0 net/socket.c:2191\n__do_sys_sendto net/socket.c:2203 [inline]\n__se_sys_sendto net/socket.c:2199 [inline]\n__x64_sys_sendto+0x130/0x200 net/socket.c:2199\ndo_syscall_64+0xd8/0x1f0 arch/x86/entry/common.c:83\nentry_SYSCALL_64_after_hwframe+0x6d/0x75\nUninit was created at:\nslab_post_alloc_hook mm/slub.c:3804 [inline]\nslab_alloc_node mm/slub.c:3845 [inline]\nkmem_cache_alloc_node+0x5f6/0xc50 mm/slub.c:3888\nkmalloc_reserve+0x13c/0x4a0 net/core/skbuff.c:577\n__alloc_skb+0x35a/0x7c0 net/core/skbuff.c:668\nalloc_skb include/linux/skbuff.h:1318 [inline]\n__ip_append_data+0x49ab/0x68c0 net/ipv4/ip_output.c:1128\nip_append_data+0x1e7/0x260 net/ipv4/ip_output.c:1365\nraw_sendmsg+0x22b1/0x2690 net/ipv4/raw.c:648\ninet_sendmsg+0x27b/0x2a0 net/ipv4/af_inet.c:851\nsock_sendmsg_nosec net/socket.c:730 [inline]\n__sock_sendmsg+0x274/0x3c0 net/socket.c:745\n__sys_sendto+0x62c/0x7b0 net/socket.c:2191\n__do_sys_sendto net/socket.c:2203 [inline]\n__se_sys_sendto net/socket.c:2199 [inline]\n__x64_sys_sendto+0x130/0x200 net/socket.c:2199\ndo_syscall_64+0xd8/0x1f0 arch/x86/entry/common.c:83\nentry_SYSCALL_64_after_hwframe+0x6d/0x75\nCPU: 1 PID: 15709 Comm: syz-executor.7 Not tainted 6.8.0-11567-gb3603fcb79b1 #25\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014

In the Linux kernel, the following vulnerability has been resolved:\nwifi: iwlwifi: mvm: guard against invalid STA ID on removal\nGuard against invalid station IDs in iwl_mvm_mld_rm_sta_id as that would\nresult in out-of-bounds array accesses. This prevents issues should the\ndriver get into a bad state during error handling.

In the Linux kernel, the following vulnerability has been resolved:\nblock: fix overflow in blk_ioctl_discard()\nThere is no check for overflow of 'start + len' in blk_ioctl_discard().\nHung task occurs if submit an discard ioctl with the following param:\nstart = 0x80000000000ff000, len = 0x8000000000fff000;\nAdd the overflow validation now.

In the Linux kernel, the following vulnerability has been resolved:\ntcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets\nTCP_SYN_RECV state is really special, it is only used by\ncross-syn connections, mostly used by fuzzers.\nIn the following crash [1], syzbot managed to trigger a divide\nby zero in tcp_rcv_space_adjust()\nA socket makes the following state transitions,\nwithout ever calling tcp_init_transfer(),\nmeaning tcp_init_buffer_space() is also not called.\nTCP_CLOSE\nconnect()\nTCP_SYN_SENT\nTCP_SYN_RECV\nshutdown() -> tcp_shutdown(sk, SEND_SHUTDOWN)\nTCP_FIN_WAIT1\nTo fix this issue, change tcp_shutdown() to not\nperform a TCP_SYN_RECV -> TCP_FIN_WAIT1 transition,\nwhich makes no sense anyway.\nWhen tcp_rcv_state_process() later changes socket state\nfrom TCP_SYN_RECV to TCP_ESTABLISH, then look at\nsk->sk_shutdown to finally enter TCP_FIN_WAIT1 state,\nand send a FIN packet from a sane socket state.\nThis means tcp_send_fin() can now be called from BH\ncontext, and must use GFP_ATOMIC allocations.\n[1]\ndivide error: 0000 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nRIP: 0010:tcp_rcv_space_adjust+0x2df/0x890 net/ipv4/tcp_input.c:767\nCode: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 <48> f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48\nRSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246\nRAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7\nR10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30\nR13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da\nFS: 00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0\nCall Trace:\n\ntcp_recvmsg_locked+0x106d/0x25a0 net/ipv4/tcp.c:2513\ntcp_recvmsg+0x25d/0x920 net/ipv4/tcp.c:2578\ninet6_recvmsg+0x16a/0x730 net/ipv6/af_inet6.c:680\nsock_recvmsg_nosec net/socket.c:1046 [inline]\nsock_recvmsg+0x109/0x280 net/socket.c:1068\n____sys_recvmsg+0x1db/0x470 net/socket.c:2803\n___sys_recvmsg net/socket.c:2845 [inline]\ndo_recvmmsg+0x474/0xae0 net/socket.c:2939\n__sys_recvmmsg net/socket.c:3018 [inline]\n__do_sys_recvmmsg net/socket.c:3041 [inline]\n__se_sys_recvmmsg net/socket.c:3034 [inline]\n__x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034\ndo_syscall_x64 arch/x86/entry/common.c:52 [inline]\ndo_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\nentry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7faeb6363db9\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012b\nRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9\nRDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005\nRBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c\nR10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000\nR13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001

In the Linux kernel, the following vulnerability has been resolved:\ntcp: Use refcount_inc_not_zero() in tcp_twsk_unique().\nAnderson Nascimento reported a use-after-free splat in tcp_twsk_unique()\nwith nice analysis.\nSince commit ec94c2696f0b ("tcp/dccp: avoid one atomic operation for\ntimewait hashdance"), inet_twsk_hashdance() sets TIME-WAIT socket's\nsk_refcnt after putting it into ehash and releasing the bucket lock.\nThus, there is a small race window where other threads could try to\nreuse the port during connect() and call sock_hold() in tcp_twsk_unique()\nfor the TIME-WAIT socket with zero refcnt.\nIf that happens, the refcnt taken by tcp_twsk_unique() is overwritten\nand sock_put() will cause underflow, triggering a real use-after-free\nsomewhere else.\nTo avoid the use-after-free, we need to use refcount_inc_not_zero() in\ntcp_twsk_unique() and give up on reusing the port if it returns false.\n[0]:\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 0 PID: 1039313 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110\nCPU: 0 PID: 1039313 Comm: trigger Not tainted 6.8.6-200.fc39.x86_64 #1\nHardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023\nRIP: 0010:refcount_warn_saturate+0xe5/0x110\nCode: 42 8e ff 0f 0b c3 cc cc cc cc 80 3d aa 13 ea 01 00 0f 85 5e ff ff ff 48 c7 c7 f8 8e b7 82 c6 05 96 13 ea 01 01 e8 7b 42 8e ff <0f> 0b c3 cc cc cc cc 48 c7 c7 50 8f b7 82 c6 05 7a 13 ea 01 01 e8\nRSP: 0018:ffffc90006b43b60 EFLAGS: 00010282\nRAX: 0000000000000000 RBX: ffff888009bb3ef0 RCX: 0000000000000027\nRDX: ffff88807be218c8 RSI: 0000000000000001 RDI: ffff88807be218c0\nRBP: 0000000000069d70 R08: 0000000000000000 R09: ffffc90006b439f0\nR10: ffffc90006b439e8 R11: 0000000000000003 R12: ffff8880029ede84\nR13: 0000000000004e20 R14: ffffffff84356dc0 R15: ffff888009bb3ef0\nFS: 00007f62c10926c0(0000) GS:ffff88807be00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000020ccb000 CR3: 000000004628c005 CR4: 0000000000f70ef0\nPKRU: 55555554\nCall Trace:\n\n? refcount_warn_saturate+0xe5/0x110\n? __warn+0x81/0x130\n? refcount_warn_saturate+0xe5/0x110\n? report_bug+0x171/0x1a0\n? refcount_warn_saturate+0xe5/0x110\n? handle_bug+0x3c/0x80\n? exc_invalid_op+0x17/0x70\n? asm_exc_invalid_op+0x1a/0x20\n? refcount_warn_saturate+0xe5/0x110\ntcp_twsk_unique+0x186/0x190\n__inet_check_established+0x176/0x2d0\n__inet_hash_connect+0x74/0x7d0\n? __pfx___inet_check_established+0x10/0x10\ntcp_v4_connect+0x278/0x530\n__inet_stream_connect+0x10f/0x3d0\ninet_stream_connect+0x3a/0x60\n__sys_connect+0xa8/0xd0\n__x64_sys_connect+0x18/0x20\ndo_syscall_64+0x83/0x170\nentry_SYSCALL_64_after_hwframe+0x78/0x80\nRIP: 0033:0x7f62c11a885d\nCode: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a3 45 0c 00 f7 d8 64 89 01 48\nRSP: 002b:00007f62c1091e58 EFLAGS: 00000296 ORIG_RAX: 000000000000002a\nRAX: ffffffffffffffda RBX: 0000000020ccb004 RCX: 00007f62c11a885d\nRDX: 0000000000000010 RSI: 0000000020ccb000 RDI: 0000000000000003\nRBP: 00007f62c1091e90 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000296 R12: 00007f62c10926c0\nR13: ffffffffffffff88 R14: 0000000000000000 R15: 00007ffe237885b0\n

In the Linux kernel, the following vulnerability has been resolved:\nUSB: core: Fix access violation during port device removal\nTesting with KASAN and syzkaller revealed a bug in port.c:disable_store():\nusb_hub_to_struct_hub() can return NULL if the hub that the port belongs to\nis concurrently removed, but the function does not check for this\npossibility before dereferencing the returned value.\nIt turns out that the first dereference is unnecessary, since hub->intfdev\nis the parent of the port device, so it can be changed easily. Adding a\ncheck for hub == NULL prevents further problems.\nThe same bug exists in the disable_show() routine, and it can be fixed the\nsame way.

In the Linux kernel, the following vulnerability has been resolved:\nmptcp: ensure snd_nxt is properly initialized on connect\nChristoph reported a splat hinting at a corrupted snd_una:\nWARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005\nModules linked in:\nCPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 #59\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014\nWorkqueue: events mptcp_worker\nRIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005\nCode: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8\n8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe\n<0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9\nRSP: 0018:ffffc9000013fd48 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4\nRDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001\nRBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000\nR13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000\nFS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0\nCall Trace:\n\n__mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline]\nmptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline]\n__mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615\nmptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767\nprocess_one_work+0x1e0/0x560 kernel/workqueue.c:3254\nprocess_scheduled_works kernel/workqueue.c:3335 [inline]\nworker_thread+0x3c7/0x640 kernel/workqueue.c:3416\nkthread+0x121/0x170 kernel/kthread.c:388\nret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147\nret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243\n\nWhen fallback to TCP happens early on a client socket, snd_nxt\nis not yet initialized and any incoming ack will copy such value\ninto snd_una. If the mptcp worker (dumbly) tries mptcp-level\nre-injection after such ack, that would unconditionally trigger a send\nbuffer cleanup using 'bad' snd_una values.\nWe could easily disable re-injection for fallback sockets, but such\ndumb behavior already helped catching a few subtle issues and a very\nlow to zero impact in practice.\nInstead address the issue always initializing snd_nxt (and write_seq,\nfor consistency) at connect time.

In the Linux kernel, the following vulnerability has been resolved:\ntipc: fix UAF in error path\nSam Page (sam4k) working with Trend Micro Zero Day Initiative reported\na UAF in the tipc_buf_append() error path:\nBUG: KASAN: slab-use-after-free in kfree_skb_list_reason+0x47e/0x4c0\nlinux/net/core/skbuff.c:1183\nRead of size 8 at addr ffff88804d2a7c80 by task poc/8034\nCPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.16.0-debian-1.16.0-5 04/01/2014\nCall Trace:\n\n__dump_stack linux/lib/dump_stack.c:88\ndump_stack_lvl+0xd9/0x1b0 linux/lib/dump_stack.c:106\nprint_address_description linux/mm/kasan/report.c:377\nprint_report+0xc4/0x620 linux/mm/kasan/report.c:488\nkasan_report+0xda/0x110 linux/mm/kasan/report.c:601\nkfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183\nskb_release_data+0x5af/0x880 linux/net/core/skbuff.c:1026\nskb_release_all linux/net/core/skbuff.c:1094\n__kfree_skb linux/net/core/skbuff.c:1108\nkfree_skb_reason+0x12d/0x210 linux/net/core/skbuff.c:1144\nkfree_skb linux/./include/linux/skbuff.h:1244\ntipc_buf_append+0x425/0xb50 linux/net/tipc/msg.c:186\ntipc_link_input+0x224/0x7c0 linux/net/tipc/link.c:1324\ntipc_link_rcv+0x76e/0x2d70 linux/net/tipc/link.c:1824\ntipc_rcv+0x45f/0x10f0 linux/net/tipc/node.c:2159\ntipc_udp_recv+0x73b/0x8f0 linux/net/tipc/udp_media.c:390\nudp_queue_rcv_one_skb+0xad2/0x1850 linux/net/ipv4/udp.c:2108\nudp_queue_rcv_skb+0x131/0xb00 linux/net/ipv4/udp.c:2186\nudp_unicast_rcv_skb+0x165/0x3b0 linux/net/ipv4/udp.c:2346\n__udp4_lib_rcv+0x2594/0x3400 linux/net/ipv4/udp.c:2422\nip_protocol_deliver_rcu+0x30c/0x4e0 linux/net/ipv4/ip_input.c:205\nip_local_deliver_finish+0x2e4/0x520 linux/net/ipv4/ip_input.c:233\nNF_HOOK linux/./include/linux/netfilter.h:314\nNF_HOOK linux/./include/linux/netfilter.h:308\nip_local_deliver+0x18e/0x1f0 linux/net/ipv4/ip_input.c:254\ndst_input linux/./include/net/dst.h:461\nip_rcv_finish linux/net/ipv4/ip_input.c:449\nNF_HOOK linux/./include/linux/netfilter.h:314\nNF_HOOK linux/./include/linux/netfilter.h:308\nip_rcv+0x2c5/0x5d0 linux/net/ipv4/ip_input.c:569\n__netif_receive_skb_one_core+0x199/0x1e0 linux/net/core/dev.c:5534\n__netif_receive_skb+0x1f/0x1c0 linux/net/core/dev.c:5648\nprocess_backlog+0x101/0x6b0 linux/net/core/dev.c:5976\n__napi_poll.constprop.0+0xba/0x550 linux/net/core/dev.c:6576\nnapi_poll linux/net/core/dev.c:6645\nnet_rx_action+0x95a/0xe90 linux/net/core/dev.c:6781\n__do_softirq+0x21f/0x8e7 linux/kernel/softirq.c:553\ndo_softirq linux/kernel/softirq.c:454\ndo_softirq+0xb2/0xf0 linux/kernel/softirq.c:441\n\n\n__local_bh_enable_ip+0x100/0x120 linux/kernel/softirq.c:381\nlocal_bh_enable linux/./include/linux/bottom_half.h:33\nrcu_read_unlock_bh linux/./include/linux/rcupdate.h:851\n__dev_queue_xmit+0x871/0x3ee0 linux/net/core/dev.c:4378\ndev_queue_xmit linux/./include/linux/netdevice.h:3169\nneigh_hh_output linux/./include/net/neighbour.h:526\nneigh_output linux/./include/net/neighbour.h:540\nip_finish_output2+0x169f/0x2550 linux/net/ipv4/ip_output.c:235\n__ip_finish_output linux/net/ipv4/ip_output.c:313\n__ip_finish_output+0x49e/0x950 linux/net/ipv4/ip_output.c:295\nip_finish_output+0x31/0x310 linux/net/ipv4/ip_output.c:323\nNF_HOOK_COND linux/./include/linux/netfilter.h:303\nip_output+0x13b/0x2a0 linux/net/ipv4/ip_output.c:433\ndst_output linux/./include/net/dst.h:451\nip_local_out linux/net/ipv4/ip_output.c:129\nip_send_skb+0x3e5/0x560 linux/net/ipv4/ip_output.c:1492\nudp_send_skb+0x73f/0x1530 linux/net/ipv4/udp.c:963\nudp_sendmsg+0x1a36/0x2b40 linux/net/ipv4/udp.c:1250\ninet_sendmsg+0x105/0x140 linux/net/ipv4/af_inet.c:850\nsock_sendmsg_nosec linux/net/socket.c:730\n__sock_sendmsg linux/net/socket.c:745\n__sys_sendto+0x42c/0x4e0 linux/net/socket.c:2191\n__do_sys_sendto linux/net/socket.c:2203\n__se_sys_sendto linux/net/socket.c:2199\n__x64_sys_sendto+0xe0/0x1c0 linux/net/socket.c:2199\ndo_syscall_x64 linux/arch/x86/entry/common.c:52\ndo_syscall_\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\ntls: fix missing memory barrier in tls_init\nIn tls_init(), a write memory barrier is missing, and store-store\nreordering may cause NULL dereference in tls_{setsockopt,getsockopt}.\nCPU0 CPU1\n----- -----\n// In tls_init()\n// In tls_ctx_create()\nctx = kzalloc()\nctx->sk_proto = READ_ONCE(sk->sk_prot) -(1)\n// In update_sk_prot()\nWRITE_ONCE(sk->sk_prot, tls_prots) -(2)\n// In sock_common_setsockopt()\nREAD_ONCE(sk->sk_prot)->setsockopt()\n// In tls_{setsockopt,getsockopt}()\nctx->sk_proto->setsockopt() -(3)\nIn the above scenario, when (1) and (2) are reordered, (3) can observe\nthe NULL value of ctx->sk_proto, causing NULL dereference.\nTo fix it, we rely on rcu_assign_pointer() which implies the release\nbarrier semantic. By moving rcu_assign_pointer() after ctx->sk_proto is\ninitialized, we can ensure that ctx->sk_proto are visible when\nchanging sk->sk_prot.

In the Linux kernel, the following vulnerability has been resolved:\nnetfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu()\nsyzbot reported that nf_reinject() could be called without rcu_read_lock() :\nWARNING: suspicious RCU usage\n6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not tainted\nnet/netfilter/nfnetlink_queue.c:263 suspicious rcu_dereference_check() usage!\nother info that might help us debug this:\nrcu_scheduler_active = 2, debug_locks = 1\n2 locks held by syz-executor.4/13427:\n#0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:329 [inline]\n#0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2190 [inline]\n#0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471\n#1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]\n#1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: nfqnl_flush net/netfilter/nfnetlink_queue.c:405 [inline]\n#1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: instance_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172\nstack backtrace:\nCPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\nCall Trace:\n\n__dump_stack lib/dump_stack.c:88 [inline]\ndump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\nlockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712\nnf_reinject net/netfilter/nfnetlink_queue.c:323 [inline]\nnfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397\nnfqnl_flush net/netfilter/nfnetlink_queue.c:410 [inline]\ninstance_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172\nrcu_do_batch kernel/rcu/tree.c:2196 [inline]\nrcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471\nhandle_softirqs+0x2d6/0x990 kernel/softirq.c:554\n__do_softirq kernel/softirq.c:588 [inline]\ninvoke_softirq kernel/softirq.c:428 [inline]\n__irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637\nirq_exit_rcu+0x9/0x30 kernel/softirq.c:649\ninstr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline]\nsysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043\n\n

In the Linux kernel, the following vulnerability has been resolved:\nnetfilter: tproxy: bail out if IP has been disabled on the device\nsyzbot reports:\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]\n[..]\nRIP: 0010:nf_tproxy_laddr4+0xb7/0x340 net/ipv4/netfilter/nf_tproxy_ipv4.c:62\nCall Trace:\nnft_tproxy_eval_v4 net/netfilter/nft_tproxy.c:56 [inline]\nnft_tproxy_eval+0xa9a/0x1a00 net/netfilter/nft_tproxy.c:168\n__in_dev_get_rcu() can return NULL, so check for this.

In the Linux kernel, the following vulnerability has been resolved:\nscsi: qla2xxx: Fix off by one in qla_edif_app_getstats()\nThe app_reply->elem[] array is allocated earlier in this function and it\nhas app_req.num_ports elements. Thus this > comparison needs to be >= to\nprevent memory corruption.

In the Linux kernel, the following vulnerability has been resolved:\ni40e: fix vf may be used uninitialized in this function warning\nTo fix the regression introduced by commit 52424f974bc5, which causes\nservers hang in very hard to reproduce conditions with resets races.\nUsing two sources for the information is the root cause.\nIn this function before the fix bumping v didn't mean bumping vf\npointer. But the code used this variables interchangeably, so stale vf\ncould point to different/not intended vf.\nRemove redundant "v" variable and iterate via single VF pointer across\nwhole function instead to guarantee VF pointer validity.

In the Linux kernel, the following vulnerability has been resolved:\nrtnetlink: Correct nested IFLA_VF_VLAN_LIST attribute validation\nEach attribute inside a nested IFLA_VF_VLAN_LIST is assumed to be a\nstruct ifla_vf_vlan_info so the size of such attribute needs to be at least\nof sizeof(struct ifla_vf_vlan_info) which is 14 bytes.\nThe current size validation in do_setvfinfo is against NLA_HDRLEN (4 bytes)\nwhich is less than sizeof(struct ifla_vf_vlan_info) so this validation\nis not enough and a too small attribute might be cast to a\nstruct ifla_vf_vlan_info, this might result in an out of bands\nread access when accessing the saved (casted) entry in ivvl.

In the Linux kernel, the following vulnerability has been resolved:\ntty: n_gsm: fix possible out-of-bounds in gsm0_receive()\nAssuming the following:\n- side A configures the n_gsm in basic option mode\n- side B sends the header of a basic option mode frame with data length 1\n- side A switches to advanced option mode\n- side B sends 2 data bytes which exceeds gsm->len\nReason: gsm->len is not used in advanced option mode.\n- side A switches to basic option mode\n- side B keeps sending until gsm0_receive() writes past gsm->buf\nReason: Neither gsm->state nor gsm->len have been reset after\nreconfiguration.\nFix this by changing gsm->count to gsm->len comparison from equal to less\nthan. Also add upper limit checks against the constant MAX_MRU in\ngsm0_receive() and gsm1_receive() to harden against memory corruption of\ngsm->len and gsm->mru.\nAll other checks remain as we still need to limit the data according to the\nuser configuration and actual payload size.

In the Linux kernel, the following vulnerability has been resolved:\nmlxsw: spectrum_acl_tcam: Fix incorrect list API usage\nBoth the function that migrates all the chunks within a region and the\nfunction that migrates all the entries within a chunk call\nlist_first_entry() on the respective lists without checking that the\nlists are not empty. This is incorrect usage of the API, which leads to\nthe following warning [1].\nFix by returning if the lists are empty as there is nothing to migrate\nin this case.\n[1]\nWARNING: CPU: 0 PID: 6437 at drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c:1266 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0>\nModules linked in:\nCPU: 0 PID: 6437 Comm: kworker/0:37 Not tainted 6.9.0-rc3-custom-00883-g94a65f079ef6 #39\nHardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019\nWorkqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work\nRIP: 0010:mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0x2c0\n[...]\nCall Trace:\n\nmlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x4a0\nprocess_one_work+0x151/0x370\nworker_thread+0x2cb/0x3e0\nkthread+0xd0/0x100\nret_from_fork+0x34/0x50\nret_from_fork_asm+0x1a/0x30\n

In the Linux kernel, the following vulnerability has been resolved:\nnetfilter: nf_tables: honor table dormant flag from netdev release event path\nCheck for table dormant flag otherwise netdev release event path tries\nto unregister an already unregistered hook.\n[524854.857999] ------------[ cut here ]------------\n[524854.858010] WARNING: CPU: 0 PID: 3386599 at net/netfilter/core.c:501 __nf_unregister_net_hook+0x21a/0x260\n[...]\n[524854.858848] CPU: 0 PID: 3386599 Comm: kworker/u32:2 Not tainted 6.9.0-rc3+ #365\n[524854.858869] Workqueue: netns cleanup_net\n[524854.858886] RIP: 0010:__nf_unregister_net_hook+0x21a/0x260\n[524854.858903] Code: 24 e8 aa 73 83 ff 48 63 43 1c 83 f8 01 0f 85 3d ff ff ff e8 98 d1 f0 ff 48 8b 3c 24 e8 8f 73 83 ff 48 63 43 1c e9 26 ff ff ff <0f> 0b 48 83 c4 18 48 c7 c7 00 68 e9 82 5b 5d 41 5c 41 5d 41 5e 41\n[524854.858914] RSP: 0018:ffff8881e36d79e0 EFLAGS: 00010246\n[524854.858926] RAX: 0000000000000000 RBX: ffff8881339ae790 RCX: ffffffff81ba524a\n[524854.858936] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881c8a16438\n[524854.858945] RBP: ffff8881c8a16438 R08: 0000000000000001 R09: ffffed103c6daf34\n[524854.858954] R10: ffff8881e36d79a7 R11: 0000000000000000 R12: 0000000000000005\n[524854.858962] R13: ffff8881c8a16000 R14: 0000000000000000 R15: ffff8881351b5a00\n[524854.858971] FS: 0000000000000000(0000) GS:ffff888390800000(0000) knlGS:0000000000000000\n[524854.858982] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[524854.858991] CR2: 00007fc9be0f16f4 CR3: 00000001437cc004 CR4: 00000000001706f0\n[524854.859000] Call Trace:\n[524854.859006] \n[524854.859013] ? __warn+0x9f/0x1a0\n[524854.859027] ? __nf_unregister_net_hook+0x21a/0x260\n[524854.859044] ? report_bug+0x1b1/0x1e0\n[524854.859060] ? handle_bug+0x3c/0x70\n[524854.859071] ? exc_invalid_op+0x17/0x40\n[524854.859083] ? asm_exc_invalid_op+0x1a/0x20\n[524854.859100] ? __nf_unregister_net_hook+0x6a/0x260\n[524854.859116] ? __nf_unregister_net_hook+0x21a/0x260\n[524854.859135] nf_tables_netdev_event+0x337/0x390 [nf_tables]\n[524854.859304] ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables]\n[524854.859461] ? packet_notifier+0xb3/0x360\n[524854.859476] ? _raw_spin_unlock_irqrestore+0x11/0x40\n[524854.859489] ? dcbnl_netdevice_event+0x35/0x140\n[524854.859507] ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables]\n[524854.859661] notifier_call_chain+0x7d/0x140\n[524854.859677] unregister_netdevice_many_notify+0x5e1/0xae0

In the Linux kernel, the following vulnerability has been resolved:\nmm/hugetlb: fix missing hugetlb_lock for resv uncharge\nThere is a recent report on UFFDIO_COPY over hugetlb:\nhttps://lore.kernel.org/all/000000000000ee06de0616177560@google.com/\n350:lockdep_assert_held(&hugetlb_lock);\nShould be an issue in hugetlb but triggered in an userfault context, where\nit goes into the unlikely path where two threads modifying the resv map\ntogether. Mike has a fix in that path for resv uncharge but it looks like\nthe locking criteria was overlooked: hugetlb_cgroup_uncharge_folio_rsvd()\nwill update the cgroup pointer, so it requires to be called with the lock\nheld.

In the Linux kernel, the following vulnerability has been resolved:\ndrm/ast: Fix soft lockup\nThere is a while-loop in ast_dp_set_on_off() that could lead to\ninfinite-loop. This is because the register, VGACRI-Dx, checked in\nthis API is a scratch register actually controlled by a MCU, named\nDPMCU, in BMC.\nThese scratch registers are protected by scu-lock. If suc-lock is not\noff, DPMCU can not update these registers and then host will have soft\nlockup due to never updated status.\nDPMCU is used to control DP and relative registers to handshake with\nhost's VGA driver. Even the most time-consuming task, DP's link\ntraining, is less than 100ms. 200ms should be enough.

In the Linux kernel, the following vulnerability has been resolved:\ndyndbg: fix old BUG_ON in >control parser\nFix a BUG_ON from 2009. Even if it looks "unreachable" (I didn't\nreally look), lets make sure by removing it, doing pr_err and return\n-EINVAL instead.

In the Linux kernel, the following vulnerability has been resolved:\nwifi: rtw89: fix null pointer access when abort scan\nDuring cancel scan we might use vif that weren't scanning.\nFix this by using the actual scanning vif.

In the Linux kernel, the following vulnerability has been resolved:\nwifi: cfg80211: check A-MSDU format more carefully\nIf it looks like there's another subframe in the A-MSDU\nbut the header isn't fully there, we can end up reading\ndata out of bounds, only to discard later. Make this a\nbit more careful and check if the subframe header can\neven be present.

In the Linux kernel, the following vulnerability has been resolved:\nscsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc()\nThe call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return an\nunsuccessful status. In such cases, the elsiocb is not issued, the\ncompletion is not called, and thus the elsiocb resource is leaked.\nCheck return value after calling lpfc_sli4_resume_rpi() and conditionally\nrelease the elsiocb resource.

In the Linux kernel, the following vulnerability has been resolved:\nblock: prevent division by zero in blk_rq_stat_sum()\nThe expression dst->nr_samples + src->nr_samples may\nhave zero value on overflow. It is necessary to add\na check to avoid division by zero.\nFound by Linux Verification Center (linuxtesting.org) with Svace.

In the Linux kernel, the following vulnerability has been resolved:\nusb: typec: ucsi: Limit read size on v1.2\nBetween UCSI 1.2 and UCSI 2.0, the size of the MESSAGE_IN region was\nincreased from 16 to 256. In order to avoid overflowing reads for older\nsystems, add a mechanism to use the read UCSI version to truncate read\nsizes on UCSI v1.2.

In the Linux kernel, the following vulnerability has been resolved:\nwifi: iwlwifi: mvm: rfi: fix potential response leaks\nIf the rx payload length check fails, or if kmemdup() fails,\nwe still need to free the command response. Fix that.

In the Linux kernel, the following vulnerability has been resolved:\ntcp: properly terminate timers for kernel sockets\nWe had various syzbot reports about tcp timers firing after\nthe corresponding netns has been dismantled.\nFortunately Josef Bacik could trigger the issue more often,\nand could test a patch I wrote two years ago.\nWhen TCP sockets are closed, we call inet_csk_clear_xmit_timers()\nto 'stop' the timers.\ninet_csk_clear_xmit_timers() can be called from any context,\nincluding when socket lock is held.\nThis is the reason it uses sk_stop_timer(), aka del_timer().\nThis means that ongoing timers might finish much later.\nFor user sockets, this is fine because each running timer\nholds a reference on the socket, and the user socket holds\na reference on the netns.\nFor kernel sockets, we risk that the netns is freed before\ntimer can complete, because kernel sockets do not hold\nreference on the netns.\nThis patch adds inet_csk_clear_xmit_timers_sync() function\nthat using sk_stop_timer_sync() to make sure all timers\nare terminated before the kernel socket is released.\nModules using kernel sockets close them in their netns exit()\nhandler.\nAlso add sock_not_owned_by_me() helper to get LOCKDEP\nsupport : inet_csk_clear_xmit_timers_sync() must not be called\nwhile socket lock is held.\nIt is very possible we can revert in the future commit\n3a58f13a881e ("net: rds: acquire refcount on TCP sockets")\nwhich attempted to solve the issue in rds only.\n(net/smc/af_smc.c and net/mptcp/subflow.c have similar code)\nWe probably can remove the check_net() tests from\ntcp_out_of_resources() and __tcp_close() in the future.

In the Linux kernel, the following vulnerability has been resolved:\nnetfilter: nf_tables: reject new basechain after table flag update\nWhen dormant flag is toggled, hooks are disabled in the commit phase by\niterating over current chains in table (existing and new).\nThe following configuration allows for an inconsistent state:\nadd table x\nadd chain x y { type filter hook input priority 0; }\nadd table x { flags dormant; }\nadd chain x w { type filter hook input priority 1; }\nwhich triggers the following warning when trying to unregister chain w\nwhich is already unregistered.\n[ 127.322252] WARNING: CPU: 7 PID: 1211 at net/netfilter/core.c:50 1 __nf_unregister_net_hook+0x21a/0x260\n[...]\n[ 127.322519] Call Trace:\n[ 127.322521] \n[ 127.322524] ? __warn+0x9f/0x1a0\n[ 127.322531] ? __nf_unregister_net_hook+0x21a/0x260\n[ 127.322537] ? report_bug+0x1b1/0x1e0\n[ 127.322545] ? handle_bug+0x3c/0x70\n[ 127.322552] ? exc_invalid_op+0x17/0x40\n[ 127.322556] ? asm_exc_invalid_op+0x1a/0x20\n[ 127.322563] ? kasan_save_free_info+0x3b/0x60\n[ 127.322570] ? __nf_unregister_net_hook+0x6a/0x260\n[ 127.322577] ? __nf_unregister_net_hook+0x21a/0x260\n[ 127.322583] ? __nf_unregister_net_hook+0x6a/0x260\n[ 127.322590] ? __nf_tables_unregister_hook+0x8a/0xe0 [nf_tables]\n[ 127.322655] nft_table_disable+0x75/0xf0 [nf_tables]\n[ 127.322717] nf_tables_commit+0x2571/0x2620 [nf_tables]

In the Linux kernel, the following vulnerability has been resolved:\nnetfilter: nf_tables: discard table flag update with pending basechain deletion\nHook unregistration is deferred to the commit phase, same occurs with\nhook updates triggered by the table dormant flag. When both commands are\ncombined, this results in deleting a basechain while leaving its hook\nstill registered in the core.

In the Linux kernel, the following vulnerability has been resolved:\nnet/sched: act_skbmod: prevent kernel-infoleak\nsyzbot found that tcf_skbmod_dump() was copying four bytes\nfrom kernel stack to user space [1].\nThe issue here is that 'struct tc_skbmod' has a four bytes hole.\nWe need to clear the structure before filling fields.\n[1]\nBUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]\nBUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]\nBUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]\nBUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]\nBUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]\nBUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185\ninstrument_copy_to_user include/linux/instrumented.h:114 [inline]\ncopy_to_user_iter lib/iov_iter.c:24 [inline]\niterate_ubuf include/linux/iov_iter.h:29 [inline]\niterate_and_advance2 include/linux/iov_iter.h:245 [inline]\niterate_and_advance include/linux/iov_iter.h:271 [inline]\n_copy_to_iter+0x366/0x2520 lib/iov_iter.c:185\ncopy_to_iter include/linux/uio.h:196 [inline]\nsimple_copy_to_iter net/core/datagram.c:532 [inline]\n__skb_datagram_iter+0x185/0x1000 net/core/datagram.c:420\nskb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546\nskb_copy_datagram_msg include/linux/skbuff.h:4050 [inline]\nnetlink_recvmsg+0x432/0x1610 net/netlink/af_netlink.c:1962\nsock_recvmsg_nosec net/socket.c:1046 [inline]\nsock_recvmsg+0x2c4/0x340 net/socket.c:1068\n__sys_recvfrom+0x35a/0x5f0 net/socket.c:2242\n__do_sys_recvfrom net/socket.c:2260 [inline]\n__se_sys_recvfrom net/socket.c:2256 [inline]\n__x64_sys_recvfrom+0x126/0x1d0 net/socket.c:2256\ndo_syscall_64+0xd5/0x1f0\nentry_SYSCALL_64_after_hwframe+0x6d/0x75\nUninit was stored to memory at:\npskb_expand_head+0x30f/0x19d0 net/core/skbuff.c:2253\nnetlink_trim+0x2c2/0x330 net/netlink/af_netlink.c:1317\nnetlink_unicast+0x9f/0x1260 net/netlink/af_netlink.c:1351\nnlmsg_unicast include/net/netlink.h:1144 [inline]\nnlmsg_notify+0x21d/0x2f0 net/netlink/af_netlink.c:2610\nrtnetlink_send+0x73/0x90 net/core/rtnetlink.c:741\nrtnetlink_maybe_send include/linux/rtnetlink.h:17 [inline]\ntcf_add_notify net/sched/act_api.c:2048 [inline]\ntcf_action_add net/sched/act_api.c:2071 [inline]\ntc_ctl_action+0x146e/0x19d0 net/sched/act_api.c:2119\nrtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595\nnetlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2559\nrtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6613\nnetlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]\nnetlink_unicast+0xf4c/0x1260 net/netlink/af_netlink.c:1361\nnetlink_sendmsg+0x10df/0x11f0 net/netlink/af_netlink.c:1905\nsock_sendmsg_nosec net/socket.c:730 [inline]\n__sock_sendmsg+0x30f/0x380 net/socket.c:745\n____sys_sendmsg+0x877/0xb60 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/0x4a0 net/socket.c:2674\ndo_syscall_64+0xd5/0x1f0\nentry_SYSCALL_64_after_hwframe+0x6d/0x75\nUninit was stored to memory at:\n__nla_put lib/nlattr.c:1041 [inline]\nnla_put+0x1c6/0x230 lib/nlattr.c:1099\ntcf_skbmod_dump+0x23f/0xc20 net/sched/act_skbmod.c:256\ntcf_action_dump_old net/sched/act_api.c:1191 [inline]\ntcf_action_dump_1+0x85e/0x970 net/sched/act_api.c:1227\ntcf_action_dump+0x1fd/0x460 net/sched/act_api.c:1251\ntca_get_fill+0x519/0x7a0 net/sched/act_api.c:1628\ntcf_add_notify_msg net/sched/act_api.c:2023 [inline]\ntcf_add_notify net/sched/act_api.c:2042 [inline]\ntcf_action_add net/sched/act_api.c:2071 [inline]\ntc_ctl_action+0x1365/0x19d0 net/sched/act_api.c:2119\nrtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595\nnetlink_rcv_skb+0x375/0x650 net/netlink/af_netli\n---truncated---

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

In the Linux kernel, the following vulnerability has been resolved:\nirqchip/gic-v3-its: Prevent double free on error\nThe error handling path in its_vpe_irq_domain_alloc() causes a double free\nwhen its_vpe_init() fails after successfully allocating at least one\ninterrupt. This happens because its_vpe_irq_domain_free() frees the\ninterrupts along with the area bitmap and the vprop_page and\nits_vpe_irq_domain_alloc() subsequently frees the area bitmap and the\nvprop_page again.\nFix this by unconditionally invoking its_vpe_irq_domain_free() which\nhandles all cases correctly and by removing the bitmap/vprop_page freeing\nfrom its_vpe_irq_domain_alloc().\n[ tglx: Massaged change log ]

In the Linux kernel, the following vulnerability has been resolved:\nmisc: lis3lv02d_i2c: Fix regulators getting en-/dis-abled twice on suspend/resume\nWhen not configured for wakeup lis3lv02d_i2c_suspend() will call\nlis3lv02d_poweroff() even if the device has already been turned off\nby the runtime-suspend handler and if configured for wakeup and\nthe device is runtime-suspended at this point then it is not turned\nback on to serve as a wakeup source.\nBefore commit b1b9f7a49440 ("misc: lis3lv02d_i2c: Add missing setting\nof the reg_ctrl callback"), lis3lv02d_poweroff() failed to disable\nthe regulators which as a side effect made calling poweroff() twice ok.\nNow that poweroff() correctly disables the regulators, doing this twice\ntriggers a WARN() in the regulator core:\nunbalanced disables for regulator-dummy\nWARNING: CPU: 1 PID: 92 at drivers/regulator/core.c:2999 _regulator_disable\n...\nFix lis3lv02d_i2c_suspend() to not call poweroff() a second time if\nalready runtime-suspended and add a poweron() call when necessary to\nmake wakeup work.\nlis3lv02d_i2c_resume() has similar issues, with an added weirness that\nit always powers on the device if it is runtime suspended, after which\nthe first runtime-resume will call poweron() again, causing the enabled\ncount for the regulator to increase by 1 every suspend/resume. These\nunbalanced regulator_enable() calls cause the regulator to never\nbe turned off and trigger the following WARN() on driver unbind:\nWARNING: CPU: 1 PID: 1724 at drivers/regulator/core.c:2396 _regulator_put\nFix this by making lis3lv02d_i2c_resume() mirror the new suspend().

In the Linux kernel, the following vulnerability has been resolved:\nvt: fix unicode buffer corruption when deleting characters\nThis is the same issue that was fixed for the VGA text buffer in commit\n39cdb68c64d8 ("vt: fix memory overlapping when deleting chars in the\nbuffer"). The cure is also the same i.e. replace memcpy() with memmove()\ndue to the overlaping buffers.

In the Linux kernel, the following vulnerability has been resolved:\ndrm/vmwgfx: Fix the lifetime of the bo cursor memory\nThe cleanup can be dispatched while the atomic update is still active,\nwhich means that the memory acquired in the atomic update needs to\nnot be invalidated by the cleanup. The buffer objects in vmw_plane_state\ninstead of using the builtin map_and_cache were trying to handle\nthe lifetime of the mapped memory themselves, leading to crashes.\nUse the map_and_cache instead of trying to manage the lifetime of the\nbuffer objects held by the vmw_plane_state.\nFixes kernel oops'es in IGT's kms_cursor_legacy forked-bo.

In the Linux kernel, the following vulnerability has been resolved:\next4: fix corruption during on-line resize\nWe observed a corruption during on-line resize of a file system that is\nlarger than 16 TiB with 4k block size. With having more then 2^32 blocks\nresize_inode is turned off by default by mke2fs. The issue can be\nreproduced on a smaller file system for convenience by explicitly\nturning off resize_inode. An on-line resize across an 8 GiB boundary (the\nsize of a meta block group in this setup) then leads to a corruption:\ndev=/dev/ # should be >= 16 GiB\nmkdir -p /corruption\n/sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15))\nmount -t ext4 $dev /corruption\ndd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15))\nsha1sum /corruption/test\n# 79d2658b39dcfd77274e435b0934028adafaab11 /corruption/test\n/sbin/resize2fs $dev $((2*2**21))\n# drop page cache to force reload the block from disk\necho 1 > /proc/sys/vm/drop_caches\nsha1sum /corruption/test\n# 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3 /corruption/test\n2^21 = 2^15*2^6 equals 8 GiB whereof 2^15 is the number of blocks per\nblock group and 2^6 are the number of block groups that make a meta\nblock group.\nThe last checksum might be different depending on how the file is laid\nout across the physical blocks. The actual corruption occurs at physical\nblock 63*2^15 = 2064384 which would be the location of the backup of the\nmeta block group's block descriptor. During the on-line resize the file\nsystem will be converted to meta_bg starting at s_first_meta_bg which is\n2 in the example - meaning all block groups after 16 GiB. However, in\next4_flex_group_add we might add block groups that are not part of the\nfirst meta block group yet. In the reproducer we achieved this by\nsubstracting the size of a whole block group from the point where the\nmeta block group would start. This must be considered when updating the\nbackup block group descriptors to follow the non-meta_bg layout. The fix\nis to add a test whether the group to add is already part of the meta\nblock group or not.

In the Linux kernel, the following vulnerability has been resolved:\nx86/fpu: Keep xfd_state in sync with MSR_IA32_XFD\nCommit 672365477ae8 ("x86/fpu: Update XFD state where required") and\ncommit 8bf26758ca96 ("x86/fpu: Add XFD state to fpstate") introduced a\nper CPU variable xfd_state to keep the MSR_IA32_XFD value cached, in\norder to avoid unnecessary writes to the MSR.\nOn CPU hotplug MSR_IA32_XFD is reset to the init_fpstate.xfd, which\nwipes out any stale state. But the per CPU cached xfd value is not\nreset, which brings them out of sync.\nAs a consequence a subsequent xfd_update_state() might fail to update\nthe MSR which in turn can result in XRSTOR raising a #NM in kernel\nspace, which crashes the kernel.\nTo fix this, introduce xfd_set_state() to write xfd_state together\nwith MSR_IA32_XFD, and use it in all places that set MSR_IA32_XFD.

In the Linux kernel, the following vulnerability has been resolved:\nusb: typec: altmodes/displayport: create sysfs nodes as driver's default device attribute group\nThe DisplayPort driver's sysfs nodes may be present to the userspace before\ntypec_altmode_set_drvdata() completes in dp_altmode_probe. This means that\na sysfs read can trigger a NULL pointer error by deferencing dp->hpd in\nhpd_show or dp->lock in pin_assignment_show, as dev_get_drvdata() returns\nNULL in those cases.\nRemove manual sysfs node creation in favor of adding attribute group as\ndefault for devices bound to the driver. The ATTRIBUTE_GROUPS() macro is\nnot used here otherwise the path to the sysfs nodes is no longer compliant\nwith the ABI.

In the Linux kernel, the following vulnerability has been resolved:\nipvlan: Dont Use skb->sk in ipvlan_process_v{4,6}_outbound\nRaw packet from PF_PACKET socket ontop of an IPv6-backed ipvlan device will\nhit WARN_ON_ONCE() in sk_mc_loop() through sch_direct_xmit() path.\nWARNING: CPU: 2 PID: 0 at net/core/sock.c:775 sk_mc_loop+0x2d/0x70\nModules linked in: sch_netem ipvlan rfkill cirrus drm_shmem_helper sg drm_kms_helper\nCPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Not tainted 6.9.0+ #279\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\nRIP: 0010:sk_mc_loop+0x2d/0x70\nCode: fa 0f 1f 44 00 00 65 0f b7 15 f7 96 a3 4f 31 c0 66 85 d2 75 26 48 85 ff 74 1c\nRSP: 0018:ffffa9584015cd78 EFLAGS: 00010212\nRAX: 0000000000000011 RBX: ffff91e585793e00 RCX: 0000000002c6a001\nRDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff91e589c0f000\nRBP: ffff91e5855bd100 R08: 0000000000000000 R09: 3d00545216f43d00\nR10: ffff91e584fdcc50 R11: 00000060dd8616f4 R12: ffff91e58132d000\nR13: ffff91e584fdcc68 R14: ffff91e5869ce800 R15: ffff91e589c0f000\nFS: 0000000000000000(0000) GS:ffff91e898100000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f788f7c44c0 CR3: 0000000008e1a000 CR4: 00000000000006f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n\n? __warn (kernel/panic.c:693)\n? sk_mc_loop (net/core/sock.c:760)\n? report_bug (lib/bug.c:201 lib/bug.c:219)\n? handle_bug (arch/x86/kernel/traps.c:239)\n? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1))\n? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621)\n? sk_mc_loop (net/core/sock.c:760)\nip6_finish_output2 (net/ipv6/ip6_output.c:83 (discriminator 1))\n? nf_hook_slow (net/netfilter/core.c:626)\nip6_finish_output (net/ipv6/ip6_output.c:222)\n? __pfx_ip6_finish_output (net/ipv6/ip6_output.c:215)\nipvlan_xmit_mode_l3 (drivers/net/ipvlan/ipvlan_core.c:602) ipvlan\nipvlan_start_xmit (drivers/net/ipvlan/ipvlan_main.c:226) ipvlan\ndev_hard_start_xmit (net/core/dev.c:3594)\nsch_direct_xmit (net/sched/sch_generic.c:343)\n__qdisc_run (net/sched/sch_generic.c:416)\nnet_tx_action (net/core/dev.c:5286)\nhandle_softirqs (kernel/softirq.c:555)\n__irq_exit_rcu (kernel/softirq.c:589)\nsysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1043)\nThe warning triggers as this:\npacket_sendmsg\npacket_snd //skb->sk is packet sk\n__dev_queue_xmit\n__dev_xmit_skb //q->enqueue is not NULL\n__qdisc_run\nsch_direct_xmit\ndev_hard_start_xmit\nipvlan_start_xmit\nipvlan_xmit_mode_l3 //l3 mode\nipvlan_process_outbound //vepa flag\nipvlan_process_v6_outbound\nip6_local_out\n__ip6_finish_output\nip6_finish_output2 //multicast packet\nsk_mc_loop //sk->sk_family is AF_PACKET\nCall ip{6}_local_out() with NULL sk in ipvlan as other tunnels to fix this.

In the Linux kernel, the following vulnerability has been resolved:\ngenirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline\nThe absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of\ninterrupt affinity reconfiguration via procfs. Instead, the change is\ndeferred until the next instance of the interrupt being triggered on the\noriginal CPU.\nWhen the interrupt next triggers on the original CPU, the new affinity is\nenforced within __irq_move_irq(). A vector is allocated from the new CPU,\nbut the old vector on the original CPU remains and is not immediately\nreclaimed. Instead, apicd->move_in_progress is flagged, and the reclaiming\nprocess is delayed until the next trigger of the interrupt on the new CPU.\nUpon the subsequent triggering of the interrupt on the new CPU,\nirq_complete_move() adds a task to the old CPU's vector_cleanup list if it\nremains online. Subsequently, the timer on the old CPU iterates over its\nvector_cleanup list, reclaiming old vectors.\nHowever, a rare scenario arises if the old CPU is outgoing before the\ninterrupt triggers again on the new CPU.\nIn that case irq_force_complete_move() is not invoked on the outgoing CPU\nto reclaim the old apicd->prev_vector because the interrupt isn't currently\naffine to the outgoing CPU, and irq_needs_fixup() returns false. Even\nthough __vector_schedule_cleanup() is later called on the new CPU, it\ndoesn't reclaim apicd->prev_vector; instead, it simply resets both\napicd->move_in_progress and apicd->prev_vector to 0.\nAs a result, the vector remains unreclaimed in vector_matrix, leading to a\nCPU vector leak.\nTo address this issue, move the invocation of irq_force_complete_move()\nbefore the irq_needs_fixup() call to reclaim apicd->prev_vector, if the\ninterrupt is currently or used to be affine to the outgoing CPU.\nAdditionally, reclaim the vector in __vector_schedule_cleanup() as well,\nfollowing a warning message, although theoretically it should never see\napicd->move_in_progress with apicd->prev_cpu pointing to an offline CPU.