In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: airspy: fix memory leak in airspy probe\n\nThe commit ca9dc8d06ab6 ("media: airspy: respect the DMA coherency\n rules") moves variable buf from stack to heap, however, it only frees\nbuf in the error handling code, missing deallocation in the success\npath.\n\nFix this by freeing buf in the success path since this variable does not\nhave any references in other code.

In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: Intel: avs: Fix potential RX buffer overflow\n\nIf an event caused firmware to return invalid RX size for\nLARGE_CONFIG_GET, memcpy_fromio() could end up copying too many bytes.\nFix by utilizing min_t().

In the Linux kernel, the following vulnerability has been resolved:\n\nmtd: maps: pxa2xx-flash: fix memory leak in probe\n\nFree 'info' upon remapping error to avoid a memory leak.\n\n[: Reword the commit log]

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nrtc: msc313: Fix function prototype mismatch in msc313_rtc_probe()\n\nWith clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),\nindirect call targets are validated against the expected function\npointer prototype to make sure the call target is valid to help mitigate\nROP attacks. If they are not identical, there is a failure at run time,\nwhich manifests as either a kernel panic or thread getting killed.\n\nmsc313_rtc_probe() was passing clk_disable_unprepare() directly, which\ndid not have matching prototypes for devm_add_action_or_reset()'s\ncallback argument. Refactor to use devm_clk_get_enabled() instead.\n\nThis was found as a result of Clang's new -Wcast-function-type-strict\nflag, which is more sensitive than the simpler -Wcast-function-type,\nwhich only checks for type width mismatches.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: fix potential memory leak in brcmf_netdev_start_xmit()\n\nThe brcmf_netdev_start_xmit() returns NETDEV_TX_OK without freeing skb\nin case of pskb_expand_head() fails, add dev_kfree_skb() to fix it.\nCompile tested only.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\ncoresight: trbe: remove cpuhp instance node before remove cpuhp state\n\ncpuhp_state_add_instance() and cpuhp_state_remove_instance() should\nbe used in pairs. Or there will lead to the warn on\ncpuhp_remove_multi_state() since the cpuhp_step list is not empty.\n\nThe following is the error log with 'rmmod coresight-trbe':\nError: Removing state 215 which has instances left.\nCall trace:\n __cpuhp_remove_state_cpuslocked+0x144/0x160\n __cpuhp_remove_state+0xac/0x100\n arm_trbe_device_remove+0x2c/0x60 [coresight_trbe]\n platform_remove+0x34/0x70\n device_remove+0x54/0x90\n device_release_driver_internal+0x1e4/0x250\n driver_detach+0x5c/0xb0\n bus_remove_driver+0x64/0xc0\n driver_unregister+0x3c/0x70\n platform_driver_unregister+0x20/0x30\n arm_trbe_exit+0x1c/0x658 [coresight_trbe]\n __arm64_sys_delete_module+0x1ac/0x24c\n invoke_syscall+0x50/0x120\n el0_svc_common.constprop.0+0x58/0x1a0\n do_el0_svc+0x38/0xd0\n el0_svc+0x2c/0xc0\n el0t_64_sync_handler+0x1ac/0x1b0\n el0t_64_sync+0x19c/0x1a0\n ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86/intel/uncore: Fix reference count leak in hswep_has_limit_sbox()\n\npci_get_device() will increase the reference count for the returned\n'dev'. We need to call pci_dev_put() to decrease the reference count.\nSince 'dev' is only used in pci_read_config_dword(), let's add\npci_dev_put() right after it.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/bridge: megachips: Fix a null pointer dereference bug\n\nWhen removing the module we will get the following warning:\n\n[ 31.911505] i2c-core: driver [stdp2690-ge-b850v3-fw] unregistered\n[ 31.912484] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI\n[ 31.913338] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\n[ 31.915280] RIP: 0010:drm_bridge_remove+0x97/0x130\n[ 31.921825] Call Trace:\n[ 31.922533] stdp4028_ge_b850v3_fw_remove+0x34/0x60 [megachips_stdpxxxx_ge_b850v3_fw]\n[ 31.923139] i2c_device_remove+0x181/0x1f0\n\nThe two bridges (stdp2690, stdp4028) do not probe at the same time, so\nthe driver does not call ge_b850v3_resgiter() when probing, causing the\ndriver to try to remove the object that has not been initialized.\n\nFix this by checking whether both the bridges are probed.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nata: ahci: Match EM_MAX_SLOTS with SATA_PMP_MAX_PORTS\n\nUBSAN complains about array-index-out-of-bounds:\n[ 1.980703] kernel: UBSAN: array-index-out-of-bounds in /build/linux-9H675w/linux-5.15.0/drivers/ata/libahci.c:968:41\n[ 1.980709] kernel: index 15 is out of range for type 'ahci_em_priv [8]'\n[ 1.980713] kernel: CPU: 0 PID: 209 Comm: scsi_eh_8 Not tainted 5.15.0-25-generic #25-Ubuntu\n[ 1.980716] kernel: Hardware name: System manufacturer System Product Name/P5Q3, BIOS 1102 06/11/2010\n[ 1.980718] kernel: Call Trace:\n[ 1.980721] kernel: \n[ 1.980723] kernel: show_stack+0x52/0x58\n[ 1.980729] kernel: dump_stack_lvl+0x4a/0x5f\n[ 1.980734] kernel: dump_stack+0x10/0x12\n[ 1.980736] kernel: ubsan_epilogue+0x9/0x45\n[ 1.980739] kernel: __ubsan_handle_out_of_bounds.cold+0x44/0x49\n[ 1.980742] kernel: ahci_qc_issue+0x166/0x170 [libahci]\n[ 1.980748] kernel: ata_qc_issue+0x135/0x240\n[ 1.980752] kernel: ata_exec_internal_sg+0x2c4/0x580\n[ 1.980754] kernel: ? vprintk_default+0x1d/0x20\n[ 1.980759] kernel: ata_exec_internal+0x67/0xa0\n[ 1.980762] kernel: sata_pmp_read+0x8d/0xc0\n[ 1.980765] kernel: sata_pmp_read_gscr+0x3c/0x90\n[ 1.980768] kernel: sata_pmp_attach+0x8b/0x310\n[ 1.980771] kernel: ata_eh_revalidate_and_attach+0x28c/0x4b0\n[ 1.980775] kernel: ata_eh_recover+0x6b6/0xb30\n[ 1.980778] kernel: ? ahci_do_hardreset+0x180/0x180 [libahci]\n[ 1.980783] kernel: ? ahci_stop_engine+0xb0/0xb0 [libahci]\n[ 1.980787] kernel: ? ahci_do_softreset+0x290/0x290 [libahci]\n[ 1.980792] kernel: ? trace_event_raw_event_ata_eh_link_autopsy_qc+0xe0/0xe0\n[ 1.980795] kernel: sata_pmp_eh_recover.isra.0+0x214/0x560\n[ 1.980799] kernel: sata_pmp_error_handler+0x23/0x40\n[ 1.980802] kernel: ahci_error_handler+0x43/0x80 [libahci]\n[ 1.980806] kernel: ata_scsi_port_error_handler+0x2b1/0x600\n[ 1.980810] kernel: ata_scsi_error+0x9c/0xd0\n[ 1.980813] kernel: scsi_error_handler+0xa1/0x180\n[ 1.980817] kernel: ? scsi_unjam_host+0x1c0/0x1c0\n[ 1.980820] kernel: kthread+0x12a/0x150\n[ 1.980823] kernel: ? set_kthread_struct+0x50/0x50\n[ 1.980826] kernel: ret_from_fork+0x22/0x30\n[ 1.980831] kernel: \n\nThis happens because sata_pmp_init_links() initialize link->pmp up to\nSATA_PMP_MAX_PORTS while em_priv is declared as 8 elements array.\n\nI can't find the maximum Enclosure Management ports specified in AHCI\nspec v1.3.1, but "12.2.1 LED message type" states that "Port Multiplier\nInformation" can utilize 4 bits, which implies it can support up to 16\nports. Hence, use SATA_PMP_MAX_PORTS as EM_MAX_SLOTS to resolve the\nissue.\n\nBugLink: https://bugs.launchpad.net/bugs/1970074

In the Linux kernel, the following vulnerability has been resolved:\n\nnbd: Fix hung when signal interrupts nbd_start_device_ioctl()\n\nsyzbot reported hung task [1]. The following program is a simplified\nversion of the reproducer:\n\nint main(void)\n{\n\tint sv[2], fd;\n\n\tif (socketpair(AF_UNIX, SOCK_STREAM, 0, sv) < 0)\n\t\treturn 1;\n\tif ((fd = open("/dev/nbd0", 0)) < 0)\n\t\treturn 1;\n\tif (ioctl(fd, NBD_SET_SIZE_BLOCKS, 0x81) < 0)\n\t\treturn 1;\n\tif (ioctl(fd, NBD_SET_SOCK, sv[0]) < 0)\n\t\treturn 1;\n\tif (ioctl(fd, NBD_DO_IT) < 0)\n\t\treturn 1;\n\treturn 0;\n}\n\nWhen signal interrupt nbd_start_device_ioctl() waiting the condition\natomic_read(&config->recv_threads) == 0, the task can hung because it\nwaits the completion of the inflight IOs.\n\nThis patch fixes the issue by clearing queue, not just shutdown, when\nsignal interrupt nbd_start_device_ioctl().

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrivers: serial: jsm: fix some leaks in probe\n\nThis error path needs to unwind instead of just returning directly.

No description is available for this CVE.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: xilinx: vipp: Fix refcount leak in xvip_graph_dma_init\n\nof_get_child_by_name() returns a node pointer with refcount\nincremented, we should use of_node_put() on it when not need anymore.\nAdd missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: qcom: Add checks for devm_kcalloc\n\nAs the devm_kcalloc may return NULL, the return value needs to be checked\nto avoid NULL poineter dereference.

In the Linux kernel, the following vulnerability has been resolved:\n\ns390/cio: fix out-of-bounds access on cio_ignore free\n\nThe channel-subsystem-driver scans for newly available devices whenever\ndevice-IDs are removed from the cio_ignore list using a command such as:\n\n echo free >/proc/cio_ignore\n\nSince an I/O device scan might interfer with running I/Os, commit\n172da89ed0ea ("s390/cio: avoid excessive path-verification requests")\nintroduced an optimization to exclude online devices from the scan.\n\nThe newly added check for online devices incorrectly assumes that\nan I/O-subchannel's drvdata points to a struct io_subchannel_private.\nFor devices that are bound to a non-default I/O subchannel driver, such\nas the vfio_ccw driver, this results in an out-of-bounds read access\nduring each scan.\n\nFix this by changing the scan logic to rely on a driver-independent\nonline indication. For this we can use struct subchannel->config.ena,\nwhich is the driver's requested subchannel-enabled state. Since I/Os\ncan only be started on enabled subchannels, this matches the intent\nof the original optimization of not scanning devices where I/O might\nbe running.

In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix potential out of bound read in ext4_fc_replay_scan()\n\nFor scan loop must ensure that at least EXT4_FC_TAG_BASE_LEN space. If remain\nspace less than EXT4_FC_TAG_BASE_LEN which will lead to out of bound read\nwhen mounting corrupt file system image.\nADD_RANGE/HEAD/TAIL is needed to add extra check when do journal scan, as this\nthree tags will read data during scan, tag length couldn't less than data length\nwhich will read.

In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: sof_es8336: fix possible use-after-free in sof_es8336_remove()\n\nsof_es8336_remove() calls cancel_delayed_work(). However, that\nfunction does not wait until the work function finishes. This\nmeans that the callback function may still be running after\nthe driver's remove function has finished, which would result\nin a use-after-free.\n\nFix by calling cancel_delayed_work_sync(), which ensures that\nthe work is properly cancelled, no longer running, and unable\nto re-schedule itself.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: Fix double release compute pasid\n\nIf kfd_process_device_init_vm returns failure after vm is converted to\ncompute vm and vm->pasid set to compute pasid, KFD will not take\npdd->drm_file reference. As a result, drm close file handler maybe\ncalled to release the compute pasid before KFD process destroy worker to\nrelease the same pasid and set vm->pasid to zero, this generates below\nWARNING backtrace and NULL pointer access.\n\nAdd helper amdgpu_amdkfd_gpuvm_set_vm_pasid and call it at the last step\nof kfd_process_device_init_vm, to ensure vm pasid is the original pasid\nif acquiring vm failed or is the compute pasid with pdd->drm_file\nreference taken to avoid double release same pasid.\n\n amdgpu: Failed to create process VM object\n ida_free called for id=32770 which is not allocated.\n WARNING: CPU: 57 PID: 72542 at ../lib/idr.c:522 ida_free+0x96/0x140\n RIP: 0010:ida_free+0x96/0x140\n Call Trace:\n amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu]\n amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu]\n drm_file_free.part.13+0x216/0x270 [drm]\n drm_close_helper.isra.14+0x60/0x70 [drm]\n drm_release+0x6e/0xf0 [drm]\n __fput+0xcc/0x280\n ____fput+0xe/0x20\n task_work_run+0x96/0xc0\n do_exit+0x3d0/0xc10\n\n BUG: kernel NULL pointer dereference, address: 0000000000000000\n RIP: 0010:ida_free+0x76/0x140\n Call Trace:\n amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu]\n amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu]\n drm_file_free.part.13+0x216/0x270 [drm]\n drm_close_helper.isra.14+0x60/0x70 [drm]\n drm_release+0x6e/0xf0 [drm]\n __fput+0xcc/0x280\n ____fput+0xe/0x20\n task_work_run+0x96/0xc0\n do_exit+0x3d0/0xc10

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\niommu/omap: Fix buffer overflow in debugfs\n\nThere are two issues here:\n\n1) The "len" variable needs to be checked before the very first write.\n Otherwise if omap2_iommu_dump_ctx() with "bytes" less than 32 it is a\n buffer overflow.\n2) The snprintf() function returns the number of bytes that *would* have\n been copied if there were enough space. But we want to know the\n number of bytes which were *actually* copied so use scnprintf()\n instead.

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix extent map use-after-free when handling missing device in read_one_chunk\n\nStore the error code before freeing the extent_map. Though it's\nreference counted structure, in that function it's the first and last\nallocation so this would lead to a potential use-after-free.\n\nThe error can happen eg. when chunk is stored on a missing device and\nthe degraded mount option is missing.\n\nBugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216721

In the Linux kernel, the following vulnerability has been resolved:\n\nmd: Replace snprintf with scnprintf\n\nCurrent code produces a warning as shown below when total characters\nin the constituent block device names plus the slashes exceeds 200.\nsnprintf() returns the number of characters generated from the given\ninput, which could cause the expression “200 – len” to wrap around\nto a large positive number. Fix this by using scnprintf() instead,\nwhich returns the actual number of characters written into the buffer.\n\n[ 1513.267938] ------------[ cut here ]------------\n[ 1513.267943] WARNING: CPU: 15 PID: 37247 at /lib/vsprintf.c:2509 vsnprintf+0x2c8/0x510\n[ 1513.267944] Modules linked in: \n[ 1513.267969] CPU: 15 PID: 37247 Comm: mdadm Not tainted 5.4.0-1085-azure #90~18.04.1-Ubuntu\n[ 1513.267969] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022\n[ 1513.267971] RIP: 0010:vsnprintf+0x2c8/0x510\n<-snip->\n[ 1513.267982] Call Trace:\n[ 1513.267986] snprintf+0x45/0x70\n[ 1513.267990] ? disk_name+0x71/0xa0\n[ 1513.267993] dump_zones+0x114/0x240 [raid0]\n[ 1513.267996] ? _cond_resched+0x19/0x40\n[ 1513.267998] raid0_run+0x19e/0x270 [raid0]\n[ 1513.268000] md_run+0x5e0/0xc50\n[ 1513.268003] ? security_capable+0x3f/0x60\n[ 1513.268005] do_md_run+0x19/0x110\n[ 1513.268006] md_ioctl+0x195e/0x1f90\n[ 1513.268007] blkdev_ioctl+0x91f/0x9f0\n[ 1513.268010] block_ioctl+0x3d/0x50\n[ 1513.268012] do_vfs_ioctl+0xa9/0x640\n[ 1513.268014] ? __fput+0x162/0x260\n[ 1513.268016] ksys_ioctl+0x75/0x80\n[ 1513.268017] __x64_sys_ioctl+0x1a/0x20\n[ 1513.268019] do_syscall_64+0x5e/0x200\n[ 1513.268021] entry_SYSCALL_64_after_hwframe+0x44/0xa9

In the Linux kernel, the following vulnerability has been resolved:\n\nslimbus: qcom-ngd: cleanup in probe error path\n\nAdd proper error path in probe() to cleanup resources previously\nacquired/allocated to fix warnings visible during probe deferral:\n\n notifier callback qcom_slim_ngd_ssr_notify already registered\n WARNING: CPU: 6 PID: 70 at kernel/notifier.c:28 notifier_chain_register+0x5c/0x90\n Modules linked in:\n CPU: 6 PID: 70 Comm: kworker/u16:1 Not tainted 6.0.0-rc3-next-20220830 #380\n Call trace:\n notifier_chain_register+0x5c/0x90\n srcu_notifier_chain_register+0x44/0x90\n qcom_register_ssr_notifier+0x38/0x4c\n qcom_slim_ngd_ctrl_probe+0xd8/0x400\n platform_probe+0x6c/0xe0\n really_probe+0xbc/0x2d4\n __driver_probe_device+0x78/0xe0\n driver_probe_device+0x3c/0x12c\n __device_attach_driver+0xb8/0x120\n bus_for_each_drv+0x78/0xd0\n __device_attach+0xa8/0x1c0\n device_initial_probe+0x18/0x24\n bus_probe_device+0xa0/0xac\n deferred_probe_work_func+0x88/0xc0\n process_one_work+0x1d4/0x320\n worker_thread+0x2cc/0x44c\n kthread+0x110/0x114\n ret_from_fork+0x10/0x20

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath9k: verify the expected usb_endpoints are present\n\nThe bug arises when a USB device claims to be an ATH9K but doesn't\nhave the expected endpoints. (In this case there was an interrupt\nendpoint where the driver expected a bulk endpoint.) The kernel\nneeds to be able to handle such devices without getting an internal error.\n\nusb 1-1: BOGUS urb xfer, pipe 3 != type 1\nWARNING: CPU: 3 PID: 500 at drivers/usb/core/urb.c:493 usb_submit_urb+0xce2/0x1430 drivers/usb/core/urb.c:493\nModules linked in:\nCPU: 3 PID: 500 Comm: kworker/3:2 Not tainted 5.10.135-syzkaller #0\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014\nWorkqueue: events request_firmware_work_func\nRIP: 0010:usb_submit_urb+0xce2/0x1430 drivers/usb/core/urb.c:493\nCall Trace:\n ath9k_hif_usb_alloc_rx_urbs drivers/net/wireless/ath/ath9k/hif_usb.c:908 [inline]\n ath9k_hif_usb_alloc_urbs+0x75e/0x1010 drivers/net/wireless/ath/ath9k/hif_usb.c:1019\n ath9k_hif_usb_dev_init drivers/net/wireless/ath/ath9k/hif_usb.c:1109 [inline]\n ath9k_hif_usb_firmware_cb+0x142/0x530 drivers/net/wireless/ath/ath9k/hif_usb.c:1242\n request_firmware_work_func+0x12e/0x240 drivers/base/firmware_loader/main.c:1097\n process_one_work+0x9af/0x1600 kernel/workqueue.c:2279\n worker_thread+0x61d/0x12f0 kernel/workqueue.c:2425\n kthread+0x3b4/0x4a0 kernel/kthread.c:313\n ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:299\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: do not BUG_ON() on ENOMEM when dropping extent items for a range\n\nIf we get -ENOMEM while dropping file extent items in a given range, at\nbtrfs_drop_extents(), due to failure to allocate memory when attempting to\nincrement the reference count for an extent or drop the reference count,\nwe handle it with a BUG_ON(). This is excessive, instead we can simply\nabort the transaction and return the error to the caller. In fact most\ncallers of btrfs_drop_extents(), directly or indirectly, already abort\nthe transaction if btrfs_drop_extents() returns any error.\n\nAlso, we already have error paths at btrfs_drop_extents() that may return\n-ENOMEM and in those cases we abort the transaction, like for example\nanything that changes the b+tree may return -ENOMEM due to a failure to\nallocate a new extent buffer when COWing an existing extent buffer, such\nas a call to btrfs_duplicate_item() for example.\n\nSo replace the BUG_ON() calls with proper logic to abort the transaction\nand return the error.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/dp: fix bridge lifetime\n\nDevice-managed resources allocated post component bind must be tied to\nthe lifetime of the aggregate DRM device or they will not necessarily be\nreleased when binding of the aggregate device is deferred.\n\nThis can lead resource leaks or failure to bind the aggregate device\nwhen binding is later retried and a second attempt to allocate the\nresources is made.\n\nFor the DP bridges, previously allocated bridges will leak on probe\ndeferral.\n\nFix this by amending the DP parser interface and tying the lifetime of\nthe bridge device to the DRM device rather than DP platform device.\n\nPatchwork: https://patchwork.freedesktop.org/patch/502667/

In the Linux kernel, the following vulnerability has been resolved:\n\nkcm: annotate data-races around kcm->rx_psock\n\nkcm->rx_psock can be read locklessly in kcm_rfree().\nAnnotate the read and writes accordingly.\n\nWe do the same for kcm->rx_wait in the following patch.\n\nsyzbot reported:\nBUG: KCSAN: data-race in kcm_rfree / unreserve_rx_kcm\n\nwrite to 0xffff888123d827b8 of 8 bytes by task 2758 on cpu 1:\nunreserve_rx_kcm+0x72/0x1f0 net/kcm/kcmsock.c:313\nkcm_rcv_strparser+0x2b5/0x3a0 net/kcm/kcmsock.c:373\n__strp_recv+0x64c/0xd20 net/strparser/strparser.c:301\nstrp_recv+0x6d/0x80 net/strparser/strparser.c:335\ntcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703\nstrp_read_sock net/strparser/strparser.c:358 [inline]\ndo_strp_work net/strparser/strparser.c:406 [inline]\nstrp_work+0xe8/0x180 net/strparser/strparser.c:415\nprocess_one_work+0x3d3/0x720 kernel/workqueue.c:2289\nworker_thread+0x618/0xa70 kernel/workqueue.c:2436\nkthread+0x1a9/0x1e0 kernel/kthread.c:376\nret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306\n\nread to 0xffff888123d827b8 of 8 bytes by task 5859 on cpu 0:\nkcm_rfree+0x14c/0x220 net/kcm/kcmsock.c:181\nskb_release_head_state+0x8e/0x160 net/core/skbuff.c:841\nskb_release_all net/core/skbuff.c:852 [inline]\n__kfree_skb net/core/skbuff.c:868 [inline]\nkfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891\nkfree_skb include/linux/skbuff.h:1216 [inline]\nkcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161\n____sys_recvmsg+0x16c/0x2e0\n___sys_recvmsg net/socket.c:2743 [inline]\ndo_recvmmsg+0x2f1/0x710 net/socket.c:2837\n__sys_recvmmsg net/socket.c:2916 [inline]\n__do_sys_recvmmsg net/socket.c:2939 [inline]\n__se_sys_recvmmsg net/socket.c:2932 [inline]\n__x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nvalue changed: 0xffff88812971ce00 -> 0x0000000000000000\n\nReported by Kernel Concurrency Sanitizer on:\nCPU: 0 PID: 5859 Comm: syz-executor.3 Not tainted 6.0.0-syzkaller-12189-g19d17ab7c68b-dirty #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022

In the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix memory leak in ocfs2_stack_glue_init()\n\nocfs2_table_header should be free in ocfs2_stack_glue_init() if\nocfs2_sysfs_init() failed, otherwise kmemleak will report memleak.\n\nBUG: memory leak\nunreferenced object 0xffff88810eeb5800 (size 128):\n comm "modprobe", pid 4507, jiffies 4296182506 (age 55.888s)\n hex dump (first 32 bytes):\n c0 40 14 a0 ff ff ff ff 00 00 00 00 01 00 00 00 .@..............\n 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace:\n [<000000001e59e1cd>] __register_sysctl_table+0xca/0xef0\n [<00000000c04f70f7>] 0xffffffffa0050037\n [<000000001bd12912>] do_one_initcall+0xdb/0x480\n [<0000000064f766c9>] do_init_module+0x1cf/0x680\n [<000000002ba52db0>] load_module+0x6441/0x6f20\n [<000000009772580d>] __do_sys_finit_module+0x12f/0x1c0\n [<00000000380c1f22>] do_syscall_64+0x3f/0x90\n [<000000004cf473bc>] entry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:\n\nqlcnic: prevent ->dcb use-after-free on qlcnic_dcb_enable() failure\n\nadapter->dcb would get silently freed inside qlcnic_dcb_enable() in\ncase qlcnic_dcb_attach() would return an error, which always happens\nunder OOM conditions. This would lead to use-after-free because both\nof the existing callers invoke qlcnic_dcb_get_info() on the obtained\npointer, which is potentially freed at that point.\n\nPropagate errors from qlcnic_dcb_enable(), and instead free the dcb\npointer at callsite using qlcnic_dcb_free(). This also removes the now\nunused qlcnic_clear_dcb_ops() helper, which was a simple wrapper around\nkfree() also causing memory leaks for partially initialized dcb.\n\nFound by Linux Verification Center (linuxtesting.org) with the SVACE\nstatic analysis tool.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix delayed allocation bug in ext4_clu_mapped for bigalloc + inline\n\nWhen converting files with inline data to extents, delayed allocations\nmade on a file system created with both the bigalloc and inline options\ncan result in invalid extent status cache content, incorrect reserved\ncluster counts, kernel memory leaks, and potential kernel panics.\n\nWith bigalloc, the code that determines whether a block must be\ndelayed allocated searches the extent tree to see if that block maps\nto a previously allocated cluster. If not, the block is delayed\nallocated, and otherwise, it isn't. However, if the inline option is\nalso used, and if the file containing the block is marked as able to\nstore data inline, there isn't a valid extent tree associated with\nthe file. The current code in ext4_clu_mapped() calls\next4_find_extent() to search the non-existent tree for a previously\nallocated cluster anyway, which typically finds nothing, as desired.\nHowever, a side effect of the search can be to cache invalid content\nfrom the non-existent tree (garbage) in the extent status tree,\nincluding bogus entries in the pending reservation tree.\n\nTo fix this, avoid searching the extent tree when allocating blocks\nfor bigalloc + inline files that are being converted from inline to\nextent mapped.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm,hugetlb: take hugetlb_lock before decrementing h->resv_huge_pages\n\nThe h->*_huge_pages counters are protected by the hugetlb_lock, but\nalloc_huge_page has a corner case where it can decrement the counter\noutside of the lock.\n\nThis could lead to a corrupted value of h->resv_huge_pages, which we have\nobserved on our systems.\n\nTake the hugetlb_lock before decrementing h->resv_huge_pages to avoid a\npotential race.

In the Linux kernel, the following vulnerability has been resolved:\n\nipc: fix memory leak in init_mqueue_fs()\n\nWhen setup_mq_sysctls() failed in init_mqueue_fs(), mqueue_inode_cachep is\nnot released. In order to fix this issue, the release path is reordered.

In the Linux kernel, the following vulnerability has been resolved:\n\nmtd: core: add missing of_node_get() in dynamic partitions code\n\nThis fixes unbalanced of_node_put():\n[ 1.078910] 6 cmdlinepart partitions found on MTD device gpmi-nand\n[ 1.085116] Creating 6 MTD partitions on "gpmi-nand":\n[ 1.090181] 0x000000000000-0x000008000000 : "nandboot"\n[ 1.096952] 0x000008000000-0x000009000000 : "nandfit"\n[ 1.103547] 0x000009000000-0x00000b000000 : "nandkernel"\n[ 1.110317] 0x00000b000000-0x00000c000000 : "nanddtb"\n[ 1.115525] ------------[ cut here ]------------\n[ 1.120141] refcount_t: addition on 0; use-after-free.\n[ 1.125328] WARNING: CPU: 0 PID: 1 at lib/refcount.c:25 refcount_warn_saturate+0xdc/0x148\n[ 1.133528] Modules linked in:\n[ 1.136589] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.0.0-rc7-next-20220930-04543-g8cf3f7\n[ 1.146342] Hardware name: Freescale i.MX8DXL DDR3L EVK (DT)\n[ 1.151999] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 1.158965] pc : refcount_warn_saturate+0xdc/0x148\n[ 1.163760] lr : refcount_warn_saturate+0xdc/0x148\n[ 1.168556] sp : ffff800009ddb080\n[ 1.171866] x29: ffff800009ddb080 x28: ffff800009ddb35a x27: 0000000000000002\n[ 1.179015] x26: ffff8000098b06ad x25: ffffffffffffffff x24: ffff0a00ffffff05\n[ 1.186165] x23: ffff00001fdf6470 x22: ffff800009ddb367 x21: 0000000000000000\n[ 1.193314] x20: ffff00001fdfebe8 x19: ffff00001fdfec50 x18: ffffffffffffffff\n[ 1.200464] x17: 0000000000000000 x16: 0000000000000118 x15: 0000000000000004\n[ 1.207614] x14: 0000000000000fff x13: ffff800009bca248 x12: 0000000000000003\n[ 1.214764] x11: 00000000ffffefff x10: c0000000ffffefff x9 : 4762cb2ccb52de00\n[ 1.221914] x8 : 4762cb2ccb52de00 x7 : 205d313431303231 x6 : 312e31202020205b\n[ 1.229063] x5 : ffff800009d55c1f x4 : 0000000000000001 x3 : 0000000000000000\n[ 1.236213] x2 : 0000000000000000 x1 : ffff800009954be6 x0 : 000000000000002a\n[ 1.243365] Call trace:\n[ 1.245806] refcount_warn_saturate+0xdc/0x148\n[ 1.250253] kobject_get+0x98/0x9c\n[ 1.253658] of_node_get+0x20/0x34\n[ 1.257072] of_fwnode_get+0x3c/0x54\n[ 1.260652] fwnode_get_nth_parent+0xd8/0xf4\n[ 1.264926] fwnode_full_name_string+0x3c/0xb4\n[ 1.269373] device_node_string+0x498/0x5b4\n[ 1.273561] pointer+0x41c/0x5d0\n[ 1.276793] vsnprintf+0x4d8/0x694\n[ 1.280198] vprintk_store+0x164/0x528\n[ 1.283951] vprintk_emit+0x98/0x164\n[ 1.287530] vprintk_default+0x44/0x6c\n[ 1.291284] vprintk+0xf0/0x134\n[ 1.294428] _printk+0x54/0x7c\n[ 1.297486] of_node_release+0xe8/0x128\n[ 1.301326] kobject_put+0x98/0xfc\n[ 1.304732] of_node_put+0x1c/0x28\n[ 1.308137] add_mtd_device+0x484/0x6d4\n[ 1.311977] add_mtd_partitions+0xf0/0x1d0\n[ 1.316078] parse_mtd_partitions+0x45c/0x518\n[ 1.320439] mtd_device_parse_register+0xb0/0x274\n[ 1.325147] gpmi_nand_probe+0x51c/0x650\n[ 1.329074] platform_probe+0xa8/0xd0\n[ 1.332740] really_probe+0x130/0x334\n[ 1.336406] __driver_probe_device+0xb4/0xe0\n[ 1.340681] driver_probe_device+0x3c/0x1f8\n[ 1.344869] __driver_attach+0xdc/0x1a4\n[ 1.348708] bus_for_each_dev+0x80/0xcc\n[ 1.352548] driver_attach+0x24/0x30\n[ 1.356127] bus_add_driver+0x108/0x1f4\n[ 1.359967] driver_register+0x78/0x114\n[ 1.363807] __platform_driver_register+0x24/0x30\n[ 1.368515] gpmi_nand_driver_init+0x1c/0x28\n[ 1.372798] do_one_initcall+0xbc/0x238\n[ 1.376638] do_initcall_level+0x94/0xb4\n[ 1.380565] do_initcalls+0x54/0x94\n[ 1.384058] do_basic_setup+0x1c/0x28\n[ 1.387724] kernel_init_freeable+0x110/0x188\n[ 1.392084] kernel_init+0x20/0x1a0\n[ 1.395578] ret_from_fork+0x10/0x20\n[ 1.399157] ---[ end trace 0000000000000000 ]---\n[ 1.403782] ------------[ cut here ]------------

In the Linux kernel, the following vulnerability has been resolved:\n\nchardev: fix error handling in cdev_device_add()\n\nWhile doing fault injection test, I got the following report:\n\n------------[ cut here ]------------\nkobject: '(null)' (0000000039956980): is not initialized, yet kobject_put() is being called.\nWARNING: CPU: 3 PID: 6306 at kobject_put+0x23d/0x4e0\nCPU: 3 PID: 6306 Comm: 283 Tainted: G W 6.1.0-rc2-00005-g307c1086d7c9 #1253\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014\nRIP: 0010:kobject_put+0x23d/0x4e0\nCall Trace:\n \n cdev_device_add+0x15e/0x1b0\n __iio_device_register+0x13b4/0x1af0 [industrialio]\n __devm_iio_device_register+0x22/0x90 [industrialio]\n max517_probe+0x3d8/0x6b4 [max517]\n i2c_device_probe+0xa81/0xc00\n\nWhen device_add() is injected fault and returns error, if dev->devt is not set,\ncdev_add() is not called, cdev_del() is not needed. Fix this by checking dev->devt\nin error path.

In the Linux kernel, the following vulnerability has been resolved:\n\nMIPS: SGI-IP27: Fix platform-device leak in bridge_platform_create()\n\nIn error case in bridge_platform_create after calling\nplatform_device_add()/platform_device_add_data()/\nplatform_device_add_resources(), release the failed\n'pdev' or it will be leak, call platform_device_put()\nto fix this problem.\n\nBesides, 'pdev' is divided into 'pdev_wd' and 'pdev_bd',\nuse platform_device_unregister() to release sgi_w1\nresources when xtalk-bridge registration fails.

No description is available for this CVE.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nPNP: fix name memory leak in pnp_alloc_dev()\n\nAfter commit 1fa5ae857bb1 ("driver core: get rid of struct device's\nbus_id string array"), the name of device is allocated dynamically,\nmove dev_set_name() after pnp_add_id() to avoid memory leak.

In the Linux kernel, the following vulnerability has been resolved:\n\next4: don't allow journal inode to have encrypt flag\n\nMounting a filesystem whose journal inode has the encrypt flag causes a\nNULL dereference in fscrypt_limit_io_blocks() when the 'inlinecrypt'\nmount option is used.\n\nThe problem is that when jbd2_journal_init_inode() calls bmap(), it\neventually finds its way into ext4_iomap_begin(), which calls\nfscrypt_limit_io_blocks(). fscrypt_limit_io_blocks() requires that if\nthe inode is encrypted, then its encryption key must already be set up.\nThat's not the case here, since the journal inode is never "opened" like\na normal file would be. Hence the crash.\n\nA reproducer is:\n\n mkfs.ext4 -F /dev/vdb\n debugfs -w /dev/vdb -R "set_inode_field <8> flags 0x80808"\n mount /dev/vdb /mnt -o inlinecrypt\n\nTo fix this, make ext4 consider journal inodes with the encrypt flag to\nbe invalid. (Note, maybe other flags should be rejected on the journal\ninode too. For now, this is just the minimal fix for the above issue.)\n\nI've marked this as fixing the commit that introduced the call to\nfscrypt_limit_io_blocks(), since that's what made an actual crash start\nbeing possible. But this fix could be applied to any version of ext4\nthat supports the encrypt feature.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/radeon: Add the missed acpi_put_table() to fix memory leak\n\nWhen the radeon driver reads the bios information from ACPI\ntable in radeon_acpi_vfct_bios(), it misses to call acpi_put_table()\nto release the ACPI memory after the init, so add acpi_put_table()\nproperly to fix the memory leak.\n\nv2: fix text formatting (Alex)

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: dvbdev: adopts refcnt to avoid UAF\n\ndvb_unregister_device() is known that prone to use-after-free.\nThat is, the cleanup from dvb_unregister_device() releases the dvb_device\neven if there are pointers stored in file->private_data still refer to it.\n\nThis patch adds a reference counter into struct dvb_device and delays its\ndeallocation until no pointer refers to the object.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()\n\nWei Chen reports a kernel bug as blew:\n\ngeneral protection fault, probably for non-canonical address\nKASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]\n...\nCall Trace:\n\n__i2c_transfer+0x77e/0x1930 drivers/i2c/i2c-core-base.c:2109\ni2c_transfer+0x1d5/0x3d0 drivers/i2c/i2c-core-base.c:2170\ni2cdev_ioctl_rdwr+0x393/0x660 drivers/i2c/i2c-dev.c:297\ni2cdev_ioctl+0x75d/0x9f0 drivers/i2c/i2c-dev.c:458\nvfs_ioctl fs/ioctl.c:51 [inline]\n__do_sys_ioctl fs/ioctl.c:870 [inline]\n__se_sys_ioctl+0xfb/0x170 fs/ioctl.c:856\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x3d/0x90 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\nRIP: 0033:0x7fd834a8bded\n\nIn az6027_i2c_xfer(), if msg[i].addr is 0x99,\na null-ptr-deref will caused when accessing msg[i].buf.\nFor msg[i].len is 0 and msg[i].buf is null.\n\nFix this by checking msg[i].len in az6027_i2c_xfer().

In the Linux kernel, the following vulnerability has been resolved:\n\nvhost/vsock: Use kvmalloc/kvfree for larger packets.\n\nWhen copying a large file over sftp over vsock, data size is usually 32kB,\nand kmalloc seems to fail to try to allocate 32 32kB regions.\n\n vhost-5837: page allocation failure: order:4, mode:0x24040c0\n Call Trace:\n [] dump_stack+0x97/0xdb\n [] warn_alloc_failed+0x10f/0x138\n [] ? __alloc_pages_direct_compact+0x38/0xc8\n [] __alloc_pages_nodemask+0x84c/0x90d\n [] alloc_kmem_pages+0x17/0x19\n [] kmalloc_order_trace+0x2b/0xdb\n [] __kmalloc+0x177/0x1f7\n [] ? copy_from_iter+0x8d/0x31d\n [] vhost_vsock_handle_tx_kick+0x1fa/0x301 [vhost_vsock]\n [] vhost_worker+0xf7/0x157 [vhost]\n [] kthread+0xfd/0x105\n [] ? vhost_dev_set_owner+0x22e/0x22e [vhost]\n [] ? flush_kthread_worker+0xf3/0xf3\n [] ret_from_fork+0x4e/0x80\n [] ? flush_kthread_worker+0xf3/0xf3\n\nWork around by doing kvmalloc instead.

In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix the assign logic of iocb\n\ncommit 18ae8d12991b ("f2fs: show more DIO information in tracepoint")\nintroduces iocb field in 'f2fs_direct_IO_enter' trace event\nAnd it only assigns the pointer and later it accesses its field\nin trace print log.\n\nUnable to handle kernel paging request at virtual address ffffffc04cef3d30\nMem abort info:\nESR = 0x96000007\nEC = 0x25: DABT (current EL), IL = 32 bits\n\n pc : trace_raw_output_f2fs_direct_IO_enter+0x54/0xa4\n lr : trace_raw_output_f2fs_direct_IO_enter+0x2c/0xa4\n sp : ffffffc0443cbbd0\n x29: ffffffc0443cbbf0 x28: ffffff8935b120d0 x27: ffffff8935b12108\n x26: ffffff8935b120f0 x25: ffffff8935b12100 x24: ffffff8935b110c0\n x23: ffffff8935b10000 x22: ffffff88859a936c x21: ffffff88859a936c\n x20: ffffff8935b110c0 x19: ffffff8935b10000 x18: ffffffc03b195060\n x17: ffffff8935b11e76 x16: 00000000000000cc x15: ffffffef855c4f2c\n x14: 0000000000000001 x13: 000000000000004e x12: ffff0000ffffff00\n x11: ffffffef86c350d0 x10: 00000000000010c0 x9 : 000000000fe0002c\n x8 : ffffffc04cef3d28 x7 : 7f7f7f7f7f7f7f7f x6 : 0000000002000000\n x5 : ffffff8935b11e9a x4 : 0000000000006250 x3 : ffff0a00ffffff04\n x2 : 0000000000000002 x1 : ffffffef86a0a31f x0 : ffffff8935b10000\n Call trace:\n trace_raw_output_f2fs_direct_IO_enter+0x54/0xa4\n print_trace_fmt+0x9c/0x138\n print_trace_line+0x154/0x254\n tracing_read_pipe+0x21c/0x380\n vfs_read+0x108/0x3ac\n ksys_read+0x7c/0xec\n __arm64_sys_read+0x20/0x30\n invoke_syscall+0x60/0x150\n el0_svc_common.llvm.1237943816091755067+0xb8/0xf8\n do_el0_svc+0x28/0xa0\n\nFix it by copying the required variables for printing and while at\nit fix the similar issue at some other places in the same file.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vkms: Fix memory leak in vkms_init()\n\nA memory leak was reported after the vkms module install failed.\n\nunreferenced object 0xffff88810bc28520 (size 16):\n comm "modprobe", pid 9662, jiffies 4298009455 (age 42.590s)\n hex dump (first 16 bytes):\n 01 01 00 64 81 88 ff ff 00 00 dc 0a 81 88 ff ff ...d............\n backtrace:\n [<00000000e7561ff8>] kmalloc_trace+0x27/0x60\n [<000000000b1954a0>] 0xffffffffc45200a9\n [<00000000abbf1da0>] do_one_initcall+0xd0/0x4f0\n [<000000001505ee87>] do_init_module+0x1a4/0x680\n [<00000000958079ad>] load_module+0x6249/0x7110\n [<00000000117e4696>] __do_sys_finit_module+0x140/0x200\n [<00000000f74b12d2>] do_syscall_64+0x35/0x80\n [<000000008fc6fcde>] entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nThe reason is that the vkms_init() returns without checking the return\nvalue of vkms_create(), and if the vkms_create() failed, the config\nallocated at the beginning of vkms_init() is leaked.\n\n vkms_init()\n config = kmalloc(...) # config allocated\n ...\n return vkms_create() # vkms_create failed and config is leaked\n\nFix this problem by checking return value of vkms_create() and free the\nconfig if error happened.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nmmc: rtsx_pci: fix return value check of mmc_add_host()\n\nmmc_add_host() may return error, if we ignore its return value, the memory\nthat allocated in mmc_alloc_host() will be leaked and it will lead a kernel\ncrash because of deleting not added device in the remove path.\n\nSo fix this by checking the return value and calling mmc_free_host() in the\nerror path, beside, runtime PM also needs be disabled.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nkcm: annotate data-races around kcm->rx_wait\n\nkcm->rx_psock can be read locklessly in kcm_rfree().\nAnnotate the read and writes accordingly.\n\nsyzbot reported:\n\nBUG: KCSAN: data-race in kcm_rcv_strparser / kcm_rfree\n\nwrite to 0xffff88810784e3d0 of 1 bytes by task 1823 on cpu 1:\nreserve_rx_kcm net/kcm/kcmsock.c:283 [inline]\nkcm_rcv_strparser+0x250/0x3a0 net/kcm/kcmsock.c:363\n__strp_recv+0x64c/0xd20 net/strparser/strparser.c:301\nstrp_recv+0x6d/0x80 net/strparser/strparser.c:335\ntcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703\nstrp_read_sock net/strparser/strparser.c:358 [inline]\ndo_strp_work net/strparser/strparser.c:406 [inline]\nstrp_work+0xe8/0x180 net/strparser/strparser.c:415\nprocess_one_work+0x3d3/0x720 kernel/workqueue.c:2289\nworker_thread+0x618/0xa70 kernel/workqueue.c:2436\nkthread+0x1a9/0x1e0 kernel/kthread.c:376\nret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306\n\nread to 0xffff88810784e3d0 of 1 bytes by task 17869 on cpu 0:\nkcm_rfree+0x121/0x220 net/kcm/kcmsock.c:181\nskb_release_head_state+0x8e/0x160 net/core/skbuff.c:841\nskb_release_all net/core/skbuff.c:852 [inline]\n__kfree_skb net/core/skbuff.c:868 [inline]\nkfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891\nkfree_skb include/linux/skbuff.h:1216 [inline]\nkcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161\n____sys_recvmsg+0x16c/0x2e0\n___sys_recvmsg net/socket.c:2743 [inline]\ndo_recvmmsg+0x2f1/0x710 net/socket.c:2837\n__sys_recvmmsg net/socket.c:2916 [inline]\n__do_sys_recvmmsg net/socket.c:2939 [inline]\n__se_sys_recvmmsg net/socket.c:2932 [inline]\n__x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nvalue changed: 0x01 -> 0x00\n\nReported by Kernel Concurrency Sanitizer on:\nCPU: 0 PID: 17869 Comm: syz-executor.2 Not tainted 6.1.0-rc1-syzkaller-00010-gbb1a1146467a-dirty #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022

In the Linux kernel, the following vulnerability has been resolved:\n\nclk: socfpga: Fix memory leak in socfpga_gate_init()\n\nFree @socfpga_clk and @ops on the error path to avoid memory leak issue.

In the Linux kernel, the following vulnerability has been resolved:\n\nvdpasim: fix memory leak when freeing IOTLBs\n\nAfter commit bda324fd037a ("vdpasim: control virtqueue support"),\nvdpasim->iommu became an array of IOTLB, so we should clean the\nmappings of each free one by one instead of just deleting the ranges\nin the first IOTLB which may leak maps.

In the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Validate BOOT record_size\n\nWhen the NTFS BOOT record_size field < 0, it represents a\nshift value. However, there is no sanity check on the shift result\nand the sbi->record_bits calculation through blksize_bits() assumes\nthe size always > 256, which could lead to NPD while mounting a\nmalformed NTFS image.\n\n[ 318.675159] BUG: kernel NULL pointer dereference, address: 0000000000000158\n[ 318.675682] #PF: supervisor read access in kernel mode\n[ 318.675869] #PF: error_code(0x0000) - not-present page\n[ 318.676246] PGD 0 P4D 0\n[ 318.676502] Oops: 0000 [#1] PREEMPT SMP NOPTI\n[ 318.676934] CPU: 0 PID: 259 Comm: mount Not tainted 5.19.0 #5\n[ 318.677289] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014\n[ 318.678136] RIP: 0010:ni_find_attr+0x2d/0x1c0\n[ 318.678656] Code: 89 ca 4d 89 c7 41 56 41 55 41 54 41 89 cc 55 48 89 fd 53 48 89 d3 48 83 ec 20 65 48 8b 04 25 28 00 00 00 48 89 44 24 180\n[ 318.679848] RSP: 0018:ffffa6c8c0297bd8 EFLAGS: 00000246\n[ 318.680104] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000080\n[ 318.680790] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\n[ 318.681679] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000\n[ 318.682577] R10: 0000000000000000 R11: 0000000000000005 R12: 0000000000000080\n[ 318.683015] R13: ffff8d5582e68400 R14: 0000000000000100 R15: 0000000000000000\n[ 318.683618] FS: 00007fd9e1c81e40(0000) GS:ffff8d55fdc00000(0000) knlGS:0000000000000000\n[ 318.684280] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 318.684651] CR2: 0000000000000158 CR3: 0000000002e1a000 CR4: 00000000000006f0\n[ 318.685623] Call Trace:\n[ 318.686607] \n[ 318.686872] ? ntfs_alloc_inode+0x1a/0x60\n[ 318.687235] attr_load_runs_vcn+0x2b/0xa0\n[ 318.687468] mi_read+0xbb/0x250\n[ 318.687576] ntfs_iget5+0x114/0xd90\n[ 318.687750] ntfs_fill_super+0x588/0x11b0\n[ 318.687953] ? put_ntfs+0x130/0x130\n[ 318.688065] ? snprintf+0x49/0x70\n[ 318.688164] ? put_ntfs+0x130/0x130\n[ 318.688256] get_tree_bdev+0x16a/0x260\n[ 318.688407] vfs_get_tree+0x20/0xb0\n[ 318.688519] path_mount+0x2dc/0x9b0\n[ 318.688877] do_mount+0x74/0x90\n[ 318.689142] __x64_sys_mount+0x89/0xd0\n[ 318.689636] do_syscall_64+0x3b/0x90\n[ 318.689998] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[ 318.690318] RIP: 0033:0x7fd9e133c48a\n[ 318.690687] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008\n[ 318.691357] RSP: 002b:00007ffd374406c8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5\n[ 318.691632] RAX: ffffffffffffffda RBX: 0000564d0b051080 RCX: 00007fd9e133c48a\n[ 318.691920] RDX: 0000564d0b051280 RSI: 0000564d0b051300 RDI: 0000564d0b0596a0\n[ 318.692123] RBP: 0000000000000000 R08: 0000564d0b0512a0 R09: 0000000000000020\n[ 318.692349] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 0000564d0b0596a0\n[ 318.692673] R13: 0000564d0b051280 R14: 0000000000000000 R15: 00000000ffffffff\n[ 318.693007] \n[ 318.693271] Modules linked in:\n[ 318.693614] CR2: 0000000000000158\n[ 318.694446] ---[ end trace 0000000000000000 ]---\n[ 318.694779] RIP: 0010:ni_find_attr+0x2d/0x1c0\n[ 318.694952] Code: 89 ca 4d 89 c7 41 56 41 55 41 54 41 89 cc 55 48 89 fd 53 48 89 d3 48 83 ec 20 65 48 8b 04 25 28 00 00 00 48 89 44 24 180\n[ 318.696042] RSP: 0018:ffffa6c8c0297bd8 EFLAGS: 00000246\n[ 318.696531] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000080\n[ 318.698114] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\n[ 318.699286] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000\n[ 318.699795] R10: 0000000000000000 R11: 0000000000000005 R12: 0000000000000080\n[ 318.700236] R13: ffff8d5582e68400 R14: 0000000000000100 R15: 0000000000000000\n[ 318.700973] FS: 00007fd9e1c81e40(0000) GS:ffff8d55fdc00000(0000) knlGS:0000000000000000\n[\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/sti: Fix return type of sti_{dvo,hda,hdmi}_connector_mode_valid()\n\nWith clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),\nindirect call targets are validated against the expected function\npointer prototype to make sure the call target is valid to help mitigate\nROP attacks. If they are not identical, there is a failure at run time,\nwhich manifests as either a kernel panic or thread getting killed. A\nproposed warning in clang aims to catch these at compile time, which\nreveals:\n\n drivers/gpu/drm/sti/sti_hda.c:637:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict]\n .mode_valid = sti_hda_connector_mode_valid,\n ^~~~~~~~~~~~~~~~~~~~~~~~~~~~\n drivers/gpu/drm/sti/sti_dvo.c:376:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict]\n .mode_valid = sti_dvo_connector_mode_valid,\n ^~~~~~~~~~~~~~~~~~~~~~~~~~~~\n drivers/gpu/drm/sti/sti_hdmi.c:1035:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict]\n .mode_valid = sti_hdmi_connector_mode_valid,\n ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\n->mode_valid() in 'struct drm_connector_helper_funcs' expects a return\ntype of 'enum drm_mode_status', not 'int'. Adjust the return type of\nsti_{dvo,hda,hdmi}_connector_mode_valid() to match the prototype's to\nresolve the warning and CFI failure.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm: Make .remove and .shutdown HW shutdown consistent\n\nDrivers' .remove and .shutdown callbacks are executed on different code\npaths. The former is called when a device is removed from the bus, while\nthe latter is called at system shutdown time to quiesce the device.\n\nThis means that some overlap exists between the two, because both have to\ntake care of properly shutting down the hardware. But currently the logic\nused in these two callbacks isn't consistent in msm drivers, which could\nlead to kernel panic.\n\nFor example, on .remove the component is deleted and its .unbind callback\nleads to the hardware being shutdown but only if the DRM device has been\nmarked as registered.\n\nThat check doesn't exist in the .shutdown logic and this can lead to the\ndriver calling drm_atomic_helper_shutdown() for a DRM device that hasn't\nbeen properly initialized.\n\nA situation like this can happen if drivers for expected sub-devices fail\nto probe, since the .bind callback will never be executed. If that is the\ncase, drm_atomic_helper_shutdown() will attempt to take mutexes that are\nonly initialized if drm_mode_config_init() is called during a device bind.\n\nThis bug was attempted to be fixed in commit 623f279c7781 ("drm/msm: fix\nshutdown hook in case GPU components failed to bind"), but unfortunately\nit still happens in some cases as the one mentioned above, i.e:\n\n systemd-shutdown[1]: Powering off.\n kvm: exiting hardware virtualization\n platform wifi-firmware.0: Removing from iommu group 12\n platform video-firmware.0: Removing from iommu group 10\n ------------[ cut here ]------------\n WARNING: CPU: 6 PID: 1 at drivers/gpu/drm/drm_modeset_lock.c:317 drm_modeset_lock_all_ctx+0x3c4/0x3d0\n ...\n Hardware name: Google CoachZ (rev3+) (DT)\n pstate: a0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : drm_modeset_lock_all_ctx+0x3c4/0x3d0\n lr : drm_modeset_lock_all_ctx+0x48/0x3d0\n sp : ffff80000805bb80\n x29: ffff80000805bb80 x28: ffff327c00128000 x27: 0000000000000000\n x26: 0000000000000000 x25: 0000000000000001 x24: ffffc95d820ec030\n x23: ffff327c00bbd090 x22: ffffc95d8215eca0 x21: ffff327c039c5800\n x20: ffff327c039c5988 x19: ffff80000805bbe8 x18: 0000000000000034\n x17: 000000040044ffff x16: ffffc95d80cac920 x15: 0000000000000000\n x14: 0000000000000315 x13: 0000000000000315 x12: 0000000000000000\n x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000\n x8 : ffff80000805bc28 x7 : 0000000000000000 x6 : 0000000000000000\n x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000\n x2 : ffff327c00128000 x1 : 0000000000000000 x0 : ffff327c039c59b0\n Call trace:\n drm_modeset_lock_all_ctx+0x3c4/0x3d0\n drm_atomic_helper_shutdown+0x70/0x134\n msm_drv_shutdown+0x30/0x40\n platform_shutdown+0x28/0x40\n device_shutdown+0x148/0x350\n kernel_power_off+0x38/0x80\n __do_sys_reboot+0x288/0x2c0\n __arm64_sys_reboot+0x28/0x34\n invoke_syscall+0x48/0x114\n el0_svc_common.constprop.0+0x44/0xec\n do_el0_svc+0x2c/0xc0\n el0_svc+0x2c/0x84\n el0t_64_sync_handler+0x11c/0x150\n el0t_64_sync+0x18c/0x190\n ---[ end trace 0000000000000000 ]---\n Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018\n Mem abort info:\n ESR = 0x0000000096000004\n EC = 0x25: DABT (current EL), IL = 32 bits\n SET = 0, FnV = 0\n EA = 0, S1PTW = 0\n FSC = 0x04: level 0 translation fault\n Data abort info:\n ISV = 0, ISS = 0x00000004\n CM = 0, WnR = 0\n user pgtable: 4k pages, 48-bit VAs, pgdp=000000010eab1000\n [0000000000000018] pgd=0000000000000000, p4d=0000000000000000\n Internal error: Oops: 96000004 [#1] PREEMPT SMP\n ...\n Hardware name: Google CoachZ (rev3+) (DT)\n pstate: a0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : ww_mutex_lock+0x28/0x32c\n lr : drm_modeset_lock_all_ctx+0x1b0/0x3d0\n sp : ffff80000805bb50\n x29: ffff80000805bb50 x28: ffff327c00128000 x27: 0000000000000000\n x26: 00000\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: fix race in sock_map_free()\n\nsock_map_free() calls release_sock(sk) without owning a reference\non the socket. This can cause use-after-free as syzbot found [1]\n\nJakub Sitnicki already took care of a similar issue\nin sock_hash_free() in commit 75e68e5bf2c7 ("bpf, sockhash:\nSynchronize delete from bucket list on map free")\n\n[1]\nrefcount_t: decrement hit 0; leaking memory.\nWARNING: CPU: 0 PID: 3785 at lib/refcount.c:31 refcount_warn_saturate+0x17c/0x1a0 lib/refcount.c:31\nModules linked in:\nCPU: 0 PID: 3785 Comm: kworker/u4:6 Not tainted 6.1.0-rc7-syzkaller-00103-gef4d3ea40565 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022\nWorkqueue: events_unbound bpf_map_free_deferred\nRIP: 0010:refcount_warn_saturate+0x17c/0x1a0 lib/refcount.c:31\nCode: 68 8b 31 c0 e8 75 71 15 fd 0f 0b e9 64 ff ff ff e8 d9 6e 4e fd c6 05 62 9c 3d 0a 01 48 c7 c7 80 bb 68 8b 31 c0 e8 54 71 15 fd <0f> 0b e9 43 ff ff ff 89 d9 80 e1 07 80 c1 03 38 c1 0f 8c a2 fe ff\nRSP: 0018:ffffc9000456fb60 EFLAGS: 00010246\nRAX: eae59bab72dcd700 RBX: 0000000000000004 RCX: ffff8880207057c0\nRDX: 0000000000000000 RSI: 0000000000000201 RDI: 0000000000000000\nRBP: 0000000000000004 R08: ffffffff816fdabd R09: fffff520008adee5\nR10: fffff520008adee5 R11: 1ffff920008adee4 R12: 0000000000000004\nR13: dffffc0000000000 R14: ffff88807b1c6c00 R15: 1ffff1100f638dcf\nFS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000001b30c30000 CR3: 000000000d08e000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n\n__refcount_dec include/linux/refcount.h:344 [inline]\nrefcount_dec include/linux/refcount.h:359 [inline]\n__sock_put include/net/sock.h:779 [inline]\ntcp_release_cb+0x2d0/0x360 net/ipv4/tcp_output.c:1092\nrelease_sock+0xaf/0x1c0 net/core/sock.c:3468\nsock_map_free+0x219/0x2c0 net/core/sock_map.c:356\nprocess_one_work+0x81c/0xd10 kernel/workqueue.c:2289\nworker_thread+0xb14/0x1330 kernel/workqueue.c:2436\nkthread+0x266/0x300 kernel/kthread.c:376\nret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306\n

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: Fix potential stack-out-of-bounds in brcmf_c_preinit_dcmds()\n\nThis patch fixes a stack-out-of-bounds read in brcmfmac that occurs\nwhen 'buf' that is not null-terminated is passed as an argument of\nstrsep() in brcmf_c_preinit_dcmds(). This buffer is filled with a firmware\nversion string by memcpy() in brcmf_fil_iovar_data_get().\nThe patch ensures buf is null-terminated.\n\nFound by a modified version of syzkaller.\n\n[ 47.569679][ T1897] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43236b for chip BCM43236/3\n[ 47.582839][ T1897] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available\n[ 47.601565][ T1897] ==================================================================\n[ 47.602574][ T1897] BUG: KASAN: stack-out-of-bounds in strsep+0x1b2/0x1f0\n[ 47.603447][ T1897] Read of size 1 at addr ffffc90001f6f000 by task kworker/0:2/1897\n[ 47.604336][ T1897]\n[ 47.604621][ T1897] CPU: 0 PID: 1897 Comm: kworker/0:2 Tainted: G O 5.14.0+ #131\n[ 47.605617][ T1897] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014\n[ 47.606907][ T1897] Workqueue: usb_hub_wq hub_event\n[ 47.607453][ T1897] Call Trace:\n[ 47.607801][ T1897] dump_stack_lvl+0x8e/0xd1\n[ 47.608295][ T1897] print_address_description.constprop.0.cold+0xf/0x334\n[ 47.609009][ T1897] ? strsep+0x1b2/0x1f0\n[ 47.609434][ T1897] ? strsep+0x1b2/0x1f0\n[ 47.609863][ T1897] kasan_report.cold+0x83/0xdf\n[ 47.610366][ T1897] ? strsep+0x1b2/0x1f0\n[ 47.610882][ T1897] strsep+0x1b2/0x1f0\n[ 47.611300][ T1897] ? brcmf_fil_iovar_data_get+0x3a/0xf0\n[ 47.611883][ T1897] brcmf_c_preinit_dcmds+0x995/0xc40\n[ 47.612434][ T1897] ? brcmf_c_set_joinpref_default+0x100/0x100\n[ 47.613078][ T1897] ? rcu_read_lock_sched_held+0xa1/0xd0\n[ 47.613662][ T1897] ? rcu_read_lock_bh_held+0xb0/0xb0\n[ 47.614208][ T1897] ? lock_acquire+0x19d/0x4e0\n[ 47.614704][ T1897] ? find_held_lock+0x2d/0x110\n[ 47.615236][ T1897] ? brcmf_usb_deq+0x1a7/0x260\n[ 47.615741][ T1897] ? brcmf_usb_rx_fill_all+0x5a/0xf0\n[ 47.616288][ T1897] brcmf_attach+0x246/0xd40\n[ 47.616758][ T1897] ? wiphy_new_nm+0x1703/0x1dd0\n[ 47.617280][ T1897] ? kmemdup+0x43/0x50\n[ 47.617720][ T1897] brcmf_usb_probe+0x12de/0x1690\n[ 47.618244][ T1897] ? brcmf_usbdev_qinit.constprop.0+0x470/0x470\n[ 47.618901][ T1897] usb_probe_interface+0x2aa/0x760\n[ 47.619429][ T1897] ? usb_probe_device+0x250/0x250\n[ 47.619950][ T1897] really_probe+0x205/0xb70\n[ 47.620435][ T1897] ? driver_allows_async_probing+0x130/0x130\n[ 47.621048][ T1897] __driver_probe_device+0x311/0x4b0\n[ 47.621595][ T1897] ? driver_allows_async_probing+0x130/0x130\n[ 47.622209][ T1897] driver_probe_device+0x4e/0x150\n[ 47.622739][ T1897] __device_attach_driver+0x1cc/0x2a0\n[ 47.623287][ T1897] bus_for_each_drv+0x156/0x1d0\n[ 47.623796][ T1897] ? bus_rescan_devices+0x30/0x30\n[ 47.624309][ T1897] ? lockdep_hardirqs_on_prepare+0x273/0x3e0\n[ 47.624907][ T1897] ? trace_hardirqs_on+0x46/0x160\n[ 47.625437][ T1897] __device_attach+0x23f/0x3a0\n[ 47.625924][ T1897] ? device_bind_driver+0xd0/0xd0\n[ 47.626433][ T1897] ? kobject_uevent_env+0x287/0x14b0\n[ 47.627057][ T1897] bus_probe_device+0x1da/0x290\n[ 47.627557][ T1897] device_add+0xb7b/0x1eb0\n[ 47.628027][ T1897] ? wait_for_completion+0x290/0x290\n[ 47.628593][ T1897] ? __fw_devlink_link_to_suppliers+0x5a0/0x5a0\n[ 47.629249][ T1897] usb_set_configuration+0xf59/0x16f0\n[ 47.629829][ T1897] usb_generic_driver_probe+0x82/0xa0\n[ 47.630385][ T1897] usb_probe_device+0xbb/0x250\n[ 47.630927][ T1897] ? usb_suspend+0x590/0x590\n[ 47.631397][ T1897] really_probe+0x205/0xb70\n[ 47.631855][ T1897] ? driver_allows_async_probing+0x130/0x130\n[ 47.632469][ T1897] __driver_probe_device+0x311/0x4b0\n[ 47.633002][ \n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nxen/gntdev: Prevent leaking grants\n\nPrior to this commit, if a grant mapping operation failed partially,\nsome of the entries in the map_ops array would be invalid, whereas all\nof the entries in the kmap_ops array would be valid. This in turn would\ncause the following logic in gntdev_map_grant_pages to become invalid:\n\n for (i = 0; i < map->count; i++) {\n if (map->map_ops[i].status == GNTST_okay) {\n map->unmap_ops[i].handle = map->map_ops[i].handle;\n if (!use_ptemod)\n alloced++;\n }\n if (use_ptemod) {\n if (map->kmap_ops[i].status == GNTST_okay) {\n if (map->map_ops[i].status == GNTST_okay)\n alloced++;\n map->kunmap_ops[i].handle = map->kmap_ops[i].handle;\n }\n }\n }\n ...\n atomic_add(alloced, &map->live_grants);\n\nAssume that use_ptemod is true (i.e., the domain mapping the granted\npages is a paravirtualized domain). In the code excerpt above, note that\nthe "alloced" variable is only incremented when both kmap_ops[i].status\nand map_ops[i].status are set to GNTST_okay (i.e., both mapping\noperations are successful). However, as also noted above, there are\ncases where a grant mapping operation fails partially, breaking the\nassumption of the code excerpt above.\n\nThe aforementioned causes map->live_grants to be incorrectly set. In\nsome cases, all of the map_ops mappings fail, but all of the kmap_ops\nmappings succeed, meaning that live_grants may remain zero. This in turn\nmakes it impossible to unmap the successfully grant-mapped pages pointed\nto by kmap_ops, because unmap_grant_pages has the following snippet of\ncode at its beginning:\n\n if (atomic_read(&map->live_grants) == 0)\n return; /* Nothing to do */\n\nIn other cases where only some of the map_ops mappings fail but all\nkmap_ops mappings succeed, live_grants is made positive, but when the\nuser requests unmapping the grant-mapped pages, __unmap_grant_pages_done\nwill then make map->live_grants negative, because the latter function\ndoes not check if all of the pages that were requested to be unmapped\nwere actually unmapped, and the same function unconditionally subtracts\n"data->count" (i.e., a value that can be greater than map->live_grants)\nfrom map->live_grants. The side effects of a negative live_grants value\nhave not been studied.\n\nThe net effect of all of this is that grant references are leaked in one\nof the above conditions. In Qubes OS v4.1 (which uses Xen's grant\nmechanism extensively for X11 GUI isolation), this issue manifests\nitself with warning messages like the following to be printed out by the\nLinux kernel in the VM that had granted pages (that contain X11 GUI\nwindow data) to dom0: "g.e. 0x1234 still pending", especially after the\nuser rapidly resizes GUI VM windows (causing some grant-mapping\noperations to partially or completely fail, due to the fact that the VM\nunshares some of the pages as part of the window resizing, making the\npages impossible to grant-map from dom0).\n\nThe fix for this issue involves counting all successful map_ops and\nkmap_ops mappings separately, and then adding the sum to live_grants.\nDuring unmapping, only the number of successfully unmapped grants is\nsubtracted from live_grants. The code is also modified to check for\nnegative live_grants values after the subtraction and warn the user.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/meson: remove drm bridges at aggregate driver unbind time\n\ndrm bridges added by meson_encoder_hdmi_init and meson_encoder_cvbs_init\nwere not manually removed at module unload time, which caused dangling\nreferences to freed memory to remain linked in the global bridge_list.\n\nWhen loading the driver modules back in, the same functions would again\ncall drm_bridge_add, and when traversing the global bridge_list, would\nend up peeking into freed memory.\n\nOnce again KASAN revealed the problem:\n\n[ +0.000095] =============================================================\n[ +0.000008] BUG: KASAN: use-after-free in __list_add_valid+0x9c/0x120\n[ +0.000018] Read of size 8 at addr ffff00003da291f0 by task modprobe/2483\n\n[ +0.000018] CPU: 3 PID: 2483 Comm: modprobe Tainted: G C O 5.19.0-rc6-lrmbkasan+ #1\n[ +0.000011] Hardware name: Hardkernel ODROID-N2Plus (DT)\n[ +0.000008] Call trace:\n[ +0.000006] dump_backtrace+0x1ec/0x280\n[ +0.000012] show_stack+0x24/0x80\n[ +0.000008] dump_stack_lvl+0x98/0xd4\n[ +0.000011] print_address_description.constprop.0+0x80/0x520\n[ +0.000011] print_report+0x128/0x260\n[ +0.000008] kasan_report+0xb8/0xfc\n[ +0.000008] __asan_report_load8_noabort+0x3c/0x50\n[ +0.000009] __list_add_valid+0x9c/0x120\n[ +0.000009] drm_bridge_add+0x6c/0x104 [drm]\n[ +0.000165] dw_hdmi_probe+0x1900/0x2360 [dw_hdmi]\n[ +0.000022] meson_dw_hdmi_bind+0x520/0x814 [meson_dw_hdmi]\n[ +0.000014] component_bind+0x174/0x520\n[ +0.000012] component_bind_all+0x1a8/0x38c\n[ +0.000010] meson_drv_bind_master+0x5e8/0xb74 [meson_drm]\n[ +0.000032] meson_drv_bind+0x20/0x2c [meson_drm]\n[ +0.000027] try_to_bring_up_aggregate_device+0x19c/0x390\n[ +0.000010] component_master_add_with_match+0x1c8/0x284\n[ +0.000009] meson_drv_probe+0x274/0x280 [meson_drm]\n[ +0.000026] platform_probe+0xd0/0x220\n[ +0.000009] really_probe+0x3ac/0xa80\n[ +0.000009] __driver_probe_device+0x1f8/0x400\n[ +0.000009] driver_probe_device+0x68/0x1b0\n[ +0.000009] __driver_attach+0x20c/0x480\n[ +0.000008] bus_for_each_dev+0x114/0x1b0\n[ +0.000009] driver_attach+0x48/0x64\n[ +0.000008] bus_add_driver+0x390/0x564\n[ +0.000009] driver_register+0x1a8/0x3e4\n[ +0.000009] __platform_driver_register+0x6c/0x94\n[ +0.000008] meson_drm_platform_driver_init+0x3c/0x1000 [meson_drm]\n[ +0.000027] do_one_initcall+0xc4/0x2b0\n[ +0.000011] do_init_module+0x154/0x570\n[ +0.000011] load_module+0x1a78/0x1ea4\n[ +0.000008] __do_sys_init_module+0x184/0x1cc\n[ +0.000009] __arm64_sys_init_module+0x78/0xb0\n[ +0.000009] invoke_syscall+0x74/0x260\n[ +0.000009] el0_svc_common.constprop.0+0xcc/0x260\n[ +0.000008] do_el0_svc+0x50/0x70\n[ +0.000007] el0_svc+0x68/0x1a0\n[ +0.000012] el0t_64_sync_handler+0x11c/0x150\n[ +0.000008] el0t_64_sync+0x18c/0x190\n\n[ +0.000016] Allocated by task 879:\n[ +0.000008] kasan_save_stack+0x2c/0x5c\n[ +0.000011] __kasan_kmalloc+0x90/0xd0\n[ +0.000007] __kmalloc+0x278/0x4a0\n[ +0.000011] mpi_resize+0x13c/0x1d0\n[ +0.000011] mpi_powm+0xd24/0x1570\n[ +0.000009] rsa_enc+0x1a4/0x30c\n[ +0.000009] pkcs1pad_verify+0x3f0/0x580\n[ +0.000009] public_key_verify_signature+0x7a8/0xba4\n[ +0.000010] public_key_verify_signature_2+0x40/0x60\n[ +0.000008] verify_signature+0xb4/0x114\n[ +0.000008] pkcs7_validate_trust_one.constprop.0+0x3b8/0x574\n[ +0.000009] pkcs7_validate_trust+0xb8/0x15c\n[ +0.000008] verify_pkcs7_message_sig+0xec/0x1b0\n[ +0.000012] verify_pkcs7_signature+0x78/0xac\n[ +0.000007] mod_verify_sig+0x110/0x190\n[ +0.000009] module_sig_check+0x114/0x1e0\n[ +0.000009] load_module+0xa0/0x1ea4\n[ +0.000008] __do_sys_init_module+0x184/0x1cc\n[ +0.000008] __arm64_sys_init_module+0x78/0xb0\n[ +0.000008] invoke_syscall+0x74/0x260\n[ +0.000009] el0_svc_common.constprop.0+0x1a8/0x260\n[ +0.000008] do_el0_svc+0x50/0x70\n[ +0.000007] el0_svc+0x68/0x1a0\n[ +0.000009] el0t_64_sync_handler+0x11c/0x150\n[ +0.000009] el0t_64\n---truncated---

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nrapidio: fix possible UAF when kfifo_alloc() fails\n\nIf kfifo_alloc() fails in mport_cdev_open(), goto err_fifo and just free\npriv. But priv is still in the chdev->file_list, then list traversal\nmay cause UAF. This fixes the following smatch warning:\n\ndrivers/rapidio/devices/rio_mport_cdev.c:1930 mport_cdev_open() warn: '&priv->list' not removed from list

In the Linux kernel, the following vulnerability has been resolved:\n\nsctp: handle the error returned from sctp_auth_asoc_init_active_key\n\nWhen it returns an error from sctp_auth_asoc_init_active_key(), the\nactive_key is actually not updated. The old sh_key will be freeed\nwhile it's still used as active key in asoc. Then an use-after-free\nwill be triggered when sending patckets, as found by syzbot:\n\n sctp_auth_shkey_hold+0x22/0xa0 net/sctp/auth.c:112\n sctp_set_owner_w net/sctp/socket.c:132 [inline]\n sctp_sendmsg_to_asoc+0xbd5/0x1a20 net/sctp/socket.c:1863\n sctp_sendmsg+0x1053/0x1d50 net/sctp/socket.c:2025\n inet_sendmsg+0x99/0xe0 net/ipv4/af_inet.c:819\n sock_sendmsg_nosec net/socket.c:714 [inline]\n sock_sendmsg+0xcf/0x120 net/socket.c:734\n\nThis patch is to fix it by not replacing the sh_key when it returns\nerrors from sctp_auth_asoc_init_active_key() in sctp_auth_set_key().\nFor sctp_auth_set_active_key(), old active_key_id will be set back\nto asoc->active_key_id when the same thing happens.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrivers: net: qlcnic: Fix potential memory leak in qlcnic_sriov_init()\n\nIf vp alloc failed in qlcnic_sriov_init(), all previously allocated vp\nneeds to be freed.

In the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: fix use-after-free on source server when doing inter-server copy\n\nUse-after-free occurred when the laundromat tried to free expired\ncpntf_state entry on the s2s_cp_stateids list after inter-server\ncopy completed. The sc_cp_list that the expired copy state was\ninserted on was already freed.\n\nWhen COPY completes, the Linux client normally sends LOCKU(lock_state x),\nFREE_STATEID(lock_state x) and CLOSE(open_state y) to the source server.\nThe nfs4_put_stid call from nfsd4_free_stateid cleans up the copy state\nfrom the s2s_cp_stateids list before freeing the lock state's stid.\n\nHowever, sometimes the CLOSE was sent before the FREE_STATEID request.\nWhen this happens, the nfsd4_close_open_stateid call from nfsd4_close\nfrees all lock states on its st_locks list without cleaning up the copy\nstate on the sc_cp_list list. When the time the FREE_STATEID arrives the\nserver returns BAD_STATEID since the lock state was freed. This causes\nthe use-after-free error to occur when the laundromat tries to free\nthe expired cpntf_state.\n\nThis patch adds a call to nfs4_free_cpntf_statelist in\nnfsd4_close_open_stateid to clean up the copy state before calling\nfree_ol_stateid_reaplist to free the lock state's stid on the reaplist.

In the Linux kernel, the following vulnerability has been resolved:\n\nbinder: fix UAF of alloc->vma in race with munmap()\n\nIn commit 720c24192404 ("ANDROID: binder: change down_write to\ndown_read") binder assumed the mmap read lock is sufficient to protect\nalloc->vma inside binder_update_page_range(). This used to be accurate\nuntil commit dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in\nmunmap"), which now downgrades the mmap_lock after detaching the vma\nfrom the rbtree in munmap(). Then it proceeds to teardown and free the\nvma with only the read lock held.\n\nThis means that accesses to alloc->vma in binder_update_page_range() now\nwill race with vm_area_free() in munmap() and can cause a UAF as shown\nin the following KASAN trace:\n\n ==================================================================\n BUG: KASAN: use-after-free in vm_insert_page+0x7c/0x1f0\n Read of size 8 at addr ffff16204ad00600 by task server/558\n\n CPU: 3 PID: 558 Comm: server Not tainted 5.10.150-00001-gdc8dcf942daa #1\n Hardware name: linux,dummy-virt (DT)\n Call trace:\n dump_backtrace+0x0/0x2a0\n show_stack+0x18/0x2c\n dump_stack+0xf8/0x164\n print_address_description.constprop.0+0x9c/0x538\n kasan_report+0x120/0x200\n __asan_load8+0xa0/0xc4\n vm_insert_page+0x7c/0x1f0\n binder_update_page_range+0x278/0x50c\n binder_alloc_new_buf+0x3f0/0xba0\n binder_transaction+0x64c/0x3040\n binder_thread_write+0x924/0x2020\n binder_ioctl+0x1610/0x2e5c\n __arm64_sys_ioctl+0xd4/0x120\n el0_svc_common.constprop.0+0xac/0x270\n do_el0_svc+0x38/0xa0\n el0_svc+0x1c/0x2c\n el0_sync_handler+0xe8/0x114\n el0_sync+0x180/0x1c0\n\n Allocated by task 559:\n kasan_save_stack+0x38/0x6c\n __kasan_kmalloc.constprop.0+0xe4/0xf0\n kasan_slab_alloc+0x18/0x2c\n kmem_cache_alloc+0x1b0/0x2d0\n vm_area_alloc+0x28/0x94\n mmap_region+0x378/0x920\n do_mmap+0x3f0/0x600\n vm_mmap_pgoff+0x150/0x17c\n ksys_mmap_pgoff+0x284/0x2dc\n __arm64_sys_mmap+0x84/0xa4\n el0_svc_common.constprop.0+0xac/0x270\n do_el0_svc+0x38/0xa0\n el0_svc+0x1c/0x2c\n el0_sync_handler+0xe8/0x114\n el0_sync+0x180/0x1c0\n\n Freed by task 560:\n kasan_save_stack+0x38/0x6c\n kasan_set_track+0x28/0x40\n kasan_set_free_info+0x24/0x4c\n __kasan_slab_free+0x100/0x164\n kasan_slab_free+0x14/0x20\n kmem_cache_free+0xc4/0x34c\n vm_area_free+0x1c/0x2c\n remove_vma+0x7c/0x94\n __do_munmap+0x358/0x710\n __vm_munmap+0xbc/0x130\n __arm64_sys_munmap+0x4c/0x64\n el0_svc_common.constprop.0+0xac/0x270\n do_el0_svc+0x38/0xa0\n el0_svc+0x1c/0x2c\n el0_sync_handler+0xe8/0x114\n el0_sync+0x180/0x1c0\n\n [...]\n ==================================================================\n\nTo prevent the race above, revert back to taking the mmap write lock\ninside binder_update_page_range(). One might expect an increase of mmap\nlock contention. However, binder already serializes these calls via top\nlevel alloc->mutex. Also, there was no performance impact shown when\nrunning the binder benchmark tests.\n\nNote this patch is specific to stable branches 5.4 and 5.10. Since in\nnewer kernel releases binder no longer caches a pointer to the vma.\nInstead, it has been refactored to use vma_lookup() which avoids the\nissue described here. This switch was introduced in commit a43cfc87caaf\n("android: binder: stop saving a pointer to the VMA").

In the Linux kernel, the following vulnerability has been resolved:\n\ncpufreq: qcom: fix writes in read-only memory region\n\nThis commit fixes a kernel oops because of a write in some read-only memory:\n\n [ 9.068287] Unable to handle kernel write to read-only memory at virtual address ffff800009240ad8\n ..snip..\n [ 9.138790] Internal error: Oops: 9600004f [#1] PREEMPT SMP\n ..snip..\n [ 9.269161] Call trace:\n [ 9.276271] __memcpy+0x5c/0x230\n [ 9.278531] snprintf+0x58/0x80\n [ 9.282002] qcom_cpufreq_msm8939_name_version+0xb4/0x190\n [ 9.284869] qcom_cpufreq_probe+0xc8/0x39c\n ..snip..\n\nThe following line defines a pointer that point to a char buffer stored\nin read-only memory:\n\n char *pvs_name = "speedXX-pvsXX-vXX";\n\nThis pointer is meant to hold a template "speedXX-pvsXX-vXX" where the\nXX values get overridden by the qcom_cpufreq_krait_name_version function. Since\nthe template is actually stored in read-only memory, when the function\nexecutes the following call we get an oops:\n\n snprintf(*pvs_name, sizeof("speedXX-pvsXX-vXX"), "speed%d-pvs%d-v%d",\n speed, pvs, pvs_ver);\n\nTo fix this issue, we instead store the template name onto the stack by\nusing the following syntax:\n\n char pvs_name_buffer[] = "speedXX-pvsXX-vXX";\n\nBecause the `pvs_name` needs to be able to be assigned to NULL, the\ntemplate buffer is stored in the pvs_name_buffer and not under the\npvs_name variable.

In the Linux kernel, the following vulnerability has been resolved:\n\niommu/mediatek: Fix crash on isr after kexec()\n\nIf the system is rebooted via isr(), the IRQ handler might\nbe triggered before the domain is initialized. Resulting on\nan invalid memory access error.\n\nFix:\n[ 0.500930] Unable to handle kernel read from unreadable memory at virtual address 0000000000000070\n[ 0.501166] Call trace:\n[ 0.501174] report_iommu_fault+0x28/0xfc\n[ 0.501180] mtk_iommu_isr+0x10c/0x1c0\n\n[ joro: Fixed spelling in commit message ]

No description is available for this CVE.

No description is available for this CVE.

A flaw was found in CUPS, a widely used printing service on Linux and UNIX-like systems. The issue arises when authentication is configured to use a method other than Basic, but the attacker sends an HTTP request with a Basic authentication header. Due to improper validation in the cupsdAuthorize() function, the password is not checked. This vulnerability allows attackers to bypass authentication entirely, resulting in unauthorized access to administrative functions and system configuration.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.