In the Linux kernel, the following vulnerability has been resolved:\nmemory: pl353-smc: Fix refcount leak bug in pl353_smc_probe()\nThe break of for_each_available_child_of_node() needs a\ncorresponding of_node_put() when the reference 'child' is not\nused anymore. Here we do not need to call of_node_put() in\nfail path as '!match' means no break.\nWhile the of_platform_device_create() will created a new\nreference by 'child' but it has considered the refcounting.

In the Linux kernel, the following vulnerability has been resolved:\ndrm/amd: fix potential memory leak\nThis patch fix potential memory leak (clk_src) when function run\ninto last return NULL.\ns/free/kfree/ - Alex

In the Linux kernel, the following vulnerability has been resolved:\nnilfs2: fix shift-out-of-bounds/overflow in nilfs_sb2_bad_offset()\nPatch series "nilfs2: fix UBSAN shift-out-of-bounds warnings on mount\ntime".\nThe first patch fixes a bug reported by syzbot, and the second one fixes\nthe remaining bug of the same kind. Although they are triggered by the\nsame super block data anomaly, I divided it into the above two because the\ndetails of the issues and how to fix it are different.\nBoth are required to eliminate the shift-out-of-bounds issues at mount\ntime.\nThis patch (of 2):\nIf the block size exponent information written in an on-disk superblock is\ncorrupted, nilfs_sb2_bad_offset helper function can trigger\nshift-out-of-bounds warning followed by a kernel panic (if panic_on_warn\nis set):\nshift exponent 38983 is too large for 64-bit type 'unsigned long long'\nCall Trace:\n\n__dump_stack lib/dump_stack.c:88 [inline]\ndump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106\nubsan_epilogue lib/ubsan.c:151 [inline]\n__ubsan_handle_shift_out_of_bounds+0x33d/0x3b0 lib/ubsan.c:322\nnilfs_sb2_bad_offset fs/nilfs2/the_nilfs.c:449 [inline]\nnilfs_load_super_block+0xdf5/0xe00 fs/nilfs2/the_nilfs.c:523\ninit_nilfs+0xb7/0x7d0 fs/nilfs2/the_nilfs.c:577\nnilfs_fill_super+0xb1/0x5d0 fs/nilfs2/super.c:1047\nnilfs_mount+0x613/0x9b0 fs/nilfs2/super.c:1317\n...\nIn addition, since nilfs_sb2_bad_offset() performs multiplication without\nconsidering the upper bound, the computation may overflow if the disk\nlayout parameters are not normal.\nThis fixes these issues by inserting preliminary sanity checks for those\nparameters and by converting the comparison from one involving\nmultiplication and left bit-shifting to one using division and right\nbit-shifting.

In the Linux kernel, the following vulnerability has been resolved:\nrtc: class: Fix potential memleak in devm_rtc_allocate_device()\ndevm_rtc_allocate_device() will alloc a rtc_device first, and then run\ndev_set_name(). If dev_set_name() failed, the rtc_device will memleak.\nMove devm_add_action_or_reset() in front of dev_set_name() to prevent\nmemleak.\nunreferenced object 0xffff888110a53000 (size 2048):\ncomm "python3", pid 470, jiffies 4296078308 (age 58.882s)\nhex dump (first 32 bytes):\n00 00 00 00 00 00 00 00 08 30 a5 10 81 88 ff ff .........0......\n08 30 a5 10 81 88 ff ff 00 00 00 00 00 00 00 00 .0..............\nbacktrace:\n[<000000004aac0364>] kmalloc_trace+0x21/0x110\n[<000000000ff02202>] devm_rtc_allocate_device+0xd4/0x400\n[<000000001bdf5639>] devm_rtc_device_register+0x1a/0x80\n[<00000000351bf81c>] rx4581_probe+0xdd/0x110 [rtc_rx4581]\n[<00000000f0eba0ae>] spi_probe+0xde/0x130\n[<00000000bff89ee8>] really_probe+0x175/0x3f0\n[<00000000128e8d84>] __driver_probe_device+0xe6/0x170\n[<00000000ee5bf913>] device_driver_attach+0x32/0x80\n[<00000000f3f28f92>] bind_store+0x10b/0x1a0\n[<000000009ff812d8>] drv_attr_store+0x49/0x70\n[<000000008139c323>] sysfs_kf_write+0x8d/0xb0\n[<00000000b6146e01>] kernfs_fop_write_iter+0x214/0x2d0\n[<00000000ecbe3895>] vfs_write+0x61a/0x7d0\n[<00000000aa2196ea>] ksys_write+0xc8/0x190\n[<0000000046a600f5>] do_syscall_64+0x37/0x90\n[<00000000541a336f>] entry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:\nntb_netdev: Use dev_kfree_skb_any() in interrupt context\nTX/RX callback handlers (ntb_netdev_tx_handler(),\nntb_netdev_rx_handler()) can be called in interrupt\ncontext via the DMA framework when the respective\nDMA operations have completed. As such, any calls\nby these routines to free skb's, should use the\ninterrupt context safe dev_kfree_skb_any() function.\nPreviously, these callback handlers would call the\ninterrupt unsafe version of dev_kfree_skb(). This has\nnot presented an issue on Intel IOAT DMA engines as\nthat driver utilizes tasklets rather than a hard\ninterrupt handler, like the AMD PTDMA DMA driver.\nOn AMD systems, a kernel WARNING message is\nencountered, which is being issued from\nskb_release_head_state() due to in_hardirq()\nbeing true.\nBesides the user visible WARNING from the kernel,\nthe other symptom of this bug was that TCP/IP performance\nacross the ntb_netdev interface was very poor, i.e.\napproximately an order of magnitude below what was\nexpected. With the repair to use dev_kfree_skb_any(),\nkernel WARNINGs from skb_release_head_state() ceased\nand TCP/IP performance, as measured by iperf, was on\npar with expected results, approximately 20 Gb/s on\nAMD Milan based server. Note that this performance\nis comparable with Intel based servers.

In the Linux kernel, the following vulnerability has been resolved:\nRDMA/core: Make sure "ib_port" is valid when access sysfs node\nThe "ib_port" structure must be set before adding the sysfs kobject,\nand reset after removing it, otherwise it may crash when accessing\nthe sysfs node:\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000050\nMem abort info:\nESR = 0x96000006\nException class = DABT (current EL), IL = 32 bits\nSET = 0, FnV = 0\nEA = 0, S1PTW = 0\nData abort info:\nISV = 0, ISS = 0x00000006\nCM = 0, WnR = 0\nuser pgtable: 4k pages, 48-bit VAs, pgdp = 00000000e85f5ba5\n[0000000000000050] pgd=0000000848fd9003, pud=000000085b387003, pmd=0000000000000000\nInternal error: Oops: 96000006 [#2] PREEMPT SMP\nModules linked in: ib_umad(O) mlx5_ib(O) nfnetlink_cttimeout(E) nfnetlink(E) act_gact(E) cls_flower(E) sch_ingress(E) openvswitch(E) nsh(E) nf_nat_ipv6(E) nf_nat_ipv4(E) nf_conncount(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) mst_pciconf(O) ipmi_devintf(E) ipmi_msghandler(E) ipmb_dev_int(OE) mlx5_core(O) mlxfw(O) mlxdevm(O) auxiliary(O) ib_uverbs(O) ib_core(O) mlx_compat(O) psample(E) sbsa_gwdt(E) uio_pdrv_genirq(E) uio(E) mlxbf_pmc(OE) mlxbf_gige(OE) mlxbf_tmfifo(OE) gpio_mlxbf2(OE) pwr_mlxbf(OE) mlx_trio(OE) i2c_mlxbf(OE) mlx_bootctl(OE) bluefield_edac(OE) knem(O) ip_tables(E) ipv6(E) crc_ccitt(E) [last unloaded: mst_pci]\nProcess grep (pid: 3372, stack limit = 0x0000000022055c92)\nCPU: 5 PID: 3372 Comm: grep Tainted: G D OE 4.19.161-mlnx.47.gadcd9e3 #1\nHardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS BlueField:3.9.2-15-ga2403ab Sep 8 2022\npstate: 40000005 (nZcv daif -PAN -UAO)\npc : hw_stat_port_show+0x4c/0x80 [ib_core]\nlr : port_attr_show+0x40/0x58 [ib_core]\nsp : ffff000029f43b50\nx29: ffff000029f43b50 x28: 0000000019375000\nx27: ffff8007b821a540 x26: ffff000029f43e30\nx25: 0000000000008000 x24: ffff000000eaa958\nx23: 0000000000001000 x22: ffff8007a4ce3000\nx21: ffff8007baff8000 x20: ffff8007b9066ac0\nx19: ffff8007bae97578 x18: 0000000000000000\nx17: 0000000000000000 x16: 0000000000000000\nx15: 0000000000000000 x14: 0000000000000000\nx13: 0000000000000000 x12: 0000000000000000\nx11: 0000000000000000 x10: 0000000000000000\nx9 : 0000000000000000 x8 : ffff8007a4ce4000\nx7 : 0000000000000000 x6 : 000000000000003f\nx5 : ffff000000e6a280 x4 : ffff8007a4ce3000\nx3 : 0000000000000000 x2 : aaaaaaaaaaaaaaab\nx1 : ffff8007b9066a10 x0 : ffff8007baff8000\nCall trace:\nhw_stat_port_show+0x4c/0x80 [ib_core]\nport_attr_show+0x40/0x58 [ib_core]\nsysfs_kf_seq_show+0x8c/0x150\nkernfs_seq_show+0x44/0x50\nseq_read+0x1b4/0x45c\nkernfs_fop_read+0x148/0x1d8\n__vfs_read+0x58/0x180\nvfs_read+0x94/0x154\nksys_read+0x68/0xd8\n__arm64_sys_read+0x28/0x34\nel0_svc_common+0x88/0x18c\nel0_svc_handler+0x78/0x94\nel0_svc+0x8/0xe8\nCode: f2955562 aa1603e4 aa1503e0 f9405683 (f9402861)

In the Linux kernel, the following vulnerability has been resolved:\nmacintosh: fix possible memory leak in macio_add_one_device()\nAfer commit 1fa5ae857bb1 ("driver core: get rid of struct device's\nbus_id string array"), the name of device is allocated dynamically. It\nneeds to be freed when of_device_register() fails. Call put_device() to\ngive up the reference that's taken in device_initialize(), so that it\ncan be freed in kobject_cleanup() when the refcount hits 0.\nmacio device is freed in macio_release_dev(), so the kfree() can be\nremoved.

In the Linux kernel, the following vulnerability has been resolved:\ncpufreq: Init completion before kobject_init_and_add()\nIn cpufreq_policy_alloc(), it will call uninitialed completion in\ncpufreq_sysfs_release() when kobject_init_and_add() fails. And\nthat will cause a crash such as the following page fault in complete:\nBUG: unable to handle page fault for address: fffffffffffffff8\n[..]\nRIP: 0010:complete+0x98/0x1f0\n[..]\nCall Trace:\nkobject_put+0x1be/0x4c0\ncpufreq_online.cold+0xee/0x1fd\ncpufreq_add_dev+0x183/0x1e0\nsubsys_interface_register+0x3f5/0x4e0\ncpufreq_register_driver+0x3b7/0x670\nacpi_cpufreq_init+0x56c/0x1000 [acpi_cpufreq]\ndo_one_initcall+0x13d/0x780\ndo_init_module+0x1c3/0x630\nload_module+0x6e67/0x73b0\n__do_sys_finit_module+0x181/0x240\ndo_syscall_64+0x35/0x80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:\nIB/mad: Don't call to function that might sleep while in atomic context\nTracepoints are not allowed to sleep, as such the following splat is\ngenerated due to call to ib_query_pkey() in atomic context.\nWARNING: CPU: 0 PID: 1888000 at kernel/trace/ring_buffer.c:2492 rb_commit+0xc1/0x220\nCPU: 0 PID: 1888000 Comm: kworker/u9:0 Kdump: loaded Tainted: G OE --------- - - 4.18.0-305.3.1.el8.x86_64 #1\nHardware name: Red Hat KVM, BIOS 1.13.0-2.module_el8.3.0+555+a55c8938 04/01/2014\nWorkqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core]\nRIP: 0010:rb_commit+0xc1/0x220\nRSP: 0000:ffffa8ac80f9bca0 EFLAGS: 00010202\nRAX: ffff8951c7c01300 RBX: ffff8951c7c14a00 RCX: 0000000000000246\nRDX: ffff8951c707c000 RSI: ffff8951c707c57c RDI: ffff8951c7c14a00\nRBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000\nR10: ffff8951c7c01300 R11: 0000000000000001 R12: 0000000000000246\nR13: 0000000000000000 R14: ffffffff964c70c0 R15: 0000000000000000\nFS: 0000000000000000(0000) GS:ffff8951fbc00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f20e8f39010 CR3: 000000002ca10005 CR4: 0000000000170ef0\nCall Trace:\nring_buffer_unlock_commit+0x1d/0xa0\ntrace_buffer_unlock_commit_regs+0x3b/0x1b0\ntrace_event_buffer_commit+0x67/0x1d0\ntrace_event_raw_event_ib_mad_recv_done_handler+0x11c/0x160 [ib_core]\nib_mad_recv_done+0x48b/0xc10 [ib_core]\n? trace_event_raw_event_cq_poll+0x6f/0xb0 [ib_core]\n__ib_process_cq+0x91/0x1c0 [ib_core]\nib_cq_poll_work+0x26/0x80 [ib_core]\nprocess_one_work+0x1a7/0x360\n? create_worker+0x1a0/0x1a0\nworker_thread+0x30/0x390\n? create_worker+0x1a0/0x1a0\nkthread+0x116/0x130\n? kthread_flush_work_fn+0x10/0x10\nret_from_fork+0x35/0x40\n---[ end trace 78ba8509d3830a16 ]---

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\nxhci: Remove device endpoints from bandwidth list when freeing the device\nEndpoints are normally deleted from the bandwidth list when they are\ndropped, before the virt device is freed.\nIf xHC host is dying or being removed then the endpoints aren't dropped\ncleanly due to functions returning early to avoid interacting with a\nnon-accessible host controller.\nSo check and delete endpoints that are still on the bandwidth list when\nfreeing the virt device.\nSolves a list_del corruption kernel crash when unbinding xhci-pci,\ncaused by xhci_mem_cleanup() when it later tried to delete already freed\nendpoints from the bandwidth list.\nThis only affects hosts that use software bandwidth checking, which\ncurrenty is only the xHC in intel Panther Point PCH (Ivy Bridge)

In the Linux kernel, the following vulnerability has been resolved:\n\nstaging: rtl8723bs: fix potential memory leak in rtw_init_drv_sw()\n\nIn rtw_init_drv_sw(), there are various init functions are called to\npopulate the padapter structure and some checks for their return value.\nHowever, except for the first one error path, the other five error paths\ndo not properly release the previous allocated resources, which leads to\nvarious memory leaks.\n\nThis patch fixes them and keeps the success and error separate.\nNote that these changes keep the form of `rtw_init_drv_sw()` in\n"drivers/staging/r8188eu/os_dep/os_intfs.c". As there is no proper device\nto test with, no runtime testing was performed.

In the Linux kernel, the following vulnerability has been resolved:\n\nplatform/chrome: cros_usbpd_notify: Fix error handling in cros_usbpd_notify_init()\n\nThe following WARNING message was given when rmmod cros_usbpd_notify:\n\n Unexpected driver unregister!\n WARNING: CPU: 0 PID: 253 at drivers/base/driver.c:270 driver_unregister+0x8a/0xb0\n Modules linked in: cros_usbpd_notify(-)\n CPU: 0 PID: 253 Comm: rmmod Not tainted 6.1.0-rc3 #24\n ...\n Call Trace:\n \n cros_usbpd_notify_exit+0x11/0x1e [cros_usbpd_notify]\n __x64_sys_delete_module+0x3c7/0x570\n ? __ia32_sys_delete_module+0x570/0x570\n ? lock_is_held_type+0xe3/0x140\n ? syscall_enter_from_user_mode+0x17/0x50\n ? rcu_read_lock_sched_held+0xa0/0xd0\n ? syscall_enter_from_user_mode+0x1c/0x50\n do_syscall_64+0x37/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n RIP: 0033:0x7f333fe9b1b7\n\nThe reason is that the cros_usbpd_notify_init() does not check the return\nvalue of platform_driver_register(), and the cros_usbpd_notify can\ninstall successfully even if platform_driver_register() failed.\n\nFix by checking the return value of platform_driver_register() and\nunregister cros_usbpd_notify_plat_driver when it failed.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: lpfc: Fix null ndlp ptr dereference in abnormal exit path for GFT_ID\n\nAn error case exit from lpfc_cmpl_ct_cmd_gft_id() results in a call to\nlpfc_nlp_put() with a null pointer to a nodelist structure.\n\nChanged lpfc_cmpl_ct_cmd_gft_id() to initialize nodelist pointer upon\nentry.

In the Linux kernel, the following vulnerability has been resolved:\n\nfs/binfmt_elf: Fix memory leak in load_elf_binary()\n\nThere is a memory leak reported by kmemleak:\n\n unreferenced object 0xffff88817104ef80 (size 224):\n comm "xfs_admin", pid 47165, jiffies 4298708825 (age 1333.476s)\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 60 a8 b3 00 81 88 ff ff a8 10 5a 00 81 88 ff ff `.........Z.....\n backtrace:\n [] __alloc_file+0x21/0x250\n [] alloc_empty_file+0x41/0xf0\n [] path_openat+0xea/0x3d30\n [] do_filp_open+0x1b9/0x290\n [] do_open_execat+0xce/0x5b0\n [] open_exec+0x27/0x50\n [] load_elf_binary+0x510/0x3ed0\n [] bprm_execve+0x599/0x1240\n [] do_execveat_common.isra.0+0x4c7/0x680\n [] __x64_sys_execve+0x88/0xb0\n [] do_syscall_64+0x35/0x80\n\nIf "interp_elf_ex" fails to allocate memory in load_elf_binary(),\nthe program will take the "out_free_ph" error handing path,\nresulting in "interpreter" file resource is not released.\n\nFix it by adding an error handing path "out_free_file", which will\nrelease the file resource when "interp_elf_ex" failed to allocate\nmemory.

In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix leaking uninitialized memory in fast-commit journal\n\nWhen space at the end of fast-commit journal blocks is unused, make sure\nto zero it out so that uninitialized memory is not leaked to disk.

In the Linux kernel, the following vulnerability has been resolved:\n\nmt76: mt7915: Fix PCI device refcount leak in mt7915_pci_init_hif2()\n\nAs comment of pci_get_device() says, it returns a pci_device with its\nrefcount increased. We need to call pci_dev_put() to decrease the\nrefcount. Save the return value of pci_get_device() and call\npci_dev_put() to decrease the refcount.

In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/52xx: Fix a resource leak in an error handling path\n\nThe error handling path of mpc52xx_lpbfifo_probe() has a request_irq()\nthat is not balanced by a corresponding free_irq().\n\nAdd the missing call, as already done in the remove function.

In the Linux kernel, the following vulnerability has been resolved:\n\nMIPS: vpe-mt: fix possible memory leak while module exiting\n\nAfer commit 1fa5ae857bb1 ("driver core: get rid of struct device's\nbus_id string array"), the name of device is allocated dynamically,\nit need be freed when module exiting, call put_device() to give up\nreference, so that it can be freed in kobject_cleanup() when the\nrefcount hit to 0. The vpe_device is static, so remove kfree() from\nvpe_device_release().

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ethernet: ti: am65-cpsw: Fix PM runtime leakage in am65_cpsw_nuss_ndo_slave_open()\n\nEnsure pm_runtime_put() is issued in error path.

In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Fix xid leak in cifs_flock()\n\nIf not flock, before return -ENOLCK, should free the xid,\notherwise, the xid will be leaked.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: iscsi: iscsi_tcp: Fix null-ptr-deref while calling getpeername()\n\nFix a NULL pointer crash that occurs when we are freeing the socket at the\nsame time we access it via sysfs.\n\nThe problem is that:\n\n 1. iscsi_sw_tcp_conn_get_param() and iscsi_sw_tcp_host_get_param() take\n the frwd_lock and do sock_hold() then drop the frwd_lock. sock_hold()\n does a get on the "struct sock".\n\n 2. iscsi_sw_tcp_release_conn() does sockfd_put() which does the last put\n on the "struct socket" and that does __sock_release() which sets the\n sock->ops to NULL.\n\n 3. iscsi_sw_tcp_conn_get_param() and iscsi_sw_tcp_host_get_param() then\n call kernel_getpeername() which accesses the NULL sock->ops.\n\nAbove we do a get on the "struct sock", but we needed a get on the "struct\nsocket". Originally, we just held the frwd_lock the entire time but in\ncommit bcf3a2953d36 ("scsi: iscsi: iscsi_tcp: Avoid holding spinlock while\ncalling getpeername()") we switched to refcount based because the network\nlayer changed and started taking a mutex in that path, so we could no\nlonger hold the frwd_lock.\n\nInstead of trying to maintain multiple refcounts, this just has us use a\nmutex for accessing the socket in the interface code paths.

In the Linux kernel, the following vulnerability has been resolved:\n\nclk: tegra: Fix refcount leak in tegra210_clock_init\n\nof_find_matching_node() 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\nmtd: core: Fix refcount error in del_mtd_device()\n\ndel_mtd_device() will call of_node_put() to mtd_get_of_node(mtd), which\nis mtd->dev.of_node. However, memset(&mtd->dev, 0) is called before\nof_node_put(). As the result, of_node_put() won't do anything in\ndel_mtd_device(), and causes the refcount leak.\n\ndel_mtd_device()\n memset(&mtd->dev, 0, sizeof(mtd->dev) # clear mtd->dev\n of_node_put()\n mtd_get_of_node(mtd) # mtd->dev is cleared, can't locate of_node\n # of_node_put(NULL) won't do anything\n\nFix the error by caching the pointer of the device_node.\n\nOF: ERROR: memory leak, expected refcount 1 instead of 2,\nof_node_get()/of_node_put() unbalanced - destroy cset entry: attach\noverlay node /spi/spi-sram@0\nCPU: 3 PID: 275 Comm: python3 Tainted: G N 6.1.0-rc3+ #54\n 0d8a1edddf51f172ff5226989a7565c6313b08e2\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\nrel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014\nCall Trace:\n\n dump_stack_lvl+0x67/0x83\n kobject_get+0x155/0x160\n of_node_get+0x1f/0x30\n of_fwnode_get+0x43/0x70\n fwnode_handle_get+0x54/0x80\n fwnode_get_nth_parent+0xc9/0xe0\n fwnode_full_name_string+0x3f/0xa0\n device_node_string+0x30f/0x750\n pointer+0x598/0x7a0\n vsnprintf+0x62d/0x9b0\n ...\n cfs_overlay_release+0x30/0x90\n config_item_release+0xbe/0x1a0\n config_item_put+0x5e/0x80\n configfs_rmdir+0x3bd/0x540\n vfs_rmdir+0x18c/0x320\n do_rmdir+0x198/0x330\n __x64_sys_rmdir+0x2c/0x40\n do_syscall_64+0x37/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\n[: Light reword of the commit log]

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix resolving backrefs for inline extent followed by prealloc\n\nIf a file consists of an inline extent followed by a regular or prealloc\nextent, then a legitimate attempt to resolve a logical address in the\nnon-inline region will result in add_all_parents reading the invalid\noffset field of the inline extent. If the inline extent item is placed\nin the leaf eb s.t. it is the first item, attempting to access the\noffset field will not only be meaningless, it will go past the end of\nthe eb and cause this panic:\n\n [17.626048] BTRFS warning (device dm-2): bad eb member end: ptr 0x3fd4 start 30834688 member offset 16377 size 8\n [17.631693] general protection fault, probably for non-canonical address 0x5088000000000: 0000 [#1] SMP PTI\n [17.635041] CPU: 2 PID: 1267 Comm: btrfs Not tainted 5.12.0-07246-g75175d5adc74-dirty #199\n [17.637969] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014\n [17.641995] RIP: 0010:btrfs_get_64+0xe7/0x110\n [17.649890] RSP: 0018:ffffc90001f73a08 EFLAGS: 00010202\n [17.651652] RAX: 0000000000000001 RBX: ffff88810c42d000 RCX: 0000000000000000\n [17.653921] RDX: 0005088000000000 RSI: ffffc90001f73a0f RDI: 0000000000000001\n [17.656174] RBP: 0000000000000ff9 R08: 0000000000000007 R09: c0000000fffeffff\n [17.658441] R10: ffffc90001f73790 R11: ffffc90001f73788 R12: ffff888106afe918\n [17.661070] R13: 0000000000003fd4 R14: 0000000000003f6f R15: cdcdcdcdcdcdcdcd\n [17.663617] FS: 00007f64e7627d80(0000) GS:ffff888237c80000(0000) knlGS:0000000000000000\n [17.666525] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n [17.668664] CR2: 000055d4a39152e8 CR3: 000000010c596002 CR4: 0000000000770ee0\n [17.671253] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n [17.673634] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n [17.676034] PKRU: 55555554\n [17.677004] Call Trace:\n [17.677877] add_all_parents+0x276/0x480\n [17.679325] find_parent_nodes+0xfae/0x1590\n [17.680771] btrfs_find_all_leafs+0x5e/0xa0\n [17.682217] iterate_extent_inodes+0xce/0x260\n [17.683809] ? btrfs_inode_flags_to_xflags+0x50/0x50\n [17.685597] ? iterate_inodes_from_logical+0xa1/0xd0\n [17.687404] iterate_inodes_from_logical+0xa1/0xd0\n [17.689121] ? btrfs_inode_flags_to_xflags+0x50/0x50\n [17.691010] btrfs_ioctl_logical_to_ino+0x131/0x190\n [17.692946] btrfs_ioctl+0x104a/0x2f60\n [17.694384] ? selinux_file_ioctl+0x182/0x220\n [17.695995] ? __x64_sys_ioctl+0x84/0xc0\n [17.697394] __x64_sys_ioctl+0x84/0xc0\n [17.698697] do_syscall_64+0x33/0x40\n [17.700017] entry_SYSCALL_64_after_hwframe+0x44/0xae\n [17.701753] RIP: 0033:0x7f64e72761b7\n [17.709355] RSP: 002b:00007ffefb067f58 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\n [17.712088] RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f64e72761b7\n [17.714667] RDX: 00007ffefb067fb0 RSI: 00000000c0389424 RDI: 0000000000000003\n [17.717386] RBP: 00007ffefb06d188 R08: 000055d4a390d2b0 R09: 00007f64e7340a60\n [17.719938] R10: 0000000000000231 R11: 0000000000000246 R12: 0000000000000001\n [17.722383] R13: 0000000000000000 R14: 00000000c0389424 R15: 000055d4a38fd2a0\n [17.724839] Modules linked in:\n\nFix the bug by detecting the inline extent item in add_all_parents and\nskipping to the next extent item.

In the Linux kernel, the following vulnerability has been resolved:\n\nnfs: fix possible null-ptr-deref when parsing param\n\nAccording to commit "vfs: parse: deal with zero length string value",\nkernel will set the param->string to null pointer in vfs_parse_fs_string()\nif fs string has zero length.\n\nYet the problem is that, nfs_fs_context_parse_param() will dereferences the\nparam->string, without checking whether it is a null pointer, which may\ntrigger a null-ptr-deref bug.\n\nThis patch solves it by adding sanity check on param->string\nin nfs_fs_context_parse_param().

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau: fix a use-after-free in nouveau_gem_prime_import_sg_table()\n\nnouveau_bo_init() is backed by ttm_bo_init() and ferries its return code\nback to the caller. On failures, ttm will call nouveau_bo_del_ttm() and\nfree the memory.Thus, when nouveau_bo_init() returns an error, the gem\nobject has already been released. Then the call to nouveau_bo_ref() will\nuse the freed "nvbo->bo" and lead to a use-after-free bug.\n\nWe should delete the call to nouveau_bo_ref() to avoid the use-after-free.

In the Linux kernel, the following vulnerability has been resolved:\n\ngpiolib: cdev: fix NULL-pointer dereferences\n\nThere are several places where we can crash the kernel by requesting\nlines, unbinding the GPIO device, then calling any of the system calls\nrelevant to the GPIO character device's annonymous file descriptors:\nioctl(), read(), poll().\n\nWhile I observed it with the GPIO simulator, it will also happen for any\nof the GPIO devices that can be hot-unplugged - for instance any HID GPIO\nexpander (e.g. CP2112).\n\nThis affects both v1 and v2 uAPI.\n\nThis fixes it partially by checking if gdev->chip is not NULL but it\ndoesn't entirely remedy the situation as we still have a race condition\nin which another thread can remove the device after the check.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: sched: cake: fix null pointer access issue when cake_init() fails\n\nWhen the default qdisc is cake, if the qdisc of dev_queue fails to be\ninited during mqprio_init(), cake_reset() is invoked to clear\nresources. In this case, the tins is NULL, and it will cause gpf issue.\n\nThe process is as follows:\nqdisc_create_dflt()\n cake_init()\n q->tins = kvcalloc(...) --->failed, q->tins is NULL\n ...\n qdisc_put()\n ...\n cake_reset()\n ...\n cake_dequeue_one()\n b = &q->tins[...] --->q->tins is NULL\n\nThe following is the Call Trace information:\ngeneral protection fault, probably for non-canonical address\n0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nRIP: 0010:cake_dequeue_one+0xc9/0x3c0\nCall Trace:\n\ncake_reset+0xb1/0x140\nqdisc_reset+0xed/0x6f0\nqdisc_destroy+0x82/0x4c0\nqdisc_put+0x9e/0xb0\nqdisc_create_dflt+0x2c3/0x4a0\nmqprio_init+0xa71/0x1760\nqdisc_create+0x3eb/0x1000\ntc_modify_qdisc+0x408/0x1720\nrtnetlink_rcv_msg+0x38e/0xac0\nnetlink_rcv_skb+0x12d/0x3a0\nnetlink_unicast+0x4a2/0x740\nnetlink_sendmsg+0x826/0xcc0\nsock_sendmsg+0xc5/0x100\n____sys_sendmsg+0x583/0x690\n___sys_sendmsg+0xe8/0x160\n__sys_sendmsg+0xbf/0x160\ndo_syscall_64+0x35/0x80\nentry_SYSCALL_64_after_hwframe+0x46/0xb0\nRIP: 0033:0x7f89e5122d04\n

In the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Fix memory leak on ntfs_fill_super() error path\n\nsyzbot reported kmemleak as below:\n\nBUG: memory leak\nunreferenced object 0xffff8880122f1540 (size 32):\n comm "a.out", pid 6664, jiffies 4294939771 (age 25.500s)\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 ed ff ed ff 00 00 00 00 ................\n backtrace:\n [] ntfs_init_fs_context+0x22/0x1c0\n [] alloc_fs_context+0x217/0x430\n [] path_mount+0x704/0x1080\n [] __x64_sys_mount+0x18c/0x1d0\n [] do_syscall_64+0x34/0xb0\n [] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nThis patch fixes this issue by freeing mount options on error path of\nntfs_fill_super().

In the Linux kernel, the following vulnerability has been resolved:\n\nclk: samsung: Fix memory leak in _samsung_clk_register_pll()\n\nIf clk_register() fails, @pll->rate_table may have allocated memory by\nkmemdup(), so it needs to be freed, otherwise will cause memory leak\nissue, this patch fixes it.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm/uffd: fix warning without PTE_MARKER_UFFD_WP compiled in\n\nWhen PTE_MARKER_UFFD_WP not configured, it's still possible to reach pte\nmarker code and trigger an warning. Add a few CONFIG_PTE_MARKER_UFFD_WP\nifdefs to make sure the code won't be reached when not compiled in.

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_conn: Fix crash on hci_create_cis_sync\n\nWhen attempting to connect multiple ISO sockets without using\nDEFER_SETUP may result in the following crash:\n\nBUG: KASAN: null-ptr-deref in hci_create_cis_sync+0x18b/0x2b0\nRead of size 2 at addr 0000000000000036 by task kworker/u3:1/50\n\nCPU: 0 PID: 50 Comm: kworker/u3:1 Not tainted\n6.0.0-rc7-02243-gb84a13ff4eda #4373\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009),\nBIOS 1.16.0-1.fc36 04/01/2014\nWorkqueue: hci0 hci_cmd_sync_work\nCall Trace:\n \n dump_stack_lvl+0x19/0x27\n kasan_report+0xbc/0xf0\n ? hci_create_cis_sync+0x18b/0x2b0\n hci_create_cis_sync+0x18b/0x2b0\n ? get_link_mode+0xd0/0xd0\n ? __ww_mutex_lock_slowpath+0x10/0x10\n ? mutex_lock+0xe0/0xe0\n ? get_link_mode+0xd0/0xd0\n hci_cmd_sync_work+0x111/0x190\n process_one_work+0x427/0x650\n worker_thread+0x87/0x750\n ? process_one_work+0x650/0x650\n kthread+0x14e/0x180\n ? kthread_exit+0x50/0x50\n ret_from_fork+0x22/0x30\n

In the Linux kernel, the following vulnerability has been resolved:\n\nARC: mm: fix leakage of memory allocated for PTE\n\nSince commit d9820ff ("ARC: mm: switch pgtable_t back to struct page *")\na memory leakage problem occurs. Memory allocated for page table entries\nnot released during process termination. This issue can be reproduced by\na small program that allocates a large amount of memory. After several\nruns, you'll see that the amount of free memory has reduced and will\ncontinue to reduce after each run. All ARC CPUs are effected by this\nissue. The issue was introduced since the kernel stable release v5.15-rc1.\n\nAs described in commit d9820ff after switch pgtable_t back to struct\npage *, a pointer to "struct page" and appropriate functions are used to\nallocate and free a memory page for PTEs, but the pmd_pgtable macro hasn't\nchanged and returns the direct virtual address from the PMD (PGD) entry.\nThan this address used as a parameter in the __pte_free() and as a result\nthis function couldn't release memory page allocated for PTEs.\n\nFix this issue by changing the pmd_pgtable macro and returning pointer to\nstruct page.

In the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: Reinject transport-mode packets through workqueue\n\nThe following warning is displayed when the tcp6-multi-diffip11 stress\ntest case of the LTP test suite is tested:\n\nwatchdog: BUG: soft lockup - CPU#0 stuck for 22s! [ns-tcpserver:48198]\nCPU: 0 PID: 48198 Comm: ns-tcpserver Kdump: loaded Not tainted 6.0.0-rc6+ #39\nHardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : des3_ede_encrypt+0x27c/0x460 [libdes]\nlr : 0x3f\nsp : ffff80000ceaa1b0\nx29: ffff80000ceaa1b0 x28: ffff0000df056100 x27: ffff0000e51e5280\nx26: ffff80004df75030 x25: ffff0000e51e4600 x24: 000000000000003b\nx23: 0000000000802080 x22: 000000000000003d x21: 0000000000000038\nx20: 0000000080000020 x19: 000000000000000a x18: 0000000000000033\nx17: ffff0000e51e4780 x16: ffff80004e2d1448 x15: ffff80004e2d1248\nx14: ffff0000e51e4680 x13: ffff80004e2d1348 x12: ffff80004e2d1548\nx11: ffff80004e2d1848 x10: ffff80004e2d1648 x9 : ffff80004e2d1748\nx8 : ffff80004e2d1948 x7 : 000000000bcaf83d x6 : 000000000000001b\nx5 : ffff80004e2d1048 x4 : 00000000761bf3bf x3 : 000000007f1dd0a3\nx2 : ffff0000e51e4780 x1 : ffff0000e3b9a2f8 x0 : 00000000db44e872\nCall trace:\n des3_ede_encrypt+0x27c/0x460 [libdes]\n crypto_des3_ede_encrypt+0x1c/0x30 [des_generic]\n crypto_cbc_encrypt+0x148/0x190\n crypto_skcipher_encrypt+0x2c/0x40\n crypto_authenc_encrypt+0xc8/0xfc [authenc]\n crypto_aead_encrypt+0x2c/0x40\n echainiv_encrypt+0x144/0x1a0 [echainiv]\n crypto_aead_encrypt+0x2c/0x40\n esp6_output_tail+0x1c8/0x5d0 [esp6]\n esp6_output+0x120/0x278 [esp6]\n xfrm_output_one+0x458/0x4ec\n xfrm_output_resume+0x6c/0x1f0\n xfrm_output+0xac/0x4ac\n __xfrm6_output+0x130/0x270\n xfrm6_output+0x60/0xec\n ip6_xmit+0x2ec/0x5bc\n inet6_csk_xmit+0xbc/0x10c\n __tcp_transmit_skb+0x460/0x8c0\n tcp_write_xmit+0x348/0x890\n __tcp_push_pending_frames+0x44/0x110\n tcp_rcv_established+0x3c8/0x720\n tcp_v6_do_rcv+0xdc/0x4a0\n tcp_v6_rcv+0xc24/0xcb0\n ip6_protocol_deliver_rcu+0xf0/0x574\n ip6_input_finish+0x48/0x7c\n ip6_input+0x48/0xc0\n ip6_rcv_finish+0x80/0x9c\n xfrm_trans_reinject+0xb0/0xf4\n tasklet_action_common.constprop.0+0xf8/0x134\n tasklet_action+0x30/0x3c\n __do_softirq+0x128/0x368\n do_softirq+0xb4/0xc0\n __local_bh_enable_ip+0xb0/0xb4\n put_cpu_fpsimd_context+0x40/0x70\n kernel_neon_end+0x20/0x40\n sha1_base_do_update.constprop.0.isra.0+0x11c/0x140 [sha1_ce]\n sha1_ce_finup+0x94/0x110 [sha1_ce]\n crypto_shash_finup+0x34/0xc0\n hmac_finup+0x48/0xe0\n crypto_shash_finup+0x34/0xc0\n shash_digest_unaligned+0x74/0x90\n crypto_shash_digest+0x4c/0x9c\n shash_ahash_digest+0xc8/0xf0\n shash_async_digest+0x28/0x34\n crypto_ahash_digest+0x48/0xcc\n crypto_authenc_genicv+0x88/0xcc [authenc]\n crypto_authenc_encrypt+0xd8/0xfc [authenc]\n crypto_aead_encrypt+0x2c/0x40\n echainiv_encrypt+0x144/0x1a0 [echainiv]\n crypto_aead_encrypt+0x2c/0x40\n esp6_output_tail+0x1c8/0x5d0 [esp6]\n esp6_output+0x120/0x278 [esp6]\n xfrm_output_one+0x458/0x4ec\n xfrm_output_resume+0x6c/0x1f0\n xfrm_output+0xac/0x4ac\n __xfrm6_output+0x130/0x270\n xfrm6_output+0x60/0xec\n ip6_xmit+0x2ec/0x5bc\n inet6_csk_xmit+0xbc/0x10c\n __tcp_transmit_skb+0x460/0x8c0\n tcp_write_xmit+0x348/0x890\n __tcp_push_pending_frames+0x44/0x110\n tcp_push+0xb4/0x14c\n tcp_sendmsg_locked+0x71c/0xb64\n tcp_sendmsg+0x40/0x6c\n inet6_sendmsg+0x4c/0x80\n sock_sendmsg+0x5c/0x6c\n __sys_sendto+0x128/0x15c\n __arm64_sys_sendto+0x30/0x40\n invoke_syscall+0x50/0x120\n el0_svc_common.constprop.0+0x170/0x194\n do_el0_svc+0x38/0x4c\n el0_svc+0x28/0xe0\n el0t_64_sync_handler+0xbc/0x13c\n el0t_64_sync+0x180/0x184\n\nGet softirq info by bcc tool:\n./softirqs -NT 10\nTracing soft irq event time... Hit Ctrl-C to end.\n\n15:34:34\nSOFTIRQ TOTAL_nsecs\nblock 158990\ntimer 20030920\nsched 46577080\nnet_rx 676746820\ntasklet 9906067650\n\n15:34:45\nSOFTIRQ TOTAL_nsecs\nblock 86100\nsched 38849790\nnet_rx \n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\nclk: tegra20: Fix refcount leak in tegra20_clock_init\nof_find_matching_node() 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\ndrm/rockchip: lvds: fix PM usage counter unbalance in poweron\n\npm_runtime_get_sync will increment pm usage counter even it failed.\nForgetting to putting operation will result in reference leak here.\nWe fix it by replacing it with the newest pm_runtime_resume_and_get\nto keep usage counter balanced.

In the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Validate buffer length while parsing index\n\nindx_read is called when we have some NTFS directory operations that\nneed more information from the index buffers. This adds a sanity check\nto make sure the returned index buffer length is legit, or we may have\nsome out-of-bound memory accesses.\n\n[ 560.897595] BUG: KASAN: slab-out-of-bounds in hdr_find_e.isra.0+0x10c/0x320\n[ 560.898321] Read of size 2 at addr ffff888009497238 by task exp/245\n[ 560.898760]\n[ 560.899129] CPU: 0 PID: 245 Comm: exp Not tainted 6.0.0-rc6 #37\n[ 560.899505] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014\n[ 560.900170] Call Trace:\n[ 560.900407] \n[ 560.900732] dump_stack_lvl+0x49/0x63\n[ 560.901108] print_report.cold+0xf5/0x689\n[ 560.901395] ? hdr_find_e.isra.0+0x10c/0x320\n[ 560.901716] kasan_report+0xa7/0x130\n[ 560.901950] ? hdr_find_e.isra.0+0x10c/0x320\n[ 560.902208] __asan_load2+0x68/0x90\n[ 560.902427] hdr_find_e.isra.0+0x10c/0x320\n[ 560.902846] ? cmp_uints+0xe0/0xe0\n[ 560.903363] ? cmp_sdh+0x90/0x90\n[ 560.903883] ? ntfs_bread_run+0x190/0x190\n[ 560.904196] ? rwsem_down_read_slowpath+0x750/0x750\n[ 560.904969] ? ntfs_fix_post_read+0xe0/0x130\n[ 560.905259] ? __kasan_check_write+0x14/0x20\n[ 560.905599] ? up_read+0x1a/0x90\n[ 560.905853] ? indx_read+0x22c/0x380\n[ 560.906096] indx_find+0x2ef/0x470\n[ 560.906352] ? indx_find_buffer+0x2d0/0x2d0\n[ 560.906692] ? __kasan_kmalloc+0x88/0xb0\n[ 560.906977] dir_search_u+0x196/0x2f0\n[ 560.907220] ? ntfs_nls_to_utf16+0x450/0x450\n[ 560.907464] ? __kasan_check_write+0x14/0x20\n[ 560.907747] ? mutex_lock+0x8f/0xe0\n[ 560.907970] ? __mutex_lock_slowpath+0x20/0x20\n[ 560.908214] ? kmem_cache_alloc+0x143/0x4b0\n[ 560.908459] ntfs_lookup+0xe0/0x100\n[ 560.908788] __lookup_slow+0x116/0x220\n[ 560.909050] ? lookup_fast+0x1b0/0x1b0\n[ 560.909309] ? lookup_fast+0x13f/0x1b0\n[ 560.909601] walk_component+0x187/0x230\n[ 560.909944] link_path_walk.part.0+0x3f0/0x660\n[ 560.910285] ? handle_lookup_down+0x90/0x90\n[ 560.910618] ? path_init+0x642/0x6e0\n[ 560.911084] ? percpu_counter_add_batch+0x6e/0xf0\n[ 560.912559] ? __alloc_file+0x114/0x170\n[ 560.913008] path_openat+0x19c/0x1d10\n[ 560.913419] ? getname_flags+0x73/0x2b0\n[ 560.913815] ? kasan_save_stack+0x3a/0x50\n[ 560.914125] ? kasan_save_stack+0x26/0x50\n[ 560.914542] ? __kasan_slab_alloc+0x6d/0x90\n[ 560.914924] ? kmem_cache_alloc+0x143/0x4b0\n[ 560.915339] ? getname_flags+0x73/0x2b0\n[ 560.915647] ? getname+0x12/0x20\n[ 560.916114] ? __x64_sys_open+0x4c/0x60\n[ 560.916460] ? path_lookupat.isra.0+0x230/0x230\n[ 560.916867] ? __isolate_free_page+0x2e0/0x2e0\n[ 560.917194] do_filp_open+0x15c/0x1f0\n[ 560.917448] ? may_open_dev+0x60/0x60\n[ 560.917696] ? expand_files+0xa4/0x3a0\n[ 560.917923] ? __kasan_check_write+0x14/0x20\n[ 560.918185] ? _raw_spin_lock+0x88/0xdb\n[ 560.918409] ? _raw_spin_lock_irqsave+0x100/0x100\n[ 560.918783] ? _find_next_bit+0x4a/0x130\n[ 560.919026] ? _raw_spin_unlock+0x19/0x40\n[ 560.919276] ? alloc_fd+0x14b/0x2d0\n[ 560.919635] do_sys_openat2+0x32a/0x4b0\n[ 560.920035] ? file_open_root+0x230/0x230\n[ 560.920336] ? __rcu_read_unlock+0x5b/0x280\n[ 560.920813] do_sys_open+0x99/0xf0\n[ 560.921208] ? filp_open+0x60/0x60\n[ 560.921482] ? exit_to_user_mode_prepare+0x49/0x180\n[ 560.921867] __x64_sys_open+0x4c/0x60\n[ 560.922128] do_syscall_64+0x3b/0x90\n[ 560.922369] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[ 560.923030] RIP: 0033:0x7f7dff2e4469\n[ 560.923681] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 088\n[ 560.924451] RSP: 002b:00007ffd41a210b8 EFLAGS: 00000206 ORIG_RAX: 0000000000000002\n[ 560.925168] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f7dff2e4469\n[ 560.925655] RDX: 0000000000000000 RSI: 0000000000000002 RDI:\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Lag, fix failure to cancel delayed bond work\n\nCommit 0d4e8ed139d8 ("net/mlx5: Lag, avoid lockdep warnings")\naccidentally removed a call to cancel delayed bond work thus it may\ncause queued delay to expire and fall on an already destroyed work\nqueue.\n\nFix by restoring the call cancel_delayed_work_sync() before\ndestroying the workqueue.\n\nThis prevents call trace such as this:\n\n[ 329.230417] BUG: kernel NULL pointer dereference, address: 0000000000000000\n [ 329.231444] #PF: supervisor write access in kernel mode\n [ 329.232233] #PF: error_code(0x0002) - not-present page\n [ 329.233007] PGD 0 P4D 0\n [ 329.233476] Oops: 0002 [#1] SMP\n [ 329.234012] CPU: 5 PID: 145 Comm: kworker/u20:4 Tainted: G OE 6.0.0-rc5_mlnx #1\n [ 329.235282] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n [ 329.236868] Workqueue: mlx5_cmd_0000:08:00.1 cmd_work_handler [mlx5_core]\n [ 329.237886] RIP: 0010:_raw_spin_lock+0xc/0x20\n [ 329.238585] Code: f0 0f b1 17 75 02 f3 c3 89 c6 e9 6f 3c 5f ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 31 c0 ba 01 00 00 00 0f b1 17 75 02 f3 c3 89 c6 e9 45 3c 5f ff 0f 1f 44 00 00 0f 1f\n [ 329.241156] RSP: 0018:ffffc900001b0e98 EFLAGS: 00010046\n [ 329.241940] RAX: 0000000000000000 RBX: ffffffff82374ae0 RCX: 0000000000000000\n [ 329.242954] RDX: 0000000000000001 RSI: 0000000000000014 RDI: 0000000000000000\n [ 329.243974] RBP: ffff888106ccf000 R08: ffff8881004000c8 R09: ffff888100400000\n [ 329.244990] R10: 0000000000000000 R11: ffffffff826669f8 R12: 0000000000002000\n [ 329.246009] R13: 0000000000000005 R14: ffff888100aa7ce0 R15: ffff88852ca80000\n [ 329.247030] FS: 0000000000000000(0000) GS:ffff88852ca80000(0000) knlGS:0000000000000000\n [ 329.248260] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n [ 329.249111] CR2: 0000000000000000 CR3: 000000016d675001 CR4: 0000000000770ee0\n [ 329.250133] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n [ 329.251152] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n [ 329.252176] PKRU: 55555554

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vmwgfx: Validate the box size for the snooped cursor\n\nInvalid userspace dma surface copies could potentially overflow\nthe memcpy from the surface to the snooped image leading to crashes.\nTo fix it the dimensions of the copybox have to be validated\nagainst the expected size of the snooped cursor.

In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: mediatek: mt8173: Enable IRQ when pdata is ready\n\nIf the device does not come straight from reset, we might receive an IRQ\nbefore we are ready to handle it.\n\n\n[ 2.334737] Unable to handle kernel read from unreadable memory at virtual address 00000000000001e4\n[ 2.522601] Call trace:\n[ 2.525040] regmap_read+0x1c/0x80\n[ 2.528434] mt8173_afe_irq_handler+0x40/0xf0\n...\n[ 2.598921] start_kernel+0x338/0x42c

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: hinic: fix memory leak when reading function table\n\nWhen the input parameter idx meets the expected case option in\nhinic_dbg_get_func_table(), read_data is not released. Fix it.

In the Linux kernel, the following vulnerability has been resolved:\ndrm/msm/hdmi: fix memory corruption with too many bridges\nAdd the missing sanity check on the bridge counter to avoid corrupting\ndata beyond the fixed-sized bridge array in case there are ever more\nthan eight bridges.\nPatchwork: https://patchwork.freedesktop.org/patch/502670/

In the Linux kernel, the following vulnerability has been resolved:\n\next4: don't set up encryption key during jbd2 transaction\n\nCommit a80f7fcf1867 ("ext4: fixup ext4_fc_track_* functions' signature")\nextended the scope of the transaction in ext4_unlink() too far, making\nit include the call to ext4_find_entry(). However, ext4_find_entry()\ncan deadlock when called from within a transaction because it may need\nto set up the directory's encryption key.\n\nFix this by restoring the transaction to its original scope.

In the Linux kernel, the following vulnerability has been resolved:\n\next4: avoid crash when inline data creation follows DIO write\n\nWhen inode is created and written to using direct IO, there is nothing\nto clear the EXT4_STATE_MAY_INLINE_DATA flag. Thus when inode gets\ntruncated later to say 1 byte and written using normal write, we will\ntry to store the data as inline data. This confuses the code later\nbecause the inode now has both normal block and inline data allocated\nand the confusion manifests for example as:\n\nkernel BUG at fs/ext4/inode.c:2721!\ninvalid opcode: 0000 [#1] PREEMPT SMP KASAN\nCPU: 0 PID: 359 Comm: repro Not tainted 5.19.0-rc8-00001-g31ba1e3b8305-dirty #15\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014\nRIP: 0010:ext4_writepages+0x363d/0x3660\nRSP: 0018:ffffc90000ccf260 EFLAGS: 00010293\nRAX: ffffffff81e1abcd RBX: 0000008000000000 RCX: ffff88810842a180\nRDX: 0000000000000000 RSI: 0000008000000000 RDI: 0000000000000000\nRBP: ffffc90000ccf650 R08: ffffffff81e17d58 R09: ffffed10222c680b\nR10: dfffe910222c680c R11: 1ffff110222c680a R12: ffff888111634128\nR13: ffffc90000ccf880 R14: 0000008410000000 R15: 0000000000000001\nFS: 00007f72635d2640(0000) GS:ffff88811b000000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000565243379180 CR3: 000000010aa74000 CR4: 0000000000150eb0\nCall Trace:\n \n do_writepages+0x397/0x640\n filemap_fdatawrite_wbc+0x151/0x1b0\n file_write_and_wait_range+0x1c9/0x2b0\n ext4_sync_file+0x19e/0xa00\n vfs_fsync_range+0x17b/0x190\n ext4_buffered_write_iter+0x488/0x530\n ext4_file_write_iter+0x449/0x1b90\n vfs_write+0xbcd/0xf40\n ksys_write+0x198/0x2c0\n __x64_sys_write+0x7b/0x90\n do_syscall_64+0x3d/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n \n\nFix the problem by clearing EXT4_STATE_MAY_INLINE_DATA when we are doing\ndirect IO write to a file.

In the Linux kernel, the following vulnerability has been resolved:\n\nblk-mq: fix possible memleak when register 'hctx' failed\n\nThere's issue as follows when do fault injection test:\nunreferenced object 0xffff888132a9f400 (size 512):\n comm "insmod", pid 308021, jiffies 4324277909 (age 509.733s)\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 08 f4 a9 32 81 88 ff ff ...........2....\n 08 f4 a9 32 81 88 ff ff 00 00 00 00 00 00 00 00 ...2............\n backtrace:\n [<00000000e8952bb4>] kmalloc_node_trace+0x22/0xa0\n [<00000000f9980e0f>] blk_mq_alloc_and_init_hctx+0x3f1/0x7e0\n [<000000002e719efa>] blk_mq_realloc_hw_ctxs+0x1e6/0x230\n [<000000004f1fda40>] blk_mq_init_allocated_queue+0x27e/0x910\n [<00000000287123ec>] __blk_mq_alloc_disk+0x67/0xf0\n [<00000000a2a34657>] 0xffffffffa2ad310f\n [<00000000b173f718>] 0xffffffffa2af824a\n [<0000000095a1dabb>] do_one_initcall+0x87/0x2a0\n [<00000000f32fdf93>] do_init_module+0xdf/0x320\n [<00000000cbe8541e>] load_module+0x3006/0x3390\n [<0000000069ed1bdb>] __do_sys_finit_module+0x113/0x1b0\n [<00000000a1a29ae8>] do_syscall_64+0x35/0x80\n [<000000009cd878b0>] entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nFault injection context as follows:\n kobject_add\n blk_mq_register_hctx\n blk_mq_sysfs_register\n blk_register_queue\n device_add_disk\n null_add_dev.part.0 [null_blk]\n\nAs 'blk_mq_register_hctx' may already add some objects when failed halfway,\nbut there isn't do fallback, caller don't know which objects add failed.\nTo solve above issue just do fallback when add objects failed halfway in\n'blk_mq_register_hctx'.

In the Linux kernel, the following vulnerability has been resolved:\n\nefi: ssdt: Don't free memory if ACPI table was loaded successfully\n\nAmadeusz reports KASAN use-after-free errors introduced by commit\n3881ee0b1edc ("efi: avoid efivars layer when loading SSDTs from\nvariables"). The problem appears to be that the memory that holds the\nnew ACPI table is now freed unconditionally, instead of only when the\nACPI core reported a failure to load the table.\n\nSo let's fix this, by omitting the kfree() on success.

In the Linux kernel, the following vulnerability has been resolved:\n\nkernfs: fix use-after-free in __kernfs_remove\n\nSyzkaller managed to trigger concurrent calls to\nkernfs_remove_by_name_ns() for the same file resulting in\na KASAN detected use-after-free. The race occurs when the root\nnode is freed during kernfs_drain().\n\nTo prevent this acquire an additional reference for the root\nof the tree that is removed before calling __kernfs_remove().\n\nFound by syzkaller with the following reproducer (slab_nomerge is\nrequired):\n\nsyz_mount_image$ext4(0x0, &(0x7f0000000100)='./file0\\x00', 0x100000, 0x0, 0x0, 0x0, 0x0)\nr0 = openat(0xffffffffffffff9c, &(0x7f0000000080)='/proc/self/exe\\x00', 0x0, 0x0)\nclose(r0)\npipe2(&(0x7f0000000140)={0xffffffffffffffff, 0xffffffffffffffff}, 0x800)\nmount$9p_fd(0x0, &(0x7f0000000040)='./file0\\x00', &(0x7f00000000c0), 0x408, &(0x7f0000000280)={'trans=fd,', {'rfdno', 0x3d, r0}, 0x2c, {'wfdno', 0x3d, r1}, 0x2c, {[{@cache_loose}, {@mmap}, {@loose}, {@loose}, {@mmap}], [{@mask={'mask', 0x3d, '^MAY_EXEC'}}, {@fsmagic={'fsmagic', 0x3d, 0x10001}}, {@dont_hash}]}})\n\nSample report:\n\n==================================================================\nBUG: KASAN: use-after-free in kernfs_type include/linux/kernfs.h:335 [inline]\nBUG: KASAN: use-after-free in kernfs_leftmost_descendant fs/kernfs/dir.c:1261 [inline]\nBUG: KASAN: use-after-free in __kernfs_remove.part.0+0x843/0x960 fs/kernfs/dir.c:1369\nRead of size 2 at addr ffff8880088807f0 by task syz-executor.2/857\n\nCPU: 0 PID: 857 Comm: syz-executor.2 Not tainted 6.0.0-rc3-00363-g7726d4c3e60b #5\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\nCall Trace:\n \n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x6e/0x91 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:317 [inline]\n print_report.cold+0x5e/0x5e5 mm/kasan/report.c:433\n kasan_report+0xa3/0x130 mm/kasan/report.c:495\n kernfs_type include/linux/kernfs.h:335 [inline]\n kernfs_leftmost_descendant fs/kernfs/dir.c:1261 [inline]\n __kernfs_remove.part.0+0x843/0x960 fs/kernfs/dir.c:1369\n __kernfs_remove fs/kernfs/dir.c:1356 [inline]\n kernfs_remove_by_name_ns+0x108/0x190 fs/kernfs/dir.c:1589\n sysfs_slab_add+0x133/0x1e0 mm/slub.c:5943\n __kmem_cache_create+0x3e0/0x550 mm/slub.c:4899\n create_cache mm/slab_common.c:229 [inline]\n kmem_cache_create_usercopy+0x167/0x2a0 mm/slab_common.c:335\n p9_client_create+0xd4d/0x1190 net/9p/client.c:993\n v9fs_session_init+0x1e6/0x13c0 fs/9p/v9fs.c:408\n v9fs_mount+0xb9/0xbd0 fs/9p/vfs_super.c:126\n legacy_get_tree+0xf1/0x200 fs/fs_context.c:610\n vfs_get_tree+0x85/0x2e0 fs/super.c:1530\n do_new_mount fs/namespace.c:3040 [inline]\n path_mount+0x675/0x1d00 fs/namespace.c:3370\n do_mount fs/namespace.c:3383 [inline]\n __do_sys_mount fs/namespace.c:3591 [inline]\n __se_sys_mount fs/namespace.c:3568 [inline]\n __x64_sys_mount+0x282/0x300 fs/namespace.c:3568\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\nRIP: 0033:0x7f725f983aed\nCode: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f725f0f7028 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5\nRAX: ffffffffffffffda RBX: 00007f725faa3f80 RCX: 00007f725f983aed\nRDX: 00000000200000c0 RSI: 0000000020000040 RDI: 0000000000000000\nRBP: 00007f725f9f419c R08: 0000000020000280 R09: 0000000000000000\nR10: 0000000000000408 R11: 0000000000000246 R12: 0000000000000000\nR13: 0000000000000006 R14: 00007f725faa3f80 R15: 00007f725f0d7000\n \n\nAllocated by task 855:\n kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38\n kasan_set_track mm/kasan/common.c:45 [inline]\n set_alloc_info mm/kasan/common.c:437 [inline]\n __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:470\n kasan_slab_alloc include/linux/kasan.h:224 [inline]\n slab_post_alloc_hook mm/slab.h:7\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: aoa: i2sbus: fix possible memory leak in i2sbus_add_dev()\n\ndev_set_name() in soundbus_add_one() allocates memory for name, it need be\nfreed when of_device_register() fails, call soundbus_dev_put() to give up\nthe reference that hold in device_initialize(), so that it can be freed in\nkobject_cleanup() when the refcount hit to 0. And other resources are also\nfreed in i2sbus_release_dev(), so it can return 0 directly.

In the Linux kernel, the following vulnerability has been resolved:\n\nmmc: vub300: fix warning - do not call blocking ops when !TASK_RUNNING\n\nvub300_enable_sdio_irq() works with mutex and need TASK_RUNNING here.\nEnsure that we mark current as TASK_RUNNING for sleepable context.\n\n[ 77.554641] do not call blocking ops when !TASK_RUNNING; state=1 set at [] sdio_irq_thread+0x17d/0x5b0\n[ 77.554652] WARNING: CPU: 2 PID: 1983 at kernel/sched/core.c:9813 __might_sleep+0x116/0x160\n[ 77.554905] CPU: 2 PID: 1983 Comm: ksdioirqd/mmc1 Tainted: G OE 6.1.0-rc5 #1\n[ 77.554910] Hardware name: Intel(R) Client Systems NUC8i7BEH/NUC8BEB, BIOS BECFL357.86A.0081.2020.0504.1834 05/04/2020\n[ 77.554912] RIP: 0010:__might_sleep+0x116/0x160\n[ 77.554920] RSP: 0018:ffff888107b7fdb8 EFLAGS: 00010282\n[ 77.554923] RAX: 0000000000000000 RBX: ffff888118c1b740 RCX: 0000000000000000\n[ 77.554926] RDX: 0000000000000001 RSI: 0000000000000004 RDI: ffffed1020f6ffa9\n[ 77.554928] RBP: ffff888107b7fde0 R08: 0000000000000001 R09: ffffed1043ea60ba\n[ 77.554930] R10: ffff88821f5305cb R11: ffffed1043ea60b9 R12: ffffffff93aa3a60\n[ 77.554932] R13: 000000000000011b R14: 7fffffffffffffff R15: ffffffffc0558660\n[ 77.554934] FS: 0000000000000000(0000) GS:ffff88821f500000(0000) knlGS:0000000000000000\n[ 77.554937] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 77.554939] CR2: 00007f8a44010d68 CR3: 000000024421a003 CR4: 00000000003706e0\n[ 77.554942] Call Trace:\n[ 77.554944] \n[ 77.554952] mutex_lock+0x78/0xf0\n[ 77.554973] vub300_enable_sdio_irq+0x103/0x3c0 [vub300]\n[ 77.554981] sdio_irq_thread+0x25c/0x5b0\n[ 77.555006] kthread+0x2b8/0x370\n[ 77.555017] ret_from_fork+0x1f/0x30\n[ 77.555023] \n[ 77.555025] ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:\n\nmemory: of: Fix refcount leak bug in of_lpddr3_get_ddr_timings()\n\nWe should add the of_node_put() when breaking out of\nfor_each_child_of_node() as it will automatically increase\nand decrease the refcount.

In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix off-by-one errors in fast-commit block filling\n\nDue to several different off-by-one errors, or perhaps due to a late\nchange in design that wasn't fully reflected in the code that was\nactually merged, there are several very strange constraints on how\nfast-commit blocks are filled with tlv entries:\n\n- tlvs must start at least 10 bytes before the end of the block, even\n though the minimum tlv length is 8. Otherwise, the replay code will\n ignore them. (BUG: ext4_fc_reserve_space() could violate this\n requirement if called with a len of blocksize - 9 or blocksize - 8.\n Fortunately, this doesn't seem to happen currently.)\n\n- tlvs must end at least 1 byte before the end of the block. Otherwise\n the replay code will consider them to be invalid. This quirk\n contributed to a bug (fixed by an earlier commit) where uninitialized\n memory was being leaked to disk in the last byte of blocks.\n\nAlso, strangely these constraints don't apply to the replay code in\ne2fsprogs, which will accept any tlvs in the blocks (with no bounds\nchecks at all, but that is a separate issue...).\n\nGiven that this all seems to be a bug, let's fix it by just filling\nblocks with tlv entries in the natural way.\n\nNote that old kernels will be unable to replay fast-commit journals\ncreated by kernels that have this commit.

In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: ac97: fix possible memory leak in snd_ac97_dev_register()\n\nIf device_register() fails in snd_ac97_dev_register(), it should\ncall put_device() to give up reference, or the name allocated in\ndev_set_name() is leaked.

In the Linux kernel, the following vulnerability has been resolved:\n\nremoteproc: imx_dsp_rproc: Add mutex protection for workqueue\n\nThe workqueue may execute late even after remoteproc is stopped or\nstopping, some resources (rpmsg device and endpoint) have been\nreleased in rproc_stop_subdevices(), then rproc_vq_interrupt()\naccessing these resources will cause kennel dump.\n\nCall trace:\n virtqueue_add_split+0x1ac/0x560\n virtqueue_add_inbuf+0x4c/0x60\n rpmsg_recv_done+0x15c/0x294\n vring_interrupt+0x6c/0xa4\n rproc_vq_interrupt+0x30/0x50\n imx_dsp_rproc_vq_work+0x24/0x40 [imx_dsp_rproc]\n process_one_work+0x1d0/0x354\n worker_thread+0x13c/0x470\n kthread+0x154/0x160\n ret_from_fork+0x10/0x20\n\nAdd mutex protection in imx_dsp_rproc_vq_work(), if the state is\nnot running, then just skip calling rproc_vq_interrupt().\n\nAlso the flush workqueue operation can't be added in rproc stop\nfor the same reason. The call sequence is\n\nrproc_shutdown\n-> rproc_stop\n ->rproc_stop_subdevices\n ->rproc->ops->stop()\n ->imx_dsp_rproc_stop\n ->flush_work\n -> rproc_vq_interrupt\n\nThe resource needed by rproc_vq_interrupt has been released in\nrproc_stop_subdevices, so flush_work is not safe to be called in\nimx_dsp_rproc_stop.

In the Linux kernel, the following vulnerability has been resolved:\n\nx86/fpu: Fix copy_xstate_to_uabi() to copy init states correctly\n\nWhen an extended state component is not present in fpstate, but in init\nstate, the function copies from init_fpstate via copy_feature().\n\nBut, dynamic states are not present in init_fpstate because of all-zeros\ninit states. Then retrieving them from init_fpstate will explode like this:\n\n BUG: kernel NULL pointer dereference, address: 0000000000000000\n ...\n RIP: 0010:memcpy_erms+0x6/0x10\n ? __copy_xstate_to_uabi_buf+0x381/0x870\n fpu_copy_guest_fpstate_to_uabi+0x28/0x80\n kvm_arch_vcpu_ioctl+0x14c/0x1460 [kvm]\n ? __this_cpu_preempt_check+0x13/0x20\n ? vmx_vcpu_put+0x2e/0x260 [kvm_intel]\n kvm_vcpu_ioctl+0xea/0x6b0 [kvm]\n ? kvm_vcpu_ioctl+0xea/0x6b0 [kvm]\n ? __fget_light+0xd4/0x130\n __x64_sys_ioctl+0xe3/0x910\n ? debug_smp_processor_id+0x17/0x20\n ? fpregs_assert_state_consistent+0x27/0x50\n do_syscall_64+0x3f/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nAdjust the 'mask' to zero out the userspace buffer for the features that\nare not available both from fpstate and from init_fpstate.\n\nThe dynamic features depend on the compacted XSAVE format. Ensure it is\nenabled before reading XCOMP_BV in init_fpstate.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mt76: mt7921: resource leaks at mt7921_check_offload_capability()\n\nFixed coverity issue with resource leaks at variable "fw" going out of\nscope leaks the storage it points to mt7921_check_offload_capability().\n\nAddresses-Coverity-ID: 1527806 ("Resource leaks")

In the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: Fix use-after-free in acpi_ut_copy_ipackage_to_ipackage()\n\nThere is an use-after-free reported by KASAN:\n\n BUG: KASAN: use-after-free in acpi_ut_remove_reference+0x3b/0x82\n Read of size 1 at addr ffff888112afc460 by task modprobe/2111\n CPU: 0 PID: 2111 Comm: modprobe Not tainted 6.1.0-rc7-dirty\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),\n Call Trace:\n \n kasan_report+0xae/0xe0\n acpi_ut_remove_reference+0x3b/0x82\n acpi_ut_copy_iobject_to_iobject+0x3be/0x3d5\n acpi_ds_store_object_to_local+0x15d/0x3a0\n acpi_ex_store+0x78d/0x7fd\n acpi_ex_opcode_1A_1T_1R+0xbe4/0xf9b\n acpi_ps_parse_aml+0x217/0x8d5\n ...\n \n\nThe root cause of the problem is that the acpi_operand_object\nis freed when acpi_ut_walk_package_tree() fails in\nacpi_ut_copy_ipackage_to_ipackage(), lead to repeated release in\nacpi_ut_copy_iobject_to_iobject(). The problem was introduced\nby "8aa5e56eeb61" commit, this commit is to fix memory leak in\nacpi_ut_copy_iobject_to_iobject(), repeatedly adding remove\noperation, lead to "acpi_operand_object" used after free.\n\nFix it by removing acpi_ut_remove_reference() in\nacpi_ut_copy_ipackage_to_ipackage(). acpi_ut_copy_ipackage_to_ipackage()\nis called to copy an internal package object into another internal\npackage object, when it fails, the memory of acpi_operand_object\nshould be freed by the caller.

In the Linux kernel, the following vulnerability has been resolved:\n\nrpmsg: char: Avoid double destroy of default endpoint\n\nThe rpmsg_dev_remove() in rpmsg_core is the place for releasing\nthis default endpoint.\n\nSo need to avoid destroying the default endpoint in\nrpmsg_chrdev_eptdev_destroy(), this should be the same as\nrpmsg_eptdev_release(). Otherwise there will be double destroy\nissue that ept->refcount report warning:\n\nrefcount_t: underflow; use-after-free.\n\nCall trace:\n refcount_warn_saturate+0xf8/0x150\n virtio_rpmsg_destroy_ept+0xd4/0xec\n rpmsg_dev_remove+0x60/0x70\n\nThe issue can be reproduced by stopping remoteproc before\nclosing the /dev/rpmsgX.

In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: hisilicon/hpre - fix resource leak in remove process\n\nIn hpre_remove(), when the disable operation of qm sriov failed,\nthe following logic should continue to be executed to release the\nremaining resources that have been allocated, instead of returning\ndirectly, otherwise there will be resource leakage.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: Fix UBSAN shift-out-of-bounds warning\n\nIf get_num_sdma_queues or get_num_xgmi_sdma_queues is 0, we end up\ndoing a shift operation where the number of bits shifted equals\nnumber of bits in the operand. This behaviour is undefined.\n\nSet num_sdma_queues or num_xgmi_sdma_queues to ULLONG_MAX, if the\ncount is >= number of bits in the operand.\n\nBug: https://gitlab.freedesktop.org/drm/amd/-/issues/1472

A null pointer dereference occurs in the function break_word_for_overflow_wrap() in MuPDF 1.26.4 when rendering a malformed EPUB document. Specifically, the function calls fz_html_split_flow() to split a FLOW_WORD node, but does not check if node->next is valid before accessing node->next->overflow_wrap, resulting in a crash if the split fails or returns a partial node chain.

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_core: Disable works on hci_unregister_dev\n\nThis make use of disable_work_* on hci_unregister_dev since the hci_dev is\nabout to be freed new submissions are not disarable.

A flaw was found in Libtiff. This vulnerability is a "write-what-where" condition, triggered when the library processes a specially crafted TIFF image file.\n\nBy providing an abnormally large image height value in the file's metadata, an attacker can trick the library into writing attacker-controlled color data to an arbitrary memory location. This memory corruption can be exploited to cause a denial of service (application crash) or to achieve arbitrary code execution with the permissions of the user.

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.

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\neth: mlx4: Fix IS_ERR() vs NULL check bug in mlx4_en_create_rx_ring\n\nReplace NULL check with IS_ERR() check after calling page_pool_create()\nsince this function returns error pointers (ERR_PTR).\nUsing NULL check could lead to invalid pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ethernet: ti: am65-cpsw-nuss: Fix null pointer dereference for ndev\n\nIn the TX completion packet stage of TI SoCs with CPSW2G instance, which\nhas single external ethernet port, ndev is accessed without being\ninitialized if no TX packets have been processed. It results into null\npointer dereference, causing kernel to crash. Fix this by having a check\non the number of TX packets which have been processed.

In the Linux kernel, the following vulnerability has been resolved:\n\nice: fix NULL access of tx->in_use in ice_ptp_ts_irq\n\nThe E810 device has support for a "low latency" firmware interface to\naccess and read the Tx timestamps. This interface does not use the standard\nTx timestamp logic, due to the latency overhead of proxying sideband\ncommand requests over the firmware AdminQ.\n\nThe logic still makes use of the Tx timestamp tracking structure,\nice_ptp_tx, as it uses the same "ready" bitmap to track which Tx\ntimestamps complete.\n\nUnfortunately, the ice_ptp_ts_irq() function does not check if the tracker\nis initialized before its first access. This results in NULL dereference or\nuse-after-free bugs similar to the following:\n\n[245977.278756] BUG: kernel NULL pointer dereference, address: 0000000000000000\n[245977.278774] RIP: 0010:_find_first_bit+0x19/0x40\n[245977.278796] Call Trace:\n[245977.278809] ? ice_misc_intr+0x364/0x380 [ice]\n\nThis can occur if a Tx timestamp interrupt races with the driver reset\nlogic.\n\nFix this by only checking the in_use bitmap (and other fields) if the\ntracker is marked as initialized. The reset flow will clear the init field\nunder lock before it tears the tracker down, thus preventing any\nuse-after-free or NULL access.

In the Linux kernel, the following vulnerability has been resolved:\n\nice: fix NULL access of tx->in_use in ice_ll_ts_intr\n\nRecent versions of the E810 firmware have support for an extra interrupt to\nhandle report of the "low latency" Tx timestamps coming from the\nspecialized low latency firmware interface. Instead of polling the\nregisters, software can wait until the low latency interrupt is fired.\n\nThis logic makes use of the Tx timestamp tracking structure, ice_ptp_tx, as\nit uses the same "ready" bitmap to track which Tx timestamps complete.\n\nUnfortunately, the ice_ll_ts_intr() function does not check if the\ntracker is initialized before its first access. This results in NULL\ndereference or use-after-free bugs similar to the issues fixed in the\nice_ptp_ts_irq() function.\n\nFix this by only checking the in_use bitmap (and other fields) if the\ntracker is marked as initialized. The reset flow will clear the init field\nunder lock before it tears the tracker down, thus preventing any\nuse-after-free or NULL access.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/tcp: Fix socket memory leak in TCP-AO failure handling for IPv6\n\nWhen tcp_ao_copy_all_matching() fails in tcp_v6_syn_recv_sock() it just\nexits the function. This ends up causing a memory-leak:\n\nunreferenced object 0xffff0000281a8200 (size 2496):\n comm "softirq", pid 0, jiffies 4295174684\n hex dump (first 32 bytes):\n 7f 00 00 06 7f 00 00 06 00 00 00 00 cb a8 88 13 ................\n 0a 00 03 61 00 00 00 00 00 00 00 00 00 00 00 00 ...a............\n backtrace (crc 5ebdbe15):\n kmemleak_alloc+0x44/0xe0\n kmem_cache_alloc_noprof+0x248/0x470\n sk_prot_alloc+0x48/0x120\n sk_clone_lock+0x38/0x3b0\n inet_csk_clone_lock+0x34/0x150\n tcp_create_openreq_child+0x3c/0x4a8\n tcp_v6_syn_recv_sock+0x1c0/0x620\n tcp_check_req+0x588/0x790\n tcp_v6_rcv+0x5d0/0xc18\n ip6_protocol_deliver_rcu+0x2d8/0x4c0\n ip6_input_finish+0x74/0x148\n ip6_input+0x50/0x118\n ip6_sublist_rcv+0x2fc/0x3b0\n ipv6_list_rcv+0x114/0x170\n __netif_receive_skb_list_core+0x16c/0x200\n netif_receive_skb_list_internal+0x1f0/0x2d0\n\nThis is because in tcp_v6_syn_recv_sock (and the IPv4 counterpart), when\nexiting upon error, inet_csk_prepare_forced_close() and tcp_done() need\nto be called. They make sure the newsk will end up being correctly\nfree'd.\n\ntcp_v4_syn_recv_sock() makes this very clear by having the put_and_exit\nlabel that takes care of things. So, this patch here makes sure\ntcp_v4_syn_recv_sock and tcp_v6_syn_recv_sock have similar\nerror-handling and thus fixes the leak for TCP-AO.

In the Linux kernel, the following vulnerability has been resolved:\n\naudit: fix out-of-bounds read in audit_compare_dname_path()\n\nWhen a watch on dir=/ is combined with an fsnotify event for a\nsingle-character name directly under / (e.g., creating /a), an\nout-of-bounds read can occur in audit_compare_dname_path().\n\nThe helper parent_len() returns 1 for "/". In audit_compare_dname_path(),\nwhen parentlen equals the full path length (1), the code sets p = path + 1\nand pathlen = 1 - 1 = 0. The subsequent loop then dereferences\np[pathlen - 1] (i.e., p[-1]), causing an out-of-bounds read.\n\nFix this by adding a pathlen > 0 check to the while loop condition\nto prevent the out-of-bounds access.\n\n[PM: subject tweak, sign-off email fixes]

In the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86: asus-wmi: Fix racy registrations\n\nasus_wmi_register_driver() may be called from multiple drivers\nconcurrently, which can lead to the racy list operations, eventually\ncorrupting the memory and hitting Oops on some ASUS machines.\nAlso, the error handling is missing, and it forgot to unregister ACPI\nlps0 dev ops in the error case.\n\nThis patch covers those issues by introducing a simple mutex at\nacpi_wmi_register_driver() & *_unregister_driver, and adding the\nproper call of asus_s2idle_check_unregister() in the error path.

In the Linux kernel, the following vulnerability has been resolved:\n\nring-buffer: Fix overflow in __rb_map_vma\n\nAn overflow occurred when performing the following calculation:\n\n nr_pages = ((nr_subbufs + 1) << subbuf_order) - pgoff;\n\nAdd a check before the calculation to avoid this problem.\n\nsyzbot reported this as a slab-out-of-bounds in __rb_map_vma:\n\nBUG: KASAN: slab-out-of-bounds in __rb_map_vma+0x9ab/0xae0 kernel/trace/ring_buffer.c:7058\nRead of size 8 at addr ffff8880767dd2b8 by task syz-executor187/5836\n\nCPU: 0 UID: 0 PID: 5836 Comm: syz-executor187 Not tainted 6.13.0-rc2-syzkaller-00159-gf932fb9b4074 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024\nCall Trace:\n \n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xc3/0x620 mm/kasan/report.c:489\n kasan_report+0xd9/0x110 mm/kasan/report.c:602\n __rb_map_vma+0x9ab/0xae0 kernel/trace/ring_buffer.c:7058\n ring_buffer_map+0x56e/0x9b0 kernel/trace/ring_buffer.c:7138\n tracing_buffers_mmap+0xa6/0x120 kernel/trace/trace.c:8482\n call_mmap include/linux/fs.h:2183 [inline]\n mmap_file mm/internal.h:124 [inline]\n __mmap_new_file_vma mm/vma.c:2291 [inline]\n __mmap_new_vma mm/vma.c:2355 [inline]\n __mmap_region+0x1786/0x2670 mm/vma.c:2456\n mmap_region+0x127/0x320 mm/mmap.c:1348\n do_mmap+0xc00/0xfc0 mm/mmap.c:496\n vm_mmap_pgoff+0x1ba/0x360 mm/util.c:580\n ksys_mmap_pgoff+0x32c/0x5c0 mm/mmap.c:542\n __do_sys_mmap arch/x86/kernel/sys_x86_64.c:89 [inline]\n __se_sys_mmap arch/x86/kernel/sys_x86_64.c:82 [inline]\n __x64_sys_mmap+0x125/0x190 arch/x86/kernel/sys_x86_64.c:82\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nThe reproducer for this bug is:\n\n------------------------8<-------------------------\n #include \n #include \n #include \n #include \n #include \n\n int main(int argc, char **argv)\n {\n int page_size = getpagesize();\n int fd;\n void *meta;\n\n system("echo 1 > /sys/kernel/tracing/buffer_size_kb");\n fd = open("/sys/kernel/tracing/per_cpu/cpu0/trace_pipe_raw", O_RDONLY);\n\n meta = mmap(NULL, page_size, PROT_READ, MAP_SHARED, fd, page_size * 5);\n }\n------------------------>8-------------------------

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: skb_partial_csum_set() fix against transport header magic value\n\nskb->transport_header uses the special 0xFFFF value\nto mark if the transport header was set or not.\n\nWe must prevent callers to accidentaly set skb->transport_header\nto 0xFFFF. Note that only fuzzers can possibly do this today.\n\nsyzbot reported:\n\nWARNING: CPU: 0 PID: 2340 at include/linux/skbuff.h:2847 skb_transport_offset include/linux/skbuff.h:2956 [inline]\nWARNING: CPU: 0 PID: 2340 at include/linux/skbuff.h:2847 virtio_net_hdr_to_skb+0xbcc/0x10c0 include/linux/virtio_net.h:103\nModules linked in:\nCPU: 0 PID: 2340 Comm: syz-executor.0 Not tainted 6.3.0-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023\nRIP: 0010:skb_transport_header include/linux/skbuff.h:2847 [inline]\nRIP: 0010:skb_transport_offset include/linux/skbuff.h:2956 [inline]\nRIP: 0010:virtio_net_hdr_to_skb+0xbcc/0x10c0 include/linux/virtio_net.h:103\nCode: 41 39 df 0f 82 c3 04 00 00 48 8b 7c 24 10 44 89 e6 e8 08 6e 59 ff 48 85 c0 74 54 e8 ce 36 7e fc e9 37 f8 ff ff e8 c4 36 7e fc <0f> 0b e9 93 f8 ff ff 44 89 f7 44 89 e6 e8 32 38 7e fc 45 39 e6 0f\nRSP: 0018:ffffc90004497880 EFLAGS: 00010293\nRAX: ffffffff84fea55c RBX: 000000000000ffff RCX: ffff888120be2100\nRDX: 0000000000000000 RSI: 000000000000ffff RDI: 000000000000ffff\nRBP: ffffc90004497990 R08: ffffffff84fe9de5 R09: 0000000000000034\nR10: ffffea00048ebd80 R11: 0000000000000034 R12: ffff88811dc2d9c8\nR13: dffffc0000000000 R14: ffff88811dc2d9ae R15: 1ffff11023b85b35\nFS: 00007f9211a59700(0000) GS:ffff8881f6c00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00000000200002c0 CR3: 00000001215a5000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n\npacket_snd net/packet/af_packet.c:3076 [inline]\npacket_sendmsg+0x4590/0x61a0 net/packet/af_packet.c:3115\nsock_sendmsg_nosec net/socket.c:724 [inline]\nsock_sendmsg net/socket.c:747 [inline]\n__sys_sendto+0x472/0x630 net/socket.c:2144\n__do_sys_sendto net/socket.c:2156 [inline]\n__se_sys_sendto net/socket.c:2152 [inline]\n__x64_sys_sendto+0xe5/0x100 net/socket.c:2152\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x2f/0x50 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\nRIP: 0033:0x7f9210c8c169\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f9211a59168 EFLAGS: 00000246 ORIG_RAX: 000000000000002c\nRAX: ffffffffffffffda RBX: 00007f9210dabf80 RCX: 00007f9210c8c169\nRDX: 000000000000ffed RSI: 00000000200000c0 RDI: 0000000000000003\nRBP: 00007f9210ce7ca1 R08: 0000000020000540 R09: 0000000000000014\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 00007ffe135d65cf R14: 00007f9211a59300 R15: 0000000000022000

In the Linux kernel, the following vulnerability has been resolved:\n\npowercap: arm_scmi: Remove recursion while parsing zones\n\nPowercap zones can be defined as arranged in a hierarchy of trees and when\nregistering a zone with powercap_register_zone(), the kernel powercap\nsubsystem expects this to happen starting from the root zones down to the\nleaves; on the other side, de-registration by powercap_deregister_zone()\nmust begin from the leaf zones.\n\nAvailable SCMI powercap zones are retrieved dynamically from the platform\nat probe time and, while any defined hierarchy between the zones is\ndescribed properly in the zones descriptor, the platform returns the\navailables zones with no particular well-defined order: as a consequence,\nthe trees possibly composing the hierarchy of zones have to be somehow\nwalked properly to register the retrieved zones from the root.\n\nCurrently the ARM SCMI Powercap driver walks the zones using a recursive\nalgorithm; this approach, even though correct and tested can lead to kernel\nstack overflow when processing a returned hierarchy of zones composed by\nparticularly high trees.\n\nAvoid possible kernel stack overflow by substituting the recursive approach\nwith an iterative one supported by a dynamically allocated stack-like data\nstructure.

In the Linux kernel, the following vulnerability has been resolved:\n\nxsk: Fix xsk_diag use-after-free error during socket cleanup\n\nFix a use-after-free error that is possible if the xsk_diag interface\nis used after the socket has been unbound from the device. This can\nhappen either due to the socket being closed or the device\ndisappearing. In the early days of AF_XDP, the way we tested that a\nsocket was not bound to a device was to simply check if the netdevice\npointer in the xsk socket structure was NULL. Later, a better system\nwas introduced by having an explicit state variable in the xsk socket\nstruct. For example, the state of a socket that is on the way to being\nclosed and has been unbound from the device is XSK_UNBOUND.\n\nThe commit in the Fixes tag below deleted the old way of signalling\nthat a socket is unbound, setting dev to NULL. This in the belief that\nall code using the old way had been exterminated. That was\nunfortunately not true as the xsk diagnostics code was still using the\nold way and thus does not work as intended when a socket is going\ndown. Fix this by introducing a test against the state variable. If\nthe socket is in the state XSK_UNBOUND, simply abort the diagnostic's\nnetlink operation.

In the Linux kernel, the following vulnerability has been resolved:\n\nclk: mediatek: fix of_iomap memory leak\n\nSmatch reports:\ndrivers/clk/mediatek/clk-mtk.c:583 mtk_clk_simple_probe() warn:\n 'base' from of_iomap() not released on lines: 496.\n\nThis problem was also found in linux-next. In mtk_clk_simple_probe(),\nbase is not released when handling errors\nif clk_data is not existed, which may cause a leak.\nSo free_base should be added here to release base.

In the Linux kernel, the following vulnerability has been resolved:\n\nntfs: Fix panic about slab-out-of-bounds caused by ntfs_listxattr()\n\nHere is a BUG report from syzbot:\n\nBUG: KASAN: slab-out-of-bounds in ntfs_list_ea fs/ntfs3/xattr.c:191 [inline]\nBUG: KASAN: slab-out-of-bounds in ntfs_listxattr+0x401/0x570 fs/ntfs3/xattr.c:710\nRead of size 1 at addr ffff888021acaf3d by task syz-executor128/3632\n\nCall Trace:\n ntfs_list_ea fs/ntfs3/xattr.c:191 [inline]\n ntfs_listxattr+0x401/0x570 fs/ntfs3/xattr.c:710\n vfs_listxattr fs/xattr.c:457 [inline]\n listxattr+0x293/0x2d0 fs/xattr.c:804\n\nFix the logic of ea_all iteration. When the ea->name_len is 0,\nreturn immediately, or Add2Ptr() would visit invalid memory\nin the next loop.\n\n[almaz.alexandrovich@paragon-software.com: lines of the patch have changed]

In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix NULL pointer dereference in smb2_get_info_filesystem()\n\nIf share is , share->path is NULL and it cause NULL pointer\ndereference issue.

In the Linux kernel, the following vulnerability has been resolved:\n\nubifs: Fix memory leak in do_rename\n\nIf renaming a file in an encrypted directory, function\nfscrypt_setup_filename allocates memory for a file name. This name is\nnever used, and before returning to the caller the memory for it is not\nfreed.\n\nWhen running kmemleak on it we see that it is registered as a leak. The\nreport below is triggered by a simple program 'rename' that renames a\nfile in an encrypted directory:\n\n unreferenced object 0xffff888101502840 (size 32):\n comm "rename", pid 9404, jiffies 4302582475 (age 435.735s)\n backtrace:\n __kmem_cache_alloc_node\n __kmalloc\n fscrypt_setup_filename\n do_rename\n ubifs_rename\n vfs_rename\n do_renameat2\n\nTo fix this we can remove the call to fscrypt_setup_filename as it's not\nneeded.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: xsk: Fix crash on regular rq reactivation\n\nWhen the regular rq is reactivated after the XSK socket is closed\nit could be reading stale cqes which eventually corrupts the rq.\nThis leads to no more traffic being received on the regular rq and a\ncrash on the next close or deactivation of the rq.\n\nKal Cuttler Conely reported this issue as a crash on the release\npath when the xdpsock sample program is stopped (killed) and restarted\nin sequence while traffic is running.\n\nThis patch flushes all cqes when during the rq flush. The cqe flushing\nis done in the reset state of the rq. mlx5e_rq_to_ready code is moved\ninto the flush function to allow for this.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/mediatek: dp: Only trigger DRM HPD events if bridge is attached\n\nThe MediaTek DisplayPort interface bridge driver starts its interrupts\nas soon as its probed. However when the interrupts trigger the bridge\nmight not have been attached to a DRM device. As drm_helper_hpd_irq_event()\ndoes not check whether the passed in drm_device is valid or not, a NULL\npointer passed in results in a kernel NULL pointer dereference in it.\n\nCheck whether the bridge is attached and only trigger an HPD event if\nit is.

In the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: fix leaked reference count of nfsd4_ssc_umount_item\n\nThe reference count of nfsd4_ssc_umount_item is not decremented\non error conditions. This prevents the laundromat from unmounting\nthe vfsmount of the source file.\n\nThis patch decrements the reference count of nfsd4_ssc_umount_item\non error.

In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: prevent use-after-free by freeing the cfile later\n\nIn smb2_compound_op we have a possible use-after-free\nwhich can cause hard to debug problems later on.\n\nThis was revealed during stress testing with KASAN enabled\nkernel. Fixing it by moving the cfile free call to\na few lines below, after the usage.

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_conn: fail SCO/ISO via hci_conn_failed if ACL gone early\n\nNot calling hci_(dis)connect_cfm before deleting conn referred to by a\nsocket generally results to use-after-free.\n\nWhen cleaning up SCO connections when the parent ACL is deleted too\nearly, use hci_conn_failed to do the connection cleanup properly.\n\nWe also need to clean up ISO connections in a similar situation when\nconnecting has started but LE Create CIS is not yet sent, so do it too\nhere.

In the Linux kernel, the following vulnerability has been resolved:\n\nregulator: da9063: better fix null deref with partial DT\n\nTwo versions of the original patch were sent but V1 was merged instead\nof V2 due to a mistake.\n\nSo update to V2.\n\nThe advantage of V2 is that it completely avoids dereferencing the pointer,\neven just to take the address, which may fix problems with some compilers.\nBoth versions work on my gcc 9.4 but use the safer one.