In the Linux kernel, the following vulnerability has been resolved:\n\nnet: nfc: Fix use-after-free in local_cleanup()\n\nFix a use-after-free that occurs in kfree_skb() called from\nlocal_cleanup(). This could happen when killing nfc daemon (e.g. neard)\nafter detaching an nfc device.\nWhen detaching an nfc device, local_cleanup() called from\nnfc_llcp_unregister_device() frees local->rx_pending and decreases\nlocal->ref by kref_put() in nfc_llcp_local_put().\nIn the terminating process, nfc daemon releases all sockets and it leads\nto decreasing local->ref. After the last release of local->ref,\nlocal_cleanup() called from local_release() frees local->rx_pending\nagain, which leads to the bug.\n\nSetting local->rx_pending to NULL in local_cleanup() could prevent\nuse-after-free when local_cleanup() is called twice.\n\nFound by a modified version of syzkaller.\n\nBUG: KASAN: use-after-free in kfree_skb()\n\nCall Trace:\ndump_stack_lvl (lib/dump_stack.c:106)\nprint_address_description.constprop.0.cold (mm/kasan/report.c:306)\nkasan_check_range (mm/kasan/generic.c:189)\nkfree_skb (net/core/skbuff.c:955)\nlocal_cleanup (net/nfc/llcp_core.c:159)\nnfc_llcp_local_put.part.0 (net/nfc/llcp_core.c:172)\nnfc_llcp_local_put (net/nfc/llcp_core.c:181)\nllcp_sock_destruct (net/nfc/llcp_sock.c:959)\n__sk_destruct (net/core/sock.c:2133)\nsk_destruct (net/core/sock.c:2181)\n__sk_free (net/core/sock.c:2192)\nsk_free (net/core/sock.c:2203)\nllcp_sock_release (net/nfc/llcp_sock.c:646)\n__sock_release (net/socket.c:650)\nsock_close (net/socket.c:1365)\n__fput (fs/file_table.c:306)\ntask_work_run (kernel/task_work.c:179)\nptrace_notify (kernel/signal.c:2354)\nsyscall_exit_to_user_mode_prepare (kernel/entry/common.c:278)\nsyscall_exit_to_user_mode (kernel/entry/common.c:296)\ndo_syscall_64 (arch/x86/entry/common.c:86)\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:106)\n\nAllocated by task 4719:\nkasan_save_stack (mm/kasan/common.c:45)\n__kasan_slab_alloc (mm/kasan/common.c:325)\nslab_post_alloc_hook (mm/slab.h:766)\nkmem_cache_alloc_node (mm/slub.c:3497)\n__alloc_skb (net/core/skbuff.c:552)\npn533_recv_response (drivers/nfc/pn533/usb.c:65)\n__usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1671)\nusb_giveback_urb_bh (drivers/usb/core/hcd.c:1704)\ntasklet_action_common.isra.0 (kernel/softirq.c:797)\n__do_softirq (kernel/softirq.c:571)\n\nFreed by task 1901:\nkasan_save_stack (mm/kasan/common.c:45)\nkasan_set_track (mm/kasan/common.c:52)\nkasan_save_free_info (mm/kasan/genericdd.c:518)\n__kasan_slab_free (mm/kasan/common.c:236)\nkmem_cache_free (mm/slub.c:3809)\nkfree_skbmem (net/core/skbuff.c:874)\nkfree_skb (net/core/skbuff.c:931)\nlocal_cleanup (net/nfc/llcp_core.c:159)\nnfc_llcp_unregister_device (net/nfc/llcp_core.c:1617)\nnfc_unregister_device (net/nfc/core.c:1179)\npn53x_unregister_nfc (drivers/nfc/pn533/pn533.c:2846)\npn533_usb_disconnect (drivers/nfc/pn533/usb.c:579)\nusb_unbind_interface (drivers/usb/core/driver.c:458)\ndevice_release_driver_internal (drivers/base/dd.c:1279)\nbus_remove_device (drivers/base/bus.c:529)\ndevice_del (drivers/base/core.c:3665)\nusb_disable_device (drivers/usb/core/message.c:1420)\nusb_disconnect (drivers/usb/core.c:2261)\nhub_event (drivers/usb/core/hub.c:5833)\nprocess_one_work (arch/x86/include/asm/jump_label.h:27 include/linux/jump_label.h:212 include/trace/events/workqueue.h:108 kernel/workqueue.c:2281)\nworker_thread (include/linux/list.h:282 kernel/workqueue.c:2423)\nkthread (kernel/kthread.c:319)\nret_from_fork (arch/x86/entry/entry_64.S:301)

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915: Fix a memory leak with reused mmap_offset\n\ndrm_vma_node_allow() and drm_vma_node_revoke() should be called in\nbalanced pairs. We call drm_vma_node_allow() once per-file everytime a\nuser calls mmap_offset, but only call drm_vma_node_revoke once per-file\non each mmap_offset. As the mmap_offset is reused by the client, the\nper-file vm_count may remain non-zero and the rbtree leaked.\n\nCall drm_vma_node_allow_once() instead to prevent that memory leak.

In the Linux kernel, the following vulnerability has been resolved:\n\nacpi: Fix suspend with Xen PV\n\nCommit f1e525009493 ("x86/boot: Skip realmode init code when running as\nXen PV guest") missed one code path accessing real_mode_header, leading\nto dereferencing NULL when suspending the system under Xen:\n\n [ 348.284004] PM: suspend entry (deep)\n [ 348.289532] Filesystems sync: 0.005 seconds\n [ 348.291545] Freezing user space processes ... (elapsed 0.000 seconds) done.\n [ 348.292457] OOM killer disabled.\n [ 348.292462] Freezing remaining freezable tasks ... (elapsed 0.104 seconds) done.\n [ 348.396612] printk: Suspending console(s) (use no_console_suspend to debug)\n [ 348.749228] PM: suspend devices took 0.352 seconds\n [ 348.769713] ACPI: EC: interrupt blocked\n [ 348.816077] BUG: kernel NULL pointer dereference, address: 000000000000001c\n [ 348.816080] #PF: supervisor read access in kernel mode\n [ 348.816081] #PF: error_code(0x0000) - not-present page\n [ 348.816083] PGD 0 P4D 0\n [ 348.816086] Oops: 0000 [#1] PREEMPT SMP NOPTI\n [ 348.816089] CPU: 0 PID: 6764 Comm: systemd-sleep Not tainted 6.1.3-1.fc32.qubes.x86_64 #1\n [ 348.816092] Hardware name: Star Labs StarBook/StarBook, BIOS 8.01 07/03/2022\n [ 348.816093] RIP: e030:acpi_get_wakeup_address+0xc/0x20\n\nFix that by adding an optional acpi callback allowing to skip setting\nthe wakeup address, as in the Xen PV case this will be handled by the\nhypervisor anyway.

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Skip task with pid=1 in send_signal_common()\n\nThe following kernel panic can be triggered when a task with pid=1 attaches\na prog that attempts to send killing signal to itself, also see [1] for more\ndetails:\n\n Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b\n CPU: 3 PID: 1 Comm: systemd Not tainted 6.1.0-09652-g59fe41b5255f #148\n Call Trace:\n \n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x100/0x178 lib/dump_stack.c:106\n panic+0x2c4/0x60f kernel/panic.c:275\n do_exit.cold+0x63/0xe4 kernel/exit.c:789\n do_group_exit+0xd4/0x2a0 kernel/exit.c:950\n get_signal+0x2460/0x2600 kernel/signal.c:2858\n arch_do_signal_or_restart+0x78/0x5d0 arch/x86/kernel/signal.c:306\n exit_to_user_mode_loop kernel/entry/common.c:168 [inline]\n exit_to_user_mode_prepare+0x15f/0x250 kernel/entry/common.c:203\n __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]\n syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:296\n do_syscall_64+0x44/0xb0 arch/x86/entry/common.c:86\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nSo skip task with pid=1 in bpf_send_signal_common() to avoid the panic.\n\n [1] https://lore.kernel.org/bpf/20221222043507.33037-1-sunhao.th@gmail.com

In the Linux kernel, the following vulnerability has been resolved:\n\nblock, bfq: fix uaf for bfqq in bic_set_bfqq()\n\nAfter commit 64dc8c732f5c ("block, bfq: fix possible uaf for 'bfqq->bic'"),\nbic->bfqq will be accessed in bic_set_bfqq(), however, in some context\nbic->bfqq will be freed, and bic_set_bfqq() is called with the freed\nbic->bfqq.\n\nFix the problem by always freeing bfqq after bic_set_bfqq().

In the Linux kernel, the following vulnerability has been resolved:\n\nfscache: Use wait_on_bit() to wait for the freeing of relinquished volume\n\nThe freeing of relinquished volume will wake up the pending volume\nacquisition by using wake_up_bit(), however it is mismatched with\nwait_var_event() used in fscache_wait_on_volume_collision() and it will\nnever wake up the waiter in the wait-queue because these two functions\noperate on different wait-queues.\n\nAccording to the implementation in fscache_wait_on_volume_collision(),\nif the wake-up of pending acquisition is delayed longer than 20 seconds\n(e.g., due to the delay of on-demand fd closing), the first\nwait_var_event_timeout() will timeout and the following wait_var_event()\nwill hang forever as shown below:\n\n FS-Cache: Potential volume collision new=00000024 old=00000022\n ......\n INFO: task mount:1148 blocked for more than 122 seconds.\n Not tainted 6.1.0-rc6+ #1\n task:mount state:D stack:0 pid:1148 ppid:1\n Call Trace:\n \n __schedule+0x2f6/0xb80\n schedule+0x67/0xe0\n fscache_wait_on_volume_collision.cold+0x80/0x82\n __fscache_acquire_volume+0x40d/0x4e0\n erofs_fscache_register_volume+0x51/0xe0 [erofs]\n erofs_fscache_register_fs+0x19c/0x240 [erofs]\n erofs_fc_fill_super+0x746/0xaf0 [erofs]\n vfs_get_super+0x7d/0x100\n get_tree_nodev+0x16/0x20\n erofs_fc_get_tree+0x20/0x30 [erofs]\n vfs_get_tree+0x24/0xb0\n path_mount+0x2fa/0xa90\n do_mount+0x7c/0xa0\n __x64_sys_mount+0x8b/0xe0\n do_syscall_64+0x30/0x60\n entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nConsidering that wake_up_bit() is more selective, so fix it by using\nwait_on_bit() instead of wait_var_event() to wait for the freeing of\nrelinquished volume. In addition because waitqueue_active() is used in\nwake_up_bit() and clear_bit() doesn't imply any memory barrier, use\nclear_and_wake_up_bit() to add the missing memory barrier between\ncursor->flags and waitqueue_active().

In the Linux kernel, the following vulnerability has been resolved:\n\nefi: fix potential NULL deref in efi_mem_reserve_persistent\n\nWhen iterating on a linked list, a result of memremap is dereferenced\nwithout checking it for NULL.\n\nThis patch adds a check that falls back on allocating a new page in\ncase memremap doesn't succeed.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.\n\n[ardb: return -ENOMEM instead of breaking out of the loop]

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: iscsi_tcp: Fix UAF during login when accessing the shost ipaddress\n\nIf during iscsi_sw_tcp_session_create() iscsi_tcp_r2tpool_alloc() fails,\nuserspace could be accessing the host's ipaddress attr. If we then free the\nsession via iscsi_session_teardown() while userspace is still accessing the\nsession we will hit a use after free bug.\n\nSet the tcp_sw_host->session after we have completed session creation and\ncan no longer fail.

In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: core: Fix race by not overwriting udev->descriptor in hub_port_init()\n\nSyzbot reported an out-of-bounds read in sysfs.c:read_descriptors():\n\nBUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883\nRead of size 8 at addr ffff88801e78b8c8 by task udevd/5011\n\nCPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106\n print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351\n print_report mm/kasan/report.c:462 [inline]\n kasan_report+0x11c/0x130 mm/kasan/report.c:572\n read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883\n...\nAllocated by task 758:\n...\n __do_kmalloc_node mm/slab_common.c:966 [inline]\n __kmalloc+0x5e/0x190 mm/slab_common.c:979\n kmalloc include/linux/slab.h:563 [inline]\n kzalloc include/linux/slab.h:680 [inline]\n usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887\n usb_enumerate_device drivers/usb/core/hub.c:2407 [inline]\n usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545\n\nAs analyzed by Khazhy Kumykov, the cause of this bug is a race between\nread_descriptors() and hub_port_init(): The first routine uses a field\nin udev->descriptor, not expecting it to change, while the second\noverwrites it.\n\nPrior to commit 45bf39f8df7f ("USB: core: Don't hold device lock while\nreading the "descriptors" sysfs file") this race couldn't occur,\nbecause the routines were mutually exclusive thanks to the device\nlocking. Removing that locking from read_descriptors() exposed it to\nthe race.\n\nThe best way to fix the bug is to keep hub_port_init() from changing\nudev->descriptor once udev has been initialized and registered.\nDrivers expect the descriptors stored in the kernel to be immutable;\nwe should not undermine this expectation. In fact, this change should\nhave been made long ago.\n\nSo now hub_port_init() will take an additional argument, specifying a\nbuffer in which to store the device descriptor it reads. (If udev has\nnot yet been initialized, the buffer pointer will be NULL and then\nhub_port_init() will store the device descriptor in udev as before.)\nThis eliminates the data race responsible for the out-of-bounds read.\n\nThe changes to hub_port_init() appear more extensive than they really\nare, because of indentation changes resulting from an attempt to avoid\nwriting to other parts of the usb_device structure after it has been\ninitialized. Similar changes should be made to the code that reads\nthe BOS descriptor, but that can be handled in a separate patch later\non. This patch is sufficient to fix the bug found by syzbot.

In the Linux kernel, the following vulnerability has been resolved:\n\npadata: Fix refcnt handling in padata_free_shell()\n\nIn a high-load arm64 environment, the pcrypt_aead01 test in LTP can lead\nto system UAF (Use-After-Free) issues. Due to the lengthy analysis of\nthe pcrypt_aead01 function call, I'll describe the problem scenario\nusing a simplified model:\n\nSuppose there's a user of padata named `user_function` that adheres to\nthe padata requirement of calling `padata_free_shell` after `serial()`\nhas been invoked, as demonstrated in the following code:\n\n```c\nstruct request {\n struct padata_priv padata;\n struct completion *done;\n};\n\nvoid parallel(struct padata_priv *padata) {\n do_something();\n}\n\nvoid serial(struct padata_priv *padata) {\n struct request *request = container_of(padata,\n struct request,\n padata);\n complete(request->done);\n}\n\nvoid user_function() {\n DECLARE_COMPLETION(done)\n padata->parallel = parallel;\n padata->serial = serial;\n padata_do_parallel();\n wait_for_completion(&done);\n padata_free_shell();\n}\n```\n\nIn the corresponding padata.c file, there's the following code:\n\n```c\nstatic void padata_serial_worker(struct work_struct *serial_work) {\n ...\n cnt = 0;\n\n while (!list_empty(&local_list)) {\n ...\n padata->serial(padata);\n cnt++;\n }\n\n local_bh_enable();\n\n if (refcount_sub_and_test(cnt, &pd->refcnt))\n padata_free_pd(pd);\n}\n```\n\nBecause of the high system load and the accumulation of unexecuted\nsoftirq at this moment, `local_bh_enable()` in padata takes longer\nto execute than usual. Subsequently, when accessing `pd->refcnt`,\n`pd` has already been released by `padata_free_shell()`, resulting\nin a UAF issue with `pd->refcnt`.\n\nThe fix is straightforward: add `refcount_dec_and_test` before calling\n`padata_free_pd` in `padata_free_shell`.

In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: s390: vsie: fix race during shadow creation\n\nRight now it is possible to see gmap->private being zero in\nkvm_s390_vsie_gmap_notifier resulting in a crash. This is due to the\nfact that we add gmap->private == kvm after creation:\n\nstatic int acquire_gmap_shadow(struct kvm_vcpu *vcpu,\n struct vsie_page *vsie_page)\n{\n[...]\n gmap = gmap_shadow(vcpu->arch.gmap, asce, edat);\n if (IS_ERR(gmap))\n return PTR_ERR(gmap);\n gmap->private = vcpu->kvm;\n\nLet children inherit the private field of the parent.

In the Linux kernel, the following vulnerability has been resolved:\n\npower: supply: rk817: Fix node refcount leak\n\nDan Carpenter reports that the Smatch static checker warning has found\nthat there is another refcount leak in the probe function. While\nof_node_put() was added in one of the return paths, it should in\nfact be added for ALL return paths that return an error and at driver\nremoval time.

In the Linux kernel, the following vulnerability has been resolved:\n\nserial: 8250_port: Check IRQ data before use\n\nIn case the leaf driver wants to use IRQ polling (irq = 0) and\nIIR register shows that an interrupt happened in the 8250 hardware\nthe IRQ data can be NULL. In such a case we need to skip the wake\nevent as we came to this path from the timer interrupt and quite\nlikely system is already awake.\n\nWithout this fix we have got an Oops:\n\n serial8250: ttyS0 at I/O 0x3f8 (irq = 0, base_baud = 115200) is a 16550A\n ...\n BUG: kernel NULL pointer dereference, address: 0000000000000010\n RIP: 0010:serial8250_handle_irq+0x7c/0x240\n Call Trace:\n ? serial8250_handle_irq+0x7c/0x240\n ? __pfx_serial8250_timeout+0x10/0x10

In the Linux kernel, the following vulnerability has been resolved:\n\nerofs: fix memory leak of LZMA global compressed deduplication\n\nWhen stressing microLZMA EROFS images with the new global compressed\ndeduplication feature enabled (`-Ededupe`), I found some short-lived\ntemporary pages weren't properly released, which could slowly cause\nunexpected OOMs hours later.\n\nLet's fix it now (LZ4 and DEFLATE don't have this issue.)

In the Linux kernel, the following vulnerability has been resolved:\n\nHID: intel-ish-hid: ipc: Disable and reenable ACPI GPE bit\n\nThe EHL (Elkhart Lake) based platforms provide a OOB (Out of band)\nservice, which allows to wakup device when the system is in S5 (Soft-Off\nstate). This OOB service can be enabled/disabled from BIOS settings. When\nenabled, the ISH device gets PME wake capability. To enable PME wakeup,\ndriver also needs to enable ACPI GPE bit.\n\nOn resume, BIOS will clear the wakeup bit. So driver need to re-enable it\nin resume function to keep the next wakeup capability. But this BIOS\nclearing of wakeup bit doesn't decrement internal OS GPE reference count,\nso this reenabling on every resume will cause reference count to overflow.\n\nSo first disable and reenable ACPI GPE bit using acpi_disable_gpe().

In the Linux kernel, the following vulnerability has been resolved:\n\nphy: lynx-28g: serialize concurrent phy_set_mode_ext() calls to shared registers\n\nThe protocol converter configuration registers PCC8, PCCC, PCCD\n(implemented by the driver), as well as others, control protocol\nconverters from multiple lanes (each represented as a different\nstruct phy). So, if there are simultaneous calls to phy_set_mode_ext()\nto lanes sharing the same PCC register (either for the "old" or for the\n"new" protocol), corruption of the values programmed to hardware is\npossible, because lynx_28g_rmw() has no locking.\n\nAdd a spinlock in the struct lynx_28g_priv shared by all lanes, and take\nthe global spinlock from the phy_ops :: set_mode() implementation. There\nare no other callers which modify PCC registers.

An issue was discovered in the Linux kernel before 6.6.8. rose_ioctl in net/rose/af_rose.c has a use-after-free because of a rose_accept race condition.

An issue was discovered in the Linux kernel before 6.6.8. atalk_ioctl in net/appletalk/ddp.c has a use-after-free because of an atalk_recvmsg race condition.

sec_attest_info in drivers/accel/habanalabs/common/habanalabs_ioctl.c in the Linux kernel through 6.6.5 allows an information leak to user space because info->pad0 is not initialized.

Transmit requests in Xen's virtual network protocol can consist of\nmultiple parts. While not really useful, except for the initial part\nany of them may be of zero length, i.e. carry no data at all. Besides a\ncertain initial portion of the to be transferred data, these parts are\ndirectly translated into what Linux calls SKB fragments. Such converted\nrequest parts can, when for a particular SKB they are all of length\nzero, lead to a de-reference of NULL in core networking code.

ntfs3 in the Linux kernel before 6.5.11 allows a physically proximate attacker to read kernel memory by mounting a filesystem (e.g., if a Linux distribution is configured to allow unprivileged mounts of removable media) and then leveraging local access to trigger an out-of-bounds read. A length value can be larger than the amount of memory allocated. NOTE: the supplier's perspective is that there is no vulnerability when an attack requires an attacker-modified filesystem image.

An issue was discovered in drivers/usb/storage/ene_ub6250.c for the ENE UB6250 reader driver in the Linux kernel before 6.2.5. An object could potentially extend beyond the end of an allocation.

Babel is a compiler for writingJavaScript. In `@babel/traverse` prior to versions 7.23.2 and 8.0.0-alpha.4 and all versions of `babel-traverse`, using Babel to compile code that was specifically crafted by an attacker can lead to arbitrary code execution during compilation, when using plugins that rely on the `path.evaluate()`or `path.evaluateTruthy()` internal Babel methods. Known affected plugins are `@babel/plugin-transform-runtime`; `@babel/preset-env` when using its `useBuiltIns` option; and any "polyfill provider" plugin that depends on `@babel/helper-define-polyfill-provider`, such as `babel-plugin-polyfill-corejs3`, `babel-plugin-polyfill-corejs2`, `babel-plugin-polyfill-es-shims`, `babel-plugin-polyfill-regenerator`. No other plugins under the `@babel/` namespace are impacted, but third-party plugins might be. Users that only compile trusted code are not impacted. The vulnerability has been fixed in `@babel/traverse@7.23.2` and `@babel/traverse@8.0.0-alpha.4`. Those who cannot upgrade `@babel/traverse` and are using one of the affected packages mentioned above should upgrade them to their latest version to avoid triggering the vulnerable code path in affected `@babel/traverse` versions: `@babel/plugin-transform-runtime` v7.23.2, `@babel/preset-env` v7.23.2, `@babel/helper-define-polyfill-provider` v0.4.3, `babel-plugin-polyfill-corejs2` v0.4.6, `babel-plugin-polyfill-corejs3` v0.8.5, `babel-plugin-polyfill-es-shims` v0.10.0, `babel-plugin-polyfill-regenerator` v0.5.3.

An integer overflow flaw was found in the Linux kernel. This issue leads to the kernel allocating `skb_shared_info` in the userspace, which is exploitable in systems without SMAP protection since `skb_shared_info` contains references to function pointers.

In GNU tar before 1.35, mishandled extension attributes in a PAX archive can lead to an application crash in xheader.c.

A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation.\n\nWhen nf_tables_delrule() is flushing table rules, it is not checked whether the chain is bound and the chain's owner rule can also release the objects in certain circumstances.\n\nWe recommend upgrading past commit 6eaf41e87a223ae6f8e7a28d6e78384ad7e407f8.

The session restore helper crashed whenever there was no parameter sent to the message handler. This vulnerability affects Firefox for iOS < 115.

The permission request prompt from the site in the background tab was overlaid on top of the site in the foreground tab. This vulnerability affects Firefox for iOS < 115.

When Firefox is configured to block storage of all cookies, it was still possible to store data in localstorage by using an iframe with a source of 'about:blank'. This could have led to malicious websites storing tracking data without permission. This vulnerability affects Firefox < 115.

When choosing a site-isolated process for a document loaded from a data: URL that was the result of a redirect, Firefox would load that document in the same process as the site that issued the redirect. This bypassed the site-isolation protections against Spectre-like attacks on sites that host an "open redirect". Firefox no longer follows HTTP redirects to data: URLs. This vulnerability affects Firefox < 114.

Closing of an event channel in the Linux kernel can result in a deadlock.\nThis happens when the close is being performed in parallel to an unrelated\nXen console action and the handling of a Xen console interrupt in an\nunprivileged guest.\n\nThe closing of an event channel is e.g. triggered by removal of a\nparavirtual device on the other side. As this action will cause console\nmessages to be issued on the other side quite often, the chance of\ntriggering the deadlock is not neglectable.\n\nNote that 32-bit Arm-guests are not affected, as the 32-bit Linux kernel\non Arm doesn't use queued-RW-locks, which are required to trigger the\nissue (on Arm32 a waiting writer doesn't block further readers to get\nthe lock).

A race condition occurred between the functions lmLogClose and txEnd in JFS, in the Linux Kernel, executed in different threads. This flaw allows a local attacker with normal user privileges to crash the system or leak internal kernel information.

Documents were incorrectly assuming an ordering of principal objects when ensuring we were loading an appropriately privileged principal. In certain circumstances it might have been possible to cause a document to be loaded with a higher privileged principal than intended. This vulnerability affects Firefox < 113.

Service workers could reveal script base URL due to dynamic `import()`. This vulnerability affects Firefox < 113.

Under certain circumstances, a call to the bind function may have resulted in the incorrect realm. This may have created a vulnerability relating to JavaScript-implemented sandboxes such as SES. This vulnerability affects Firefox for Android < 112, Firefox < 112, and Focus for Android < 112.

When a secure cookie existed in the Firefox cookie jar an insecure cookie for the same domain could have been created, when it should have silently failed. This could have led to a desynchronization in expected results when reading from the secure cookie. This vulnerability affects Firefox for Android < 112, Firefox < 112, and Focus for Android < 112.

When recording the screen while in Private Browsing on Firefox for Android the address bar and keyboard were not hidden, potentially leaking sensitive information. \n\n*This bug only affects Firefox for Android. Other operating systems are unaffected.* This vulnerability affects Firefox for Android < 112 and Focus for Android < 112.

If multiple instances of resource exhaustion occurred at the incorrect time, the garbage collector could have caused memory corruption and a potentially exploitable crash. This vulnerability affects Firefox for Android < 112, Firefox < 112, and Focus for Android < 112.

Using a redirect embedded into sourceMappingUrls could allow for navigation to external protocol links in sandboxed iframes without allow-top-navigation-to-custom-protocols. This vulnerability affects Firefox for Android < 112, Firefox < 112, and Focus for Android < 112.

Under specific circumstances a WebExtension may have received a jar:file:/// URI instead of a moz-extension:/// URI during a load request. This leaked directory paths on the user's machine. This vulnerability affects Firefox for Android < 112, Firefox < 112, and Focus for Android < 112.

When following a redirect to a publicly accessible web extension file, the URL may have been translated to the actual local path, leaking potentially sensitive information. This vulnerability affects Firefox < 111.

The fullscreen notification could have been hidden on Firefox for Android by using download popups, resulting in potential user confusion or spoofing attacks.
*This bug only affects Firefox for Android. Other operating systems are unaffected.*. This vulnerability affects Firefox < 111.

Under certain circumstances, a ServiceWorker's offline cache may have leaked to the file system when using private browsing mode. This vulnerability affects Firefox < 111.

Android applications with unpatched vulnerabilities can be launched from a browser using Intents, exposing users to these vulnerabilities. Firefox will now confirm with users that they want to launch an external application before doing so.
*This bug only affects Firefox for Android. Other versions of Firefox are unaffected.*. This vulnerability affects Firefox < 111.

By displaying a prompt with a long description, the fullscreen notification could have been hidden, resulting in potential user confusion or spoofing attacks.
*This bug only affects Firefox for Android. Other operating systems are unaffected.*. This vulnerability affects Firefox < 111.

Per origin notification permissions were being stored in a way that didn't take into account what browsing context the permission was granted in. This lead to the possibility of notifications to be displayed during different browsing sessions.
*This bug only affects Firefox for Android. Other operating systems are unaffected.*. This vulnerability affects Firefox < 109.

A compromised web child process could disable web security opening restrictions, leading to a new child process being spawned within the file:// context. Given a reliable exploit primitive, this new process could be exploited again leading to arbitrary file read. This vulnerability affects Firefox < 109.

Improper\nAccess Control in System Management Mode (SMM) may allow an attacker access to\nthe SPI flash potentially leading to arbitrary code execution.

In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: VMX: Do _all_ initialization before exposing /dev/kvm to userspace\n\nCall kvm_init() only after _all_ setup is complete, as kvm_init() exposes\n/dev/kvm to userspace and thus allows userspace to create VMs (and call\nother ioctls). E.g. KVM will encounter a NULL pointer when attempting to\nadd a vCPU to the per-CPU loaded_vmcss_on_cpu list if userspace is able to\ncreate a VM before vmx_init() configures said list.\n\n BUG: kernel NULL pointer dereference, address: 0000000000000008\n #PF: supervisor write access in kernel mode\n #PF: error_code(0x0002) - not-present page\n PGD 0 P4D 0\n Oops: 0002 [#1] SMP\n CPU: 6 PID: 1143 Comm: stable Not tainted 6.0.0-rc7+ #988\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n RIP: 0010:vmx_vcpu_load_vmcs+0x68/0x230 [kvm_intel]\n \n vmx_vcpu_load+0x16/0x60 [kvm_intel]\n kvm_arch_vcpu_load+0x32/0x1f0 [kvm]\n vcpu_load+0x2f/0x40 [kvm]\n kvm_arch_vcpu_create+0x231/0x310 [kvm]\n kvm_vm_ioctl+0x79f/0xe10 [kvm]\n ? handle_mm_fault+0xb1/0x220\n __x64_sys_ioctl+0x80/0xb0\n do_syscall_64+0x2b/0x50\n entry_SYSCALL_64_after_hwframe+0x46/0xb0\n RIP: 0033:0x7f5a6b05743b\n \n Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel(+) kvm irqbypass

In the Linux kernel, the following vulnerability has been resolved:\n\nIB/hfi1: Correctly move list in sc_disable()\n\nCommit 13bac861952a ("IB/hfi1: Fix abba locking issue with sc_disable()")\nincorrectly tries to move a list from one list head to another. The\nresult is a kernel crash.\n\nThe crash is triggered when a link goes down and there are waiters for a\nsend to complete. The following signature is seen:\n\n BUG: kernel NULL pointer dereference, address: 0000000000000030\n [...]\n Call Trace:\n sc_disable+0x1ba/0x240 [hfi1]\n pio_freeze+0x3d/0x60 [hfi1]\n handle_freeze+0x27/0x1b0 [hfi1]\n process_one_work+0x1b0/0x380\n ? process_one_work+0x380/0x380\n worker_thread+0x30/0x360\n ? process_one_work+0x380/0x380\n kthread+0xd7/0x100\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork+0x1f/0x30\n\nThe fix is to use the correct call to move the list.

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/hns: Fix NULL pointer problem in free_mr_init()\n\nLock grab occurs in a concurrent scenario, resulting in stepping on a NULL\npointer. It should be init mutex_init() first before use the lock.\n\n Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n Call trace:\n __mutex_lock.constprop.0+0xd0/0x5c0\n __mutex_lock_slowpath+0x1c/0x2c\n mutex_lock+0x44/0x50\n free_mr_send_cmd_to_hw+0x7c/0x1c0 [hns_roce_hw_v2]\n hns_roce_v2_dereg_mr+0x30/0x40 [hns_roce_hw_v2]\n hns_roce_dereg_mr+0x4c/0x130 [hns_roce_hw_v2]\n ib_dereg_mr_user+0x54/0x124\n uverbs_free_mr+0x24/0x30\n destroy_hw_idr_uobject+0x38/0x74\n uverbs_destroy_uobject+0x48/0x1c4\n uobj_destroy+0x74/0xcc\n ib_uverbs_cmd_verbs+0x368/0xbb0\n ib_uverbs_ioctl+0xec/0x1a4\n __arm64_sys_ioctl+0xb4/0x100\n invoke_syscall+0x50/0x120\n el0_svc_common.constprop.0+0x58/0x190\n do_el0_svc+0x30/0x90\n el0_svc+0x2c/0xb4\n el0t_64_sync_handler+0x1a4/0x1b0\n el0t_64_sync+0x19c/0x1a0

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix mr leak in RESPST_ERR_RNR\n\nrxe_recheck_mr() will increase mr's ref_cnt, so we should call rxe_put(mr)\nto drop mr's ref_cnt in RESPST_ERR_RNR to avoid below warning:\n\n WARNING: CPU: 0 PID: 4156 at drivers/infiniband/sw/rxe/rxe_pool.c:259 __rxe_cleanup+0x1df/0x240 [rdma_rxe]\n...\n Call Trace:\n rxe_dereg_mr+0x4c/0x60 [rdma_rxe]\n ib_dereg_mr_user+0xa8/0x200 [ib_core]\n ib_mr_pool_destroy+0x77/0xb0 [ib_core]\n nvme_rdma_destroy_queue_ib+0x89/0x240 [nvme_rdma]\n nvme_rdma_free_queue+0x40/0x50 [nvme_rdma]\n nvme_rdma_teardown_io_queues.part.0+0xc3/0x120 [nvme_rdma]\n nvme_rdma_error_recovery_work+0x4d/0xf0 [nvme_rdma]\n process_one_work+0x582/0xa40\n ? pwq_dec_nr_in_flight+0x100/0x100\n ? rwlock_bug.part.0+0x60/0x60\n worker_thread+0x2a9/0x700\n ? process_one_work+0xa40/0xa40\n kthread+0x168/0x1a0\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork+0x22/0x30

In the Linux kernel, the following vulnerability has been resolved:\n\nSUNRPC: Fix null-ptr-deref when xps sysfs alloc failed\n\nThere is a null-ptr-deref when xps sysfs alloc failed:\n BUG: KASAN: null-ptr-deref in sysfs_do_create_link_sd+0x40/0xd0\n Read of size 8 at addr 0000000000000030 by task gssproxy/457\n\n CPU: 5 PID: 457 Comm: gssproxy Not tainted 6.0.0-09040-g02357b27ee03 #9\n Call Trace:\n \n dump_stack_lvl+0x34/0x44\n kasan_report+0xa3/0x120\n sysfs_do_create_link_sd+0x40/0xd0\n rpc_sysfs_client_setup+0x161/0x1b0\n rpc_new_client+0x3fc/0x6e0\n rpc_create_xprt+0x71/0x220\n rpc_create+0x1d4/0x350\n gssp_rpc_create+0xc3/0x160\n set_gssp_clnt+0xbc/0x140\n write_gssp+0x116/0x1a0\n proc_reg_write+0xd6/0x130\n vfs_write+0x177/0x690\n ksys_write+0xb9/0x150\n do_syscall_64+0x35/0x80\n entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nWhen the xprt_switch sysfs alloc failed, should not add xprt and\nswitch sysfs to it, otherwise, maybe null-ptr-deref; also initialize\nthe 'xps_sysfs' to NULL to avoid oops when destroy it.

In the Linux kernel, the following vulnerability has been resolved:\n\nnfs4: Fix kmemleak when allocate slot failed\n\nIf one of the slot allocate failed, should cleanup all the other\nallocated slots, otherwise, the allocated slots will leak:\n\n unreferenced object 0xffff8881115aa100 (size 64):\n comm ""mount.nfs"", pid 679, jiffies 4294744957 (age 115.037s)\n hex dump (first 32 bytes):\n 00 cc 19 73 81 88 ff ff 00 a0 5a 11 81 88 ff ff ...s......Z.....\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace:\n [<000000007a4c434a>] nfs4_find_or_create_slot+0x8e/0x130\n [<000000005472a39c>] nfs4_realloc_slot_table+0x23f/0x270\n [<00000000cd8ca0eb>] nfs40_init_client+0x4a/0x90\n [<00000000128486db>] nfs4_init_client+0xce/0x270\n [<000000008d2cacad>] nfs4_set_client+0x1a2/0x2b0\n [<000000000e593b52>] nfs4_create_server+0x300/0x5f0\n [<00000000e4425dd2>] nfs4_try_get_tree+0x65/0x110\n [<00000000d3a6176f>] vfs_get_tree+0x41/0xf0\n [<0000000016b5ad4c>] path_mount+0x9b3/0xdd0\n [<00000000494cae71>] __x64_sys_mount+0x190/0x1d0\n [<000000005d56bdec>] do_syscall_64+0x35/0x80\n [<00000000687c9ae4>] entry_SYSCALL_64_after_hwframe+0x46/0xb0

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: Fix possible memory leaks in dsa_loop_init()\n\nkmemleak reported memory leaks in dsa_loop_init():\n\nkmemleak: 12 new suspected memory leaks\n\nunreferenced object 0xffff8880138ce000 (size 2048):\n comm "modprobe", pid 390, jiffies 4295040478 (age 238.976s)\n backtrace:\n [<000000006a94f1d5>] kmalloc_trace+0x26/0x60\n [<00000000a9c44622>] phy_device_create+0x5d/0x970\n [<00000000d0ee2afc>] get_phy_device+0xf3/0x2b0\n [<00000000dca0c71f>] __fixed_phy_register.part.0+0x92/0x4e0\n [<000000008a834798>] fixed_phy_register+0x84/0xb0\n [<0000000055223fcb>] dsa_loop_init+0xa9/0x116 [dsa_loop]\n ...\n\nThere are two reasons for memleak in dsa_loop_init().\n\nFirst, fixed_phy_register() create and register phy_device:\n\nfixed_phy_register()\n get_phy_device()\n phy_device_create() # freed by phy_device_free()\n phy_device_register() # freed by phy_device_remove()\n\nBut fixed_phy_unregister() only calls phy_device_remove().\nSo the memory allocated in phy_device_create() is leaked.\n\nSecond, when mdio_driver_register() fail in dsa_loop_init(),\nit just returns and there is no cleanup for phydevs.\n\nFix the problems by catching the error of mdio_driver_register()\nin dsa_loop_init(), then calling both fixed_phy_unregister() and\nphy_device_free() to release phydevs.\nAlso add a function for phydevs cleanup to avoid duplacate.

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/core: Fix null-ptr-deref in ib_core_cleanup()\n\nKASAN reported a null-ptr-deref error:\n\n KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]\n CPU: 1 PID: 379\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)\n RIP: 0010:destroy_workqueue+0x2f/0x740\n RSP: 0018:ffff888016137df8 EFLAGS: 00000202\n ...\n Call Trace:\n ib_core_cleanup+0xa/0xa1 [ib_core]\n __do_sys_delete_module.constprop.0+0x34f/0x5b0\n do_syscall_64+0x3a/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n RIP: 0033:0x7fa1a0d221b7\n ...\n\nIt is because the fail of roce_gid_mgmt_init() is ignored:\n\n ib_core_init()\n roce_gid_mgmt_init()\n gid_cache_wq = alloc_ordered_workqueue # fail\n ...\n ib_core_cleanup()\n roce_gid_mgmt_cleanup()\n destroy_workqueue(gid_cache_wq)\n # destroy an unallocated wq\n\nFix this by catching the fail of roce_gid_mgmt_init() in ib_core_init().

In the Linux kernel, the following vulnerability has been resolved:\n\nnfc: fdp: Fix potential memory leak in fdp_nci_send()\n\nfdp_nci_send() will call fdp_nci_i2c_write that will not free skb in\nthe function. As a result, when fdp_nci_i2c_write() finished, the skb\nwill memleak. fdp_nci_send() should free skb after fdp_nci_i2c_write()\nfinished.

In the Linux kernel, the following vulnerability has been resolved:\n\nnfc: nxp-nci: Fix potential memory leak in nxp_nci_send()\n\nnxp_nci_send() will call nxp_nci_i2c_write(), and only free skb when\nnxp_nci_i2c_write() failed. However, even if the nxp_nci_i2c_write()\nrun succeeds, the skb will not be freed in nxp_nci_i2c_write(). As the\nresult, the skb will memleak. nxp_nci_send() should also free the skb\nwhen nxp_nci_i2c_write() succeeds.

In the Linux kernel, the following vulnerability has been resolved:\n\nnfc: nfcmrvl: Fix potential memory leak in nfcmrvl_i2c_nci_send()\n\nnfcmrvl_i2c_nci_send() will be called by nfcmrvl_nci_send(), and skb\nshould be freed in nfcmrvl_i2c_nci_send(). However, nfcmrvl_nci_send()\nwill only free skb when i2c_master_send() return >=0, which means skb\nwill memleak when i2c_master_send() failed. Free skb no matter whether\ni2c_master_send() succeeds.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: sched: Fix use after free in red_enqueue()\n\nWe can't use "skb" again after passing it to qdisc_enqueue(). This is\nbasically identical to commit 2f09707d0c97 ("sch_sfb: Also store skb\nlen before calling child enqueue").

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: netlink notifier might race to release objects\n\ncommit release path is invoked via call_rcu and it runs lockless to\nrelease the objects after rcu grace period. The netlink notifier handler\nmight win race to remove objects that the transaction context is still\nreferencing from the commit release path.\n\nCall rcu_barrier() to ensure pending rcu callbacks run to completion\nif the list of transactions to be destroyed is not empty.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: release flow rule object from commit path\n\nNo need to postpone this to the commit release path, since no packets\nare walking over this object, this is accessed from control plane only.\nThis helped uncovered UAF triggered by races with the netlink notifier.

In the Linux kernel, the following vulnerability has been resolved:\n\nipvs: fix WARNING in __ip_vs_cleanup_batch()\n\nDuring the initialization of ip_vs_conn_net_init(), if file ip_vs_conn\nor ip_vs_conn_sync fails to be created, the initialization is successful\nby default. Therefore, the ip_vs_conn or ip_vs_conn_sync file doesn't\nbe found during the remove.\n\nThe following is the stack information:\nname 'ip_vs_conn_sync'\nWARNING: CPU: 3 PID: 9 at fs/proc/generic.c:712\nremove_proc_entry+0x389/0x460\nModules linked in:\nWorkqueue: netns cleanup_net\nRIP: 0010:remove_proc_entry+0x389/0x460\nCall Trace:\n\n__ip_vs_cleanup_batch+0x7d/0x120\nops_exit_list+0x125/0x170\ncleanup_net+0x4ea/0xb00\nprocess_one_work+0x9bf/0x1710\nworker_thread+0x665/0x1080\nkthread+0x2e4/0x3a0\nret_from_fork+0x1f/0x30\n

In the Linux kernel, the following vulnerability has been resolved:\n\nipvs: fix WARNING in ip_vs_app_net_cleanup()\n\nDuring the initialization of ip_vs_app_net_init(), if file ip_vs_app\nfails to be created, the initialization is successful by default.\nTherefore, the ip_vs_app file doesn't be found during the remove in\nip_vs_app_net_cleanup(). It will cause WRNING.\n\nThe following is the stack information:\nname 'ip_vs_app'\nWARNING: CPU: 1 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460\nModules linked in:\nWorkqueue: netns cleanup_net\nRIP: 0010:remove_proc_entry+0x389/0x460\nCall Trace:\n\nops_exit_list+0x125/0x170\ncleanup_net+0x4ea/0xb00\nprocess_one_work+0x9bf/0x1710\nworker_thread+0x665/0x1080\nkthread+0x2e4/0x3a0\nret_from_fork+0x1f/0x30\n

In the Linux kernel, the following vulnerability has been resolved:\n\nrose: Fix NULL pointer dereference in rose_send_frame()\n\nThe syzkaller reported an issue:\n\nKASAN: null-ptr-deref in range [0x0000000000000380-0x0000000000000387]\nCPU: 0 PID: 4069 Comm: kworker/0:15 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022\nWorkqueue: rcu_gp srcu_invoke_callbacks\nRIP: 0010:rose_send_frame+0x1dd/0x2f0 net/rose/rose_link.c:101\nCall Trace:\n \n rose_transmit_clear_request+0x1d5/0x290 net/rose/rose_link.c:255\n rose_rx_call_request+0x4c0/0x1bc0 net/rose/af_rose.c:1009\n rose_loopback_timer+0x19e/0x590 net/rose/rose_loopback.c:111\n call_timer_fn+0x1a0/0x6b0 kernel/time/timer.c:1474\n expire_timers kernel/time/timer.c:1519 [inline]\n __run_timers.part.0+0x674/0xa80 kernel/time/timer.c:1790\n __run_timers kernel/time/timer.c:1768 [inline]\n run_timer_softirq+0xb3/0x1d0 kernel/time/timer.c:1803\n __do_softirq+0x1d0/0x9c8 kernel/softirq.c:571\n [...]\n \n\nIt triggers NULL pointer dereference when 'neigh->dev->dev_addr' is\ncalled in the rose_send_frame(). It's the first occurrence of the\n`neigh` is in rose_loopback_timer() as `rose_loopback_neigh', and\nthe 'dev' in 'rose_loopback_neigh' is initialized sa nullptr.\n\nIt had been fixed by commit 3b3fd068c56e3fbea30090859216a368398e39bf\n("rose: Fix Null pointer dereference in rose_send_frame()") ever.\nBut it's introduced by commit 3c53cd65dece47dd1f9d3a809f32e59d1d87b2b8\n("rose: check NULL rose_loopback_neigh->loopback") again.\n\nWe fix it by add NULL check in rose_transmit_clear_request(). When\nthe 'dev' in 'neigh' is NULL, we don't reply the request and just\nclear it.\n\nsyzkaller don't provide repro, and I provide a syz repro like:\nr0 = syz_init_net_socket$bt_sco(0x1f, 0x5, 0x2)\nioctl$sock_inet_SIOCSIFFLAGS(r0, 0x8914, &(0x7f0000000180)={'rose0\\x00', 0x201})\nr1 = syz_init_net_socket$rose(0xb, 0x5, 0x0)\nbind$rose(r1, &(0x7f00000000c0)=@full={0xb, @dev, @null, 0x0, [@null, @null, @netrom, @netrom, @default, @null]}, 0x40)\nconnect$rose(r1, &(0x7f0000000240)=@short={0xb, @dev={0xbb, 0xbb, 0xbb, 0x1, 0x0}, @remote={0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0x1}, 0x1, @netrom={0xbb, 0xbb, 0xbb, 0xbb, 0xbb, 0x0, 0x0}}, 0x1c)

In the Linux kernel, the following vulnerability has been resolved:\n\nmISDN: fix possible memory leak in mISDN_register_device()\n\nAfer commit 1fa5ae857bb1 ("driver core: get rid of struct device's\nbus_id string array"), the name of device is allocated dynamically,\nadd put_device() to give up the reference, so that the name can be\nfreed in kobject_cleanup() when the refcount is 0.\n\nSet device class before put_device() to avoid null release() function\nWARN message in device_release().

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix inode list leak during backref walking at resolve_indirect_refs()\n\nDuring backref walking, at resolve_indirect_refs(), if we get an error\nwe jump to the 'out' label and call ulist_free() on the 'parents' ulist,\nwhich frees all the elements in the ulist - however that does not free\nany inode lists that may be attached to elements, through the 'aux' field\nof a ulist node, so we end up leaking lists if we have any attached to\nthe unodes.\n\nFix this by calling free_leaf_list() instead of ulist_free() when we exit\nfrom resolve_indirect_refs(). The static function free_leaf_list() is\nmoved up for this to be possible and it's slightly simplified by removing\nunnecessary code.

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix inode list leak during backref walking at find_parent_nodes()\n\nDuring backref walking, at find_parent_nodes(), if we are dealing with a\ndata extent and we get an error while resolving the indirect backrefs, at\nresolve_indirect_refs(), or in the while loop that iterates over the refs\nin the direct refs rbtree, we end up leaking the inode lists attached to\nthe direct refs we have in the direct refs rbtree that were not yet added\nto the refs ulist passed as argument to find_parent_nodes(). Since they\nwere not yet added to the refs ulist and prelim_release() does not free\nthe lists, on error the caller can only free the lists attached to the\nrefs that were added to the refs ulist, all the remaining refs get their\ninode lists never freed, therefore leaking their memory.\n\nFix this by having prelim_release() always free any attached inode list\nto each ref found in the rbtree, and have find_parent_nodes() set the\nref's inode list to NULL once it transfers ownership of the inode list\nto a ref added to the refs ulist passed to find_parent_nodes().

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix ulist leaks in error paths of qgroup self tests\n\nIn the test_no_shared_qgroup() and test_multiple_refs() qgroup self tests,\nif we fail to add the tree ref, remove the extent item or remove the\nextent ref, we are returning from the test function without freeing the\n"old_roots" ulist that was allocated by the previous calls to\nbtrfs_find_all_roots(). Fix that by calling ulist_free() before returning.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ipset: enforce documented limit to prevent allocating huge memory\n\nDaniel Xu reported that the hash:net,iface type of the ipset subsystem does\nnot limit adding the same network with different interfaces to a set, which\ncan lead to huge memory usage or allocation failure.\n\nThe quick reproducer is\n\n$ ipset create ACL.IN.ALL_PERMIT hash:net,iface hashsize 1048576 timeout 0\n$ for i in $(seq 0 100); do /sbin/ipset add ACL.IN.ALL_PERMIT 0.0.0.0/0,kaf_$i timeout 0 -exist; done\n\nThe backtrace when vmalloc fails:\n\n [Tue Oct 25 00:13:08 2022] ipset: vmalloc error: size 1073741848, exceeds total pages\n <...>\n [Tue Oct 25 00:13:08 2022] Call Trace:\n [Tue Oct 25 00:13:08 2022] \n [Tue Oct 25 00:13:08 2022] dump_stack_lvl+0x48/0x60\n [Tue Oct 25 00:13:08 2022] warn_alloc+0x155/0x180\n [Tue Oct 25 00:13:08 2022] __vmalloc_node_range+0x72a/0x760\n [Tue Oct 25 00:13:08 2022] ? hash_netiface4_add+0x7c0/0xb20\n [Tue Oct 25 00:13:08 2022] ? __kmalloc_large_node+0x4a/0x90\n [Tue Oct 25 00:13:08 2022] kvmalloc_node+0xa6/0xd0\n [Tue Oct 25 00:13:08 2022] ? hash_netiface4_resize+0x99/0x710\n <...>\n\nThe fix is to enforce the limit documented in the ipset(8) manpage:\n\n> The internal restriction of the hash:net,iface set type is that the same\n> network prefix cannot be stored with more than 64 different interfaces\n> in a single set.

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix use-after-free caused by l2cap_reassemble_sdu\n\nFix the race condition between the following two flows that run in\nparallel:\n\n1. l2cap_reassemble_sdu -> chan->ops->recv (l2cap_sock_recv_cb) ->\n __sock_queue_rcv_skb.\n\n2. bt_sock_recvmsg -> skb_recv_datagram, skb_free_datagram.\n\nAn SKB can be queued by the first flow and immediately dequeued and\nfreed by the second flow, therefore the callers of l2cap_reassemble_sdu\ncan't use the SKB after that function returns. However, some places\ncontinue accessing struct l2cap_ctrl that resides in the SKB's CB for a\nshort time after l2cap_reassemble_sdu returns, leading to a\nuse-after-free condition (the stack trace is below, line numbers for\nkernel 5.19.8).\n\nFix it by keeping a local copy of struct l2cap_ctrl.\n\nBUG: KASAN: use-after-free in l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth\nRead of size 1 at addr ffff88812025f2f0 by task kworker/u17:3/43169\n\nWorkqueue: hci0 hci_rx_work [bluetooth]\nCall Trace:\n \n dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4))\n print_report.cold (mm/kasan/report.c:314 mm/kasan/report.c:429)\n ? l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth\n kasan_report (mm/kasan/report.c:162 mm/kasan/report.c:493)\n ? l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth\n l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth\n l2cap_rx (net/bluetooth/l2cap_core.c:7236 net/bluetooth/l2cap_core.c:7271) bluetooth\n ret_from_fork (arch/x86/entry/entry_64.S:306)\n \n\nAllocated by task 43169:\n kasan_save_stack (mm/kasan/common.c:39)\n __kasan_slab_alloc (mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469)\n kmem_cache_alloc_node (mm/slab.h:750 mm/slub.c:3243 mm/slub.c:3293)\n __alloc_skb (net/core/skbuff.c:414)\n l2cap_recv_frag (./include/net/bluetooth/bluetooth.h:425 net/bluetooth/l2cap_core.c:8329) bluetooth\n l2cap_recv_acldata (net/bluetooth/l2cap_core.c:8442) bluetooth\n hci_rx_work (net/bluetooth/hci_core.c:3642 net/bluetooth/hci_core.c:3832) bluetooth\n process_one_work (kernel/workqueue.c:2289)\n worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2437)\n kthread (kernel/kthread.c:376)\n ret_from_fork (arch/x86/entry/entry_64.S:306)\n\nFreed by task 27920:\n kasan_save_stack (mm/kasan/common.c:39)\n kasan_set_track (mm/kasan/common.c:45)\n kasan_set_free_info (mm/kasan/generic.c:372)\n ____kasan_slab_free (mm/kasan/common.c:368 mm/kasan/common.c:328)\n slab_free_freelist_hook (mm/slub.c:1780)\n kmem_cache_free (mm/slub.c:3536 mm/slub.c:3553)\n skb_free_datagram (./include/net/sock.h:1578 ./include/net/sock.h:1639 net/core/datagram.c:323)\n bt_sock_recvmsg (net/bluetooth/af_bluetooth.c:295) bluetooth\n l2cap_sock_recvmsg (net/bluetooth/l2cap_sock.c:1212) bluetooth\n sock_read_iter (net/socket.c:1087)\n new_sync_read (./include/linux/fs.h:2052 fs/read_write.c:401)\n vfs_read (fs/read_write.c:482)\n ksys_read (fs/read_write.c:620)\n do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)\n entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: fix use-after-free in l2cap_conn_del()\n\nWhen l2cap_recv_frame() is invoked to receive data, and the cid is\nL2CAP_CID_A2MP, if the channel does not exist, it will create a channel.\nHowever, after a channel is created, the hold operation of the channel\nis not performed. In this case, the value of channel reference counting\nis 1. As a result, after hci_error_reset() is triggered, l2cap_conn_del()\ninvokes the close hook function of A2MP to release the channel. Then\n l2cap_chan_unlock(chan) will trigger UAF issue.\n\nThe process is as follows:\nReceive data:\nl2cap_data_channel()\n a2mp_channel_create() --->channel ref is 2\n l2cap_chan_put() --->channel ref is 1\n\nTriger event:\n hci_error_reset()\n hci_dev_do_close()\n ...\n l2cap_disconn_cfm()\n l2cap_conn_del()\n l2cap_chan_hold() --->channel ref is 2\n l2cap_chan_del() --->channel ref is 1\n a2mp_chan_close_cb() --->channel ref is 0, release channel\n l2cap_chan_unlock() --->UAF of channel\n\nThe detailed Call Trace is as follows:\nBUG: KASAN: use-after-free in __mutex_unlock_slowpath+0xa6/0x5e0\nRead of size 8 at addr ffff8880160664b8 by task kworker/u11:1/7593\nWorkqueue: hci0 hci_error_reset\nCall Trace:\n \n dump_stack_lvl+0xcd/0x134\n print_report.cold+0x2ba/0x719\n kasan_report+0xb1/0x1e0\n kasan_check_range+0x140/0x190\n __mutex_unlock_slowpath+0xa6/0x5e0\n l2cap_conn_del+0x404/0x7b0\n l2cap_disconn_cfm+0x8c/0xc0\n hci_conn_hash_flush+0x11f/0x260\n hci_dev_close_sync+0x5f5/0x11f0\n hci_dev_do_close+0x2d/0x70\n hci_error_reset+0x9e/0x140\n process_one_work+0x98a/0x1620\n worker_thread+0x665/0x1080\n kthread+0x2e4/0x3a0\n ret_from_fork+0x1f/0x30\n \n\nAllocated by task 7593:\n kasan_save_stack+0x1e/0x40\n __kasan_kmalloc+0xa9/0xd0\n l2cap_chan_create+0x40/0x930\n amp_mgr_create+0x96/0x990\n a2mp_channel_create+0x7d/0x150\n l2cap_recv_frame+0x51b8/0x9a70\n l2cap_recv_acldata+0xaa3/0xc00\n hci_rx_work+0x702/0x1220\n process_one_work+0x98a/0x1620\n worker_thread+0x665/0x1080\n kthread+0x2e4/0x3a0\n ret_from_fork+0x1f/0x30\n\nFreed by task 7593:\n kasan_save_stack+0x1e/0x40\n kasan_set_track+0x21/0x30\n kasan_set_free_info+0x20/0x30\n ____kasan_slab_free+0x167/0x1c0\n slab_free_freelist_hook+0x89/0x1c0\n kfree+0xe2/0x580\n l2cap_chan_put+0x22a/0x2d0\n l2cap_conn_del+0x3fc/0x7b0\n l2cap_disconn_cfm+0x8c/0xc0\n hci_conn_hash_flush+0x11f/0x260\n hci_dev_close_sync+0x5f5/0x11f0\n hci_dev_do_close+0x2d/0x70\n hci_error_reset+0x9e/0x140\n process_one_work+0x98a/0x1620\n worker_thread+0x665/0x1080\n kthread+0x2e4/0x3a0\n ret_from_fork+0x1f/0x30\n\nLast potentially related work creation:\n kasan_save_stack+0x1e/0x40\n __kasan_record_aux_stack+0xbe/0xd0\n call_rcu+0x99/0x740\n netlink_release+0xe6a/0x1cf0\n __sock_release+0xcd/0x280\n sock_close+0x18/0x20\n __fput+0x27c/0xa90\n task_work_run+0xdd/0x1a0\n exit_to_user_mode_prepare+0x23c/0x250\n syscall_exit_to_user_mode+0x19/0x50\n do_syscall_64+0x42/0x80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nSecond to last potentially related work creation:\n kasan_save_stack+0x1e/0x40\n __kasan_record_aux_stack+0xbe/0xd0\n call_rcu+0x99/0x740\n netlink_release+0xe6a/0x1cf0\n __sock_release+0xcd/0x280\n sock_close+0x18/0x20\n __fput+0x27c/0xa90\n task_work_run+0xdd/0x1a0\n exit_to_user_mode_prepare+0x23c/0x250\n syscall_exit_to_user_mode+0x19/0x50\n do_syscall_64+0x42/0x80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix memory leak in vhci_write\n\nSyzkaller reports a memory leak as follows:\n====================================\nBUG: memory leak\nunreferenced object 0xffff88810d81ac00 (size 240):\n [...]\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace:\n [] __alloc_skb+0x1f9/0x270 net/core/skbuff.c:418\n [] alloc_skb include/linux/skbuff.h:1257 [inline]\n [] bt_skb_alloc include/net/bluetooth/bluetooth.h:469 [inline]\n [] vhci_get_user drivers/bluetooth/hci_vhci.c:391 [inline]\n [] vhci_write+0x5f/0x230 drivers/bluetooth/hci_vhci.c:511\n [] call_write_iter include/linux/fs.h:2192 [inline]\n [] new_sync_write fs/read_write.c:491 [inline]\n [] vfs_write+0x42d/0x540 fs/read_write.c:578\n [] ksys_write+0x9d/0x160 fs/read_write.c:631\n [] do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n [] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n [] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n====================================\n\nHCI core will uses hci_rx_work() to process frame, which is queued to\nthe hdev->rx_q tail in hci_recv_frame() by HCI driver.\n\nYet the problem is that, HCI core may not free the skb after handling\nACL data packets. To be more specific, when start fragment does not\ncontain the L2CAP length, HCI core just copies skb into conn->rx_skb and\nfinishes frame process in l2cap_recv_acldata(), without freeing the skb,\nwhich triggers the above memory leak.\n\nThis patch solves it by releasing the relative skb, after processing\nthe above case in l2cap_recv_acldata().

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: mdio: fix undefined behavior in bit shift for __mdiobus_register\n\nShifting signed 32-bit value by 31 bits is undefined, so changing\nsignificant bit to unsigned. The UBSAN warning calltrace like below:\n\nUBSAN: shift-out-of-bounds in drivers/net/phy/mdio_bus.c:586:27\nleft shift of 1 by 31 places cannot be represented in type 'int'\nCall Trace:\n \n dump_stack_lvl+0x7d/0xa5\n dump_stack+0x15/0x1b\n ubsan_epilogue+0xe/0x4e\n __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c\n __mdiobus_register+0x49d/0x4e0\n fixed_mdio_bus_init+0xd8/0x12d\n do_one_initcall+0x76/0x430\n kernel_init_freeable+0x3b3/0x422\n kernel_init+0x24/0x1e0\n ret_from_fork+0x1f/0x30\n

In the Linux kernel, the following vulnerability has been resolved:\n\nibmvnic: Free rwi on reset success\n\nFree the rwi structure in the event that the last rwi in the list\nprocessed successfully. The logic in commit 4f408e1fa6e1 ("ibmvnic:\nretry reset if there are no other resets") introduces an issue that\nresults in a 32 byte memory leak whenever the last rwi in the list\ngets processed.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: Fix possible leaked pernet namespace in smc_init()\n\nIn smc_init(), register_pernet_subsys(&smc_net_stat_ops) is called\nwithout any error handling.\nIf it fails, registering of &smc_net_ops won't be reverted.\nAnd if smc_nl_init() fails, &smc_net_stat_ops itself won't be reverted.\n\nThis leaves wild ops in subsystem linkedlist and when another module\ntries to call register_pernet_operations() it triggers page fault:\n\nBUG: unable to handle page fault for address: fffffbfff81b964c\nRIP: 0010:register_pernet_operations+0x1b9/0x5f0\nCall Trace:\n \n register_pernet_subsys+0x29/0x40\n ebtables_init+0x58/0x1000 [ebtables]\n ...

In the Linux kernel, the following vulnerability has been resolved:\n\nnet, neigh: Fix null-ptr-deref in neigh_table_clear()\n\nWhen IPv6 module gets initialized but hits an error in the middle,\nkenel panic with:\n\nKASAN: null-ptr-deref in range [0x0000000000000598-0x000000000000059f]\nCPU: 1 PID: 361 Comm: insmod\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996)\nRIP: 0010:__neigh_ifdown.isra.0+0x24b/0x370\nRSP: 0018:ffff888012677908 EFLAGS: 00000202\n...\nCall Trace:\n \n neigh_table_clear+0x94/0x2d0\n ndisc_cleanup+0x27/0x40 [ipv6]\n inet6_init+0x21c/0x2cb [ipv6]\n do_one_initcall+0xd3/0x4d0\n do_init_module+0x1ae/0x670\n...\nKernel panic - not syncing: Fatal exception\n\nWhen ipv6 initialization fails, it will try to cleanup and calls:\n\nneigh_table_clear()\n neigh_ifdown(tbl, NULL)\n pneigh_queue_purge(&tbl->proxy_queue, dev_net(dev == NULL))\n # dev_net(NULL) triggers null-ptr-deref.\n\nFix it by passing NULL to pneigh_queue_purge() in neigh_ifdown() if dev\nis NULL, to make kernel not panic immediately.

In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: fix WARNING in ip6_route_net_exit_late()\n\nDuring the initialization of ip6_route_net_init_late(), if file\nipv6_route or rt6_stats fails to be created, the initialization is\nsuccessful by default. Therefore, the ipv6_route or rt6_stats file\ndoesn't be found during the remove in ip6_route_net_exit_late(). It\nwill cause WRNING.\n\nThe following is the stack information:\nname 'rt6_stats'\nWARNING: CPU: 0 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460\nModules linked in:\nWorkqueue: netns cleanup_net\nRIP: 0010:remove_proc_entry+0x389/0x460\nPKRU: 55555554\nCall Trace:\n\nops_exit_list+0xb0/0x170\ncleanup_net+0x4ea/0xb00\nprocess_one_work+0x9bf/0x1710\nworker_thread+0x665/0x1080\nkthread+0x2e4/0x3a0\nret_from_fork+0x1f/0x30\n

In the Linux kernel, the following vulnerability has been resolved:\n\nblock: Fix possible memory leak for rq_wb on add_disk failure\n\nkmemleak reported memory leaks in device_add_disk():\n\nkmemleak: 3 new suspected memory leaks\n\nunreferenced object 0xffff88800f420800 (size 512):\n comm "modprobe", pid 4275, jiffies 4295639067 (age 223.512s)\n hex dump (first 32 bytes):\n 04 00 00 00 08 00 00 00 01 00 00 00 00 00 00 00 ................\n 00 e1 f5 05 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace:\n [<00000000d3662699>] kmalloc_trace+0x26/0x60\n [<00000000edc7aadc>] wbt_init+0x50/0x6f0\n [<0000000069601d16>] wbt_enable_default+0x157/0x1c0\n [<0000000028fc393f>] blk_register_queue+0x2a4/0x420\n [<000000007345a042>] device_add_disk+0x6fd/0xe40\n [<0000000060e6aab0>] nbd_dev_add+0x828/0xbf0 [nbd]\n ...\n\nIt is because the memory allocated in wbt_enable_default() is not\nreleased in device_add_disk() error path.\nNormally, these memory are freed in:\n\ndel_gendisk()\n rq_qos_exit()\n rqos->ops->exit(rqos);\n wbt_exit()\n\nSo rq_qos_exit() is called to free the rq_wb memory for wbt_init().\nHowever in the error path of device_add_disk(), only\nblk_unregister_queue() is called and make rq_wb memory leaked.\n\nAdd rq_qos_exit() to the error path to fix it.

In the Linux kernel, the following vulnerability has been resolved:\n\nblk-mq: Fix kmemleak in blk_mq_init_allocated_queue\n\nThere is a kmemleak caused by modprobe null_blk.ko\n\nunreferenced object 0xffff8881acb1f000 (size 1024):\n comm "modprobe", pid 836, jiffies 4294971190 (age 27.068s)\n hex dump (first 32 bytes):\n 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........\n ff ff ff ff ff ff ff ff 00 53 99 9e ff ff ff ff .........S......\n backtrace:\n [<000000004a10c249>] kmalloc_node_trace+0x22/0x60\n [<00000000648f7950>] blk_mq_alloc_and_init_hctx+0x289/0x350\n [<00000000af06de0e>] blk_mq_realloc_hw_ctxs+0x2fe/0x3d0\n [<00000000e00c1872>] blk_mq_init_allocated_queue+0x48c/0x1440\n [<00000000d16b4e68>] __blk_mq_alloc_disk+0xc8/0x1c0\n [<00000000d10c98c3>] 0xffffffffc450d69d\n [<00000000b9299f48>] 0xffffffffc4538392\n [<0000000061c39ed6>] do_one_initcall+0xd0/0x4f0\n [<00000000b389383b>] do_init_module+0x1a4/0x680\n [<0000000087cf3542>] load_module+0x6249/0x7110\n [<00000000beba61b8>] __do_sys_finit_module+0x140/0x200\n [<00000000fdcfff51>] do_syscall_64+0x35/0x80\n [<000000003c0f1f71>] entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nThat is because q->ma_ops is set to NULL before blk_release_queue is\ncalled.\n\nblk_mq_init_queue_data\n blk_mq_init_allocated_queue\n blk_mq_realloc_hw_ctxs\n for (i = 0; i < set->nr_hw_queues; i++) {\n old_hctx = xa_load(&q->hctx_table, i);\n if (!blk_mq_alloc_and_init_hctx(.., i, ..)) [1]\n if (!old_hctx)\n break;\n\n xa_for_each_start(&q->hctx_table, j, hctx, j)\n blk_mq_exit_hctx(q, set, hctx, j); [2]\n\n if (!q->nr_hw_queues) [3]\n goto err_hctxs;\n\n err_exit:\n q->mq_ops = NULL; [4]\n\n blk_put_queue\n blk_release_queue\n if (queue_is_mq(q)) [5]\n blk_mq_release(q);\n\n[1]: blk_mq_alloc_and_init_hctx failed at i != 0.\n[2]: The hctxs allocated by [1] are moved to q->unused_hctx_list and\nwill be cleaned up in blk_mq_release.\n[3]: q->nr_hw_queues is 0.\n[4]: Set q->mq_ops to NULL.\n[5]: queue_is_mq returns false due to [4]. And blk_mq_release\nwill not be called. The hctxs in q->unused_hctx_list are leaked.\n\nTo fix it, call blk_release_queue in exception path.

In the Linux kernel, the following vulnerability has been resolved:\n\ni2c: piix4: Fix adapter not be removed in piix4_remove()\n\nIn piix4_probe(), the piix4 adapter will be registered in:\n\n piix4_probe()\n piix4_add_adapters_sb800() / piix4_add_adapter()\n i2c_add_adapter()\n\nBased on the probed device type, piix4_add_adapters_sb800() or single\npiix4_add_adapter() will be called.\nFor the former case, piix4_adapter_count is set as the number of adapters,\nwhile for antoher case it is not set and kept default *zero*.\n\nWhen piix4 is removed, piix4_remove() removes the adapters added in\npiix4_probe(), basing on the piix4_adapter_count value.\nBecause the count is zero for the single adapter case, the adapter won't\nbe removed and makes the sources allocated for adapter leaked, such as\nthe i2c client and device.\n\nThese sources can still be accessed by i2c or bus and cause problems.\nAn easily reproduced case is that if a new adapter is registered, i2c\nwill get the leaked adapter and try to call smbus_algorithm, which was\nalready freed:\n\nTriggered by: rmmod i2c_piix4 && modprobe max31730\n\n BUG: unable to handle page fault for address: ffffffffc053d860\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n Oops: 0000 [#1] PREEMPT SMP KASAN\n CPU: 0 PID: 3752 Comm: modprobe Tainted: G\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)\n RIP: 0010:i2c_default_probe (drivers/i2c/i2c-core-base.c:2259) i2c_core\n RSP: 0018:ffff888107477710 EFLAGS: 00000246\n ...\n \n i2c_detect (drivers/i2c/i2c-core-base.c:2302) i2c_core\n __process_new_driver (drivers/i2c/i2c-core-base.c:1336) i2c_core\n bus_for_each_dev (drivers/base/bus.c:301)\n i2c_for_each_dev (drivers/i2c/i2c-core-base.c:1823) i2c_core\n i2c_register_driver (drivers/i2c/i2c-core-base.c:1861) i2c_core\n do_one_initcall (init/main.c:1296)\n do_init_module (kernel/module/main.c:2455)\n ...\n \n ---[ end trace 0000000000000000 ]---\n\nFix this problem by correctly set piix4_adapter_count as 1 for the\nsingle adapter so it can be normally removed.

In the Linux kernel, the following vulnerability has been resolved:\n\nfscrypt: stop using keyrings subsystem for fscrypt_master_key\n\nThe approach of fs/crypto/ internally managing the fscrypt_master_key\nstructs as the payloads of "struct key" objects contained in a\n"struct key" keyring has outlived its usefulness. The original idea was\nto simplify the code by reusing code from the keyrings subsystem.\nHowever, several issues have arisen that can't easily be resolved:\n\n- When a master key struct is destroyed, blk_crypto_evict_key() must be\n called on any per-mode keys embedded in it. (This started being the\n case when inline encryption support was added.) Yet, the keyrings\n subsystem can arbitrarily delay the destruction of keys, even past the\n time the filesystem was unmounted. Therefore, currently there is no\n easy way to call blk_crypto_evict_key() when a master key is\n destroyed. Currently, this is worked around by holding an extra\n reference to the filesystem's request_queue(s). But it was overlooked\n that the request_queue reference is *not* guaranteed to pin the\n corresponding blk_crypto_profile too; for device-mapper devices that\n support inline crypto, it doesn't. This can cause a use-after-free.\n\n- When the last inode that was using an incompletely-removed master key\n is evicted, the master key removal is completed by removing the key\n struct from the keyring. Currently this is done via key_invalidate().\n Yet, key_invalidate() takes the key semaphore. This can deadlock when\n called from the shrinker, since in fscrypt_ioctl_add_key(), memory is\n allocated with GFP_KERNEL under the same semaphore.\n\n- More generally, the fact that the keyrings subsystem can arbitrarily\n delay the destruction of keys (via garbage collection delay, or via\n random processes getting temporary key references) is undesirable, as\n it means we can't strictly guarantee that all secrets are ever wiped.\n\n- Doing the master key lookups via the keyrings subsystem results in the\n key_permission LSM hook being called. fscrypt doesn't want this, as\n all access control for encrypted files is designed to happen via the\n files themselves, like any other files. The workaround which SELinux\n users are using is to change their SELinux policy to grant key search\n access to all domains. This works, but it is an odd extra step that\n shouldn't really have to be done.\n\nThe fix for all these issues is to change the implementation to what I\nshould have done originally: don't use the keyrings subsystem to keep\ntrack of the filesystem's fscrypt_master_key structs. Instead, just\nstore them in a regular kernel data structure, and rework the reference\ncounting, locking, and lifetime accordingly. Retain support for\nRCU-mode key lookups by using a hash table. Replace fscrypt_sb_free()\nwith fscrypt_sb_delete(), which releases the keys synchronously and runs\na bit earlier during unmount, so that block devices are still available.\n\nA side effect of this patch is that neither the master keys themselves\nnor the filesystem keyrings will be listed in /proc/keys anymore.\n("Master key users" and the master key users keyrings will still be\nlisted.) However, this was mostly an implementation detail, and it was\nintended just for debugging purposes. I don't know of anyone using it.\n\nThis patch does *not* change how "master key users" (->mk_users) works;\nthat still uses the keyrings subsystem. That is still needed for key\nquotas, and changing that isn't necessary to solve the issues listed\nabove. If we decide to change that too, it would be a separate patch.\n\nI've marked this as fixing the original commit that added the fscrypt\nkeyring, but as noted above the most important issue that this patch\nfixes wasn't introduced until the addition of inline encryption support.

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix tree mod log mishandling of reallocated nodes\n\nWe have been seeing the following panic in production\n\n kernel BUG at fs/btrfs/tree-mod-log.c:677!\n invalid opcode: 0000 [#1] SMP\n RIP: 0010:tree_mod_log_rewind+0x1b4/0x200\n RSP: 0000:ffffc9002c02f890 EFLAGS: 00010293\n RAX: 0000000000000003 RBX: ffff8882b448c700 RCX: 0000000000000000\n RDX: 0000000000008000 RSI: 00000000000000a7 RDI: ffff88877d831c00\n RBP: 0000000000000002 R08: 000000000000009f R09: 0000000000000000\n R10: 0000000000000000 R11: 0000000000100c40 R12: 0000000000000001\n R13: ffff8886c26d6a00 R14: ffff88829f5424f8 R15: ffff88877d831a00\n FS: 00007fee1d80c780(0000) GS:ffff8890400c0000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007fee1963a020 CR3: 0000000434f33002 CR4: 00000000007706e0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n PKRU: 55555554\n Call Trace:\n btrfs_get_old_root+0x12b/0x420\n btrfs_search_old_slot+0x64/0x2f0\n ? tree_mod_log_oldest_root+0x3d/0xf0\n resolve_indirect_ref+0xfd/0x660\n ? ulist_alloc+0x31/0x60\n ? kmem_cache_alloc_trace+0x114/0x2c0\n find_parent_nodes+0x97a/0x17e0\n ? ulist_alloc+0x30/0x60\n btrfs_find_all_roots_safe+0x97/0x150\n iterate_extent_inodes+0x154/0x370\n ? btrfs_search_path_in_tree+0x240/0x240\n iterate_inodes_from_logical+0x98/0xd0\n ? btrfs_search_path_in_tree+0x240/0x240\n btrfs_ioctl_logical_to_ino+0xd9/0x180\n btrfs_ioctl+0xe2/0x2ec0\n ? __mod_memcg_lruvec_state+0x3d/0x280\n ? do_sys_openat2+0x6d/0x140\n ? kretprobe_dispatcher+0x47/0x70\n ? kretprobe_rethook_handler+0x38/0x50\n ? rethook_trampoline_handler+0x82/0x140\n ? arch_rethook_trampoline_callback+0x3b/0x50\n ? kmem_cache_free+0xfb/0x270\n ? do_sys_openat2+0xd5/0x140\n __x64_sys_ioctl+0x71/0xb0\n do_syscall_64+0x2d/0x40\n\nWhich is this code in tree_mod_log_rewind()\n\n switch (tm->op) {\n case BTRFS_MOD_LOG_KEY_REMOVE_WHILE_FREEING:\n BUG_ON(tm->slot < n);\n\nThis occurs because we replay the nodes in order that they happened, and\nwhen we do a REPLACE we will log a REMOVE_WHILE_FREEING for every slot,\nstarting at 0. 'n' here is the number of items in this block, which in\nthis case was 1, but we had 2 REMOVE_WHILE_FREEING operations.\n\nThe actual root cause of this was that we were replaying operations for\na block that shouldn't have been replayed. Consider the following\nsequence of events\n\n1. We have an already modified root, and we do a btrfs_get_tree_mod_seq().\n2. We begin removing items from this root, triggering KEY_REPLACE for\n it's child slots.\n3. We remove one of the 2 children this root node points to, thus triggering\n the root node promotion of the remaining child, and freeing this node.\n4. We modify a new root, and re-allocate the above node to the root node of\n this other root.\n\nThe tree mod log looks something like this\n\n logical 0 op KEY_REPLACE (slot 1) seq 2\n logical 0 op KEY_REMOVE (slot 1) seq 3\n logical 0 op KEY_REMOVE_WHILE_FREEING (slot 0) seq 4\n logical 4096 op LOG_ROOT_REPLACE (old logical 0) seq 5\n logical 8192 op KEY_REMOVE_WHILE_FREEING (slot 1) seq 6\n logical 8192 op KEY_REMOVE_WHILE_FREEING (slot 0) seq 7\n logical 0 op LOG_ROOT_REPLACE (old logical 8192) seq 8\n\n>From here the bug is triggered by the following steps\n\n1. Call btrfs_get_old_root() on the new_root.\n2. We call tree_mod_log_oldest_root(btrfs_root_node(new_root)), which is\n currently logical 0.\n3. tree_mod_log_oldest_root() calls tree_mod_log_search_oldest(), which\n gives us the KEY_REPLACE seq 2, and since that's not a\n LOG_ROOT_REPLACE we incorrectly believe that we don't have an old\n root, because we expect that the most recent change should be a\n LOG_ROOT_REPLACE.\n4. Back in tree_mod_log_oldest_root() we don't have a LOG_ROOT_REPLACE,\n so we don't set old_root, we simply use our e\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\ncxl/pmem: Fix cxl_pmem_region and cxl_memdev leak\n\nWhen a cxl_nvdimm object goes through a ->remove() event (device\nphysically removed, nvdimm-bridge disabled, or nvdimm device disabled),\nthen any associated regions must also be disabled. As highlighted by the\ncxl-create-region.sh test [1], a single device may host multiple\nregions, but the driver was only tracking one region at a time. This\nleads to a situation where only the last enabled region per nvdimm\ndevice is cleaned up properly. Other regions are leaked, and this also\ncauses cxl_memdev reference leaks.\n\nFix the tracking by allowing cxl_nvdimm objects to track multiple region\nassociations.

In the Linux kernel, the following vulnerability has been resolved:\n\ncxl/region: Fix decoder allocation crash\n\nWhen an intermediate port's decoders have been exhausted by existing\nregions, and creating a new region with the port in question in it's\nhierarchical path is attempted, cxl_port_attach_region() fails to find a\nport decoder (as would be expected), and drops into the failure / cleanup\npath.\n\nHowever, during cleanup of the region reference, a sanity check attempts\nto dereference the decoder, which in the above case didn't exist. This\ncauses a NULL pointer dereference BUG.\n\nTo fix this, refactor the decoder allocation and de-allocation into\nhelper routines, and in this 'free' routine, check that the decoder,\n@cxld, is valid before attempting any operations on it.

In the Linux kernel, the following vulnerability has been resolved:\n\ncxl/region: Fix region HPA ordering validation\n\nSome regions may not have any address space allocated. Skip them when\nvalidating HPA order otherwise a crash like the following may result:\n\n devm_cxl_add_region: cxl_acpi cxl_acpi.0: decoder3.4: created region9\n BUG: kernel NULL pointer dereference, address: 0000000000000000\n [..]\n RIP: 0010:store_targetN+0x655/0x1740 [cxl_core]\n [..]\n Call Trace:\n \n kernfs_fop_write_iter+0x144/0x200\n vfs_write+0x24a/0x4d0\n ksys_write+0x69/0xf0\n do_syscall_64+0x3a/0x90\n\nstore_targetN+0x655/0x1740:\nalloc_region_ref at drivers/cxl/core/region.c:676\n(inlined by) cxl_port_attach_region at drivers/cxl/core/region.c:850\n(inlined by) cxl_region_attach at drivers/cxl/core/region.c:1290\n(inlined by) attach_target at drivers/cxl/core/region.c:1410\n(inlined by) store_targetN at drivers/cxl/core/region.c:1453

In the Linux kernel, the following vulnerability has been resolved:\n\ncxl/region: Fix cxl_region leak, cleanup targets at region delete\n\nWhen a region is deleted any targets that have been previously assigned\nto that region hold references to it. Trigger those references to\ndrop by detaching all targets at unregister_region() time.\n\nOtherwise that region object will leak as userspace has lost the ability\nto detach targets once region sysfs is torn down.

In the Linux kernel, the following vulnerability has been resolved:\n\nftrace: Fix use-after-free for dynamic ftrace_ops\n\nKASAN reported a use-after-free with ftrace ops [1]. It was found from\nvmcore that perf had registered two ops with the same content\nsuccessively, both dynamic. After unregistering the second ops, a\nuse-after-free occurred.\n\nIn ftrace_shutdown(), when the second ops is unregistered, the\nFTRACE_UPDATE_CALLS command is not set because there is another enabled\nops with the same content. Also, both ops are dynamic and the ftrace\ncallback function is ftrace_ops_list_func, so the\nFTRACE_UPDATE_TRACE_FUNC command will not be set. Eventually the value\nof 'command' will be 0 and ftrace_shutdown() will skip the rcu\nsynchronization.\n\nHowever, ftrace may be activated. When the ops is released, another CPU\nmay be accessing the ops. Add the missing synchronization to fix this\nproblem.\n\n[1]\nBUG: KASAN: use-after-free in __ftrace_ops_list_func kernel/trace/ftrace.c:7020 [inline]\nBUG: KASAN: use-after-free in ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049\nRead of size 8 at addr ffff56551965bbc8 by task syz-executor.2/14468\n\nCPU: 1 PID: 14468 Comm: syz-executor.2 Not tainted 5.10.0 #7\nHardware name: linux,dummy-virt (DT)\nCall trace:\n dump_backtrace+0x0/0x40c arch/arm64/kernel/stacktrace.c:132\n show_stack+0x30/0x40 arch/arm64/kernel/stacktrace.c:196\n __dump_stack lib/dump_stack.c:77 [inline]\n dump_stack+0x1b4/0x248 lib/dump_stack.c:118\n print_address_description.constprop.0+0x28/0x48c mm/kasan/report.c:387\n __kasan_report mm/kasan/report.c:547 [inline]\n kasan_report+0x118/0x210 mm/kasan/report.c:564\n check_memory_region_inline mm/kasan/generic.c:187 [inline]\n __asan_load8+0x98/0xc0 mm/kasan/generic.c:253\n __ftrace_ops_list_func kernel/trace/ftrace.c:7020 [inline]\n ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049\n ftrace_graph_call+0x0/0x4\n __might_sleep+0x8/0x100 include/linux/perf_event.h:1170\n __might_fault mm/memory.c:5183 [inline]\n __might_fault+0x58/0x70 mm/memory.c:5171\n do_strncpy_from_user lib/strncpy_from_user.c:41 [inline]\n strncpy_from_user+0x1f4/0x4b0 lib/strncpy_from_user.c:139\n getname_flags+0xb0/0x31c fs/namei.c:149\n getname+0x2c/0x40 fs/namei.c:209\n [...]\n\nAllocated by task 14445:\n kasan_save_stack+0x24/0x50 mm/kasan/common.c:48\n kasan_set_track mm/kasan/common.c:56 [inline]\n __kasan_kmalloc mm/kasan/common.c:479 [inline]\n __kasan_kmalloc.constprop.0+0x110/0x13c mm/kasan/common.c:449\n kasan_kmalloc+0xc/0x14 mm/kasan/common.c:493\n kmem_cache_alloc_trace+0x440/0x924 mm/slub.c:2950\n kmalloc include/linux/slab.h:563 [inline]\n kzalloc include/linux/slab.h:675 [inline]\n perf_event_alloc.part.0+0xb4/0x1350 kernel/events/core.c:11230\n perf_event_alloc kernel/events/core.c:11733 [inline]\n __do_sys_perf_event_open kernel/events/core.c:11831 [inline]\n __se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723\n __arm64_sys_perf_event_open+0x6c/0x80 kernel/events/core.c:11723\n [...]\n\nFreed by task 14445:\n kasan_save_stack+0x24/0x50 mm/kasan/common.c:48\n kasan_set_track+0x24/0x34 mm/kasan/common.c:56\n kasan_set_free_info+0x20/0x40 mm/kasan/generic.c:358\n __kasan_slab_free.part.0+0x11c/0x1b0 mm/kasan/common.c:437\n __kasan_slab_free mm/kasan/common.c:445 [inline]\n kasan_slab_free+0x2c/0x40 mm/kasan/common.c:446\n slab_free_hook mm/slub.c:1569 [inline]\n slab_free_freelist_hook mm/slub.c:1608 [inline]\n slab_free mm/slub.c:3179 [inline]\n kfree+0x12c/0xc10 mm/slub.c:4176\n perf_event_alloc.part.0+0xa0c/0x1350 kernel/events/core.c:11434\n perf_event_alloc kernel/events/core.c:11733 [inline]\n __do_sys_perf_event_open kernel/events/core.c:11831 [inline]\n __se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723\n [...]

In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: kprobe: Fix memory leak in test_gen_kprobe/kretprobe_cmd()\n\ntest_gen_kprobe_cmd() only free buf in fail path, hence buf will leak\nwhen there is no failure. Move kfree(buf) from fail path to common path\nto prevent the memleak. The same reason and solution in\ntest_gen_kretprobe_cmd().\n\nunreferenced object 0xffff888143b14000 (size 2048):\n comm "insmod", pid 52490, jiffies 4301890980 (age 40.553s)\n hex dump (first 32 bytes):\n 70 3a 6b 70 72 6f 62 65 73 2f 67 65 6e 5f 6b 70 p:kprobes/gen_kp\n 72 6f 62 65 5f 74 65 73 74 20 64 6f 5f 73 79 73 robe_test do_sys\n backtrace:\n [<000000006d7b836b>] kmalloc_trace+0x27/0xa0\n [<0000000009528b5b>] 0xffffffffa059006f\n [<000000008408b580>] do_one_initcall+0x87/0x2a0\n [<00000000c4980a7e>] do_init_module+0xdf/0x320\n [<00000000d775aad0>] load_module+0x3006/0x3390\n [<00000000e9a74b80>] __do_sys_finit_module+0x113/0x1b0\n [<000000003726480d>] do_syscall_64+0x35/0x80\n [<000000003441e93b>] entry_SYSCALL_64_after_hwframe+0x46/0xb0

In the Linux kernel, the following vulnerability has been resolved:\n\nring-buffer: Check for NULL cpu_buffer in ring_buffer_wake_waiters()\n\nOn some machines the number of listed CPUs may be bigger than the actual\nCPUs that exist. The tracing subsystem allocates a per_cpu directory with\naccess to the per CPU ring buffer via a cpuX file. But to save space, the\nring buffer will only allocate buffers for online CPUs, even though the\nCPU array will be as big as the nr_cpu_ids.\n\nWith the addition of waking waiters on the ring buffer when closing the\nfile, the ring_buffer_wake_waiters() now needs to make sure that the\nbuffer is allocated (with the irq_work allocated with it) before trying to\nwake waiters, as it will cause a NULL pointer dereference.\n\nWhile debugging this, I added a NULL check for the buffer itself (which is\nOK to do), and also NULL pointer checks against buffer->buffers (which is\nnot fine, and will WARN) as well as making sure the CPU number passed in\nis within the nr_cpu_ids (which is also not fine if it isn't).\n\n\nBugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1204705

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: meson: vdec: fix possible refcount leak in vdec_probe()\n\nv4l2_device_unregister need to be called to put the refcount got by\nv4l2_device_register when vdec_probe fails or vdec_remove is called.

In the Linux kernel, the following vulnerability has been resolved:\n\nx86/tdx: Panic on bad configs that #VE on "private" memory access\n\nAll normal kernel memory is "TDX private memory". This includes\neverything from kernel stacks to kernel text. Handling\nexceptions on arbitrary accesses to kernel memory is essentially\nimpossible because they can happen in horribly nasty places like\nkernel entry/exit. But, TDX hardware can theoretically _deliver_\na virtualization exception (#VE) on any access to private memory.\n\nBut, it's not as bad as it sounds. TDX can be configured to never\ndeliver these exceptions on private memory with a "TD attribute"\ncalled ATTR_SEPT_VE_DISABLE. The guest has no way to *set* this\nattribute, but it can check it.\n\nEnsure ATTR_SEPT_VE_DISABLE is set in early boot. panic() if it\nis unset. There is no sane way for Linux to run with this\nattribute clear so a panic() is appropriate.\n\nThere's small window during boot before the check where kernel\nhas an early #VE handler. But the handler is only for port I/O\nand will also panic() as soon as it sees any other #VE, such as\na one generated by a private memory access.\n\n[ dhansen: Rewrite changelog and rebase on new tdx_parse_tdinfo().\n Add Kirill's tested-by because I made changes since\n he wrote this. ]

In the Linux kernel, the following vulnerability has been resolved:\n\nACPI: APEI: Fix integer overflow in ghes_estatus_pool_init()\n\nChange num_ghes from int to unsigned int, preventing an overflow\nand causing subsequent vmalloc() to fail.\n\nThe overflow happens in ghes_estatus_pool_init() when calculating\nlen during execution of the statement below as both multiplication\noperands here are signed int:\n\nlen += (num_ghes * GHES_ESOURCE_PREALLOC_MAX_SIZE);\n\nThe following call trace is observed because of this bug:\n\n[ 9.317108] swapper/0: vmalloc error: size 18446744071562596352, exceeds total pages, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0-1\n[ 9.317131] Call Trace:\n[ 9.317134] \n[ 9.317137] dump_stack_lvl+0x49/0x5f\n[ 9.317145] dump_stack+0x10/0x12\n[ 9.317146] warn_alloc.cold+0x7b/0xdf\n[ 9.317150] ? __device_attach+0x16a/0x1b0\n[ 9.317155] __vmalloc_node_range+0x702/0x740\n[ 9.317160] ? device_add+0x17f/0x920\n[ 9.317164] ? dev_set_name+0x53/0x70\n[ 9.317166] ? platform_device_add+0xf9/0x240\n[ 9.317168] __vmalloc_node+0x49/0x50\n[ 9.317170] ? ghes_estatus_pool_init+0x43/0xa0\n[ 9.317176] vmalloc+0x21/0x30\n[ 9.317177] ghes_estatus_pool_init+0x43/0xa0\n[ 9.317179] acpi_hest_init+0x129/0x19c\n[ 9.317185] acpi_init+0x434/0x4a4\n[ 9.317188] ? acpi_sleep_proc_init+0x2a/0x2a\n[ 9.317190] do_one_initcall+0x48/0x200\n[ 9.317195] kernel_init_freeable+0x221/0x284\n[ 9.317200] ? rest_init+0xe0/0xe0\n[ 9.317204] kernel_init+0x1a/0x130\n[ 9.317205] ret_from_fork+0x22/0x30\n[ 9.317208] \n\n[ rjw: Subject and changelog edits ]

In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: smm: number of GPRs in the SMRAM image depends on the image format\n\nOn 64 bit host, if the guest doesn't have X86_FEATURE_LM, KVM will\naccess 16 gprs to 32-bit smram image, causing out-ouf-bound ram\naccess.\n\nOn 32 bit host, the rsm_load_state_64/enter_smm_save_state_64\nis compiled out, thus access overflow can't happen.

In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: Reject attempts to consume or refresh inactive gfn_to_pfn_cache\n\nReject kvm_gpc_check() and kvm_gpc_refresh() if the cache is inactive.\nNot checking the active flag during refresh is particularly egregious, as\nKVM can end up with a valid, inactive cache, which can lead to a variety\nof use-after-free bugs, e.g. consuming a NULL kernel pointer or missing\nan mmu_notifier invalidation due to the cache not being on the list of\ngfns to invalidate.\n\nNote, "active" needs to be set if and only if the cache is on the list\nof caches, i.e. is reachable via mmu_notifier events. If a relevant\nmmu_notifier event occurs while the cache is "active" but not on the\nlist, KVM will not acquire the cache's lock and so will not serailize\nthe mmu_notifier event with active users and/or kvm_gpc_refresh().\n\nA race between KVM_XEN_ATTR_TYPE_SHARED_INFO and KVM_XEN_HVM_EVTCHN_SEND\ncan be exploited to trigger the bug.\n\n1. Deactivate shinfo cache:\n\nkvm_xen_hvm_set_attr\ncase KVM_XEN_ATTR_TYPE_SHARED_INFO\n kvm_gpc_deactivate\n kvm_gpc_unmap\n gpc->valid = false\n gpc->khva = NULL\n gpc->active = false\n\nResult: active = false, valid = false\n\n2. Cause cache refresh:\n\nkvm_arch_vm_ioctl\ncase KVM_XEN_HVM_EVTCHN_SEND\n kvm_xen_hvm_evtchn_send\n kvm_xen_set_evtchn\n kvm_xen_set_evtchn_fast\n kvm_gpc_check\n return -EWOULDBLOCK because !gpc->valid\n kvm_xen_set_evtchn_fast\n return -EWOULDBLOCK\n kvm_gpc_refresh\n hva_to_pfn_retry\n gpc->valid = true\n gpc->khva = not NULL\n\nResult: active = false, valid = true\n\n3. Race ioctl KVM_XEN_HVM_EVTCHN_SEND against ioctl\nKVM_XEN_ATTR_TYPE_SHARED_INFO:\n\nkvm_arch_vm_ioctl\ncase KVM_XEN_HVM_EVTCHN_SEND\n kvm_xen_hvm_evtchn_send\n kvm_xen_set_evtchn\n kvm_xen_set_evtchn_fast\n read_lock gpc->lock\n kvm_xen_hvm_set_attr case\n KVM_XEN_ATTR_TYPE_SHARED_INFO\n mutex_lock kvm->lock\n kvm_xen_shared_info_init\n kvm_gpc_activate\n gpc->khva = NULL\n kvm_gpc_check\n [ Check passes because gpc->valid is\n still true, even though gpc->khva\n is already NULL. ]\n shinfo = gpc->khva\n pending_bits = shinfo->evtchn_pending\n CRASH: test_and_set_bit(..., pending_bits)

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: fix memory leak in query_regdb_file()\n\nIn the function query_regdb_file() the alpha2 parameter is duplicated\nusing kmemdup() and subsequently freed in regdb_fw_cb(). However,\nrequest_firmware_nowait() can fail without calling regdb_fw_cb() and\nthus leak memory.