In the Linux kernel, the following vulnerability has been resolved:\n\npipe: wakeup wr_wait after setting max_usage\n\nCommit c73be61cede5 ("pipe: Add general notification queue support") a\nregression was introduced that would lock up resized pipes under certain\nconditions. See the reproducer in [1].\n\nThe commit resizing the pipe ring size was moved to a different\nfunction, doing that moved the wakeup for pipe->wr_wait before actually\nraising pipe->max_usage. If a pipe was full before the resize occured it\nwould result in the wakeup never actually triggering pipe_write.\n\nSet @max_usage and @nr_accounted before waking writers if this isn't a\nwatch queue.\n\n[Christian Brauner <brauner@kernel.org>: rewrite to account for watch queues]

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: zoned: fix lock ordering in btrfs_zone_activate()\n\nThe btrfs CI reported a lockdep warning as follows by running generic\ngeneric/129.\n\n WARNING: possible circular locking dependency detected\n 6.7.0-rc5+ #1 Not tainted\n ------------------------------------------------------\n kworker/u5:5/793427 is trying to acquire lock:\n ffff88813256d028 (&cache->lock){+.+.}-{2:2}, at: btrfs_zone_finish_one_bg+0x5e/0x130\n but task is already holding lock:\n ffff88810a23a318 (&fs_info->zone_active_bgs_lock){+.+.}-{2:2}, at: btrfs_zone_finish_one_bg+0x34/0x130\n which lock already depends on the new lock.\n\n the existing dependency chain (in reverse order) is:\n -> #1 (&fs_info->zone_active_bgs_lock){+.+.}-{2:2}:\n ...\n -> #0 (&cache->lock){+.+.}-{2:2}:\n ...\n\nThis is because we take fs_info->zone_active_bgs_lock after a block_group's\nlock in btrfs_zone_activate() while doing the opposite in other places.\n\nFix the issue by expanding the fs_info->zone_active_bgs_lock's critical\nsection and taking it before a block_group's lock.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/tegra: rgb: Fix missing clk_put() in the error handling paths of tegra_dc_rgb_probe()\n\nIf clk_get_sys(..., "pll_d2_out0") fails, the clk_get_sys() call must be\nundone.\n\nAdd the missing clk_put and a new 'put_pll_d_out0' label in the error\nhandling path, and use it.

In the Linux kernel, the following vulnerability has been resolved:\n\nx86/mm: Ensure input to pfn_to_kaddr() is treated as a 64-bit type\n\nOn 64-bit platforms, the pfn_to_kaddr() macro requires that the input\nvalue is 64 bits in order to ensure that valid address bits don't get\nlost when shifting that input by PAGE_SHIFT to calculate the physical\naddress to provide a virtual address for.\n\nOne such example is in pvalidate_pages() (used by SEV-SNP guests), where\nthe GFN in the struct used for page-state change requests is a 40-bit\nbit-field, so attempts to pass this GFN field directly into\npfn_to_kaddr() ends up causing guest crashes when dealing with addresses\nabove the 1TB range due to the above.\n\nFix this issue with SEV-SNP guests, as well as any similar cases that\nmight cause issues in current/future code, by using an inline function,\ninstead of a macro, so that the input is implicitly cast to the\nexpected 64-bit input type prior to performing the shift operation.\n\nWhile it might be argued that the issue is on the caller side, other\narchs/macros have taken similar approaches to deal with instances like\nthis, such as ARM explicitly casting the input to phys_addr_t:\n\n e48866647b48 ("ARM: 8396/1: use phys_addr_t in pfn_to_kaddr()")\n\nA C inline function is even better though.\n\n[ mingo: Refined the changelog some more & added __always_inline. ]

In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: drop any code related to SCM_RIGHTS\n\nThis is dead code after we dropped support for passing io_uring fds\nover SCM_RIGHTS, get rid of it.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vkms: Avoid reading beyond LUT array\n\nWhen the floor LUT index (drm_fixp2int(lut_index) is the last\nindex of the array the ceil LUT index will point to an entry\nbeyond the array. Make sure we guard against it and use the\nvalue of the floor LUT index.\n\nv3:\n - Drop bits from commit description that didn't contribute\n anything of value

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: nxp: imx8-isi: Check whether crossbar pad is non-NULL before access\n\nWhen translating source to sink streams in the crossbar subdev, the\ndriver tries to locate the remote subdev connected to the sink pad. The\nremote pad may be NULL, if userspace tries to enable a stream that ends\nat an unconnected crossbar sink. When that occurs, the driver\ndereferences the NULL pad, leading to a crash.\n\nPrevent the crash by checking if the pad is NULL before using it, and\nreturn an error if it is.

In the Linux kernel, the following vulnerability has been resolved:\n\naio: fix mremap after fork null-deref\n\nCommit e4a0d3e720e7 ("aio: Make it possible to remap aio ring") introduced\na null-deref if mremap is called on an old aio mapping after fork as\nmm->ioctx_table will be set to NULL.\n\n[jmoyer@redhat.com: fix 80 column issue]

In the Linux kernel, the following vulnerability has been resolved:\n\npmdomain: mediatek: fix race conditions with genpd\n\nIf the power domains are registered first with genpd and *after that*\nthe driver attempts to power them on in the probe sequence, then it is\npossible that a race condition occurs if genpd tries to power them on\nin the same time.\nThe same is valid for powering them off before unregistering them\nfrom genpd.\nAttempt to fix race conditions by first removing the domains from genpd\nand *after that* powering down domains.\nAlso first power up the domains and *after that* register them\nto genpd.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled\n\nWhen QoS is disabled, the queue priority value will not map to the correct\nieee80211 queue since there is only one queue. Stop/wake queue 0 when QoS\nis disabled to prevent trying to stop/wake a non-existent queue and failing\nto stop/wake the actual queue instantiated.\n\nLog of issue before change (with kernel parameter qos=0):\n [ +5.112651] ------------[ cut here ]------------\n [ +0.000005] WARNING: CPU: 7 PID: 25513 at net/mac80211/util.c:449 __ieee80211_wake_queue+0xd5/0x180 [mac80211]\n [ +0.000067] Modules linked in: b43(O) snd_seq_dummy snd_hrtimer snd_seq snd_seq_device nft_chain_nat xt_MASQUERADE nf_nat xfrm_user xfrm_algo xt_addrtype overlay ccm af_packet amdgpu snd_hda_codec_cirrus snd_hda_codec_generic ledtrig_audio drm_exec amdxcp gpu_sched xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_rpfilter ipt_rpfilter xt_pkttype xt_LOG nf_log_syslog xt_tcpudp nft_compat nf_tables nfnetlink sch_fq_codel btusb uinput iTCO_wdt ctr btrtl intel_pmc_bxt i915 intel_rapl_msr mei_hdcp mei_pxp joydev at24 watchdog btintel atkbd libps2 serio radeon btbcm vivaldi_fmap btmtk intel_rapl_common snd_hda_codec_hdmi bluetooth uvcvideo nls_iso8859_1 applesmc nls_cp437 x86_pkg_temp_thermal snd_hda_intel intel_powerclamp vfat videobuf2_vmalloc coretemp fat snd_intel_dspcfg crc32_pclmul uvc polyval_clmulni snd_intel_sdw_acpi loop videobuf2_memops snd_hda_codec tun drm_suballoc_helper polyval_generic drm_ttm_helper drm_buddy tap ecdh_generic videobuf2_v4l2 gf128mul macvlan ttm ghash_clmulni_intel ecc tg3\n [ +0.000044] videodev bridge snd_hda_core rapl crc16 drm_display_helper cec mousedev snd_hwdep evdev intel_cstate bcm5974 hid_appleir videobuf2_common stp mac_hid libphy snd_pcm drm_kms_helper acpi_als mei_me intel_uncore llc mc snd_timer intel_gtt industrialio_triggered_buffer apple_mfi_fastcharge i2c_i801 mei snd lpc_ich agpgart ptp i2c_smbus thunderbolt apple_gmux i2c_algo_bit kfifo_buf video industrialio soundcore pps_core wmi tiny_power_button sbs sbshc button ac cordic bcma mac80211 cfg80211 ssb rfkill libarc4 kvm_intel kvm drm irqbypass fuse backlight firmware_class efi_pstore configfs efivarfs dmi_sysfs ip_tables x_tables autofs4 dm_crypt cbc encrypted_keys trusted asn1_encoder tee tpm rng_core input_leds hid_apple led_class hid_generic usbhid hid sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10dif_generic ahci libahci libata uhci_hcd ehci_pci ehci_hcd crct10dif_pclmul crct10dif_common sha512_ssse3 sha512_generic sha256_ssse3 sha1_ssse3 aesni_intel usbcore scsi_mod libaes crypto_simd cryptd scsi_common\n [ +0.000055] usb_common rtc_cmos btrfs blake2b_generic libcrc32c crc32c_generic crc32c_intel xor raid6_pq dm_snapshot dm_bufio dm_mod dax [last unloaded: b43(O)]\n [ +0.000009] CPU: 7 PID: 25513 Comm: irq/17-b43 Tainted: G W O 6.6.7 #1-NixOS\n [ +0.000003] Hardware name: Apple Inc. MacBookPro8,3/Mac-942459F5819B171B, BIOS 87.0.0.0.0 06/13/2019\n [ +0.000001] RIP: 0010:__ieee80211_wake_queue+0xd5/0x180 [mac80211]\n [ +0.000046] Code: 00 45 85 e4 0f 85 9b 00 00 00 48 8d bd 40 09 00 00 f0 48 0f ba ad 48 09 00 00 00 72 0f 5b 5d 41 5c 41 5d 41 5e e9 cb 6d 3c d0 <0f> 0b 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8d b4 16 94 00 00\n [ +0.000002] RSP: 0018:ffffc90003c77d60 EFLAGS: 00010097\n [ +0.000001] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000\n [ +0.000001] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88820b924900\n [ +0.000002] RBP: ffff88820b924900 R08: ffffc90003c77d90 R09: 000000000003bfd0\n [ +0.000001] R10: ffff88820b924900 R11: ffffc90003c77c68 R12: 0000000000000000\n [ +0.000001] R13: 0000000000000000 R14: ffffc90003c77d90 R15: ffffffffc0fa6f40\n [ +0.000001] FS: 0000000000000000(0000) GS:ffff88846fb80000(0000) knlGS:0000000000000000\n [ +0.000001] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n [ +0.000001] CR2: 00007fafda7ae008 CR3: 000000046d220005 CR4: 00000000000606e0\n [ +0.000002] Call Trace:\n [ +0.000003] <TASK>\n [ +0.000001] ? __ieee80211_wake_queue+0xd5/0x180 [mac80211]\n [ +0.000044] ? __warn+0x81/0x130\n [ +0.000005] ? __ieee80211_wake_queue+0xd5/0x180 [mac80211]\n [ +0.000045] ? report_bug+0x171/0x1a0\n [ +0.000004] ? handle_bug+0x41/0x70\n [ +0.000004] ? exc_invalid_op+0x17/0x70\n [ +0.000003] ? asm_exc_invalid_op+0x1a/0x20\n [ +0.000005] ? __ieee80211_wake_queue+0xd5/0x180 [mac80211]\n [ +0.000043] ieee80211_wake_queue+0x4a/0x80 [mac80211]\n [ +0.000044] b43_dma_handle_txstatus+0x29c/0x3a0 [b43]\n [ +0.000016] ? __pfx_irq_thread_fn+0x10/0x10\n [ +0.000002] b43_handle_txstatus+0x61/0x80 [b43]\n [ +0.000012] b43_interrupt_thread_handler+0x3f9/0x6b0 [b43]\n [ +0.000011] irq_thread_fn+0x23/0x60\n [ +0.000002] irq_thread+0xfe/0x1c0\n [ +0.000002] ? __pfx_irq_thread_dtor+0x10/0x10\n [ +0.000001] ? __pfx_irq_thread+0x10/0x10\n [ +0.000001] kthread+0xe8/0x120\n [ +0.000003] ? __pfx_kthread+0x10/0x10\n [ +0.000003] ret_from_fork+0x34/0x50\n [ +0.000002] ? __pfx_kthread+0x10/0x10\n [ +0.000002] ret_from_fork_asm+0x1b/0x30\n [ +0.000004] </TASK>\n [ +0.000001] ---[ end trace 0000000000000000 ]---\n\n [ +0.000065] ------------[ cut here ]------------\n [ +0.000001] WARNING: CPU: 0 PID: 56077 at net/mac80211/util.c:514 __ieee80211_stop_queue+0xcc/0xe0 [mac80211]\n [ +0.000077] Modules linked in: b43(O) snd_seq_dummy snd_hrtimer snd_seq snd_seq_device nft_chain_nat xt_MASQUERADE nf_nat xfrm_user xfrm_algo xt_addrtype overlay ccm af_packet amdgpu snd_hda_codec_cirrus snd_hda_codec_generic ledtrig_audio drm_exec amdxcp gpu_sched xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_rpfilter ipt_rpfilter xt_pkttype xt_LOG nf_log_syslog xt_tcpudp nft_compat nf_tables nfnetlink sch_fq_codel btusb uinput iTCO_wdt ctr btrtl intel_pmc_bxt i915 intel_rapl_msr mei_hdcp mei_pxp joydev at24 watchdog btintel atkbd libps2 serio radeon btbcm vivaldi_fmap btmtk intel_rapl_common snd_hda_codec_hdmi bluetooth uvcvideo nls_iso8859_1 applesmc nls_cp437 x86_pkg_temp_thermal snd_hda_intel intel_powerclamp vfat videobuf2_vmalloc coretemp fat snd_intel_dspcfg crc32_pclmul uvc polyval_clmulni snd_intel_sdw_acpi loop videobuf2_memops snd_hda_codec tun drm_suballoc_helper polyval_generic drm_ttm_helper drm_buddy tap ecdh_generic videobuf2_v4l2 gf128mul macvlan ttm ghash_clmulni_intel ecc tg3\n [ +0.000073] videodev bridge snd_hda_core rapl crc16 drm_display_helper cec mousedev snd_hwdep evdev intel_cstate bcm5974 hid_appleir videobuf2_common stp mac_hid libphy snd_pcm drm_kms_helper acpi_als mei_me intel_uncore llc mc snd_timer intel_gtt industrialio_triggered_buffer apple_mfi_fastcharge i2c_i801 mei snd lpc_ich agpgart ptp i2c_smbus thunderbolt apple_gmux i2c_algo_bit kfifo_buf video industrialio soundcore pps_core wmi tiny_power_button sbs sbshc button ac cordic bcma mac80211 cfg80211 ssb rfkill libarc4 kvm_intel kvm drm irqbypass fuse backlight firmware_class efi_pstore configfs efivarfs dmi_sysfs ip_tables x_tables autofs4 dm_crypt cbc encrypted_keys trusted asn1_encoder tee tpm rng_core input_leds hid_apple led_class hid_generic usbhid hid sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10dif_generic ahci libahci libata uhci_hcd ehci_pci ehci_hcd crct10dif_pclmul crct10dif_common sha512_ssse3 sha512_generic sha256_ssse3 sha1_ssse3 aesni_intel usbcore scsi_mod libaes crypto_simd cryptd scsi_common\n [ +0.000084] usb_common rtc_cmos btrfs blake2b_generic libcrc32c crc32c_generic crc32c_intel xor raid6_pq dm_snapshot dm_bufio dm_mod dax [last unloaded: b43]\n [ +0.000012] CPU: 0 PID: 56077 Comm: kworker/u16:17 Tainted: G W O 6.6.7 #1-NixOS\n [ +0.000003] Hardware name: Apple Inc. MacBookPro8,3/Mac-942459F5819B171B, BIOS 87.0.0.0.0 06/13/2019\n [ +0.000001] Workqueue: phy7 b43_tx_work [b43]\n [ +0.000019] RIP: 0010:__ieee80211_stop_queue+0xcc/0xe0 [mac80211]\n [ +0.000076] Code: 74 11 48 8b 78 08 0f b7 d6 89 e9 4c 89 e6 e8 ab f4 00 00 65 ff 0d 9c b7 34 3f 0f 85 55 ff ff ff 0f 1f 44 00 00 e9 4b ff ff ff <0f> 0b 5b 5d 41 5c 41 5d c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90\n [ +0.000002] RSP: 0000:ffffc90004157d50 EFLAGS: 00010097\n [ +0.000002] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000\n [ +0.000002] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff8882d65d0900\n [ +0.000002] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000001\n [ +0.000001] R10: 00000000000000ff R11: ffff88814d0155a0 R12: ffff8882d65d0900\n [ +0.000002] R13: 0000000000000000 R14: ffff8881002d2800 R15: 00000000000000d0\n [ +0.000002] FS: 0000000000000000(0000) GS:ffff88846f800000(0000) knlGS:0000000000000000\n [ +0.000003] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n [ +0.000002] CR2: 00007f2e8c10c880 CR3: 0000000385b66005 CR4: 00000000000606f0\n [ +0.000002] Call Trace:\n [ +0.000001] <TASK>\n [ +0.000001] ? __ieee80211_stop_queue+0xcc/0xe0 [mac80211]\n [ +0.000075] ? __warn+0x81/0x130\n [ +0.000004] ? __ieee80211_stop_queue+0xcc/0xe0 [mac80211]\n [ +0.000075] ? report_bug+0x171/0x1a0\n [ +0.000005] ? handle_bug+0x41/0x70\n [ +0.000003] ? exc_invalid_op+0x17/0x70\n [ +0.000004] ? asm_exc_invalid_op+0x1a/0x20\n [ +0.000004] ? __ieee80211_stop_queue+0xcc/0xe0 [mac80211]\n [ +0.000076] ieee80211_stop_queue+0x36/0x50 [mac80211]\n [ +0.000077] b43_dma_tx+0x550/0x780 [b43]\n [ +0.000023] b43_tx_work+0x90/0x130 [b43]\n [ +0.000018] process_one_work+0x174/0x340\n [ +0.000003] worker_thread+0x27b/0x3a0\n [ +0.000004] ? __pfx_worker_thread+0x10/0x10\n [ +0.000002] kthread+0xe8/0x120\n [ +0.000003] ? __pfx_kthread+0x10/0x10\n [ +0.000004] ret_from_fork+0x34/0x50\n [ +0.000002] ? __pfx_kthread+0x10/0x10\n [ +0.000003] ret_from_fork_asm+0x1b/0x30\n [ +0.000006] </TASK>\n [ +0.000001] ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:\n\niio: core: fix memleak in iio_device_register_sysfs\n\nWhen iio_device_register_sysfs_group() fails, we should\nfree iio_dev_opaque->chan_attr_group.attrs to prevent\npotential memleak.

In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: lib/mpi - Fix unexpected pointer access in mpi_ec_init\n\nWhen the mpi_ec_ctx structure is initialized, some fields are not\ncleared, causing a crash when referencing the field when the\nstructure was released. Initially, this issue was ignored because\nmemory for mpi_ec_ctx is allocated with the __GFP_ZERO flag.\nFor example, this error will be triggered when calculating the\nZa value for SM2 separately.

In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: scomp - fix req->dst buffer overflow\n\nThe req->dst buffer size should be checked before copying from the\nscomp_scratch->dst to avoid req->dst buffer overflow problem.

In the Linux kernel, the following vulnerability has been resolved:\n\nx86/alternatives: Disable KASAN in apply_alternatives()\n\nFei has reported that KASAN triggers during apply_alternatives() on\na 5-level paging machine:\n\n BUG: KASAN: out-of-bounds in rcu_is_watching()\n Read of size 4 at addr ff110003ee6419a0 by task swapper/0/0\n ...\n __asan_load4()\n rcu_is_watching()\n trace_hardirqs_on()\n text_poke_early()\n apply_alternatives()\n ...\n\nOn machines with 5-level paging, cpu_feature_enabled(X86_FEATURE_LA57)\ngets patched. It includes KASAN code, where KASAN_SHADOW_START depends on\n__VIRTUAL_MASK_SHIFT, which is defined with cpu_feature_enabled().\n\nKASAN gets confused when apply_alternatives() patches the\nKASAN_SHADOW_START users. A test patch that makes KASAN_SHADOW_START\nstatic, by replacing __VIRTUAL_MASK_SHIFT with 56, works around the issue.\n\nFix it for real by disabling KASAN while the kernel is patching alternatives.\n\n[ mingo: updated the changelog ]

In the Linux kernel, the following vulnerability has been resolved:\n\nx86/srso: Add SRSO mitigation for Hygon processors\n\nAdd mitigation for the speculative return stack overflow vulnerability\nwhich exists on Hygon processors too.

In the Linux kernel, the following vulnerability has been resolved:\n\nice: switch: fix potential memleak in ice_add_adv_recipe()\n\nWhen ice_add_special_words() fails, the 'rm' is not released, which will\nlead to a memory leak. Fix this up by going to 'err_unroll' label.\n\nCompile tested only.

In the Linux kernel, the following vulnerability has been resolved:\n\ncxl/region: Fix null pointer dereference for resetting decoder\n\nNot all decoders have a reset callback.\n\nThe CXL specification allows a host bridge with a single root port to\nhave no explicit HDM decoders. Currently the region driver assumes there\nare none. As such the CXL core creates a special pass through decoder\ninstance without a commit/reset callback.\n\nPrior to this patch, the ->reset() callback was called unconditionally when\ncalling cxl_region_decode_reset. Thus a configuration with 1 Host Bridge,\n1 Root Port, and one directly attached CXL type 3 device or multiple CXL\ntype 3 devices attached to downstream ports of a switch can cause a null\npointer dereference.\n\nBefore the fix, a kernel crash was observed when we destroy the region, and\na pass through decoder is reset.\n\nThe issue can be reproduced as below,\n 1) create a region with a CXL setup which includes a HB with a\n single root port under which a memdev is attached directly.\n 2) destroy the region with cxl destroy-region regionX -f.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mt76: mt7921e: fix crash in chip reset fail\n\nIn case of drv own fail in reset, we may need to run mac_reset several\ntimes. The sequence would trigger system crash as the log below.\n\nBecause we do not re-enable/schedule "tx_napi" before disable it again,\nthe process would keep waiting for state change in napi_diable(). To\navoid the problem and keep status synchronize for each run, goto final\nresource handling if drv own failed.\n\n[ 5857.353423] mt7921e 0000:3b:00.0: driver own failed\n[ 5858.433427] mt7921e 0000:3b:00.0: Timeout for driver own\n[ 5859.633430] mt7921e 0000:3b:00.0: driver own failed\n[ 5859.633444] ------------[ cut here ]------------\n[ 5859.633446] WARNING: CPU: 6 at kernel/kthread.c:659 kthread_park+0x11d\n[ 5859.633717] Workqueue: mt76 mt7921_mac_reset_work [mt7921_common]\n[ 5859.633728] RIP: 0010:kthread_park+0x11d/0x150\n[ 5859.633736] RSP: 0018:ffff8881b676fc68 EFLAGS: 00010202\n......\n[ 5859.633766] Call Trace:\n[ 5859.633768] <TASK>\n[ 5859.633771] mt7921e_mac_reset+0x176/0x6f0 [mt7921e]\n[ 5859.633778] mt7921_mac_reset_work+0x184/0x3a0 [mt7921_common]\n[ 5859.633785] ? mt7921_mac_set_timing+0x520/0x520 [mt7921_common]\n[ 5859.633794] ? __kasan_check_read+0x11/0x20\n[ 5859.633802] process_one_work+0x7ee/0x1320\n[ 5859.633810] worker_thread+0x53c/0x1240\n[ 5859.633818] kthread+0x2b8/0x370\n[ 5859.633824] ? process_one_work+0x1320/0x1320\n[ 5859.633828] ? kthread_complete_and_exit+0x30/0x30\n[ 5859.633834] ret_from_fork+0x1f/0x30\n[ 5859.633842] </TASK>

In the Linux kernel, the following vulnerability has been resolved:\n\nregmap: spi: Reserve space for register address/padding\n\nCurrently the max_raw_read and max_raw_write limits in regmap_spi struct\ndo not take into account the additional size of the transmitted register\naddress and padding. This may result in exceeding the maximum permitted\nSPI message size, which could cause undefined behaviour, e.g. data\ncorruption.\n\nFix regmap_get_spi_bus() to properly adjust the above mentioned limits\nby reserving space for the register address/padding as set in the regmap\nconfiguration.

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/irdma: Fix drain SQ hang with no completion\n\nSW generated completions for outstanding WRs posted on SQ\nafter QP is in error target the wrong CQ. This causes the\nib_drain_sq to hang with no completion.\n\nFix this to generate completions on the right CQ.\n\n[ 863.969340] INFO: task kworker/u52:2:671 blocked for more than 122 seconds.\n[ 863.979224] Not tainted 5.14.0-130.el9.x86_64 #1\n[ 863.986588] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.\n[ 863.996997] task:kworker/u52:2 state:D stack: 0 pid: 671 ppid: 2 flags:0x00004000\n[ 864.007272] Workqueue: xprtiod xprt_autoclose [sunrpc]\n[ 864.014056] Call Trace:\n[ 864.017575] __schedule+0x206/0x580\n[ 864.022296] schedule+0x43/0xa0\n[ 864.026736] schedule_timeout+0x115/0x150\n[ 864.032185] __wait_for_common+0x93/0x1d0\n[ 864.037717] ? usleep_range_state+0x90/0x90\n[ 864.043368] __ib_drain_sq+0xf6/0x170 [ib_core]\n[ 864.049371] ? __rdma_block_iter_next+0x80/0x80 [ib_core]\n[ 864.056240] ib_drain_sq+0x66/0x70 [ib_core]\n[ 864.062003] rpcrdma_xprt_disconnect+0x82/0x3b0 [rpcrdma]\n[ 864.069365] ? xprt_prepare_transmit+0x5d/0xc0 [sunrpc]\n[ 864.076386] xprt_rdma_close+0xe/0x30 [rpcrdma]\n[ 864.082593] xprt_autoclose+0x52/0x100 [sunrpc]\n[ 864.088718] process_one_work+0x1e8/0x3c0\n[ 864.094170] worker_thread+0x50/0x3b0\n[ 864.099109] ? rescuer_thread+0x370/0x370\n[ 864.104473] kthread+0x149/0x170\n[ 864.109022] ? set_kthread_struct+0x40/0x40\n[ 864.114713] ret_from_fork+0x22/0x30

In the Linux kernel, the following vulnerability has been resolved:\n\nice: Fix DMA mappings leak\n\nFix leak, when user changes ring parameters.\nDuring reallocation of RX buffers, new DMA mappings are created for\nthose buffers. New buffers with different RX ring count should\nsubstitute older ones, but those buffers were freed in ice_vsi_cfg_rxq\nand reallocated again with ice_alloc_rx_buf. kfree on rx_buf caused\nleak of already mapped DMA.\nReallocate ZC with xdp_buf struct, when BPF program loads. Reallocate\nback to rx_buf, when BPF program unloads.\nIf BPF program is loaded/unloaded and XSK pools are created, reallocate\nRX queues accordingly in XDP_SETUP_XSK_POOL handler.\n\nSteps for reproduction:\nwhile :\ndo\n for ((i=0; i<=8160; i=i+32))\n do\n ethtool -G enp130s0f0 rx $i tx $i\n sleep 0.5\n ethtool -g enp130s0f0\n done\ndone

In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: TX zerocopy should not sense pfmemalloc status\n\nWe got a recent syzbot report [1] showing a possible misuse\nof pfmemalloc page status in TCP zerocopy paths.\n\nIndeed, for pages coming from user space or other layers,\nusing page_is_pfmemalloc() is moot, and possibly could give\nfalse positives.\n\nThere has been attempts to make page_is_pfmemalloc() more robust,\nbut not using it in the first place in this context is probably better,\nremoving cpu cycles.\n\nNote to stable teams :\n\nYou need to backport 84ce071e38a6 ("net: introduce\n__skb_fill_page_desc_noacc") as a prereq.\n\nRace is more probable after commit c07aea3ef4d4\n("mm: add a signature in struct page") because page_is_pfmemalloc()\nis now using low order bit from page->lru.next, which can change\nmore often than page->index.\n\nLow order bit should never be set for lru.next (when used as an anchor\nin LRU list), so KCSAN report is mostly a false positive.\n\nBackporting to older kernel versions seems not necessary.\n\n[1]\nBUG: KCSAN: data-race in lru_add_fn / tcp_build_frag\n\nwrite to 0xffffea0004a1d2c8 of 8 bytes by task 18600 on cpu 0:\n__list_add include/linux/list.h:73 [inline]\nlist_add include/linux/list.h:88 [inline]\nlruvec_add_folio include/linux/mm_inline.h:105 [inline]\nlru_add_fn+0x440/0x520 mm/swap.c:228\nfolio_batch_move_lru+0x1e1/0x2a0 mm/swap.c:246\nfolio_batch_add_and_move mm/swap.c:263 [inline]\nfolio_add_lru+0xf1/0x140 mm/swap.c:490\nfilemap_add_folio+0xf8/0x150 mm/filemap.c:948\n__filemap_get_folio+0x510/0x6d0 mm/filemap.c:1981\npagecache_get_page+0x26/0x190 mm/folio-compat.c:104\ngrab_cache_page_write_begin+0x2a/0x30 mm/folio-compat.c:116\next4_da_write_begin+0x2dd/0x5f0 fs/ext4/inode.c:2988\ngeneric_perform_write+0x1d4/0x3f0 mm/filemap.c:3738\next4_buffered_write_iter+0x235/0x3e0 fs/ext4/file.c:270\next4_file_write_iter+0x2e3/0x1210\ncall_write_iter include/linux/fs.h:2187 [inline]\nnew_sync_write fs/read_write.c:491 [inline]\nvfs_write+0x468/0x760 fs/read_write.c:578\nksys_write+0xe8/0x1a0 fs/read_write.c:631\n__do_sys_write fs/read_write.c:643 [inline]\n__se_sys_write fs/read_write.c:640 [inline]\n__x64_sys_write+0x3e/0x50 fs/read_write.c:640\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\nread to 0xffffea0004a1d2c8 of 8 bytes by task 18611 on cpu 1:\npage_is_pfmemalloc include/linux/mm.h:1740 [inline]\n__skb_fill_page_desc include/linux/skbuff.h:2422 [inline]\nskb_fill_page_desc include/linux/skbuff.h:2443 [inline]\ntcp_build_frag+0x613/0xb20 net/ipv4/tcp.c:1018\ndo_tcp_sendpages+0x3e8/0xaf0 net/ipv4/tcp.c:1075\ntcp_sendpage_locked net/ipv4/tcp.c:1140 [inline]\ntcp_sendpage+0x89/0xb0 net/ipv4/tcp.c:1150\ninet_sendpage+0x7f/0xc0 net/ipv4/af_inet.c:833\nkernel_sendpage+0x184/0x300 net/socket.c:3561\nsock_sendpage+0x5a/0x70 net/socket.c:1054\npipe_to_sendpage+0x128/0x160 fs/splice.c:361\nsplice_from_pipe_feed fs/splice.c:415 [inline]\n__splice_from_pipe+0x222/0x4d0 fs/splice.c:559\nsplice_from_pipe fs/splice.c:594 [inline]\ngeneric_splice_sendpage+0x89/0xc0 fs/splice.c:743\ndo_splice_from fs/splice.c:764 [inline]\ndirect_splice_actor+0x80/0xa0 fs/splice.c:931\nsplice_direct_to_actor+0x305/0x620 fs/splice.c:886\ndo_splice_direct+0xfb/0x180 fs/splice.c:974\ndo_sendfile+0x3bf/0x910 fs/read_write.c:1249\n__do_sys_sendfile64 fs/read_write.c:1317 [inline]\n__se_sys_sendfile64 fs/read_write.c:1303 [inline]\n__x64_sys_sendfile64+0x10c/0x150 fs/read_write.c:1303\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: 0x0000000000000000 -> 0xffffea0004a1d288\n\nReported by Kernel Concurrency Sanitizer on:\nCPU: 1 PID: 18611 Comm: syz-executor.4 Not tainted 6.0.0-rc2-syzkaller-00248-ge022620b5d05-dirty #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022

In the Linux kernel, the following vulnerability has been resolved:\n\ncgroup: Add missing cpus_read_lock() to cgroup_attach_task_all()\n\nsyzbot is hitting percpu_rwsem_assert_held(&cpu_hotplug_lock) warning at\ncpuset_attach() [1], for commit 4f7e7236435ca0ab ("cgroup: Fix\nthreadgroup_rwsem <-> cpus_read_lock() deadlock") missed that\ncpuset_attach() is also called from cgroup_attach_task_all().\nAdd cpus_read_lock() like what cgroup_procs_write_start() does.

In the Linux kernel, the following vulnerability has been resolved:\n\npeci: cpu: Fix use-after-free in adev_release()\n\nWhen auxiliary_device_add() returns an error, auxiliary_device_uninit()\nis called, which causes refcount for device to be decremented and\n.release callback will be triggered.\n\nBecause adev_release() re-calls auxiliary_device_uninit(), it will cause\nuse-after-free:\n[ 1269.455172] WARNING: CPU: 0 PID: 14267 at lib/refcount.c:28 refcount_warn_saturate+0x110/0x15\n[ 1269.464007] refcount_t: underflow; use-after-free.

In the Linux kernel, the following vulnerability has been resolved:\n\nsmb3: fix temporary data corruption in collapse range\n\ncollapse range doesn't discard the affected cached region\nso can risk temporarily corrupting the file data. This\nfixes xfstest generic/031\n\nI also decided to merge a minor cleanup to this into the same patch\n(avoiding rereading inode size repeatedly unnecessarily) to make it\nclearer.

In the Linux kernel, the following vulnerability has been resolved:\n\nsmb3: fix temporary data corruption in insert range\n\ninsert range doesn't discard the affected cached region\nso can risk temporarily corrupting file data.\n\nAlso includes some minor cleanup (avoiding rereading\ninode size repeatedly unnecessarily) to make it clearer.

In the Linux kernel, the following vulnerability has been resolved:\n\nexfat: fix overflow for large capacity partition\n\nUsing int type for sector index, there will be overflow in a large\ncapacity partition.\n\nFor example, if storage with sector size of 512 bytes and partition\ncapacity is larger than 2TB, there will be overflow.

In the Linux kernel, the following vulnerability has been resolved:\n\ngpio: mockup: fix NULL pointer dereference when removing debugfs\n\nWe now remove the device's debugfs entries when unbinding the driver.\nThis now causes a NULL-pointer dereference on module exit because the\nplatform devices are unregistered *after* the global debugfs directory\nhas been recursively removed. Fix it by unregistering the devices first.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/gem: Really move i915_gem_context.link under ref protection\n\ni915_perf assumes that it can use the i915_gem_context reference to\nprotect its i915->gem.contexts.list iteration. However, this requires\nthat we do not remove the context from the list until after we drop the\nfinal reference and release the struct. If, as currently, we remove the\ncontext from the list during context_close(), the link.next pointer may\nbe poisoned while we are holding the context reference and cause a GPF:\n\n[ 4070.573157] i915 0000:00:02.0: [drm:i915_perf_open_ioctl [i915]] filtering on ctx_id=0x1fffff ctx_id_mask=0x1fffff\n[ 4070.574881] general protection fault, probably for non-canonical address 0xdead000000000100: 0000 [#1] PREEMPT SMP\n[ 4070.574897] CPU: 1 PID: 284392 Comm: amd_performance Tainted: G E 5.17.9 #180\n[ 4070.574903] Hardware name: Intel Corporation NUC7i5BNK/NUC7i5BNB, BIOS BNKBL357.86A.0052.2017.0918.1346 09/18/2017\n[ 4070.574907] RIP: 0010:oa_configure_all_contexts.isra.0+0x222/0x350 [i915]\n[ 4070.574982] Code: 08 e8 32 6e 10 e1 4d 8b 6d 50 b8 ff ff ff ff 49 83 ed 50 f0 41 0f c1 04 24 83 f8 01 0f 84 e3 00 00 00 85 c0 0f 8e fa 00 00 00 <49> 8b 45 50 48 8d 70 b0 49 8d 45 50 48 39 44 24 10 0f 85 34 fe ff\n[ 4070.574990] RSP: 0018:ffffc90002077b78 EFLAGS: 00010202\n[ 4070.574995] RAX: 0000000000000002 RBX: 0000000000000002 RCX: 0000000000000000\n[ 4070.575000] RDX: 0000000000000001 RSI: ffffc90002077b20 RDI: ffff88810ddc7c68\n[ 4070.575004] RBP: 0000000000000001 R08: ffff888103242648 R09: fffffffffffffffc\n[ 4070.575008] R10: ffffffff82c50bc0 R11: 0000000000025c80 R12: ffff888101bf1860\n[ 4070.575012] R13: dead0000000000b0 R14: ffffc90002077c04 R15: ffff88810be5cabc\n[ 4070.575016] FS: 00007f1ed50c0780(0000) GS:ffff88885ec80000(0000) knlGS:0000000000000000\n[ 4070.575021] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 4070.575025] CR2: 00007f1ed5590280 CR3: 000000010ef6f005 CR4: 00000000003706e0\n[ 4070.575029] Call Trace:\n[ 4070.575033] <TASK>\n[ 4070.575037] lrc_configure_all_contexts+0x13e/0x150 [i915]\n[ 4070.575103] gen8_enable_metric_set+0x4d/0x90 [i915]\n[ 4070.575164] i915_perf_open_ioctl+0xbc0/0x1500 [i915]\n[ 4070.575224] ? asm_common_interrupt+0x1e/0x40\n[ 4070.575232] ? i915_oa_init_reg_state+0x110/0x110 [i915]\n[ 4070.575290] drm_ioctl_kernel+0x85/0x110\n[ 4070.575296] ? update_load_avg+0x5f/0x5e0\n[ 4070.575302] drm_ioctl+0x1d3/0x370\n[ 4070.575307] ? i915_oa_init_reg_state+0x110/0x110 [i915]\n[ 4070.575382] ? gen8_gt_irq_handler+0x46/0x130 [i915]\n[ 4070.575445] __x64_sys_ioctl+0x3c4/0x8d0\n[ 4070.575451] ? __do_softirq+0xaa/0x1d2\n[ 4070.575456] do_syscall_64+0x35/0x80\n[ 4070.575461] entry_SYSCALL_64_after_hwframe+0x44/0xae\n[ 4070.575467] RIP: 0033:0x7f1ed5c10397\n[ 4070.575471] Code: 3c 1c e8 1c ff ff ff 85 c0 79 87 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a9 da 0d 00 f7 d8 64 89 01 48\n[ 4070.575478] RSP: 002b:00007ffd65c8d7a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\n[ 4070.575484] RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 00007f1ed5c10397\n[ 4070.575488] RDX: 00007ffd65c8d7c0 RSI: 0000000040106476 RDI: 0000000000000006\n[ 4070.575492] RBP: 00005620972f9c60 R08: 000000000000000a R09: 0000000000000005\n[ 4070.575496] R10: 000000000000000d R11: 0000000000000246 R12: 000000000000000a\n[ 4070.575500] R13: 000000000000000d R14: 0000000000000000 R15: 00007ffd65c8d7c0\n[ 4070.575505] </TASK>\n[ 4070.575507] Modules linked in: nls_ascii(E) nls_cp437(E) vfat(E) fat(E) i915(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) crct10dif_pclmul(E) crc32_pclmul(E) crc32c_intel(E) aesni_intel(E) crypto_simd(E) intel_gtt(E) cryptd(E) ttm(E) rapl(E) intel_cstate(E) drm_kms_helper(E) cfbfillrect(E) syscopyarea(E) cfbimgblt(E) intel_uncore(E) sysfillrect(E) mei_me(E) sysimgblt(E) i2c_i801(E) fb_sys_fops(E) mei(E) intel_pch_thermal(E) i2c_smbus(E) cfbcopyarea(E) video(E) button(E) efivarfs(E) autofs4(E)\n[ 4070.575549] ---[ end trace 0000000000000000 ]---\n\nv3: fix incorrect syntax of spin_lock() replacing spin_lock_irqsave()\n\nv2: irqsave not required in a worker, neither conversion to irq safe\n elsewhere (Tvrtko),\n - perf: it's safe to call gen8_configure_context() even if context has\n been closed, no need to check,\n - drop unrelated cleanup (Andi, Tvrtko)\n\nReferences: a4e7ccdac38e ("drm/i915: Move context management under GEM")\n(cherry picked from commit ad3aa7c31efa5a09b0dba42e66cfdf77e0db7dc2)

In the Linux kernel, the following vulnerability has been resolved:\n\ngpio: mockup: Fix potential resource leakage when register a chip\n\nIf creation of software node fails, the locally allocated string\narray is left unfreed. Free it on error path.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm/slub: fix to return errno if kmalloc() fails\n\nIn create_unique_id(), kmalloc(, GFP_KERNEL) can fail due to\nout-of-memory, if it fails, return errno correctly rather than\ntriggering panic via BUG_ON();\n\nkernel BUG at mm/slub.c:5893!\nInternal error: Oops - BUG: 0 [#1] PREEMPT SMP\n\nCall trace:\n sysfs_slab_add+0x258/0x260 mm/slub.c:5973\n __kmem_cache_create+0x60/0x118 mm/slub.c:4899\n create_cache mm/slab_common.c:229 [inline]\n kmem_cache_create_usercopy+0x19c/0x31c mm/slab_common.c:335\n kmem_cache_create+0x1c/0x28 mm/slab_common.c:390\n f2fs_kmem_cache_create fs/f2fs/f2fs.h:2766 [inline]\n f2fs_init_xattr_caches+0x78/0xb4 fs/f2fs/xattr.c:808\n f2fs_fill_super+0x1050/0x1e0c fs/f2fs/super.c:4149\n mount_bdev+0x1b8/0x210 fs/super.c:1400\n f2fs_mount+0x44/0x58 fs/f2fs/super.c:4512\n legacy_get_tree+0x30/0x74 fs/fs_context.c:610\n vfs_get_tree+0x40/0x140 fs/super.c:1530\n do_new_mount+0x1dc/0x4e4 fs/namespace.c:3040\n path_mount+0x358/0x914 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 __arm64_sys_mount+0x2f8/0x408 fs/namespace.c:3568

In the Linux kernel, the following vulnerability has been resolved:\n\nmm: slub: fix flush_cpu_slab()/__free_slab() invocations in task context.\n\nCommit 5a836bf6b09f ("mm: slub: move flush_cpu_slab() invocations\n__free_slab() invocations out of IRQ context") moved all flush_cpu_slab()\ninvocations to the global workqueue to avoid a problem related\nwith deactivate_slab()/__free_slab() being called from an IRQ context\non PREEMPT_RT kernels.\n\nWhen the flush_all_cpu_locked() function is called from a task context\nit may happen that a workqueue with WQ_MEM_RECLAIM bit set ends up\nflushing the global workqueue, this will cause a dependency issue.\n\n workqueue: WQ_MEM_RECLAIM nvme-delete-wq:nvme_delete_ctrl_work [nvme_core]\n is flushing !WQ_MEM_RECLAIM events:flush_cpu_slab\n WARNING: CPU: 37 PID: 410 at kernel/workqueue.c:2637\n check_flush_dependency+0x10a/0x120\n Workqueue: nvme-delete-wq nvme_delete_ctrl_work [nvme_core]\n RIP: 0010:check_flush_dependency+0x10a/0x120[ 453.262125] Call Trace:\n __flush_work.isra.0+0xbf/0x220\n ? __queue_work+0x1dc/0x420\n flush_all_cpus_locked+0xfb/0x120\n __kmem_cache_shutdown+0x2b/0x320\n kmem_cache_destroy+0x49/0x100\n bioset_exit+0x143/0x190\n blk_release_queue+0xb9/0x100\n kobject_cleanup+0x37/0x130\n nvme_fc_ctrl_free+0xc6/0x150 [nvme_fc]\n nvme_free_ctrl+0x1ac/0x2b0 [nvme_core]\n\nFix this bug by creating a workqueue for the flush operation with\nthe WQ_MEM_RECLAIM bit set.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nfnetlink_osf: fix possible bogus match in nf_osf_find()\n\nnf_osf_find() incorrectly returns true on mismatch, this leads to\ncopying uninitialized memory area in nft_osf which can be used to leak\nstale kernel stack data to userspace.

In the Linux kernel, the following vulnerability has been resolved:\n\nice: Don't double unplug aux on peer initiated reset\n\nIn the IDC callback that is accessed when the aux drivers request a reset,\nthe function to unplug the aux devices is called. This function is also\ncalled in the ice_prepare_for_reset function. This double call is causing\na "scheduling while atomic" BUG.\n\n[ 662.676430] ice 0000:4c:00.0 rocep76s0: cqp opcode = 0x1 maj_err_code = 0xffff min_err_code = 0x8003\n\n[ 662.676609] ice 0000:4c:00.0 rocep76s0: [Modify QP Cmd Error][op_code=8] status=-29 waiting=1 completion_err=1 maj=0xffff min=0x8003\n\n[ 662.815006] ice 0000:4c:00.0 rocep76s0: ICE OICR event notification: oicr = 0x10000003\n\n[ 662.815014] ice 0000:4c:00.0 rocep76s0: critical PE Error, GLPE_CRITERR=0x00011424\n\n[ 662.815017] ice 0000:4c:00.0 rocep76s0: Requesting a reset\n\n[ 662.815475] BUG: scheduling while atomic: swapper/37/0/0x00010002\n\n[ 662.815475] BUG: scheduling while atomic: swapper/37/0/0x00010002\n[ 662.815477] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs rfkill 8021q garp mrp stp llc vfat fat rpcrdma intel_rapl_msr intel_rapl_common sunrpc i10nm_edac rdma_ucm nfit ib_srpt libnvdimm ib_isert iscsi_target_mod x86_pkg_temp_thermal intel_powerclamp coretemp target_core_mod snd_hda_intel ib_iser snd_intel_dspcfg libiscsi snd_intel_sdw_acpi scsi_transport_iscsi kvm_intel iTCO_wdt rdma_cm snd_hda_codec kvm iw_cm ipmi_ssif iTCO_vendor_support snd_hda_core irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hwdep snd_seq snd_seq_device rapl snd_pcm snd_timer isst_if_mbox_pci pcspkr isst_if_mmio irdma intel_uncore idxd acpi_ipmi joydev isst_if_common snd mei_me idxd_bus ipmi_si soundcore i2c_i801 mei ipmi_devintf i2c_smbus i2c_ismt ipmi_msghandler acpi_power_meter acpi_pad rv(OE) ib_uverbs ib_cm ib_core xfs libcrc32c ast i2c_algo_bit drm_vram_helper drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm_ttm_helpe\n r ttm\n[ 662.815546] nvme nvme_core ice drm crc32c_intel i40e t10_pi wmi pinctrl_emmitsburg dm_mirror dm_region_hash dm_log dm_mod fuse\n[ 662.815557] Preemption disabled at:\n[ 662.815558] [<0000000000000000>] 0x0\n[ 662.815563] CPU: 37 PID: 0 Comm: swapper/37 Kdump: loaded Tainted: G S OE 5.17.1 #2\n[ 662.815566] Hardware name: Intel Corporation D50DNP/D50DNP, BIOS SE5C6301.86B.6624.D18.2111021741 11/02/2021\n[ 662.815568] Call Trace:\n[ 662.815572] <IRQ>\n[ 662.815574] dump_stack_lvl+0x33/0x42\n[ 662.815581] __schedule_bug.cold.147+0x7d/0x8a\n[ 662.815588] __schedule+0x798/0x990\n[ 662.815595] schedule+0x44/0xc0\n[ 662.815597] schedule_preempt_disabled+0x14/0x20\n[ 662.815600] __mutex_lock.isra.11+0x46c/0x490\n[ 662.815603] ? __ibdev_printk+0x76/0xc0 [ib_core]\n[ 662.815633] device_del+0x37/0x3d0\n[ 662.815639] ice_unplug_aux_dev+0x1a/0x40 [ice]\n[ 662.815674] ice_schedule_reset+0x3c/0xd0 [ice]\n[ 662.815693] irdma_iidc_event_handler.cold.7+0xb6/0xd3 [irdma]\n[ 662.815712] ? bitmap_find_next_zero_area_off+0x45/0xa0\n[ 662.815719] ice_send_event_to_aux+0x54/0x70 [ice]\n[ 662.815741] ice_misc_intr+0x21d/0x2d0 [ice]\n[ 662.815756] __handle_irq_event_percpu+0x4c/0x180\n[ 662.815762] handle_irq_event_percpu+0xf/0x40\n[ 662.815764] handle_irq_event+0x34/0x60\n[ 662.815766] handle_edge_irq+0x9a/0x1c0\n[ 662.815770] __common_interrupt+0x62/0x100\n[ 662.815774] common_interrupt+0xb4/0xd0\n[ 662.815779] </IRQ>\n[ 662.815780] <TASK>\n[ 662.815780] asm_common_interrupt+0x1e/0x40\n[ 662.815785] RIP: 0010:cpuidle_enter_state+0xd6/0x380\n[ 662.815789] Code: 49 89 c4 0f 1f 44 00 00 31 ff e8 65 d7 95 ff 45 84 ff 74 12 9c 58 f6 c4 02 0f 85 64 02 00 00 31 ff e8 ae c5 9c ff fb 45 85 f6 <0f> 88 12 01 00 00 49 63 d6 4c 2b 24 24 48 8d 04 52 48 8d 04 82 49\n[ 662.815791] RSP: 0018:ff2c2c4f18edbe80 EFLAGS: 00000202\n[ 662.815793] RAX: ff280805df140000 RBX: 0000000000000002 RCX: 000000000000001f\n[ 662.815795] RDX: 0000009a52da2d08 RSI: ffffffff93f8240b RDI: ffffffff93f53ee7\n[ 662.815796] RBP: ff5e2bd11ff41928 R08: 0000000000000000 R09: 000000000002f8c0\n[ 662.815797] R10: 0000010c3f18e2cf R11: 000000000000000f R12: 0000009a52da2d08\n[ 662.815798] R13: ffffffff94ad7e20 R14: 0000000000000002 R15: 0000000000000000\n[ 662.815801] cpuidle_enter+0x29/0x40\n[ 662.815803] do_idle+0x261/0x2b0\n[ 662.815807] cpu_startup_entry+0x19/0x20\n[ 662.815809] start_secondary+0x114/0x150\n[ 662.815813] secondary_startup_64_no_verify+0xd5/0xdb\n[ 662.815818] </TASK>\n[ 662.815846] bad: scheduling from the idle thread!\n[ 662.815849] CPU: 37 PID: 0 Comm: swapper/37 Kdump: loaded Tainted: G S W OE 5.17.1 #2\n[ 662.815852] Hardware name: Intel Corporation D50DNP/D50DNP, BIOS SE5C6301.86B.6624.D18.2111021741 11/02/2021\n[ 662.815853] Call Trace:\n[ 662.815855] <IRQ>\n[ 662.815856] dump_stack_lvl+0x33/0x42\n[ 662.815860] dequeue_task_idle+0x20/0x30\n[ 662.815863] __schedule+0x1c3/0x990\n[ 662.815868] schedule+0x44/0xc0\n[ 662.815871] schedule_preempt_disabled+0x14/0x20\n[ 662.815873] __mutex_lock.isra.11+0x3a8/0x490\n[ 662.815876] ? __ibdev_printk+0x76/0xc0 [ib_core]\n[ 662.815904] device_del+0x37/0x3d0\n[ 662.815909] ice_unplug_aux_dev+0x1a/0x40 [ice]\n[ 662.815937] ice_schedule_reset+0x3c/0xd0 [ice]\n[ 662.815961] irdma_iidc_event_handler.cold.7+0xb6/0xd3 [irdma]\n[ 662.815979] ? bitmap_find_next_zero_area_off+0x45/0xa0\n[ 662.815985] ice_send_event_to_aux+0x54/0x70 [ice]\n[ 662.816011] ice_misc_intr+0x21d/0x2d0 [ice]\n[ 662.816033] __handle_irq_event_percpu+0x4c/0x180\n[ 662.816037] handle_irq_event_percpu+0xf/0x40\n[ 662.816039] handle_irq_event+0x34/0x60\n[ 662.816042] handle_edge_irq+0x9a/0x1c0\n[ 662.816045] __common_interrupt+0x62/0x100\n[ 662.816048] common_interrupt+0xb4/0xd0\n[ 662.816052] </IRQ>\n[ 662.816053] <TASK>\n[ 662.816054] asm_common_interrupt+0x1e/0x40\n[ 662.816057] RIP: 0010:cpuidle_enter_state+0xd6/0x380\n[ 662.816060] Code: 49 89 c4 0f 1f 44 00 00 31 ff e8 65 d7 95 ff 45 84 ff 74 12 9c 58 f6 c4 02 0f 85 64 02 00 00 31 ff e8 ae c5 9c ff fb 45 85 f6 <0f> 88 12 01 00 00 49 63 d6 4c 2b 24 24 48 8d 04 52 48 8d 04 82 49\n[ 662.816063] RSP: 0018:ff2c2c4f18edbe80 EFLAGS: 00000202\n[ 662.816065] RAX: ff280805df140000 RBX: 0000000000000002 RCX: 000000000000001f\n[ 662.816067] RDX: 0000009a52da2d08 RSI: ffffffff93f8240b RDI: ffffffff93f53ee7\n[ 662.816068] RBP: ff5e2bd11ff41928 R08: 0000000000000000 R09: 000000000002f8c0\n[ 662.816070] R10: 0000010c3f18e2cf R11: 000000000000000f R12: 0000009a52da2d08\n[ 662.816071] R13: ffffffff94ad7e20 R14: 0000000000000002 R15: 0000000000000000\n[ 662.816075] cpuidle_enter+0x29/0x40\n[ 662.816077] do_idle+0x261/0x2b0\n[ 662.816080] cpu_startup_entry+0x19/0x20\n[ 662.816083] start_secondary+0x114/0x150\n[ 662.816087] secondary_startup_64_no_verify+0xd5/0xdb\n[ 662.816091] </TASK>\n[ 662.816169] bad: scheduling from the idle thread!\n\nThe correct place to unplug the aux devices for a reset is in the\nprepare_for_reset function, as this is a common place for all reset flows.\nIt also has built in protection from being called twice in a single reset\ninstance before the aux devices are replugged.

In the Linux kernel, the following vulnerability has been resolved:\n\nice: Fix crash by keep old cfg when update TCs more than queues\n\nThere are problems if allocated queues less than Traffic Classes.\n\nCommit a632b2a4c920 ("ice: ethtool: Prohibit improper channel config\nfor DCB") already disallow setting less queues than TCs.\n\nAnother case is if we first set less queues, and later update more TCs\nconfig due to LLDP, ice_vsi_cfg_tc() will failed but left dirty\nnum_txq/rxq and tc_cfg in vsi, that will cause invalid pointer access.\n\n[ 95.968089] ice 0000:3b:00.1: More TCs defined than queues/rings allocated.\n[ 95.968092] ice 0000:3b:00.1: Trying to use more Rx queues (8), than were allocated (1)!\n[ 95.968093] ice 0000:3b:00.1: Failed to config TC for VSI index: 0\n[ 95.969621] general protection fault: 0000 [#1] SMP NOPTI\n[ 95.969705] CPU: 1 PID: 58405 Comm: lldpad Kdump: loaded Tainted: G U W O --------- -t - 4.18.0 #1\n[ 95.969867] Hardware name: O.E.M/BC11SPSCB10, BIOS 8.23 12/30/2021\n[ 95.969992] RIP: 0010:devm_kmalloc+0xa/0x60\n[ 95.970052] Code: 5c ff ff ff 31 c0 5b 5d 41 5c c3 b8 f4 ff ff ff eb f4 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 89 d1 <8b> 97 60 02 00 00 48 8d 7e 18 48 39 f7 72 3f 55 89 ce 53 48 8b 4c\n[ 95.970344] RSP: 0018:ffffc9003f553888 EFLAGS: 00010206\n[ 95.970425] RAX: dead000000000200 RBX: ffffea003c425b00 RCX: 00000000006080c0\n[ 95.970536] RDX: 00000000006080c0 RSI: 0000000000000200 RDI: dead000000000200\n[ 95.970648] RBP: dead000000000200 R08: 00000000000463c0 R09: ffff888ffa900000\n[ 95.970760] R10: 0000000000000000 R11: 0000000000000002 R12: ffff888ff6b40100\n[ 95.970870] R13: ffff888ff6a55018 R14: 0000000000000000 R15: ffff888ff6a55460\n[ 95.970981] FS: 00007f51b7d24700(0000) GS:ffff88903ee80000(0000) knlGS:0000000000000000\n[ 95.971108] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 95.971197] CR2: 00007fac5410d710 CR3: 0000000f2c1de002 CR4: 00000000007606e0\n[ 95.971309] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 95.971419] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 95.971530] PKRU: 55555554\n[ 95.971573] Call Trace:\n[ 95.971622] ice_setup_rx_ring+0x39/0x110 [ice]\n[ 95.971695] ice_vsi_setup_rx_rings+0x54/0x90 [ice]\n[ 95.971774] ice_vsi_open+0x25/0x120 [ice]\n[ 95.971843] ice_open_internal+0xb8/0x1f0 [ice]\n[ 95.971919] ice_ena_vsi+0x4f/0xd0 [ice]\n[ 95.971987] ice_dcb_ena_dis_vsi.constprop.5+0x29/0x90 [ice]\n[ 95.972082] ice_pf_dcb_cfg+0x29a/0x380 [ice]\n[ 95.972154] ice_dcbnl_setets+0x174/0x1b0 [ice]\n[ 95.972220] dcbnl_ieee_set+0x89/0x230\n[ 95.972279] ? dcbnl_ieee_del+0x150/0x150\n[ 95.972341] dcb_doit+0x124/0x1b0\n[ 95.972392] rtnetlink_rcv_msg+0x243/0x2f0\n[ 95.972457] ? dcb_doit+0x14d/0x1b0\n[ 95.972510] ? __kmalloc_node_track_caller+0x1d3/0x280\n[ 95.972591] ? rtnl_calcit.isra.31+0x100/0x100\n[ 95.972661] netlink_rcv_skb+0xcf/0xf0\n[ 95.972720] netlink_unicast+0x16d/0x220\n[ 95.972781] netlink_sendmsg+0x2ba/0x3a0\n[ 95.975891] sock_sendmsg+0x4c/0x50\n[ 95.979032] ___sys_sendmsg+0x2e4/0x300\n[ 95.982147] ? kmem_cache_alloc+0x13e/0x190\n[ 95.985242] ? __wake_up_common_lock+0x79/0x90\n[ 95.988338] ? __check_object_size+0xac/0x1b0\n[ 95.991440] ? _copy_to_user+0x22/0x30\n[ 95.994539] ? move_addr_to_user+0xbb/0xd0\n[ 95.997619] ? __sys_sendmsg+0x53/0x80\n[ 96.000664] __sys_sendmsg+0x53/0x80\n[ 96.003747] do_syscall_64+0x5b/0x1d0\n[ 96.006862] entry_SYSCALL_64_after_hwframe+0x65/0xca\n\nOnly update num_txq/rxq when passed check, and restore tc_cfg if setup\nqueue map failed.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Fix memory leak in __qlt_24xx_handle_abts()\n\nCommit 8f394da36a36 ("scsi: qla2xxx: Drop TARGET_SCF_LOOKUP_LUN_FROM_TAG")\nmade the __qlt_24xx_handle_abts() function return early if\ntcm_qla2xxx_find_cmd_by_tag() didn't find a command, but it missed to clean\nup the allocated memory for the management command.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm/slab_common: fix possible double free of kmem_cache\n\nWhen doing slub_debug test, kfence's 'test_memcache_typesafe_by_rcu'\nkunit test case cause a use-after-free error:\n\n BUG: KASAN: use-after-free in kobject_del+0x14/0x30\n Read of size 8 at addr ffff888007679090 by task kunit_try_catch/261\n\n CPU: 1 PID: 261 Comm: kunit_try_catch Tainted: G B N 6.0.0-rc5-next-20220916 #17\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n Call Trace:\n <TASK>\n dump_stack_lvl+0x34/0x48\n print_address_description.constprop.0+0x87/0x2a5\n print_report+0x103/0x1ed\n kasan_report+0xb7/0x140\n kobject_del+0x14/0x30\n kmem_cache_destroy+0x130/0x170\n test_exit+0x1a/0x30\n kunit_try_run_case+0xad/0xc0\n kunit_generic_run_threadfn_adapter+0x26/0x50\n kthread+0x17b/0x1b0\n </TASK>\n\nThe cause is inside kmem_cache_destroy():\n\nkmem_cache_destroy\n acquire lock/mutex\n shutdown_cache\n schedule_work(kmem_cache_release) (if RCU flag set)\n release lock/mutex\n kmem_cache_release (if RCU flag not set)\n\nIn some certain timing, the scheduled work could be run before\nthe next RCU flag checking, which can then get a wrong value\nand lead to double kmem_cache_release().\n\nFix it by caching the RCU flag inside protected area, just like 'refcnt'

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: fix nft_counters_enabled underflow at nf_tables_addchain()\n\nsyzbot is reporting underflow of nft_counters_enabled counter at\nnf_tables_addchain() [1], for commit 43eb8949cfdffa76 ("netfilter:\nnf_tables: do not leave chain stats enabled on error") missed that\nnf_tables_chain_destroy() after nft_basechain_init() in the error path of\nnf_tables_addchain() decrements the counter because nft_basechain_init()\nmakes nft_is_base_chain() return true by setting NFT_CHAIN_BASE flag.\n\nIncrement the counter immediately after returning from\nnft_basechain_init().

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ebtables: fix memory leak when blob is malformed\n\nThe bug fix was incomplete, it "replaced" crash with a memory leak.\nThe old code had an assignment to "ret" embedded into the conditional,\nrestore this.

In the Linux kernel, the following vulnerability has been resolved:\n\nbonding: fix NULL deref in bond_rr_gen_slave_id\n\nFix a NULL dereference of the struct bonding.rr_tx_counter member because\nif a bond is initially created with an initial mode != zero (Round Robin)\nthe memory required for the counter is never created and when the mode is\nchanged there is never any attempt to verify the memory is allocated upon\nswitching modes.\n\nThis causes the following Oops on an aarch64 machine:\n [ 334.686773] Unable to handle kernel paging request at virtual address ffff2c91ac905000\n [ 334.694703] Mem abort info:\n [ 334.697486] ESR = 0x0000000096000004\n [ 334.701234] EC = 0x25: DABT (current EL), IL = 32 bits\n [ 334.706536] SET = 0, FnV = 0\n [ 334.709579] EA = 0, S1PTW = 0\n [ 334.712719] FSC = 0x04: level 0 translation fault\n [ 334.717586] Data abort info:\n [ 334.720454] ISV = 0, ISS = 0x00000004\n [ 334.724288] CM = 0, WnR = 0\n [ 334.727244] swapper pgtable: 4k pages, 48-bit VAs, pgdp=000008044d662000\n [ 334.733944] [ffff2c91ac905000] pgd=0000000000000000, p4d=0000000000000000\n [ 334.740734] Internal error: Oops: 96000004 [#1] SMP\n [ 334.745602] Modules linked in: bonding tls veth rfkill sunrpc arm_spe_pmu vfat fat acpi_ipmi ipmi_ssif ixgbe igb i40e mdio ipmi_devintf ipmi_msghandler arm_cmn arm_dsu_pmu cppc_cpufreq acpi_tad fuse zram crct10dif_ce ast ghash_ce sbsa_gwdt nvme drm_vram_helper drm_ttm_helper nvme_core ttm xgene_hwmon\n [ 334.772217] CPU: 7 PID: 2214 Comm: ping Not tainted 6.0.0-rc4-00133-g64ae13ed4784 #4\n [ 334.779950] Hardware name: GIGABYTE R272-P31-00/MP32-AR1-00, BIOS F18v (SCP: 1.08.20211002) 12/01/2021\n [ 334.789244] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n [ 334.796196] pc : bond_rr_gen_slave_id+0x40/0x124 [bonding]\n [ 334.801691] lr : bond_xmit_roundrobin_slave_get+0x38/0xdc [bonding]\n [ 334.807962] sp : ffff8000221733e0\n [ 334.811265] x29: ffff8000221733e0 x28: ffffdbac8572d198 x27: ffff80002217357c\n [ 334.818392] x26: 000000000000002a x25: ffffdbacb33ee000 x24: ffff07ff980fa000\n [ 334.825519] x23: ffffdbacb2e398ba x22: ffff07ff98102000 x21: ffff07ff981029c0\n [ 334.832646] x20: 0000000000000001 x19: ffff07ff981029c0 x18: 0000000000000014\n [ 334.839773] x17: 0000000000000000 x16: ffffdbacb1004364 x15: 0000aaaabe2f5a62\n [ 334.846899] x14: ffff07ff8e55d968 x13: ffff07ff8e55db30 x12: 0000000000000000\n [ 334.854026] x11: ffffdbacb21532e8 x10: 0000000000000001 x9 : ffffdbac857178ec\n [ 334.861153] x8 : ffff07ff9f6e5a28 x7 : 0000000000000000 x6 : 000000007c2b3742\n [ 334.868279] x5 : ffff2c91ac905000 x4 : ffff2c91ac905000 x3 : ffff07ff9f554400\n [ 334.875406] x2 : ffff2c91ac905000 x1 : 0000000000000001 x0 : ffff07ff981029c0\n [ 334.882532] Call trace:\n [ 334.884967] bond_rr_gen_slave_id+0x40/0x124 [bonding]\n [ 334.890109] bond_xmit_roundrobin_slave_get+0x38/0xdc [bonding]\n [ 334.896033] __bond_start_xmit+0x128/0x3a0 [bonding]\n [ 334.901001] bond_start_xmit+0x54/0xb0 [bonding]\n [ 334.905622] dev_hard_start_xmit+0xb4/0x220\n [ 334.909798] __dev_queue_xmit+0x1a0/0x720\n [ 334.913799] arp_xmit+0x3c/0xbc\n [ 334.916932] arp_send_dst+0x98/0xd0\n [ 334.920410] arp_solicit+0xe8/0x230\n [ 334.923888] neigh_probe+0x60/0xb0\n [ 334.927279] __neigh_event_send+0x3b0/0x470\n [ 334.931453] neigh_resolve_output+0x70/0x90\n [ 334.935626] ip_finish_output2+0x158/0x514\n [ 334.939714] __ip_finish_output+0xac/0x1a4\n [ 334.943800] ip_finish_output+0x40/0xfc\n [ 334.947626] ip_output+0xf8/0x1a4\n [ 334.950931] ip_send_skb+0x5c/0x100\n [ 334.954410] ip_push_pending_frames+0x3c/0x60\n [ 334.958758] raw_sendmsg+0x458/0x6d0\n [ 334.962325] inet_sendmsg+0x50/0x80\n [ 334.965805] sock_sendmsg+0x60/0x6c\n [ 334.969286] __sys_sendto+0xc8/0x134\n [ 334.972853] __arm64_sys_sendto+0x34/0x4c\n [ 334.976854] invoke_syscall+0x78/0x100\n [ 334.980594] el0_svc_common.constprop.0+0x4c/0xf4\n [ 334.985287] do_el0_svc+0x38/0x4c\n [ 334.988591] el0_svc+0x34/0x10c\n [ 334.991724] el0t_64_sync_handler+0x11c/0x150\n [ 334.996072] el0t_64_sync+0x190/0x194\n [ 334.999726] Code: b9001062 f9403c02 d53cd044 8b040042 (b8210040)\n [ 335.005810] ---[ end trace 0000000000000000 ]---\n [ 335.010416] Kernel panic - not syncing: Oops: Fatal exception in interrupt\n [ 335.017279] SMP: stopping secondary CPUs\n [ 335.021374] Kernel Offset: 0x5baca8eb0000 from 0xffff800008000000\n [ 335.027456] PHYS_OFFSET: 0x80000000\n [ 335.030932] CPU features: 0x0000,0085c029,19805c82\n [ 335.035713] Memory Limit: none\n [ 335.038756] Rebooting in 180 seconds..\n\nThe fix is to allocate the memory in bond_open() which is guaranteed\nto be called before any packets are processed.

In the Linux kernel, the following vulnerability has been resolved:\n\ncgroup: cgroup_get_from_id() must check the looked-up kn is a directory\n\ncgroup has to be one kernfs dir, otherwise kernel panic is caused,\nespecially cgroup id is provide from userspace.

In the Linux kernel, the following vulnerability has been resolved:\n\nbnxt: prevent skb UAF after handing over to PTP worker\n\nWhen reading the timestamp is required bnxt_tx_int() hands\nover the ownership of the completed skb to the PTP worker.\nThe skb should not be used afterwards, as the worker may\nrun before the rest of our code and free the skb, leading\nto a use-after-free.\n\nSince dev_kfree_skb_any() accepts NULL make the loss of\nownership more obvious and set skb to NULL.

In the Linux kernel, the following vulnerability has been resolved:\n\ns390/dasd: fix Oops in dasd_alias_get_start_dev due to missing pavgroup\n\nFix Oops in dasd_alias_get_start_dev() function caused by the pavgroup\npointer being NULL.\n\nThe pavgroup pointer is checked on the entrance of the function but\nwithout the lcu->lock being held. Therefore there is a race window\nbetween dasd_alias_get_start_dev() and _lcu_update() which sets\npavgroup to NULL with the lcu->lock held.\n\nFix by checking the pavgroup pointer with lcu->lock held.

In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix bug in extents parsing when eh_entries == 0 and eh_depth > 0\n\nWhen walking through an inode extents, the ext4_ext_binsearch_idx() function\nassumes that the extent header has been previously validated. However, there\nare no checks that verify that the number of entries (eh->eh_entries) is\nnon-zero when depth is > 0. And this will lead to problems because the\nEXT_FIRST_INDEX() and EXT_LAST_INDEX() will return garbage and result in this:\n\n[ 135.245946] ------------[ cut here ]------------\n[ 135.247579] kernel BUG at fs/ext4/extents.c:2258!\n[ 135.249045] invalid opcode: 0000 [#1] PREEMPT SMP\n[ 135.250320] CPU: 2 PID: 238 Comm: tmp118 Not tainted 5.19.0-rc8+ #4\n[ 135.252067] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014\n[ 135.255065] RIP: 0010:ext4_ext_map_blocks+0xc20/0xcb0\n[ 135.256475] Code:\n[ 135.261433] RSP: 0018:ffffc900005939f8 EFLAGS: 00010246\n[ 135.262847] RAX: 0000000000000024 RBX: ffffc90000593b70 RCX: 0000000000000023\n[ 135.264765] RDX: ffff8880038e5f10 RSI: 0000000000000003 RDI: ffff8880046e922c\n[ 135.266670] RBP: ffff8880046e9348 R08: 0000000000000001 R09: ffff888002ca580c\n[ 135.268576] R10: 0000000000002602 R11: 0000000000000000 R12: 0000000000000024\n[ 135.270477] R13: 0000000000000000 R14: 0000000000000024 R15: 0000000000000000\n[ 135.272394] FS: 00007fdabdc56740(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000\n[ 135.274510] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 135.276075] CR2: 00007ffc26bd4f00 CR3: 0000000006261004 CR4: 0000000000170ea0\n[ 135.277952] Call Trace:\n[ 135.278635] <TASK>\n[ 135.279247] ? preempt_count_add+0x6d/0xa0\n[ 135.280358] ? percpu_counter_add_batch+0x55/0xb0\n[ 135.281612] ? _raw_read_unlock+0x18/0x30\n[ 135.282704] ext4_map_blocks+0x294/0x5a0\n[ 135.283745] ? xa_load+0x6f/0xa0\n[ 135.284562] ext4_mpage_readpages+0x3d6/0x770\n[ 135.285646] read_pages+0x67/0x1d0\n[ 135.286492] ? folio_add_lru+0x51/0x80\n[ 135.287441] page_cache_ra_unbounded+0x124/0x170\n[ 135.288510] filemap_get_pages+0x23d/0x5a0\n[ 135.289457] ? path_openat+0xa72/0xdd0\n[ 135.290332] filemap_read+0xbf/0x300\n[ 135.291158] ? _raw_spin_lock_irqsave+0x17/0x40\n[ 135.292192] new_sync_read+0x103/0x170\n[ 135.293014] vfs_read+0x15d/0x180\n[ 135.293745] ksys_read+0xa1/0xe0\n[ 135.294461] do_syscall_64+0x3c/0x80\n[ 135.295284] entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nThis patch simply adds an extra check in __ext4_ext_check(), verifying that\neh_entries is not 0 when eh_depth is > 0.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: systemport: Add global locking for descriptor lifecycle\n\nThe descriptor list is a shared resource across all of the transmit queues, and\nthe locking mechanism used today only protects concurrency across a given\ntransmit queue between the transmit and reclaiming. This creates an opportunity\nfor the SYSTEMPORT hardware to work on corrupted descriptors if we have\nmultiple producers at once which is the case when using multiple transmit\nqueues.\n\nThis was particularly noticeable when using multiple flows/transmit queues and\nit showed up in interesting ways in that UDP packets would get a correct UDP\nheader checksum being calculated over an incorrect packet length. Similarly TCP\npackets would get an equally correct checksum computed by the hardware over an\nincorrect packet length.\n\nThe SYSTEMPORT hardware maintains an internal descriptor list that it re-arranges\nwhen the driver produces a new descriptor anytime it writes to the\nWRITE_PORT_{HI,LO} registers, there is however some delay in the hardware to\nre-organize its descriptors and it is possible that concurrent TX queues\neventually break this internal allocation scheme to the point where the\nlength/status part of the descriptor gets used for an incorrect data buffer.\n\nThe fix is to impose a global serialization for all TX queues in the short\nsection where we are writing to the WRITE_PORT_{HI,LO} registers which solves\nthe corruption even with multiple concurrent TX queues being used.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: dwmac-rk: fix oob read in rk_gmac_setup\n\nKASAN reports an out-of-bounds read in rk_gmac_setup on the line:\n\n while (ops->regs[i]) {\n\nThis happens for most platforms since the regs flexible array member is\nempty, so the memory after the ops structure is being read here. It\nseems that mostly this happens to contain zero anyway, so we get lucky\nand everything still works.\n\nTo avoid adding redundant data to nearly all the ops structures, add a\nnew flag to indicate whether the regs field is valid and avoid this loop\nwhen it is not.

In the Linux kernel, the following vulnerability has been resolved:\n\niocost: Fix divide-by-zero on donation from low hweight cgroup\n\nThe donation calculation logic assumes that the donor has non-zero\nafter-donation hweight, so the lowest active hweight a donating cgroup can\nhave is 2 so that it can donate 1 while keeping the other 1 for itself.\nEarlier, we only donated from cgroups with sizable surpluses so this\ncondition was always true. However, with the precise donation algorithm\nimplemented, f1de2439ec43 ("blk-iocost: revamp donation amount\ndetermination") made the donation amount calculation exact enabling even low\nhweight cgroups to donate.\n\nThis means that in rare occasions, a cgroup with active hweight of 1 can\nenter donation calculation triggering the following warning and then a\ndivide-by-zero oops.\n\n WARNING: CPU: 4 PID: 0 at block/blk-iocost.c:1928 transfer_surpluses.cold+0x0/0x53 [884/94867]\n ...\n RIP: 0010:transfer_surpluses.cold+0x0/0x53\n Code: 92 ff 48 c7 c7 28 d1 ab b5 65 48 8b 34 25 00 ae 01 00 48 81 c6 90 06 00 00 e8 8b 3f fe ff 48 c7 c0 ea ff ff ff e9 95 ff 92 ff <0f> 0b 48 c7 c7 30 da ab b5 e8 71 3f fe ff 4c 89 e8 4d 85 ed 74 0\n4\n ...\n Call Trace:\n <IRQ>\n ioc_timer_fn+0x1043/0x1390\n call_timer_fn+0xa1/0x2c0\n __run_timers.part.0+0x1ec/0x2e0\n run_timer_softirq+0x35/0x70\n ...\n iocg: invalid donation weights in /a/b: active=1 donating=1 after=0\n\nFix it by excluding cgroups w/ active hweight < 2 from donating. Excluding\nthese extreme low hweight donations shouldn't affect work conservation in\nany meaningful way.

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: mxl111sf: change mutex_init() location\n\nSyzbot reported, that mxl111sf_ctrl_msg() uses uninitialized\nmutex. The problem was in wrong mutex_init() location.\n\nPrevious mutex_init(&state->msg_lock) call was in ->init() function, but\ndvb_usbv2_init() has this order of calls:\n\n dvb_usbv2_init()\n dvb_usbv2_adapter_init()\n dvb_usbv2_adapter_frontend_init()\n props->frontend_attach()\n\n props->init()\n\nSince mxl111sf_* devices call mxl111sf_ctrl_msg() in ->frontend_attach()\ninternally we need to initialize state->msg_lock before\nfrontend_attach(). To achieve it, ->probe() call added to all mxl111sf_*\ndevices, which will simply initiaize mutex.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: nexthop: fix null pointer dereference when IPv6 is not enabled\n\nWhen we try to add an IPv6 nexthop and IPv6 is not enabled\n(!CONFIG_IPV6) we'll hit a NULL pointer dereference[1] in the error path\nof nh_create_ipv6() due to calling ipv6_stub->fib6_nh_release. The bug\nhas been present since the beginning of IPv6 nexthop gateway support.\nCommit 1aefd3de7bc6 ("ipv6: Add fib6_nh_init and release to stubs") tells\nus that only fib6_nh_init has a dummy stub because fib6_nh_release should\nnot be called if fib6_nh_init returns an error, but the commit below added\na call to ipv6_stub->fib6_nh_release in its error path. To fix it return\nthe dummy stub's -EAFNOSUPPORT error directly without calling\nipv6_stub->fib6_nh_release in nh_create_ipv6()'s error path.\n\n[1]\n Output is a bit truncated, but it clearly shows the error.\n BUG: kernel NULL pointer dereference, address: 000000000000000000\n #PF: supervisor instruction fetch in kernel modede\n #PF: error_code(0x0010) - not-present pagege\n PGD 0 P4D 0\n Oops: 0010 [#1] PREEMPT SMP NOPTI\n CPU: 4 PID: 638 Comm: ip Kdump: loaded Not tainted 5.16.0-rc1+ #446\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/01/2014\n RIP: 0010:0x0\n Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.\n RSP: 0018:ffff888109f5b8f0 EFLAGS: 00010286^Ac\n RAX: 0000000000000000 RBX: ffff888109f5ba28 RCX: 0000000000000000\n RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8881008a2860\n RBP: ffff888109f5b9d8 R08: 0000000000000000 R09: 0000000000000000\n R10: ffff888109f5b978 R11: ffff888109f5b948 R12: 00000000ffffff9f\n R13: ffff8881008a2a80 R14: ffff8881008a2860 R15: ffff8881008a2840\n FS: 00007f98de70f100(0000) GS:ffff88822bf00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: ffffffffffffffd6 CR3: 0000000100efc000 CR4: 00000000000006e0\n Call Trace:\n <TASK>\n nh_create_ipv6+0xed/0x10c\n rtm_new_nexthop+0x6d7/0x13f3\n ? check_preemption_disabled+0x3d/0xf2\n ? lock_is_held_type+0xbe/0xfd\n rtnetlink_rcv_msg+0x23f/0x26a\n ? check_preemption_disabled+0x3d/0xf2\n ? rtnl_calcit.isra.0+0x147/0x147\n netlink_rcv_skb+0x61/0xb2\n netlink_unicast+0x100/0x187\n netlink_sendmsg+0x37f/0x3a0\n ? netlink_unicast+0x187/0x187\n sock_sendmsg_nosec+0x67/0x9b\n ____sys_sendmsg+0x19d/0x1f9\n ? copy_msghdr_from_user+0x4c/0x5e\n ? rcu_read_lock_any_held+0x2a/0x78\n ___sys_sendmsg+0x6c/0x8c\n ? asm_sysvec_apic_timer_interrupt+0x12/0x20\n ? lockdep_hardirqs_on+0xd9/0x102\n ? sockfd_lookup_light+0x69/0x99\n __sys_sendmsg+0x50/0x6e\n do_syscall_64+0xcb/0xf2\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n RIP: 0033:0x7f98dea28914\n Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b5 0f 1f 80 00 00 00 00 48 8d 05 e9 5d 0c 00 8b 00 85 c0 75 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 41 54 41 89 d4 55 48 89 f5 53\n RSP: 002b:00007fff859f5e68 EFLAGS: 00000246 ORIG_RAX: 000000000000002e2e\n RAX: ffffffffffffffda RBX: 00000000619cb810 RCX: 00007f98dea28914\n RDX: 0000000000000000 RSI: 00007fff859f5ed0 RDI: 0000000000000003\n RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000008\n R10: fffffffffffffce6 R11: 0000000000000246 R12: 0000000000000001\n R13: 000055c0097ae520 R14: 000055c0097957fd R15: 00007fff859f63a0\n </TASK>\n Modules linked in: bridge stp llc bonding virtio_net

In the Linux kernel, the following vulnerability has been resolved:\n\nstaging: rtl8192e: Fix use after free in _rtl92e_pci_disconnect()\n\nThe free_rtllib() function frees the "dev" pointer so there is use\nafter free on the next line. Re-arrange things to avoid that.

In the Linux kernel, the following vulnerability has been resolved:\n\nstaging: r8188eu: fix a memory leak in rtw_wx_read32()\n\nFree "ptmp" before returning -EINVAL.

In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: fail cancellation for EXITING tasks\n\nWARNING: CPU: 1 PID: 20 at fs/io_uring.c:6269 io_try_cancel_userdata+0x3c5/0x640 fs/io_uring.c:6269\nCPU: 1 PID: 20 Comm: kworker/1:0 Not tainted 5.16.0-rc1-syzkaller #0\nWorkqueue: events io_fallback_req_func\nRIP: 0010:io_try_cancel_userdata+0x3c5/0x640 fs/io_uring.c:6269\nCall Trace:\n <TASK>\n io_req_task_link_timeout+0x6b/0x1e0 fs/io_uring.c:6886\n io_fallback_req_func+0xf9/0x1ae fs/io_uring.c:1334\n process_one_work+0x9b2/0x1690 kernel/workqueue.c:2298\n worker_thread+0x658/0x11f0 kernel/workqueue.c:2445\n kthread+0x405/0x4f0 kernel/kthread.c:327\n ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295\n </TASK>\n\nWe need original task's context to do cancellations, so if it's dying\nand the callback is executed in a fallback mode, fail the cancellation\nattempt.

In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix memleak in get_file_stream_info()\n\nFix memleak in get_file_stream_info()

In the Linux kernel, the following vulnerability has been resolved:\n\nproc/vmcore: fix clearing user buffer by properly using clear_user()\n\nTo clear a user buffer we cannot simply use memset, we have to use\nclear_user(). With a virtio-mem device that registers a vmcore_cb and\nhas some logically unplugged memory inside an added Linux memory block,\nI can easily trigger a BUG by copying the vmcore via "cp":\n\n systemd[1]: Starting Kdump Vmcore Save Service...\n kdump[420]: Kdump is using the default log level(3).\n kdump[453]: saving to /sysroot/var/crash/127.0.0.1-2021-11-11-14:59:22/\n kdump[458]: saving vmcore-dmesg.txt to /sysroot/var/crash/127.0.0.1-2021-11-11-14:59:22/\n kdump[465]: saving vmcore-dmesg.txt complete\n kdump[467]: saving vmcore\n BUG: unable to handle page fault for address: 00007f2374e01000\n #PF: supervisor write access in kernel mode\n #PF: error_code(0x0003) - permissions violation\n PGD 7a523067 P4D 7a523067 PUD 7a528067 PMD 7a525067 PTE 800000007048f867\n Oops: 0003 [#1] PREEMPT SMP NOPTI\n CPU: 0 PID: 468 Comm: cp Not tainted 5.15.0+ #6\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-27-g64f37cc530f1-prebuilt.qemu.org 04/01/2014\n RIP: 0010:read_from_oldmem.part.0.cold+0x1d/0x86\n Code: ff ff ff e8 05 ff fe ff e9 b9 e9 7f ff 48 89 de 48 c7 c7 38 3b 60 82 e8 f1 fe fe ff 83 fd 08 72 3c 49 8d 7d 08 4c 89 e9 89 e8 <49> c7 45 00 00 00 00 00 49 c7 44 05 f8 00 00 00 00 48 83 e7 f81\n RSP: 0018:ffffc9000073be08 EFLAGS: 00010212\n RAX: 0000000000001000 RBX: 00000000002fd000 RCX: 00007f2374e01000\n RDX: 0000000000000001 RSI: 00000000ffffdfff RDI: 00007f2374e01008\n RBP: 0000000000001000 R08: 0000000000000000 R09: ffffc9000073bc50\n R10: ffffc9000073bc48 R11: ffffffff829461a8 R12: 000000000000f000\n R13: 00007f2374e01000 R14: 0000000000000000 R15: ffff88807bd421e8\n FS: 00007f2374e12140(0000) GS:ffff88807f000000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f2374e01000 CR3: 000000007a4aa000 CR4: 0000000000350eb0\n Call Trace:\n read_vmcore+0x236/0x2c0\n proc_reg_read+0x55/0xa0\n vfs_read+0x95/0x190\n ksys_read+0x4f/0xc0\n do_syscall_64+0x3b/0x90\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nSome x86-64 CPUs have a CPU feature called "Supervisor Mode Access\nPrevention (SMAP)", which is used to detect wrong access from the kernel\nto user buffers like this: SMAP triggers a permissions violation on\nwrong access. In the x86-64 variant of clear_user(), SMAP is properly\nhandled via clac()+stac().\n\nTo fix, properly use clear_user() when we're dealing with a user buffer.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: mpt3sas: Fix kernel panic during drive powercycle test\n\nWhile looping over shost's sdev list it is possible that one\nof the drives is getting removed and its sas_target object is\nfreed but its sdev object remains intact.\n\nConsequently, a kernel panic can occur while the driver is trying to access\nthe sas_address field of sas_target object without also checking the\nsas_target object for NULL.

In the Linux kernel, the following vulnerability has been resolved:\n\ni2c: virtio: disable timeout handling\n\nIf a timeout is hit, it can result is incorrect data on the I2C bus\nand/or memory corruptions in the guest since the device can still be\noperating on the buffers it was given while the guest has freed them.\n\nHere is, for example, the start of a slub_debug splat which was\ntriggered on the next transfer after one transfer was forced to timeout\nby setting a breakpoint in the backend (rust-vmm/vhost-device):\n\n BUG kmalloc-1k (Not tainted): Poison overwritten\n First byte 0x1 instead of 0x6b\n Allocated in virtio_i2c_xfer+0x65/0x35c age=350 cpu=0 pid=29\n __kmalloc+0xc2/0x1c9\n virtio_i2c_xfer+0x65/0x35c\n __i2c_transfer+0x429/0x57d\n i2c_transfer+0x115/0x134\n i2cdev_ioctl_rdwr+0x16a/0x1de\n i2cdev_ioctl+0x247/0x2ed\n vfs_ioctl+0x21/0x30\n sys_ioctl+0xb18/0xb41\n Freed in virtio_i2c_xfer+0x32e/0x35c age=244 cpu=0 pid=29\n kfree+0x1bd/0x1cc\n virtio_i2c_xfer+0x32e/0x35c\n __i2c_transfer+0x429/0x57d\n i2c_transfer+0x115/0x134\n i2cdev_ioctl_rdwr+0x16a/0x1de\n i2cdev_ioctl+0x247/0x2ed\n vfs_ioctl+0x21/0x30\n sys_ioctl+0xb18/0xb41\n\nThere is no simple fix for this (the driver would have to always create\nbounce buffers and hold on to them until the device eventually returns\nthe buffers), so just disable the timeout support for now.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: Disable Tx queues when reconfiguring the interface\n\nThe Tx queues were not disabled in situations where the driver needed to\nstop the interface to apply a new configuration. This could result in a\nkernel panic when doing any of the 3 following actions:\n* reconfiguring the number of queues (ethtool -L)\n* reconfiguring the size of the ring buffers (ethtool -G)\n* installing/removing an XDP program (ip l set dev ethX xdp)\n\nPrevent the panic by making sure netif_tx_disable is called when stopping\nan interface.\n\nWithout this patch, the following kernel panic can be observed when doing\nany of the actions above:\n\nUnable to handle kernel paging request at virtual address ffff80001238d040\n[....]\n Call trace:\n dwmac4_set_addr+0x8/0x10\n dev_hard_start_xmit+0xe4/0x1ac\n sch_direct_xmit+0xe8/0x39c\n __dev_queue_xmit+0x3ec/0xaf0\n dev_queue_xmit+0x14/0x20\n[...]\n[ end trace 0000000000000002 ]---

In the Linux kernel, the following vulnerability has been resolved:\n\nethtool: ioctl: fix potential NULL deref in ethtool_set_coalesce()\n\nethtool_set_coalesce() now uses both the .get_coalesce() and\n.set_coalesce() callbacks. But the check for their availability is\nbuggy, so changing the coalesce settings on a device where the driver\nprovides only _one_ of the callbacks results in a NULL pointer\ndereference instead of an -EOPNOTSUPP.\n\nFix the condition so that the availability of both callbacks is\nensured. This also matches the netlink code.\n\nNote that reproducing this requires some effort - it only affects the\nlegacy ioctl path, and needs a specific combination of driver options:\n- have .get_coalesce() and .coalesce_supported but no\n .set_coalesce(), or\n- have .set_coalesce() but no .get_coalesce(). Here eg. ethtool doesn't\n cause the crash as it first attempts to call ethtool_get_coalesce()\n and bails out on error.

In the Linux kernel, the following vulnerability has been resolved:\n\nvdpa_sim: avoid putting an uninitialized iova_domain\n\nThe system will crash if we put an uninitialized iova_domain, this\ncould happen when an error occurs before initializing the iova_domain\nin vdpasim_create().\n\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n...\nRIP: 0010:__cpuhp_state_remove_instance+0x96/0x1c0\n...\nCall Trace:\n <TASK>\n put_iova_domain+0x29/0x220\n vdpasim_free+0xd1/0x120 [vdpa_sim]\n vdpa_release_dev+0x21/0x40 [vdpa]\n device_release+0x33/0x90\n kobject_release+0x63/0x160\n vdpasim_create+0x127/0x2a0 [vdpa_sim]\n vdpasim_net_dev_add+0x7d/0xfe [vdpa_sim_net]\n vdpa_nl_cmd_dev_add_set_doit+0xe1/0x1a0 [vdpa]\n genl_family_rcv_msg_doit+0x112/0x140\n genl_rcv_msg+0xdf/0x1d0\n ...\n\nSo we must make sure the iova_domain is already initialized before\nput it.\n\nIn addition, we may get the following warning in this case:\nWARNING: ... drivers/iommu/iova.c:344 iova_cache_put+0x58/0x70\n\nSo we must make sure the iova_cache_put() is invoked only if the\niova_cache_get() is already invoked. Let's fix it together.

In the Linux kernel, the following vulnerability has been resolved:\n\nsata_fsl: fix UAF in sata_fsl_port_stop when rmmod sata_fsl\n\nWhen the `rmmod sata_fsl.ko` command is executed in the PPC64 GNU/Linux,\na bug is reported:\n ==================================================================\n BUG: Unable to handle kernel data access on read at 0x80000800805b502c\n Oops: Kernel access of bad area, sig: 11 [#1]\n NIP [c0000000000388a4] .ioread32+0x4/0x20\n LR [80000000000c6034] .sata_fsl_port_stop+0x44/0xe0 [sata_fsl]\n Call Trace:\n .free_irq+0x1c/0x4e0 (unreliable)\n .ata_host_stop+0x74/0xd0 [libata]\n .release_nodes+0x330/0x3f0\n .device_release_driver_internal+0x178/0x2c0\n .driver_detach+0x64/0xd0\n .bus_remove_driver+0x70/0xf0\n .driver_unregister+0x38/0x80\n .platform_driver_unregister+0x14/0x30\n .fsl_sata_driver_exit+0x18/0xa20 [sata_fsl]\n .__se_sys_delete_module+0x1ec/0x2d0\n .system_call_exception+0xfc/0x1f0\n system_call_common+0xf8/0x200\n ==================================================================\n\nThe triggering of the BUG is shown in the following stack:\n\ndriver_detach\n device_release_driver_internal\n __device_release_driver\n drv->remove(dev) --> platform_drv_remove/platform_remove\n drv->remove(dev) --> sata_fsl_remove\n iounmap(host_priv->hcr_base); <---- unmap\n kfree(host_priv); <---- free\n devres_release_all\n release_nodes\n dr->node.release(dev, dr->data) --> ata_host_stop\n ap->ops->port_stop(ap) --> sata_fsl_port_stop\n ioread32(hcr_base + HCONTROL) <---- UAF\n host->ops->host_stop(host)\n\nThe iounmap(host_priv->hcr_base) and kfree(host_priv) functions should\nnot be executed in drv->remove. These functions should be executed in\nhost_stop after port_stop. Therefore, we move these functions to the\nnew function sata_fsl_host_stop and bind the new function to host_stop.

In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: fix page frag corruption on page fault\n\nSteffen reported a TCP stream corruption for HTTP requests\nserved by the apache web-server using a cifs mount-point\nand memory mapping the relevant file.\n\nThe root cause is quite similar to the one addressed by\ncommit 20eb4f29b602 ("net: fix sk_page_frag() recursion from\nmemory reclaim"). Here the nested access to the task page frag\nis caused by a page fault on the (mmapped) user-space memory\nbuffer coming from the cifs file.\n\nThe page fault handler performs an smb transaction on a different\nsocket, inside the same process context. Since sk->sk_allaction\nfor such socket does not prevent the usage for the task_frag,\nthe nested allocation modify "under the hood" the page frag\nin use by the outer sendmsg call, corrupting the stream.\n\nThe overall relevant stack trace looks like the following:\n\nhttpd 78268 [001] 3461630.850950: probe:tcp_sendmsg_locked:\n ffffffff91461d91 tcp_sendmsg_locked+0x1\n ffffffff91462b57 tcp_sendmsg+0x27\n ffffffff9139814e sock_sendmsg+0x3e\n ffffffffc06dfe1d smb_send_kvec+0x28\n [...]\n ffffffffc06cfaf8 cifs_readpages+0x213\n ffffffff90e83c4b read_pages+0x6b\n ffffffff90e83f31 __do_page_cache_readahead+0x1c1\n ffffffff90e79e98 filemap_fault+0x788\n ffffffff90eb0458 __do_fault+0x38\n ffffffff90eb5280 do_fault+0x1a0\n ffffffff90eb7c84 __handle_mm_fault+0x4d4\n ffffffff90eb8093 handle_mm_fault+0xc3\n ffffffff90c74f6d __do_page_fault+0x1ed\n ffffffff90c75277 do_page_fault+0x37\n ffffffff9160111e page_fault+0x1e\n ffffffff9109e7b5 copyin+0x25\n ffffffff9109eb40 _copy_from_iter_full+0xe0\n ffffffff91462370 tcp_sendmsg_locked+0x5e0\n ffffffff91462370 tcp_sendmsg_locked+0x5e0\n ffffffff91462b57 tcp_sendmsg+0x27\n ffffffff9139815c sock_sendmsg+0x4c\n ffffffff913981f7 sock_write_iter+0x97\n ffffffff90f2cc56 do_iter_readv_writev+0x156\n ffffffff90f2dff0 do_iter_write+0x80\n ffffffff90f2e1c3 vfs_writev+0xa3\n ffffffff90f2e27c do_writev+0x5c\n ffffffff90c042bb do_syscall_64+0x5b\n ffffffff916000ad entry_SYSCALL_64_after_hwframe+0x65\n\nThe cifs filesystem rightfully sets sk_allocations to GFP_NOFS,\nwe can avoid the nesting using the sk page frag for allocation\nlacking the __GFP_FS flag. Do not define an additional mm-helper\nfor that, as this is strictly tied to the sk page frag usage.\n\nv1 -> v2:\n - use a stricted sk_page_frag() check instead of reordering the\n code (Eric)

In the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-af: Fix a memleak bug in rvu_mbox_init()\n\nIn rvu_mbox_init(), mbox_regions is not freed or passed out\nunder the switch-default region, which could lead to a memory leak.\n\nFix this bug by changing 'return err' to 'goto free_regions'.\n\nThis bug was found by a static analyzer. The analysis employs\ndifferential checking to identify inconsistent security operations\n(e.g., checks or kfrees) between two code paths and confirms that the\ninconsistent operations are not recovered in the current function or\nthe callers, so they constitute bugs.\n\nNote that, as a bug found by static analysis, it can be a false\npositive or hard to trigger. Multiple researchers have cross-reviewed\nthe bug.\n\nBuilds with CONFIG_OCTEONTX2_AF=y show no new warnings,\nand our static analyzer no longer warns about this code.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vc4: kms: Add missing drm_crtc_commit_put\n\nCommit 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a\ncommit") introduced a global state for the HVS, with each FIFO storing\nthe current CRTC commit so that we can properly synchronize commits.\n\nHowever, the refcounting was off and we thus ended up leaking the\ndrm_crtc_commit structure every commit. Add a drm_crtc_commit_put to\nprevent the leakage.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vc4: kms: Clear the HVS FIFO commit pointer once done\n\nCommit 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a\ncommit") introduced a wait on the previous commit done on a given HVS\nFIFO.\n\nHowever, we never cleared that pointer once done. Since\ndrm_crtc_commit_put can free the drm_crtc_commit structure directly if\nwe were the last user, this means that it can lead to a use-after free\nif we were to duplicate the state, and that stale pointer would even be\ncopied to the new state.\n\nSet the pointer to NULL once we're done with the wait so that we don't\ncarry over a pointer to a free'd structure.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/devfreq: Fix OPP refcnt leak

In the Linux kernel, the following vulnerability has been resolved:\n\niwlwifi: Fix memory leaks in error handling path\n\nShould an error occur (invalid TLV len or memory allocation failure), the\nmemory already allocated in 'reduce_power_data' should be freed before\nreturning, otherwise it is leaking.

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdnsp: Fix a NULL pointer dereference in cdnsp_endpoint_init()\n\nIn cdnsp_endpoint_init(), cdnsp_ring_alloc() is assigned to pep->ring\nand there is a dereference of it in cdnsp_endpoint_init(), which could\nlead to a NULL pointer dereference on failure of cdnsp_ring_alloc().\n\nFix this bug by adding a check of pep->ring.\n\nThis bug was found by a static analyzer. The analysis employs\ndifferential checking to identify inconsistent security operations\n(e.g., checks or kfrees) between two code paths and confirms that the\ninconsistent operations are not recovered in the current function or\nthe callers, so they constitute bugs.\n\nNote that, as a bug found by static analysis, it can be a false\npositive or hard to trigger. Multiple researchers have cross-reviewed\nthe bug.\n\nBuilds with CONFIG_USB_CDNSP_GADGET=y show no new warnings,\nand our static analyzer no longer warns about this code.

In the Linux kernel, the following vulnerability has been resolved:\n\nserial: liteuart: Fix NULL pointer dereference in ->remove()\n\ndrvdata has to be set in _probe() - otherwise platform_get_drvdata()\ncauses null pointer dereference BUG in _remove().

In the Linux kernel, the following vulnerability has been resolved:\n\nserial: liteuart: fix use-after-free and memleak on unbind\n\nDeregister the port when unbinding the driver to prevent it from being\nused after releasing the driver data and leaking memory allocated by\nserial core.

In the Linux kernel, the following vulnerability has been resolved:\n\nserial: liteuart: fix minor-number leak on probe errors\n\nMake sure to release the allocated minor number before returning on\nprobe errors.

In the Linux kernel, the following vulnerability has been resolved:\n\nHID: bigbenff: prevent null pointer dereference\n\nWhen emulating the device through uhid, there is a chance we don't have\noutput reports and so report_field is null.

In the Linux kernel, the following vulnerability has been resolved:\n\ncan: sja1000: fix use after free in ems_pcmcia_add_card()\n\nIf the last channel is not available then "dev" is freed. Fortunately,\nwe can just use "pdev->irq" instead.\n\nAlso we should check if at least one channel was set up.

In the Linux kernel, the following vulnerability has been resolved:\n\ncan: pch_can: pch_can_rx_normal: fix use after free\n\nAfter calling netif_receive_skb(skb), dereferencing skb is unsafe.\nEspecially, the can_frame cf which aliases skb memory is dereferenced\njust after the call netif_receive_skb(skb).\n\nReordering the lines solves the issue.

In the Linux kernel, the following vulnerability has been resolved:\n\ncan: m_can: m_can_read_fifo: fix memory leak in error branch\n\nIn m_can_read_fifo(), if the second call to m_can_fifo_read() fails,\nthe function jump to the out_fail label and returns without calling\nm_can_receive_skb(). This means that the skb previously allocated by\nalloc_can_skb() is not freed. In other terms, this is a memory leak.\n\nThis patch adds a goto label to destroy the skb if an error occurs.\n\nIssue was found with GCC -fanalyzer, please follow the link below for\ndetails.

In the Linux kernel, the following vulnerability has been resolved:\n\nnfc: fix potential NULL pointer deref in nfc_genl_dump_ses_done\n\nThe done() netlink callback nfc_genl_dump_ses_done() should check if\nreceived argument is non-NULL, because its allocation could fail earlier\nin dumpit() (nfc_genl_dump_ses()).

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: felix: Fix memory leak in felix_setup_mmio_filtering\n\nAvoid a memory leak if there is not a CPU port defined.\n\nAddresses-Coverity-ID: 1492897 ("Resource leak")\nAddresses-Coverity-ID: 1492899 ("Resource leak")

In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix use-after-free due to delegation race\n\nA delegation break could arrive as soon as we've called vfs_setlease. A\ndelegation break runs a callback which immediately (in\nnfsd4_cb_recall_prepare) adds the delegation to del_recall_lru. If we\nthen exit nfs4_set_delegation without hashing the delegation, it will be\nfreed as soon as the callback is done with it, without ever being\nremoved from del_recall_lru.\n\nSymptoms show up later as use-after-free or list corruption warnings,\nusually in the laundromat thread.\n\nI suspect aba2072f4523 "nfsd: grant read delegations to clients holding\nwrites" made this bug easier to hit, but I looked as far back as v3.0\nand it looks to me it already had the same problem. So I'm not sure\nwhere the bug was introduced; it may have been there from the beginning.

In the Linux kernel, the following vulnerability has been resolved:\n\nIB/qib: Protect from buffer overflow in struct qib_user_sdma_pkt fields\n\nOverflowing either addrlimit or bytes_togo can allow userspace to trigger\na buffer overflow of kernel memory. Check for overflows in all the places\ndoing math on user controlled buffers.

In the Linux kernel, the following vulnerability has been resolved:\n\nregmap: Fix possible double-free in regcache_rbtree_exit()\n\nIn regcache_rbtree_insert_to_block(), when 'present' realloc failed,\nthe 'blk' which is supposed to assign to 'rbnode->block' will be freed,\nso 'rbnode->block' points a freed memory, in the error handling path of\nregcache_rbtree_init(), 'rbnode->block' will be freed again in\nregcache_rbtree_exit(), KASAN will report double-free as follows:\n\nBUG: KASAN: double-free or invalid-free in kfree+0xce/0x390\nCall Trace:\n slab_free_freelist_hook+0x10d/0x240\n kfree+0xce/0x390\n regcache_rbtree_exit+0x15d/0x1a0\n regcache_rbtree_init+0x224/0x2c0\n regcache_init+0x88d/0x1310\n __regmap_init+0x3151/0x4a80\n __devm_regmap_init+0x7d/0x100\n madera_spi_probe+0x10f/0x333 [madera_spi]\n spi_probe+0x183/0x210\n really_probe+0x285/0xc30\n\nTo fix this, moving up the assignment of rbnode->block to immediately after\nthe reallocation has succeeded so that the data structure stays valid even\nif the second reallocation fails.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: batman-adv: fix error handling\n\nSyzbot reported ODEBUG warning in batadv_nc_mesh_free(). The problem was\nin wrong error handling in batadv_mesh_init().\n\nBefore this patch batadv_mesh_init() was calling batadv_mesh_free() in case\nof any batadv_*_init() calls failure. This approach may work well, when\nthere is some kind of indicator, which can tell which parts of batadv are\ninitialized; but there isn't any.\n\nAll written above lead to cleaning up uninitialized fields. Even if we hide\nODEBUG warning by initializing bat_priv->nc.work, syzbot was able to hit\nGPF in batadv_nc_purge_paths(), because hash pointer in still NULL. [1]\n\nTo fix these bugs we can unwind batadv_*_init() calls one by one.\nIt is good approach for 2 reasons: 1) It fixes bugs on error handling\npath 2) It improves the performance, since we won't call unneeded\nbatadv_*_free() functions.\n\nSo, this patch makes all batadv_*_init() clean up all allocated memory\nbefore returning with an error to no call correspoing batadv_*_free()\nand open-codes batadv_mesh_free() with proper order to avoid touching\nuninitialized fields.

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Initialize the ODP xarray when creating an ODP MR\n\nNormally the zero fill would hide the missing initialization, but an\nerrant set to desc_size in reg_create() causes a crash:\n\n BUG: unable to handle page fault for address: 0000000800000000\n PGD 0 P4D 0\n Oops: 0000 [#1] SMP PTI\n CPU: 5 PID: 890 Comm: ib_write_bw Not tainted 5.15.0-rc4+ #47\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n RIP: 0010:mlx5_ib_dereg_mr+0x14/0x3b0 [mlx5_ib]\n Code: 48 63 cd 4c 89 f7 48 89 0c 24 e8 37 30 03 e1 48 8b 0c 24 eb a0 90 0f 1f 44 00 00 41 56 41 55 41 54 55 53 48 89 fb 48 83 ec 30 <48> 8b 2f 65 48 8b 04 25 28 00 00 00 48 89 44 24 28 31 c0 8b 87 c8\n RSP: 0018:ffff88811afa3a60 EFLAGS: 00010286\n RAX: 000000000000001c RBX: 0000000800000000 RCX: 0000000000000000\n RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000800000000\n RBP: 0000000800000000 R08: 0000000000000000 R09: c0000000fffff7ff\n R10: ffff88811afa38f8 R11: ffff88811afa38f0 R12: ffffffffa02c7ac0\n R13: 0000000000000000 R14: ffff88811afa3cd8 R15: ffff88810772fa00\n FS: 00007f47b9080740(0000) GS:ffff88852cd40000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000800000000 CR3: 000000010761e003 CR4: 0000000000370ea0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n mlx5_ib_free_odp_mr+0x95/0xc0 [mlx5_ib]\n mlx5_ib_dereg_mr+0x128/0x3b0 [mlx5_ib]\n ib_dereg_mr_user+0x45/0xb0 [ib_core]\n ? xas_load+0x8/0x80\n destroy_hw_idr_uobject+0x1a/0x50 [ib_uverbs]\n uverbs_destroy_uobject+0x2f/0x150 [ib_uverbs]\n uobj_destroy+0x3c/0x70 [ib_uverbs]\n ib_uverbs_cmd_verbs+0x467/0xb00 [ib_uverbs]\n ? uverbs_finalize_object+0x60/0x60 [ib_uverbs]\n ? ttwu_queue_wakelist+0xa9/0xe0\n ? pty_write+0x85/0x90\n ? file_tty_write.isra.33+0x214/0x330\n ? process_echoes+0x60/0x60\n ib_uverbs_ioctl+0xa7/0x110 [ib_uverbs]\n __x64_sys_ioctl+0x10d/0x8e0\n ? vfs_write+0x17f/0x260\n do_syscall_64+0x3c/0x80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nAdd the missing xarray initialization and remove the desc_size set.

In the Linux kernel, the following vulnerability has been resolved:\n\nstaging: rtl8712: fix use-after-free in rtl8712_dl_fw\n\nSyzbot reported use-after-free in rtl8712_dl_fw(). The problem was in\nrace condition between r871xu_dev_remove() ->ndo_open() callback.\n\nIt's easy to see from crash log, that driver accesses released firmware\nin ->ndo_open() callback. It may happen, since driver was releasing\nfirmware _before_ unregistering netdev. Fix it by moving\nunregister_netdev() before cleaning up resources.\n\nCall Trace:\n...\n rtl871x_open_fw drivers/staging/rtl8712/hal_init.c:83 [inline]\n rtl8712_dl_fw+0xd95/0xe10 drivers/staging/rtl8712/hal_init.c:170\n rtl8712_hal_init drivers/staging/rtl8712/hal_init.c:330 [inline]\n rtl871x_hal_init+0xae/0x180 drivers/staging/rtl8712/hal_init.c:394\n netdev_open+0xe6/0x6c0 drivers/staging/rtl8712/os_intfs.c:380\n __dev_open+0x2bc/0x4d0 net/core/dev.c:1484\n\nFreed by task 1306:\n...\n release_firmware+0x1b/0x30 drivers/base/firmware_loader/main.c:1053\n r871xu_dev_remove+0xcc/0x2c0 drivers/staging/rtl8712/usb_intf.c:599\n usb_unbind_interface+0x1d8/0x8d0 drivers/usb/core/driver.c:458

In the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: dt9812: fix DMA buffers on stack\n\nUSB transfer buffers are typically mapped for DMA and must not be\nallocated on the stack or transfers will fail.\n\nAllocate proper transfer buffers in the various command helpers and\nreturn an error on short transfers instead of acting on random stack\ndata.\n\nNote that this also fixes a stack info leak on systems where DMA is not\nused as 32 bytes are always sent to the device regardless of how short\nthe command is.

In the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: ni_usb6501: fix NULL-deref in command paths\n\nThe driver uses endpoint-sized USB transfer buffers but had no sanity\nchecks on the sizes. This can lead to zero-size-pointer dereferences or\noverflowed transfer buffers in ni6501_port_command() and\nni6501_counter_command() if a (malicious) device has smaller max-packet\nsizes than expected (or when doing descriptor fuzz testing).\n\nAdd the missing sanity checks to probe().

In the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: vmk80xx: fix transfer-buffer overflows\n\nThe driver uses endpoint-sized USB transfer buffers but up until\nrecently had no sanity checks on the sizes.\n\nCommit e1f13c879a7c ("staging: comedi: check validity of wMaxPacketSize\nof usb endpoints found") inadvertently fixed NULL-pointer dereferences\nwhen accessing the transfer buffers in case a malicious device has a\nzero wMaxPacketSize.\n\nMake sure to allocate buffers large enough to handle also the other\naccesses that are done without a size check (e.g. byte 18 in\nvmk80xx_cnt_insn_read() for the VMK8061_MODEL) to avoid writing beyond\nthe buffers, for example, when doing descriptor fuzzing.\n\nThe original driver was for a low-speed device with 8-byte buffers.\nSupport was later added for a device that uses bulk transfers and is\npresumably a full-speed device with a maximum 64-byte wMaxPacketSize.

In the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: vmk80xx: fix bulk-buffer overflow\n\nThe driver is using endpoint-sized buffers but must not assume that the\ntx and rx buffers are of equal size or a malicious device could overflow\nthe slab-allocated receive buffer when doing bulk transfers.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Fix a memory leak in an error path of qla2x00_process_els()\n\nCommit 8c0eb596baa5 ("[SCSI] qla2xxx: Fix a memory leak in an error path of\nqla2x00_process_els()"), intended to change:\n\n bsg_job->request->msgcode == FC_BSG_HST_ELS_NOLOGIN\n\n\n bsg_job->request->msgcode != FC_BSG_RPT_ELS\n\nbut changed it to:\n\n bsg_job->request->msgcode == FC_BSG_RPT_ELS\n\ninstead.\n\nChange the == to a != to avoid leaking the fcport structure or freeing\nunallocated memory.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm, slub: fix potential use-after-free in slab_debugfs_fops\n\nWhen sysfs_slab_add failed, we shouldn't call debugfs_slab_add() for s\nbecause s will be freed soon. And slab_debugfs_fops will use s later\nleading to a use-after-free.

In the Linux kernel, the following vulnerability has been resolved:\n\nice: Avoid crash from unnecessary IDA free\n\nIn the remove path, there is an attempt to free the aux_idx IDA whether\nit was allocated or not. This can potentially cause a crash when\nunloading the driver on systems that do not initialize support for RDMA.\nBut, this free cannot be gated by the status bit for RDMA, since it is\nallocated if the driver detects support for RDMA at probe time, but the\ndriver can enter into a state where RDMA is not supported after the IDA\nhas been allocated at probe time and this would lead to a memory leak.\n\nInitialize aux_idx to an invalid value and check for a valid value when\nunloading to determine if an IDA free is necessary.

In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: Fix host stage-2 PGD refcount\n\nThe KVM page-table library refcounts the pages of concatenated stage-2\nPGDs individually. However, when running KVM in protected mode, the\nhost's stage-2 PGD is currently managed by EL2 as a single high-order\ncompound page, which can cause the refcount of the tail pages to reach 0\nwhen they shouldn't, hence corrupting the page-table.\n\nFix this by introducing a new hyp_split_page() helper in the EL2 page\nallocator (matching the kernel's split_page() function), and make use of\nit from host_s2_zalloc_pages_exact().

In the Linux kernel, the following vulnerability has been resolved:\n\nice: fix locking for Tx timestamp tracking flush\n\nCommit 4dd0d5c33c3e ("ice: add lock around Tx timestamp tracker flush")\nadded a lock around the Tx timestamp tracker flow which is used to\ncleanup any left over SKBs and prepare for device removal.\n\nThis lock is problematic because it is being held around a call to\nice_clear_phy_tstamp. The clear function takes a mutex to send a PHY\nwrite command to firmware. This could lead to a deadlock if the mutex\nactually sleeps, and causes the following warning on a kernel with\npreemption debugging enabled:\n\n[ 715.419426] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:573\n[ 715.427900] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 3100, name: rmmod\n[ 715.435652] INFO: lockdep is turned off.\n[ 715.439591] Preemption disabled at:\n[ 715.439594] [<0000000000000000>] 0x0\n[ 715.446678] CPU: 52 PID: 3100 Comm: rmmod Tainted: G W OE 5.15.0-rc4+ #42 bdd7ec3018e725f159ca0d372ce8c2c0e784891c\n[ 715.458058] Hardware name: Intel Corporation S2600STQ/S2600STQ, BIOS SE5C620.86B.02.01.0010.010620200716 01/06/2020\n[ 715.468483] Call Trace:\n[ 715.470940] dump_stack_lvl+0x6a/0x9a\n[ 715.474613] ___might_sleep.cold+0x224/0x26a\n[ 715.478895] __mutex_lock+0xb3/0x1440\n[ 715.482569] ? stack_depot_save+0x378/0x500\n[ 715.486763] ? ice_sq_send_cmd+0x78/0x14c0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]\n[ 715.494979] ? kfree+0xc1/0x520\n[ 715.498128] ? mutex_lock_io_nested+0x12a0/0x12a0\n[ 715.502837] ? kasan_set_free_info+0x20/0x30\n[ 715.507110] ? __kasan_slab_free+0x10b/0x140\n[ 715.511385] ? slab_free_freelist_hook+0xc7/0x220\n[ 715.516092] ? kfree+0xc1/0x520\n[ 715.519235] ? ice_deinit_lag+0x16c/0x220 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]\n[ 715.527359] ? ice_remove+0x1cf/0x6a0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]\n[ 715.535133] ? pci_device_remove+0xab/0x1d0\n[ 715.539318] ? __device_release_driver+0x35b/0x690\n[ 715.544110] ? driver_detach+0x214/0x2f0\n[ 715.548035] ? bus_remove_driver+0x11d/0x2f0\n[ 715.552309] ? pci_unregister_driver+0x26/0x250\n[ 715.556840] ? ice_module_exit+0xc/0x2f [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]\n[ 715.564799] ? __do_sys_delete_module.constprop.0+0x2d8/0x4e0\n[ 715.570554] ? do_syscall_64+0x3b/0x90\n[ 715.574303] ? entry_SYSCALL_64_after_hwframe+0x44/0xae\n[ 715.579529] ? start_flush_work+0x542/0x8f0\n[ 715.583719] ? ice_sq_send_cmd+0x78/0x14c0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]\n[ 715.591923] ice_sq_send_cmd+0x78/0x14c0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]\n[ 715.599960] ? wait_for_completion_io+0x250/0x250\n[ 715.604662] ? lock_acquire+0x196/0x200\n[ 715.608504] ? do_raw_spin_trylock+0xa5/0x160\n[ 715.612864] ice_sbq_rw_reg+0x1e6/0x2f0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]\n[ 715.620813] ? ice_reset+0x130/0x130 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]\n[ 715.628497] ? __debug_check_no_obj_freed+0x1e8/0x3c0\n[ 715.633550] ? trace_hardirqs_on+0x1c/0x130\n[ 715.637748] ice_write_phy_reg_e810+0x70/0xf0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]\n[ 715.646220] ? do_raw_spin_trylock+0xa5/0x160\n[ 715.650581] ? ice_ptp_release+0x910/0x910 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]\n[ 715.658797] ? ice_ptp_release+0x255/0x910 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]\n[ 715.667013] ice_clear_phy_tstamp+0x2c/0x110 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]\n[ 715.675403] ice_ptp_release+0x408/0x910 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]\n[ 715.683440] ice_remove+0x560/0x6a0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]\n[ 715.691037] ? _raw_spin_unlock_irqrestore+0x46/0x73\n[ 715.696005] pci_device_remove+0xab/0x1d0\n[ 715.700018] __device_release_driver+0x35b/0x690\n[ 715.704637] driver_detach+0x214/0x2f0\n[ 715.708389] bus_remove_driver+0x11d/0x2f0\n[ 715.712489] pci_unregister_driver+0x26/0x250\n[ 715.716857] ice_module_exit+0xc/0x2f [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]\n[ 715.724637] __do_sys_delete_module.constprop.0+0x2d8/0x4e0\n[ 715.730210] ? free_module+0x6d0/0x6d0\n[ 715.733963] ? task_work_run+0xe1/0x170\n[ 715.737803] ? exit_to_user_mode_loop+0x17f/0x1d0\n[ 715.742509] ? rcu_read_lock_sched_held+0x12/0x80\n[ 715.747215] ? trace_hardirqs_on+0x1c/0x130\n[ 715.751401] do_syscall_64+0x3b/0x90\n[ 715.754981] entry_SYSCALL_64_after_hwframe+0x44/0xae\n[ 715.760033] RIP: 0033:0x7f4dfe59000b\n[ 715.763612] Code: 73 01 c3 48 8b 0d 6d 1e 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 3d 1e 0c 00 f7 d8 64 89 01 48\n[ 715.782357] RSP: 002b:00007ffe8c891708 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0\n[ 715.789923] RAX: ffffffffffffffda RBX: 00005558a20468b0 RCX: 00007f4dfe59000b\n[ 715.797054] RDX: 000000000000000a RSI: 0000000000000800 RDI: 00005558a2046918\n[ 715.804189] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000\n[ 715.811319] R10: 00007f4dfe603ac0 R11: 0000000000000206 R12: 00007ffe8c891940\n[ 715.818455] R13: 00007ffe8c8920a3 R14: 00005558a20462a0 R15: 00005558a20468b0\n\nNotice that this is the only case where we use the lock in this way. In\nthe cleanup kthread and work kthread the lock is only taken around the\nbit accesses. This was done intentionally to avoid this kind of issue.\nThe way the lock is used, we only protect ordering of bit sets vs bit\nclears. The Tx writers in the hot path don't need to be protected\nagainst the entire kthread loop. The Tx queues threads only need to\nensure that they do not re-use an index that is currently in use. The\ncleanup loop does not need to block all new set bits, since it will\nre-queue itself if new timestamps are present.\n\nFix the tracker flow so that it uses the same flow as the standard\ncleanup thread. In addition, ensure the in_use bitmap actually gets\ncleared properly.\n\nThis fixes the warning and also avoids the potential deadlock that might\nhave occurred otherwise.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/a3xx: fix error handling in a3xx_gpu_init()\n\nThese error paths returned 1 on failure, instead of a negative error\ncode. This would lead to an Oops in the caller. A second problem is\nthat the check for "if (ret != -ENODATA)" did not work because "ret" was\nset to 1.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/a4xx: fix error handling in a4xx_gpu_init()\n\nThis code returns 1 on error instead of a negative error. It leads to\nan Oops in the caller. A second problem is that the check for\n"if (ret != -ENODATA)" cannot be true because "ret" is set to 1.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm: Fix null pointer dereference on pointer edp\n\nThe initialization of pointer dev dereferences pointer edp before\nedp is null checked, so there is a potential null pointer deference\nissue. Fix this by only dereferencing edp after edp has been null\nchecked.\n\nAddresses-Coverity: ("Dereference before null check")

In the Linux kernel, the following vulnerability has been resolved:\n\nNFC: digital: fix possible memory leak in digital_tg_listen_mdaa()\n\n'params' is allocated in digital_tg_listen_mdaa(), but not free when\ndigital_send_cmd() failed, which will cause memory leak. Fix it by\nfreeing 'params' if digital_send_cmd() return failed.