In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix CT entry update leaks of modify header context\n\nThe cited commit allocates a new modify header to replace the old\none when updating CT entry. But if failed to allocate a new one, eg.\nexceed the max number firmware can support, modify header will be\nan error pointer that will trigger a panic when deallocating it. And\nthe old modify header point is copied to old attr. When the old\nattr is freed, the old modify header is lost.\n\nFix it by restoring the old attr to attr when failed to allocate a\nnew modify header context. So when the CT entry is freed, the right\nmodify header context will be freed. And the panic of accessing\nerror pointer is also fixed.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: wan: fsl_qmc_hdlc: Convert carrier_lock spinlock to a mutex\n\nThe carrier_lock spinlock protects the carrier detection. While it is\nheld, framer_get_status() is called which in turn takes a mutex.\nThis is not correct and can lead to a deadlock.\n\nA run with PROVE_LOCKING enabled detected the issue:\n [ BUG: Invalid wait context ]\n ...\n c204ddbc (&framer->mutex){+.+.}-{3:3}, at: framer_get_status+0x40/0x78\n other info that might help us debug this:\n context-{4:4}\n 2 locks held by ifconfig/146:\n #0: c0926a38 (rtnl_mutex){+.+.}-{3:3}, at: devinet_ioctl+0x12c/0x664\n #1: c2006a40 (&qmc_hdlc->carrier_lock){....}-{2:2}, at: qmc_hdlc_framer_set_carrier+0x30/0x98\n\nAvoid the spinlock usage and convert carrier_lock to a mutex.

In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to truncate preallocated blocks in f2fs_file_open()\n\nchenyuwen reports a f2fs bug as below:\n\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000011\n fscrypt_set_bio_crypt_ctx+0x78/0x1e8\n f2fs_grab_read_bio+0x78/0x208\n f2fs_submit_page_read+0x44/0x154\n f2fs_get_read_data_page+0x288/0x5f4\n f2fs_get_lock_data_page+0x60/0x190\n truncate_partial_data_page+0x108/0x4fc\n f2fs_do_truncate_blocks+0x344/0x5f0\n f2fs_truncate_blocks+0x6c/0x134\n f2fs_truncate+0xd8/0x200\n f2fs_iget+0x20c/0x5ac\n do_garbage_collect+0x5d0/0xf6c\n f2fs_gc+0x22c/0x6a4\n f2fs_disable_checkpoint+0xc8/0x310\n f2fs_fill_super+0x14bc/0x1764\n mount_bdev+0x1b4/0x21c\n f2fs_mount+0x20/0x30\n legacy_get_tree+0x50/0xbc\n vfs_get_tree+0x5c/0x1b0\n do_new_mount+0x298/0x4cc\n path_mount+0x33c/0x5fc\n __arm64_sys_mount+0xcc/0x15c\n invoke_syscall+0x60/0x150\n el0_svc_common+0xb8/0xf8\n do_el0_svc+0x28/0xa0\n el0_svc+0x24/0x84\n el0t_64_sync_handler+0x88/0xec\n\nIt is because inode.i_crypt_info is not initialized during below path:\n- mount\n - f2fs_fill_super\n - f2fs_disable_checkpoint\n - f2fs_gc\n - f2fs_iget\n - f2fs_truncate\n\nSo, let's relocate truncation of preallocated blocks to f2fs_file_open(),\nafter fscrypt_file_open().

In the Linux kernel, the following vulnerability has been resolved:\n\njfs: Fix array-index-out-of-bounds in diFree

In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix null reference error when checking end of zone\n\nThis patch fixes a potentially null pointer being accessed by\nis_end_zone_blkaddr() that checks the last block of a zone\nwhen f2fs is mounted as a single device.

In the Linux kernel, the following vulnerability has been resolved:\n\ndma: fix call order in dmam_free_coherent\n\ndmam_free_coherent() frees a DMA allocation, which makes the\nfreed vaddr available for reuse, then calls devres_destroy()\nto remove and free the data structure used to track the DMA\nallocation. Between the two calls, it is possible for a\nconcurrent task to make an allocation with the same vaddr\nand add it to the devres list.\n\nIf this happens, there will be two entries in the devres list\nwith the same vaddr and devres_destroy() can free the wrong\nentry, triggering the WARN_ON() in dmam_match.\n\nFix by destroying the devres entry before freeing the DMA\nallocation.\n\n kokonut //net/encryption\n http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03

In the Linux kernel, the following vulnerability has been resolved:\n\nmd: fix deadlock between mddev_suspend and flush bio\n\nDeadlock occurs when mddev is being suspended while some flush bio is in\nprogress. It is a complex issue.\n\nT1. the first flush is at the ending stage, it clears 'mddev->flush_bio'\n and tries to submit data, but is blocked because mddev is suspended\n by T4.\nT2. the second flush sets 'mddev->flush_bio', and attempts to queue\n md_submit_flush_data(), which is already running (T1) and won't\n execute again if on the same CPU as T1.\nT3. the third flush inc active_io and tries to flush, but is blocked because\n 'mddev->flush_bio' is not NULL (set by T2).\nT4. mddev_suspend() is called and waits for active_io dec to 0 which is inc\n by T3.\n\n T1 T2 T3 T4\n (flush 1) (flush 2) (third 3) (suspend)\n md_submit_flush_data\n mddev->flush_bio = NULL;\n .\n . md_flush_request\n . mddev->flush_bio = bio\n . queue submit_flushes\n . .\n . . md_handle_request\n . . active_io + 1\n . . md_flush_request\n . . wait !mddev->flush_bio\n . .\n . . mddev_suspend\n . . wait !active_io\n . .\n . submit_flushes\n . queue_work md_submit_flush_data\n . //md_submit_flush_data is already running (T1)\n .\n md_handle_request\n wait resume\n\nThe root issue is non-atomic inc/dec of active_io during flush process.\nactive_io is dec before md_submit_flush_data is queued, and inc soon\nafter md_submit_flush_data() run.\n md_flush_request\n active_io + 1\n submit_flushes\n active_io - 1\n md_submit_flush_data\n md_handle_request\n active_io + 1\n make_request\n active_io - 1\n\nIf active_io is dec after md_handle_request() instead of within\nsubmit_flushes(), make_request() can be called directly intead of\nmd_handle_request() in md_submit_flush_data(), and active_io will\nonly inc and dec once in the whole flush process. Deadlock will be\nfixed.\n\nAdditionally, the only difference between fixing the issue and before is\nthat there is no return error handling of make_request(). But after\nprevious patch cleaned md_write_start(), make_requst() only return error\nin raid5_make_request() by dm-raid, see commit 41425f96d7aa ("dm-raid456,\nmd/raid456: fix a deadlock for dm-raid456 while io concurrent with\nreshape)". Since dm always splits data and flush operation into two\nseparate io, io size of flush submitted by dm always is 0, make_request()\nwill not be called in md_submit_flush_data(). To prevent future\nmodifications from introducing issues, add WARN_ON to ensure\nmake_request() no error is returned in this context.

In the Linux kernel, the following vulnerability has been resolved:\n\nblock: initialize integrity buffer to zero before writing it to media\n\nMetadata added by bio_integrity_prep is using plain kmalloc, which leads\nto random kernel memory being written media. For PI metadata this is\nlimited to the app tag that isn't used by kernel generated metadata,\nbut for non-PI metadata the entire buffer leaks kernel memory.\n\nFix this by adding the __GFP_ZERO flag to allocations for writes.

In the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (ltc2991) re-order conditions to fix off by one bug\n\nLTC2991_T_INT_CH_NR is 4. The st->temp_en[] array has LTC2991_MAX_CHANNEL\n(4) elements. Thus if "channel" is equal to LTC2991_T_INT_CH_NR then we\nhave read one element beyond the end of the array. Flip the conditions\naround so that we check if "channel" is valid before using it as an array\nindex.

In the Linux kernel, the following vulnerability has been resolved:\n\nsoc: xilinx: rename cpu_number1 to dummy_cpu_number\n\nThe per cpu variable cpu_number1 is passed to xlnx_event_handler as\nargument "dev_id", but it is not used in this function. So drop the\ninitialization of this variable and rename it to dummy_cpu_number.\nThis patch is to fix the following call trace when the kernel option\nCONFIG_DEBUG_ATOMIC_SLEEP is enabled:\n\nBUG: sleeping function called from invalid context at include/linux/sched/mm.h:274\n in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0\n preempt_count: 1, expected: 0\n CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.1.0 #53\n Hardware name: Xilinx Versal vmk180 Eval board rev1.1 (QSPI) (DT)\n Call trace:\n dump_backtrace+0xd0/0xe0\n show_stack+0x18/0x40\n dump_stack_lvl+0x7c/0xa0\n dump_stack+0x18/0x34\n __might_resched+0x10c/0x140\n __might_sleep+0x4c/0xa0\n __kmem_cache_alloc_node+0xf4/0x168\n kmalloc_trace+0x28/0x38\n __request_percpu_irq+0x74/0x138\n xlnx_event_manager_probe+0xf8/0x298\n platform_probe+0x68/0xd8

In the Linux kernel, the following vulnerability has been resolved:\n\nsoc: qcom: icc-bwmon: Fix refcount imbalance seen during bwmon_remove\n\nThe following warning is seen during bwmon_remove due to refcount\nimbalance, fix this by releasing the OPPs after use.\n\nLogs:\nWARNING: at drivers/opp/core.c:1640 _opp_table_kref_release+0x150/0x158\nHardware name: Qualcomm Technologies, Inc. X1E80100 CRD (DT)\n...\nCall trace:\n_opp_table_kref_release+0x150/0x158\ndev_pm_opp_remove_table+0x100/0x1b4\ndevm_pm_opp_of_table_release+0x10/0x1c\ndevm_action_release+0x14/0x20\ndevres_release_all+0xa4/0x104\ndevice_unbind_cleanup+0x18/0x60\ndevice_release_driver_internal+0x1ec/0x228\ndriver_detach+0x50/0x98\nbus_remove_driver+0x6c/0xbc\ndriver_unregister+0x30/0x60\nplatform_driver_unregister+0x14/0x20\nbwmon_driver_exit+0x18/0x524 [icc_bwmon]\n__arm64_sys_delete_module+0x184/0x264\ninvoke_syscall+0x48/0x118\nel0_svc_common.constprop.0+0xc8/0xe8\ndo_el0_svc+0x20/0x2c\nel0_svc+0x34/0xdc\nel0t_64_sync_handler+0x13c/0x158\nel0t_64_sync+0x190/0x194\n--[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: fix TTLM teardown work\n\nThe worker calculates the wrong sdata pointer, so if it ever\nruns, it'll crash. Fix that.

In the Linux kernel, the following vulnerability has been resolved:\n\nudf: Fix bogus checksum computation in udf_rename()\n\nSyzbot reports uninitialized memory access in udf_rename() when updating\nchecksum of '..' directory entry of a moved directory. This is indeed\ntrue as we pass on-stack diriter.fi to the udf_update_tag() and because\nthat has only struct fileIdentDesc included in it and not the impUse or\nname fields, the checksumming function is going to checksum random stack\ncontents beyond the end of the structure. This is actually harmless\nbecause the following udf_fiiter_write_fi() will recompute the checksum\nfrom on-disk buffers where everything is properly included. So all that\nis needed is just removing the bogus calculation.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtw89: wow: fix GTK offload H2C skbuff issue\n\nWe mistakenly put skb too large and that may exceed skb->end.\nTherefore, we fix it.\n\nskbuff: skb_over_panic: text:ffffffffc09e9a9d len:416 put:204 head:ffff8fba04eca780 data:ffff8fba04eca7e0 tail:0x200 end:0x140 dev:<NULL>\n------------[ cut here ]------------\nkernel BUG at net/core/skbuff.c:192!\ninvalid opcode: 0000 [#1] PREEMPT SMP PTI\nCPU: 1 PID: 4747 Comm: kworker/u4:44 Tainted: G O 6.6.30-02659-gc18865c4dfbd #1 86547039b47e46935493f615ee31d0b2d711d35e\nHardware name: HP Meep/Meep, BIOS Google_Meep.11297.262.0 03/18/2021\nWorkqueue: events_unbound async_run_entry_fn\nRIP: 0010:skb_panic+0x5d/0x60\nCode: c6 63 8b 8f bb 4c 0f 45 f6 48 c7 c7 4d 89 8b bb 48 89 ce 44 89 d1 41 56 53 41 53 ff b0 c8 00 00 00 e8 27 5f 23 00 48 83 c4 20 <0f> 0b 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44\nRSP: 0018:ffffaa700144bad0 EFLAGS: 00010282\nRAX: 0000000000000089 RBX: 0000000000000140 RCX: 14432c5aad26c900\nRDX: 0000000000000000 RSI: 00000000ffffdfff RDI: 0000000000000001\nRBP: ffffaa700144bae0 R08: 0000000000000000 R09: ffffaa700144b920\nR10: 00000000ffffdfff R11: ffffffffbc28fbc0 R12: ffff8fba4e57a010\nR13: 0000000000000000 R14: ffffffffbb8f8b63 R15: 0000000000000000\nFS: 0000000000000000(0000) GS:ffff8fba7bd00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007999c4ad1000 CR3: 000000015503a000 CR4: 0000000000350ee0\nCall Trace:\n <TASK>\n ? __die_body+0x1f/0x70\n ? die+0x3d/0x60\n ? do_trap+0xa4/0x110\n ? skb_panic+0x5d/0x60\n ? do_error_trap+0x6d/0x90\n ? skb_panic+0x5d/0x60\n ? handle_invalid_op+0x30/0x40\n ? skb_panic+0x5d/0x60\n ? exc_invalid_op+0x3c/0x50\n ? asm_exc_invalid_op+0x16/0x20\n ? skb_panic+0x5d/0x60\n skb_put+0x49/0x50\n rtw89_fw_h2c_wow_gtk_ofld+0xbd/0x220 [rtw89_core 778b32de31cd1f14df2d6721ae99ba8a83636fa5]\n rtw89_wow_resume+0x31f/0x540 [rtw89_core 778b32de31cd1f14df2d6721ae99ba8a83636fa5]\n rtw89_ops_resume+0x2b/0xa0 [rtw89_core 778b32de31cd1f14df2d6721ae99ba8a83636fa5]\n ieee80211_reconfig+0x84/0x13e0 [mac80211 818a894e3b77da6298269c59ed7cdff065a4ed52]\n ? __pfx_wiphy_resume+0x10/0x10 [cfg80211 1a793119e2aeb157c4ca4091ff8e1d9ae233b59d]\n ? dev_printk_emit+0x51/0x70\n ? _dev_info+0x6e/0x90\n ? __pfx_wiphy_resume+0x10/0x10 [cfg80211 1a793119e2aeb157c4ca4091ff8e1d9ae233b59d]\n wiphy_resume+0x89/0x180 [cfg80211 1a793119e2aeb157c4ca4091ff8e1d9ae233b59d]\n ? __pfx_wiphy_resume+0x10/0x10 [cfg80211 1a793119e2aeb157c4ca4091ff8e1d9ae233b59d]\n dpm_run_callback+0x3c/0x140\n device_resume+0x1f9/0x3c0\n ? __pfx_dpm_watchdog_handler+0x10/0x10\n async_resume+0x1d/0x30\n async_run_entry_fn+0x29/0xd0\n process_scheduled_works+0x1d8/0x3d0\n worker_thread+0x1fc/0x2f0\n kthread+0xed/0x110\n ? __pfx_worker_thread+0x10/0x10\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x38/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1b/0x30\n </TASK>\nModules linked in: ccm 8021q r8153_ecm cdc_ether usbnet r8152 mii dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc uinput rfcomm cmac algif_hash rtw89_8922ae(O) algif_skcipher rtw89_8922a(O) af_alg rtw89_pci(O) rtw89_core(O) btusb(O) snd_soc_sst_bxt_da7219_max98357a btbcm(O) snd_soc_hdac_hdmi btintel(O) snd_soc_intel_hda_dsp_common snd_sof_probes btrtl(O) btmtk(O) snd_hda_codec_hdmi snd_soc_dmic uvcvideo videobuf2_vmalloc uvc videobuf2_memops videobuf2_v4l2 videobuf2_common snd_sof_pci_intel_apl snd_sof_intel_hda_common snd_soc_hdac_hda snd_sof_intel_hda soundwire_intel soundwire_generic_allocation snd_sof_intel_hda_mlink soundwire_cadence snd_sof_pci snd_sof_xtensa_dsp mac80211 snd_soc_acpi_intel_match snd_soc_acpi snd_sof snd_sof_utils soundwire_bus snd_soc_max98357a snd_soc_avs snd_soc_hda_codec snd_hda_ext_core snd_intel_dspcfg snd_intel_sdw_acpi snd_soc_da7219 snd_hda_codec snd_hwdep snd_hda_core veth ip6table_nat xt_MASQUERADE xt_cgroup fuse bluetooth ecdh_generic\n cfg80211 ecc\ngsmi: Log Shutdown Reason 0x03\n---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:\n\nriscv, bpf: Fix out-of-bounds issue when preparing trampoline image\n\nWe get the size of the trampoline image during the dry run phase and\nallocate memory based on that size. The allocated image will then be\npopulated with instructions during the real patch phase. But after\ncommit 26ef208c209a ("bpf: Use arch_bpf_trampoline_size"), the `im`\nargument is inconsistent in the dry run and real patch phase. This may\ncause emit_imm in RV64 to generate a different number of instructions\nwhen generating the 'im' address, potentially causing out-of-bounds\nissues. Let's emit the maximum number of instructions for the "im"\naddress during dry run to fix this problem.

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix null pointer dereference in resolve_prog_type() for BPF_PROG_TYPE_EXT\n\nWhen loading a EXT program without specifying `attr->attach_prog_fd`,\nthe `prog->aux->dst_prog` will be null. At this time, calling\nresolve_prog_type() anywhere will result in a null pointer dereference.\n\nExample stack trace:\n\n[ 8.107863] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004\n[ 8.108262] Mem abort info:\n[ 8.108384] ESR = 0x0000000096000004\n[ 8.108547] EC = 0x25: DABT (current EL), IL = 32 bits\n[ 8.108722] SET = 0, FnV = 0\n[ 8.108827] EA = 0, S1PTW = 0\n[ 8.108939] FSC = 0x04: level 0 translation fault\n[ 8.109102] Data abort info:\n[ 8.109203] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n[ 8.109399] CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[ 8.109614] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[ 8.109836] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000101354000\n[ 8.110011] [0000000000000004] pgd=0000000000000000, p4d=0000000000000000\n[ 8.112624] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n[ 8.112783] Modules linked in:\n[ 8.113120] CPU: 0 PID: 99 Comm: may_access_dire Not tainted 6.10.0-rc3-next-20240613-dirty #1\n[ 8.113230] Hardware name: linux,dummy-virt (DT)\n[ 8.113390] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 8.113429] pc : may_access_direct_pkt_data+0x24/0xa0\n[ 8.113746] lr : add_subprog_and_kfunc+0x634/0x8e8\n[ 8.113798] sp : ffff80008283b9f0\n[ 8.113813] x29: ffff80008283b9f0 x28: ffff800082795048 x27: 0000000000000001\n[ 8.113881] x26: ffff0000c0bb2600 x25: 0000000000000000 x24: 0000000000000000\n[ 8.113897] x23: ffff0000c1134000 x22: 000000000001864f x21: ffff0000c1138000\n[ 8.113912] x20: 0000000000000001 x19: ffff0000c12b8000 x18: ffffffffffffffff\n[ 8.113929] x17: 0000000000000000 x16: 0000000000000000 x15: 0720072007200720\n[ 8.113944] x14: 0720072007200720 x13: 0720072007200720 x12: 0720072007200720\n[ 8.113958] x11: 0720072007200720 x10: 0000000000f9fca4 x9 : ffff80008021f4e4\n[ 8.113991] x8 : 0101010101010101 x7 : 746f72705f6d656d x6 : 000000001e0e0f5f\n[ 8.114006] x5 : 000000000001864f x4 : ffff0000c12b8000 x3 : 000000000000001c\n[ 8.114020] x2 : 0000000000000002 x1 : 0000000000000000 x0 : 0000000000000000\n[ 8.114126] Call trace:\n[ 8.114159] may_access_direct_pkt_data+0x24/0xa0\n[ 8.114202] bpf_check+0x3bc/0x28c0\n[ 8.114214] bpf_prog_load+0x658/0xa58\n[ 8.114227] __sys_bpf+0xc50/0x2250\n[ 8.114240] __arm64_sys_bpf+0x28/0x40\n[ 8.114254] invoke_syscall.constprop.0+0x54/0xf0\n[ 8.114273] do_el0_svc+0x4c/0xd8\n[ 8.114289] el0_svc+0x3c/0x140\n[ 8.114305] el0t_64_sync_handler+0x134/0x150\n[ 8.114331] el0t_64_sync+0x168/0x170\n[ 8.114477] Code: 7100707f 54000081 f9401c00 f9403800 (b9400403)\n[ 8.118672] ---[ end trace 0000000000000000 ]---\n\nOne way to fix it is by forcing `attach_prog_fd` non-empty when\nbpf_prog_load(). But this will lead to `libbpf_probe_bpf_prog_type`\nAPI broken which use verifier log to probe prog type and will log\nnothing if we reject invalid EXT prog before bpf_check().\n\nAnother way is by adding null check in resolve_prog_type().\n\nThe issue was introduced by commit 4a9c7bbe2ed4 ("bpf: Resolve to\nprog->aux->dst_prog->type only for BPF_PROG_TYPE_EXT") which wanted\nto correct type resolution for BPF_PROG_TYPE_TRACING programs. Before\nthat, the type resolution of BPF_PROG_TYPE_EXT prog actually follows\nthe logic below:\n\n prog->aux->dst_prog ? prog->aux->dst_prog->type : prog->type;\n\nIt implies that when EXT program is not yet attached to `dst_prog`,\nthe prog type should be EXT itself. This code worked fine in the past.\nSo just keep using it.\n\nFix this by returning `prog->type` for BPF_PROG_TYPE_EXT if `dst_prog`\nis not present in resolve_prog_type().

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ethtool: pse-pd: Fix possible null-deref\n\nFix a possible null dereference when a PSE supports both c33 and PoDL, but\nonly one of the netlink attributes is specified. The c33 or PoDL PSE\ncapabilities are already validated in the ethnl_set_pse_validate() call.

In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix infinite loop when replaying fast_commit\n\nWhen doing fast_commit replay an infinite loop may occur due to an\nuninitialized extent_status struct. ext4_ext_determine_insert_hole() does\nnot detect the replay and calls ext4_es_find_extent_range(), which will\nreturn immediately without initializing the 'es' variable.\n\nBecause 'es' contains garbage, an integer overflow may happen causing an\ninfinite loop in this function, easily reproducible using fstest generic/039.\n\nThis commit fixes this issue by unconditionally initializing the structure\nin function ext4_es_find_extent_range().\n\nThanks to Zhang Yi, for figuring out the real problem!

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Add null check before access structs\n\nIn enable_phantom_plane, we should better check null pointer before\naccessing various structs.

In the Linux kernel, the following vulnerability has been resolved:\n\nnfs: pass explicit offset/count to trace events\n\nnfs_folio_length is unsafe to use without having the folio locked and a\ncheck for a NULL ->f_mapping that protects against truncations and can\nlead to kernel crashes. E.g. when running xfstests generic/065 with\nall nfs trace points enabled.\n\nFollow the model of the XFS trace points and pass in an explіcit offset\nand length. This has the additional benefit that these values can\nbe more accurate as some of the users touch partial folio ranges.

In the Linux kernel, the following vulnerability has been resolved:\n\niio: Fix the sorting functionality in iio_gts_build_avail_time_table\n\nThe sorting in iio_gts_build_avail_time_table is not working as intended.\nIt could result in an out-of-bounds access when the time is zero.\n\nHere are more details:\n\n1. When the gts->itime_table[i].time_us is zero, e.g., the time\nsequence is `3, 0, 1`, the inner for-loop will not terminate and do\nout-of-bound writes. This is because once `times[j] > new`, the value\n`new` will be added in the current position and the `times[j]` will be\nmoved to `j+1` position, which makes the if-condition always hold.\nMeanwhile, idx will be added one, making the loop keep running without\ntermination and out-of-bound write.\n2. If none of the gts->itime_table[i].time_us is zero, the elements\nwill just be copied without being sorted as described in the comment\n"Sort times from all tables to one and remove duplicates".\n\nFor more details, please refer to\nhttps://lore.kernel.org/all/6dd0d822-046c-4dd2-9532-79d7ab96ec05@gmail.com.

In the Linux kernel, the following vulnerability has been resolved:\n\nASoc: PCM6240: Return directly after a failed devm_kzalloc() in pcmdevice_i2c_probe()\n\nThe value “-ENOMEM” was assigned to the local variable “ret”\nin one if branch after a devm_kzalloc() call failed at the beginning.\nThis error code will trigger then a pcmdevice_remove() call with a passed\nnull pointer so that an undesirable dereference will be performed.\nThus return the appropriate error code directly.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: lpfc: Fix a possible null pointer dereference\n\nIn function lpfc_xcvr_data_show, the memory allocation with kmalloc might\nfail, thereby making rdp_context a null pointer. In the following context\nand functions that use this pointer, there are dereferencing operations,\nleading to null pointer dereference.\n\nTo fix this issue, a null pointer check should be added. If it is null,\nuse scnprintf to notify the user and return len.

In the Linux kernel, the following vulnerability has been resolved:\n\ndm-raid: Fix WARN_ON_ONCE check for sync_thread in raid_resume\n\nrm-raid devices will occasionally trigger the following warning when\nbeing resumed after a table load because DM_RECOVERY_RUNNING is set:\n\nWARNING: CPU: 7 PID: 5660 at drivers/md/dm-raid.c:4105 raid_resume+0xee/0x100 [dm_raid]\n\nThe failing check is:\nWARN_ON_ONCE(test_bit(MD_RECOVERY_RUNNING, &mddev->recovery));\n\nThis check is designed to make sure that the sync thread isn't\nregistered, but md_check_recovery can set MD_RECOVERY_RUNNING without\nthe sync_thread ever getting registered. Instead of checking if\nMD_RECOVERY_RUNNING is set, check if sync_thread is non-NULL.

In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: mxs-dcp - Ensure payload is zero when using key slot\n\nWe could leak stack memory through the payload field when running\nAES with a key from one of the hardware's key slots. Fix this by\nensuring the payload field is set to 0 in such cases.\n\nThis does not affect the common use case when the key is supplied\nfrom main memory via the descriptor payload.

In the Linux kernel, the following vulnerability has been resolved:\n\ns390/dasd: fix error checks in dasd_copy_pair_store()\n\ndasd_add_busid() can return an error via ERR_PTR() if an allocation\nfails. However, two callsites in dasd_copy_pair_store() do not check\nthe result, potentially resulting in a NULL pointer dereference. Fix\nthis by checking the result with IS_ERR() and returning the error up\nthe stack.

In the Linux kernel, the following vulnerability has been resolved:\n\nexfat: fix potential deadlock on __exfat_get_dentry_set\n\nWhen accessing a file with more entries than ES_MAX_ENTRY_NUM, the bh-array\nis allocated in __exfat_get_entry_set. The problem is that the bh-array is\nallocated with GFP_KERNEL. It does not make sense. In the following cases,\na deadlock for sbi->s_lock between the two processes may occur.\n\n CPU0 CPU1\n ---- ----\n kswapd\n balance_pgdat\n lock(fs_reclaim)\n exfat_iterate\n lock(&sbi->s_lock)\n exfat_readdir\n exfat_get_uniname_from_ext_entry\n exfat_get_dentry_set\n __exfat_get_dentry_set\n kmalloc_array\n ...\n lock(fs_reclaim)\n ...\n evict\n exfat_evict_inode\n lock(&sbi->s_lock)\n\nTo fix this, let's allocate bh-array with GFP_NOFS.

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix extent map use-after-free when adding pages to compressed bio\n\nAt add_ra_bio_pages() we are accessing the extent map to calculate\n'add_size' after we dropped our reference on the extent map, resulting\nin a use-after-free. Fix this by computing 'add_size' before dropping our\nextent map reference.

In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: fix potential null pointer use in destroy_workqueue in init_cifs error path\n\nDan Carpenter reported a Smack static checker warning:\n fs/smb/client/cifsfs.c:1981 init_cifs()\n error: we previously assumed 'serverclose_wq' could be null (see line 1895)\n\nThe patch which introduced the serverclose workqueue used the wrong\noredering in error paths in init_cifs() for freeing it on errors.

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: imx-pxp: Fix ERR_PTR dereference in pxp_probe()\n\ndevm_regmap_init_mmio() can fail, add a check and bail out in case of\nerror.

In the Linux kernel, the following vulnerability has been resolved:\n\nPCI/DPC: Fix use-after-free on concurrent DPC and hot-removal\n\nKeith reports a use-after-free when a DPC event occurs concurrently to\nhot-removal of the same portion of the hierarchy:\n\nThe dpc_handler() awaits readiness of the secondary bus below the\nDownstream Port where the DPC event occurred. To do so, it polls the\nconfig space of the first child device on the secondary bus. If that\nchild device is concurrently removed, accesses to its struct pci_dev\ncause the kernel to oops.\n\nThat's because pci_bridge_wait_for_secondary_bus() neglects to hold a\nreference on the child device. Before v6.3, the function was only\ncalled on resume from system sleep or on runtime resume. Holding a\nreference wasn't necessary back then because the pciehp IRQ thread\ncould never run concurrently. (On resume from system sleep, IRQs are\nnot enabled until after the resume_noirq phase. And runtime resume is\nalways awaited before a PCI device is removed.)\n\nHowever starting with v6.3, pci_bridge_wait_for_secondary_bus() is also\ncalled on a DPC event. Commit 53b54ad074de ("PCI/DPC: Await readiness\nof secondary bus after reset"), which introduced that, failed to\nappreciate that pci_bridge_wait_for_secondary_bus() now needs to hold a\nreference on the child device because dpc_handler() and pciehp may\nindeed run concurrently. The commit was backported to v5.10+ stable\nkernels, so that's the oldest one affected.\n\nAdd the missing reference acquisition.\n\nAbridged stack trace:\n\n BUG: unable to handle page fault for address: 00000000091400c0\n CPU: 15 PID: 2464 Comm: irq/53-pcie-dpc 6.9.0\n RIP: pci_bus_read_config_dword+0x17/0x50\n pci_dev_wait()\n pci_bridge_wait_for_secondary_bus()\n dpc_reset_link()\n pcie_do_recovery()\n dpc_handler()

In the Linux kernel, the following vulnerability has been resolved:\n\nerofs: fix race in z_erofs_get_gbuf()\n\nIn z_erofs_get_gbuf(), the current task may be migrated to another\nCPU between `z_erofs_gbuf_id()` and `spin_lock(&gbuf->lock)`.\n\nTherefore, z_erofs_put_gbuf() will trigger the following issue\nwhich was found by stress test:\n\n<2>[772156.434168] kernel BUG at fs/erofs/zutil.c:58!\n..\n<4>[772156.435007]\n<4>[772156.439237] CPU: 0 PID: 3078 Comm: stress Kdump: loaded Tainted: G E 6.10.0-rc7+ #2\n<4>[772156.439239] Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 1.0.0 01/01/2017\n<4>[772156.439241] pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)\n<4>[772156.439243] pc : z_erofs_put_gbuf+0x64/0x70 [erofs]\n<4>[772156.439252] lr : z_erofs_lz4_decompress+0x600/0x6a0 [erofs]\n..\n<6>[772156.445958] stress (3127): drop_caches: 1\n<4>[772156.446120] Call trace:\n<4>[772156.446121] z_erofs_put_gbuf+0x64/0x70 [erofs]\n<4>[772156.446761] z_erofs_lz4_decompress+0x600/0x6a0 [erofs]\n<4>[772156.446897] z_erofs_decompress_queue+0x740/0xa10 [erofs]\n<4>[772156.447036] z_erofs_runqueue+0x428/0x8c0 [erofs]\n<4>[772156.447160] z_erofs_readahead+0x224/0x390 [erofs]\n..

In the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Update log->page_{mask,bits} if log->page_size changed\n\nIf an NTFS file system is mounted to another system with different\nPAGE_SIZE from the original system, log->page_size will change in\nlog_replay(), but log->page_{mask,bits} don't change correspondingly.\nThis will cause a panic because "u32 bytes = log->page_size - page_off"\nwill get a negative value in the later read_log_page().

In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: fsl: fsl_qmc_audio: Check devm_kasprintf() returned value\n\ndevm_kasprintf() can return a NULL pointer on failure but this returned\nvalue is not checked.\n\nFix this lack and check the returned value.

In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: handle inconsistent state in nilfs_btnode_create_block()\n\nSyzbot reported that a buffer state inconsistency was detected in\nnilfs_btnode_create_block(), triggering a kernel bug.\n\nIt is not appropriate to treat this inconsistency as a bug; it can occur\nif the argument block address (the buffer index of the newly created\nblock) is a virtual block number and has been reallocated due to\ncorruption of the bitmap used to manage its allocation state.\n\nSo, modify nilfs_btnode_create_block() and its callers to treat it as a\npossible filesystem error, rather than triggering a kernel bug.

In the Linux kernel, the following vulnerability has been resolved:\n\nblock: fix deadlock between sd_remove & sd_release\n\nOur test report the following hung task:\n\n[ 2538.459400] INFO: task "kworker/0:0":7 blocked for more than 188 seconds.\n[ 2538.459427] Call trace:\n[ 2538.459430] __switch_to+0x174/0x338\n[ 2538.459436] __schedule+0x628/0x9c4\n[ 2538.459442] schedule+0x7c/0xe8\n[ 2538.459447] schedule_preempt_disabled+0x24/0x40\n[ 2538.459453] __mutex_lock+0x3ec/0xf04\n[ 2538.459456] __mutex_lock_slowpath+0x14/0x24\n[ 2538.459459] mutex_lock+0x30/0xd8\n[ 2538.459462] del_gendisk+0xdc/0x350\n[ 2538.459466] sd_remove+0x30/0x60\n[ 2538.459470] device_release_driver_internal+0x1c4/0x2c4\n[ 2538.459474] device_release_driver+0x18/0x28\n[ 2538.459478] bus_remove_device+0x15c/0x174\n[ 2538.459483] device_del+0x1d0/0x358\n[ 2538.459488] __scsi_remove_device+0xa8/0x198\n[ 2538.459493] scsi_forget_host+0x50/0x70\n[ 2538.459497] scsi_remove_host+0x80/0x180\n[ 2538.459502] usb_stor_disconnect+0x68/0xf4\n[ 2538.459506] usb_unbind_interface+0xd4/0x280\n[ 2538.459510] device_release_driver_internal+0x1c4/0x2c4\n[ 2538.459514] device_release_driver+0x18/0x28\n[ 2538.459518] bus_remove_device+0x15c/0x174\n[ 2538.459523] device_del+0x1d0/0x358\n[ 2538.459528] usb_disable_device+0x84/0x194\n[ 2538.459532] usb_disconnect+0xec/0x300\n[ 2538.459537] hub_event+0xb80/0x1870\n[ 2538.459541] process_scheduled_works+0x248/0x4dc\n[ 2538.459545] worker_thread+0x244/0x334\n[ 2538.459549] kthread+0x114/0x1bc\n\n[ 2538.461001] INFO: task "fsck.":15415 blocked for more than 188 seconds.\n[ 2538.461014] Call trace:\n[ 2538.461016] __switch_to+0x174/0x338\n[ 2538.461021] __schedule+0x628/0x9c4\n[ 2538.461025] schedule+0x7c/0xe8\n[ 2538.461030] blk_queue_enter+0xc4/0x160\n[ 2538.461034] blk_mq_alloc_request+0x120/0x1d4\n[ 2538.461037] scsi_execute_cmd+0x7c/0x23c\n[ 2538.461040] ioctl_internal_command+0x5c/0x164\n[ 2538.461046] scsi_set_medium_removal+0x5c/0xb0\n[ 2538.461051] sd_release+0x50/0x94\n[ 2538.461054] blkdev_put+0x190/0x28c\n[ 2538.461058] blkdev_release+0x28/0x40\n[ 2538.461063] __fput+0xf8/0x2a8\n[ 2538.461066] __fput_sync+0x28/0x5c\n[ 2538.461070] __arm64_sys_close+0x84/0xe8\n[ 2538.461073] invoke_syscall+0x58/0x114\n[ 2538.461078] el0_svc_common+0xac/0xe0\n[ 2538.461082] do_el0_svc+0x1c/0x28\n[ 2538.461087] el0_svc+0x38/0x68\n[ 2538.461090] el0t_64_sync_handler+0x68/0xbc\n[ 2538.461093] el0t_64_sync+0x1a8/0x1ac\n\n T1: T2:\n sd_remove\n del_gendisk\n __blk_mark_disk_dead\n blk_freeze_queue_start\n ++q->mq_freeze_depth\n bdev_release\n mutex_lock(&disk->open_mutex)\n sd_release\n scsi_execute_cmd\n blk_queue_enter\n wait_event(!q->mq_freeze_depth)\n mutex_lock(&disk->open_mutex)\n\nSCSI does not set GD_OWNS_QUEUE, so QUEUE_FLAG_DYING is not set in\nthis scenario. This is a classic ABBA deadlock. To fix the deadlock,\nmake sure we don't try to acquire disk->open_mutex after freezing\nthe queue.

In the Linux kernel, the following vulnerability has been resolved:\n\nice: Add a per-VF limit on number of FDIR filters\n\nWhile the iavf driver adds a s/w limit (128) on the number of FDIR\nfilters that the VF can request, a malicious VF driver can request more\nthan that and exhaust the resources for other VFs.\n\nAdd a similar limit in ice.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Complete command early within lock\n\nA crash was observed while performing NPIV and FW reset,\n\n BUG: kernel NULL pointer dereference, address: 000000000000001c\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 1 PREEMPT_RT SMP NOPTI\n RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0\n RSP: 0018:ffffc90026f47b88 EFLAGS: 00010246\n RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000002\n RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8881041130d0\n RBP: ffff8881041130d0 R08: 0000000000000000 R09: 0000000000000034\n R10: ffffc90026f47c48 R11: 0000000000000031 R12: 0000000000000000\n R13: 0000000000000000 R14: ffff8881565e4a20 R15: 0000000000000000\n FS: 00007f4c69ed3d00(0000) GS:ffff889faac80000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000000000000001c CR3: 0000000288a50002 CR4: 00000000007706e0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n PKRU: 55555554\n Call Trace:\n <TASK>\n ? __die_body+0x1a/0x60\n ? page_fault_oops+0x16f/0x4a0\n ? do_user_addr_fault+0x174/0x7f0\n ? exc_page_fault+0x69/0x1a0\n ? asm_exc_page_fault+0x22/0x30\n ? dma_direct_unmap_sg+0x51/0x1e0\n ? preempt_count_sub+0x96/0xe0\n qla2xxx_qpair_sp_free_dma+0x29f/0x3b0 [qla2xxx]\n qla2xxx_qpair_sp_compl+0x60/0x80 [qla2xxx]\n __qla2x00_abort_all_cmds+0xa2/0x450 [qla2xxx]\n\nThe command completion was done early while aborting the commands in driver\nunload path but outside lock to avoid the WARN_ON condition of performing\ndma_free_attr within the lock. However this caused race condition while\ncommand completion via multiple paths causing system crash.\n\nHence complete the command early in unload path but within the lock to\navoid race condition.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: mediatek: Fix potential NULL pointer dereference in dummy net_device handling\n\nMove the freeing of the dummy net_device from mtk_free_dev() to\nmtk_remove().\n\nPreviously, if alloc_netdev_dummy() failed in mtk_probe(),\neth->dummy_dev would be NULL. The error path would then call\nmtk_free_dev(), which in turn called free_netdev() assuming dummy_dev\nwas allocated (but it was not), potentially causing a NULL pointer\ndereference.\n\nBy moving free_netdev() to mtk_remove(), we ensure it's only called when\nmtk_probe() has succeeded and dummy_dev is fully allocated. This\naddresses a potential NULL pointer dereference detected by Smatch[1].

In the Linux kernel, the following vulnerability has been resolved:\n\nspi: microchip-core: ensure TX and RX FIFOs are empty at start of a transfer\n\nWhile transmitting with rx_len == 0, the RX FIFO is not going to be\nemptied in the interrupt handler. A subsequent transfer could then\nread crap from the previous transfer out of the RX FIFO into the\nstart RX buffer. The core provides a register that will empty the RX and\nTX FIFOs, so do that before each transfer.

In the Linux kernel, the following vulnerability has been resolved:\n\niommu: sprd: Avoid NULL deref in sprd_iommu_hw_en\n\nIn sprd_iommu_cleanup() before calling function sprd_iommu_hw_en()\ndom->sdev is equal to NULL, which leads to null dereference.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/client: Fix error code in drm_client_buffer_vmap_local()\n\nThis function accidentally returns zero/success on the failure path.\nIt leads to locking issues and an uninitialized *map_copy in the\ncaller.

In the Linux kernel, the following vulnerability has been resolved:\n\nRevert "ALSA: firewire-lib: operate for period elapse event in process context"\n\nCommit 7ba5ca32fe6e ("ALSA: firewire-lib: operate for period elapse event\nin process context") removed the process context workqueue from\namdtp_domain_stream_pcm_pointer() and update_pcm_pointers() to remove\nits overhead.\n\nWith RME Fireface 800, this lead to a regression since\nKernels 5.14.0, causing an AB/BA deadlock competition for the\nsubstream lock with eventual system freeze under ALSA operation:\n\nthread 0:\n * (lock A) acquire substream lock by\n snd_pcm_stream_lock_irq() in\n snd_pcm_status64()\n * (lock B) wait for tasklet to finish by calling\n tasklet_unlock_spin_wait() in\n tasklet_disable_in_atomic() in\n ohci_flush_iso_completions() of ohci.c\n\nthread 1:\n * (lock B) enter tasklet\n * (lock A) attempt to acquire substream lock,\n waiting for it to be released:\n snd_pcm_stream_lock_irqsave() in\n snd_pcm_period_elapsed() in\n update_pcm_pointers() in\n process_ctx_payloads() in\n process_rx_packets() of amdtp-stream.c\n\n? tasklet_unlock_spin_wait\n </NMI>\n <TASK>\nohci_flush_iso_completions firewire_ohci\namdtp_domain_stream_pcm_pointer snd_firewire_lib\nsnd_pcm_update_hw_ptr0 snd_pcm\nsnd_pcm_status64 snd_pcm\n\n? native_queued_spin_lock_slowpath\n </NMI>\n <IRQ>\n_raw_spin_lock_irqsave\nsnd_pcm_period_elapsed snd_pcm\nprocess_rx_packets snd_firewire_lib\nirq_target_callback snd_firewire_lib\nhandle_it_packet firewire_ohci\ncontext_tasklet firewire_ohci\n\nRestore the process context work queue to prevent deadlock\nAB/BA deadlock competition for ALSA substream lock of\nsnd_pcm_stream_lock_irq() in snd_pcm_status64()\nand snd_pcm_stream_lock_irqsave() in snd_pcm_period_elapsed().\n\nrevert commit 7ba5ca32fe6e ("ALSA: firewire-lib: operate for period\nelapse event in process context")\n\nReplace inline description to prevent future deadlock.

In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: assign CURSEG_ALL_DATA_ATGC if blkaddr is valid\n\nmkdir /mnt/test/comp\nf2fs_io setflags compression /mnt/test/comp\ndd if=/dev/zero of=/mnt/test/comp/testfile bs=16k count=1\ntruncate --size 13 /mnt/test/comp/testfile\n\nIn the above scenario, we can get a BUG_ON.\n kernel BUG at fs/f2fs/segment.c:3589!\n Call Trace:\n do_write_page+0x78/0x390 [f2fs]\n f2fs_outplace_write_data+0x62/0xb0 [f2fs]\n f2fs_do_write_data_page+0x275/0x740 [f2fs]\n f2fs_write_single_data_page+0x1dc/0x8f0 [f2fs]\n f2fs_write_multi_pages+0x1e5/0xae0 [f2fs]\n f2fs_write_cache_pages+0xab1/0xc60 [f2fs]\n f2fs_write_data_pages+0x2d8/0x330 [f2fs]\n do_writepages+0xcf/0x270\n __writeback_single_inode+0x44/0x350\n writeback_sb_inodes+0x242/0x530\n __writeback_inodes_wb+0x54/0xf0\n wb_writeback+0x192/0x310\n wb_workfn+0x30d/0x400\n\nThe reason is we gave CURSEG_ALL_DATA_ATGC to COMPR_ADDR where the\npage was set the gcing flag by set_cluster_dirty().

In the Linux kernel, the following vulnerability has been resolved:\n\nsched: act_ct: take care of padding in struct zones_ht_key\n\nBlamed commit increased lookup key size from 2 bytes to 16 bytes,\nbecause zones_ht_key got a struct net pointer.\n\nMake sure rhashtable_lookup() is not using the padding bytes\nwhich are not initialized.\n\n BUG: KMSAN: uninit-value in rht_ptr_rcu include/linux/rhashtable.h:376 [inline]\n BUG: KMSAN: uninit-value in __rhashtable_lookup include/linux/rhashtable.h:607 [inline]\n BUG: KMSAN: uninit-value in rhashtable_lookup include/linux/rhashtable.h:646 [inline]\n BUG: KMSAN: uninit-value in rhashtable_lookup_fast include/linux/rhashtable.h:672 [inline]\n BUG: KMSAN: uninit-value in tcf_ct_flow_table_get+0x611/0x2260 net/sched/act_ct.c:329\n rht_ptr_rcu include/linux/rhashtable.h:376 [inline]\n __rhashtable_lookup include/linux/rhashtable.h:607 [inline]\n rhashtable_lookup include/linux/rhashtable.h:646 [inline]\n rhashtable_lookup_fast include/linux/rhashtable.h:672 [inline]\n tcf_ct_flow_table_get+0x611/0x2260 net/sched/act_ct.c:329\n tcf_ct_init+0xa67/0x2890 net/sched/act_ct.c:1408\n tcf_action_init_1+0x6cc/0xb30 net/sched/act_api.c:1425\n tcf_action_init+0x458/0xf00 net/sched/act_api.c:1488\n tcf_action_add net/sched/act_api.c:2061 [inline]\n tc_ctl_action+0x4be/0x19d0 net/sched/act_api.c:2118\n rtnetlink_rcv_msg+0x12fc/0x1410 net/core/rtnetlink.c:6647\n netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2550\n rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6665\n netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline]\n netlink_unicast+0xf52/0x1260 net/netlink/af_netlink.c:1357\n netlink_sendmsg+0x10da/0x11e0 net/netlink/af_netlink.c:1901\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x30f/0x380 net/socket.c:745\n ____sys_sendmsg+0x877/0xb60 net/socket.c:2597\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2651\n __sys_sendmsg net/socket.c:2680 [inline]\n __do_sys_sendmsg net/socket.c:2689 [inline]\n __se_sys_sendmsg net/socket.c:2687 [inline]\n __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2687\n x64_sys_call+0x2dd6/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:47\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nLocal variable key created at:\n tcf_ct_flow_table_get+0x4a/0x2260 net/sched/act_ct.c:324\n tcf_ct_init+0xa67/0x2890 net/sched/act_ct.c:1408

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: iptables: Fix null-ptr-deref in iptable_nat_table_init().\n\nWe had a report that iptables-restore sometimes triggered null-ptr-deref\nat boot time. [0]\n\nThe problem is that iptable_nat_table_init() is exposed to user space\nbefore the kernel fully initialises netns.\n\nIn the small race window, a user could call iptable_nat_table_init()\nthat accesses net_generic(net, iptable_nat_net_id), which is available\nonly after registering iptable_nat_net_ops.\n\nLet's call register_pernet_subsys() before xt_register_template().\n\n[0]:\nbpfilter: Loaded bpfilter_umh pid 11702\nStarted bpfilter\nBUG: kernel NULL pointer dereference, address: 0000000000000013\n PF: supervisor write access in kernel mode\n PF: error_code(0x0002) - not-present page\nPGD 0 P4D 0\nPREEMPT SMP NOPTI\nCPU: 2 PID: 11879 Comm: iptables-restor Not tainted 6.1.92-99.174.amzn2023.x86_64 #1\nHardware name: Amazon EC2 c6i.4xlarge/, BIOS 1.0 10/16/2017\nRIP: 0010:iptable_nat_table_init (net/ipv4/netfilter/iptable_nat.c:87 net/ipv4/netfilter/iptable_nat.c:121) iptable_nat\nCode: 10 4c 89 f6 48 89 ef e8 0b 19 bb ff 41 89 c4 85 c0 75 38 41 83 c7 01 49 83 c6 28 41 83 ff 04 75 dc 48 8b 44 24 08 48 8b 0c 24 <48> 89 08 4c 89 ef e8 a2 3b a2 cf 48 83 c4 10 44 89 e0 5b 5d 41 5c\nRSP: 0018:ffffbef902843cd0 EFLAGS: 00010246\nRAX: 0000000000000013 RBX: ffff9f4b052caa20 RCX: ffff9f4b20988d80\nRDX: 0000000000000000 RSI: 0000000000000064 RDI: ffffffffc04201c0\nRBP: ffff9f4b29394000 R08: ffff9f4b07f77258 R09: ffff9f4b07f77240\nR10: 0000000000000000 R11: ffff9f4b09635388 R12: 0000000000000000\nR13: ffff9f4b1a3c6c00 R14: ffff9f4b20988e20 R15: 0000000000000004\nFS: 00007f6284340000(0000) GS:ffff9f51fe280000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000013 CR3: 00000001d10a6005 CR4: 00000000007706e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n <TASK>\n ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259)\n ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259)\n ? xt_find_table_lock (net/netfilter/x_tables.c:1259)\n ? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420)\n ? page_fault_oops (arch/x86/mm/fault.c:727)\n ? exc_page_fault (./arch/x86/include/asm/irqflags.h:40 ./arch/x86/include/asm/irqflags.h:75 arch/x86/mm/fault.c:1470 arch/x86/mm/fault.c:1518)\n ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:570)\n ? iptable_nat_table_init (net/ipv4/netfilter/iptable_nat.c:87 net/ipv4/netfilter/iptable_nat.c:121) iptable_nat\n xt_find_table_lock (net/netfilter/x_tables.c:1259)\n xt_request_find_table_lock (net/netfilter/x_tables.c:1287)\n get_info (net/ipv4/netfilter/ip_tables.c:965)\n ? security_capable (security/security.c:809 (discriminator 13))\n ? ns_capable (kernel/capability.c:376 kernel/capability.c:397)\n ? do_ipt_get_ctl (net/ipv4/netfilter/ip_tables.c:1656)\n ? bpfilter_send_req (net/bpfilter/bpfilter_kern.c:52) bpfilter\n nf_getsockopt (net/netfilter/nf_sockopt.c:116)\n ip_getsockopt (net/ipv4/ip_sockglue.c:1827)\n __sys_getsockopt (net/socket.c:2327)\n __x64_sys_getsockopt (net/socket.c:2342 net/socket.c:2339 net/socket.c:2339)\n do_syscall_64 (arch/x86/entry/common.c:51 arch/x86/entry/common.c:81)\n entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)\nRIP: 0033:0x7f62844685ee\nCode: 48 8b 0d 45 28 0f 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 49 89 ca b8 37 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 0a c3 66 0f 1f 84 00 00 00 00 00 48 8b 15 09\nRSP: 002b:00007ffd1f83d638 EFLAGS: 00000246 ORIG_RAX: 0000000000000037\nRAX: ffffffffffffffda RBX: 00007ffd1f83d680 RCX: 00007f62844685ee\nRDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000004\nRBP: 0000000000000004 R08: 00007ffd1f83d670 R09: 0000558798ffa2a0\nR10: 00007ffd1f83d680 R11: 0000000000000246 R12: 00007ffd1f83e3b2\nR13: 00007f628455baa0 R14: 00007ffd1f83d7b0 R15: 00007f628457a008\n </TASK>\nModules linked in: iptable_nat(+) bpfilter rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache veth xt_state xt_connmark xt_nat xt_statistic xt_MASQUERADE xt_mark xt_addrtype ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables nfnetlink overlay nls_ascii nls_cp437 vfat fat ghash_clmulni_intel aesni_intel ena crypto_simd ptp cryptd i8042 pps_core serio button sunrpc sch_fq_codel configfs loop dm_mod fuse dax dmi_sysfs crc32_pclmul crc32c_intel efivarfs\nCR2: 0000000000000013

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: iptables: Fix potential null-ptr-deref in ip6table_nat_table_init().\n\nip6table_nat_table_init() accesses net->gen->ptr[ip6table_nat_net_ops.id],\nbut the function is exposed to user space before the entry is allocated\nvia register_pernet_subsys().\n\nLet's call register_pernet_subsys() before xt_register_template().

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Fix missing lock on sync reset reload\n\nOn sync reset reload work, when remote host updates devlink on reload\nactions performed on that host, it misses taking devlink lock before\ncalling devlink_remote_reload_actions_performed() which results in\ntriggering lock assert like the following:\n\nWARNING: CPU: 4 PID: 1164 at net/devlink/core.c:261 devl_assert_locked+0x3e/0x50\n…\n CPU: 4 PID: 1164 Comm: kworker/u96:6 Tainted: G S W 6.10.0-rc2+ #116\n Hardware name: Supermicro SYS-2028TP-DECTR/X10DRT-PT, BIOS 2.0 12/18/2015\n Workqueue: mlx5_fw_reset_events mlx5_sync_reset_reload_work [mlx5_core]\n RIP: 0010:devl_assert_locked+0x3e/0x50\n…\n Call Trace:\n <TASK>\n ? __warn+0xa4/0x210\n ? devl_assert_locked+0x3e/0x50\n ? report_bug+0x160/0x280\n ? handle_bug+0x3f/0x80\n ? exc_invalid_op+0x17/0x40\n ? asm_exc_invalid_op+0x1a/0x20\n ? devl_assert_locked+0x3e/0x50\n devlink_notify+0x88/0x2b0\n ? mlx5_attach_device+0x20c/0x230 [mlx5_core]\n ? __pfx_devlink_notify+0x10/0x10\n ? process_one_work+0x4b6/0xbb0\n process_one_work+0x4b6/0xbb0\n[…]

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: make cow_file_range_inline() honor locked_page on error\n\nThe btrfs buffered write path runs through __extent_writepage() which\nhas some tricky return value handling for writepage_delalloc().\nSpecifically, when that returns 1, we exit, but for other return values\nwe continue and end up calling btrfs_folio_end_all_writers(). If the\nfolio has been unlocked (note that we check the PageLocked bit at the\nstart of __extent_writepage()), this results in an assert panic like\nthis one from syzbot:\n\n BTRFS: error (device loop0 state EAL) in free_log_tree:3267: errno=-5 IO failure\n BTRFS warning (device loop0 state EAL): Skipping commit of aborted transaction.\n BTRFS: error (device loop0 state EAL) in cleanup_transaction:2018: errno=-5 IO failure\n assertion failed: folio_test_locked(folio), in fs/btrfs/subpage.c:871\n ------------[ cut here ]------------\n kernel BUG at fs/btrfs/subpage.c:871!\n Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI\n CPU: 1 PID: 5090 Comm: syz-executor225 Not tainted\n 6.10.0-syzkaller-05505-gb1bc554e009e #0\n Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS\n Google 06/27/2024\n RIP: 0010:btrfs_folio_end_all_writers+0x55b/0x610 fs/btrfs/subpage.c:871\n Code: e9 d3 fb ff ff e8 25 22 c2 fd 48 c7 c7 c0 3c 0e 8c 48 c7 c6 80 3d\n 0e 8c 48 c7 c2 60 3c 0e 8c b9 67 03 00 00 e8 66 47 ad 07 90 <0f> 0b e8\n 6e 45 b0 07 4c 89 ff be 08 00 00 00 e8 21 12 25 fe 4c 89\n RSP: 0018:ffffc900033d72e0 EFLAGS: 00010246\n RAX: 0000000000000045 RBX: 00fff0000000402c RCX: 663b7a08c50a0a00\n RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000\n RBP: ffffc900033d73b0 R08: ffffffff8176b98c R09: 1ffff9200067adfc\n R10: dffffc0000000000 R11: fffff5200067adfd R12: 0000000000000001\n R13: dffffc0000000000 R14: 0000000000000000 R15: ffffea0001cbee80\n FS: 0000000000000000(0000) GS:ffff8880b9500000(0000)\n knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f5f076012f8 CR3: 000000000e134000 CR4: 00000000003506f0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n <TASK>\n __extent_writepage fs/btrfs/extent_io.c:1597 [inline]\n extent_write_cache_pages fs/btrfs/extent_io.c:2251 [inline]\n btrfs_writepages+0x14d7/0x2760 fs/btrfs/extent_io.c:2373\n do_writepages+0x359/0x870 mm/page-writeback.c:2656\n filemap_fdatawrite_wbc+0x125/0x180 mm/filemap.c:397\n __filemap_fdatawrite_range mm/filemap.c:430 [inline]\n __filemap_fdatawrite mm/filemap.c:436 [inline]\n filemap_flush+0xdf/0x130 mm/filemap.c:463\n btrfs_release_file+0x117/0x130 fs/btrfs/file.c:1547\n __fput+0x24a/0x8a0 fs/file_table.c:422\n task_work_run+0x24f/0x310 kernel/task_work.c:222\n exit_task_work include/linux/task_work.h:40 [inline]\n do_exit+0xa2f/0x27f0 kernel/exit.c:877\n do_group_exit+0x207/0x2c0 kernel/exit.c:1026\n __do_sys_exit_group kernel/exit.c:1037 [inline]\n __se_sys_exit_group kernel/exit.c:1035 [inline]\n __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1035\n x64_sys_call+0x2634/0x2640\n arch/x86/include/generated/asm/syscalls_64.h:232\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n RIP: 0033:0x7f5f075b70c9\n Code: Unable to access opcode bytes at\n 0x7f5f075b709f.\n\nI was hitting the same issue by doing hundreds of accelerated runs of\ngeneric/475, which also hits IO errors by design.\n\nI instrumented that reproducer with bpftrace and found that the\nundesirable folio_unlock was coming from the following callstack:\n\n folio_unlock+5\n __process_pages_contig+475\n cow_file_range_inline.constprop.0+230\n cow_file_range+803\n btrfs_run_delalloc_range+566\n writepage_delalloc+332\n __extent_writepage # inlined in my stacktrace, but I added it here\n extent_write_cache_pages+622\n\nLooking at the bisected-to patch in the syzbot report, Josef realized\nthat the logic of the cow_file_range_inline error path subtly changing.\nIn the past, on error, it jumped to out_unlock in cow_file_range(),\nwhich honors the locked_page, so when we ultimately call\nfolio_end_all_writers(), the folio of interest is still locked. After\nthe change, we always unlocked ignoring the locked_page, on both success\nand error. On the success path, this all results in returning 1 to\n__extent_writepage(), which skips the folio_end_all_writers() call,\nwhich makes it OK to have unlocked.\n\nFix the bug by wiring the locked_page into cow_file_range_inline() and\nonly setting locked_page to NULL on success.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/v3d: Prevent out of bounds access in performance query extensions\n\nCheck that the number of perfmons userspace is passing in the copy and\nreset extensions is not greater than the internal kernel storage where\nthe ids will be copied into.\n\n(cherry picked from commit f32b5128d2c440368b5bf3a7a356823e235caabb)

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/v3d: Fix potential memory leak in the timestamp extension\n\nIf fetching of userspace memory fails during the main loop, all drm sync\nobjs looked up until that point will be leaked because of the missing\ndrm_syncobj_put.\n\nFix it by exporting and using a common cleanup helper.\n\n(cherry picked from commit 753ce4fea62182c77e1691ab4f9022008f25b62e)

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/v3d: Fix potential memory leak in the performance extension\n\nIf fetching of userspace memory fails during the main loop, all drm sync\nobjs looked up until that point will be leaked because of the missing\ndrm_syncobj_put.\n\nFix it by exporting and using a common cleanup helper.\n\n(cherry picked from commit 484de39fa5f5b7bd0c5f2e2c5265167250ef7501)

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/v3d: Validate passed in drm syncobj handles in the timestamp extension\n\nIf userspace provides an unknown or invalid handle anywhere in the handle\narray the rest of the driver will not handle that well.\n\nFix it by checking handle was looked up successfully or otherwise fail the\nextension by jumping into the existing unwind.\n\n(cherry picked from commit 8d1276d1b8f738c3afe1457d4dff5cc66fc848a3)

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/v3d: Validate passed in drm syncobj handles in the performance extension\n\nIf userspace provides an unknown or invalid handle anywhere in the handle\narray the rest of the driver will not handle that well.\n\nFix it by checking handle was looked up successfully or otherwise fail the\nextension by jumping into the existing unwind.\n\n(cherry picked from commit a546b7e4d73c23838d7e4d2c92882b3ca902d213)

In the Linux kernel, the following vulnerability has been resolved:\n\nmm: huge_memory: use !CONFIG_64BIT to relax huge page alignment on 32 bit machines\n\nYves-Alexis Perez reported commit 4ef9ad19e176 ("mm: huge_memory: don't\nforce huge page alignment on 32 bit") didn't work for x86_32 [1]. It is\nbecause x86_32 uses CONFIG_X86_32 instead of CONFIG_32BIT.\n\n!CONFIG_64BIT should cover all 32 bit machines.\n\n[1] https://lore.kernel.org/linux-mm/CAHbLzkr1LwH3pcTgM+aGQ31ip2bKqiqEQ8=FQB+t2c3dhNKNHA@mail.gmail.com/

In the Linux kernel, the following vulnerability has been resolved:\n\next4: use memtostr_pad() for s_volume_name\n\nAs with the other strings in struct ext4_super_block, s_volume_name is\nnot NUL terminated. The other strings were marked in commit 072ebb3bffe6\n("ext4: add nonstring annotations to ext4.h"). Using strscpy() isn't\nthe right replacement for strncpy(); it should use memtostr_pad()\ninstead.

In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Fix server re-repick on subrequest retry\n\nWhen a subrequest is marked for needing retry, netfs will call\ncifs_prepare_write() which will make cifs repick the server for the op\nbefore renegotiating credits; it then calls cifs_issue_write() which\ninvokes smb2_async_writev() - which re-repicks the server.\n\nIf a different server is then selected, this causes the increment of\nserver->in_flight to happen against one record and the decrement to happen\nagainst another, leading to misaccounting.\n\nFix this by just removing the repick code in smb2_async_writev(). As this\nis only called from netfslib-driven code, cifs_prepare_write() should\nalways have been called first, and so server should never be NULL and the\npreparatory step is repeated in the event that we do a retry.\n\nThe problem manifests as a warning looking something like:\n\n WARNING: CPU: 4 PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs]\n ...\n RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs]\n ...\n smb2_writev_callback+0x334/0x560 [cifs]\n cifs_demultiplex_thread+0x77a/0x11b0 [cifs]\n kthread+0x187/0x1d0\n ret_from_fork+0x34/0x60\n ret_from_fork_asm+0x1a/0x30\n\nWhich may be triggered by a number of different xfstests running against an\nAzure server in multichannel mode. generic/249 seems the most repeatable,\nbut generic/215, generic/249 and generic/308 may also show it.

In the Linux kernel, the following vulnerability has been resolved:\n\ntpm: Use auth only after NULL check in tpm_buf_check_hmac_response()\n\nDereference auth after NULL check in tpm_buf_check_hmac_response().\nOtherwise, unless tpm2_sessions_init() was called, a call can cause NULL\ndereference, when TCG_TPM2_HMAC is enabled.\n\n[jarkko: adjusted the commit message.]

In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: fix error pbuf checking\n\nSyz reports a problem, which boils down to NULL vs IS_ERR inconsistent\nerror handling in io_alloc_pbuf_ring().\n\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nRIP: 0010:__io_remove_buffers+0xac/0x700 io_uring/kbuf.c:341\nCall Trace:\n <TASK>\n io_put_bl io_uring/kbuf.c:378 [inline]\n io_destroy_buffers+0x14e/0x490 io_uring/kbuf.c:392\n io_ring_ctx_free+0xa00/0x1070 io_uring/io_uring.c:2613\n io_ring_exit_work+0x80f/0x8a0 io_uring/io_uring.c:2844\n process_one_work kernel/workqueue.c:3231 [inline]\n process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312\n worker_thread+0x86d/0xd40 kernel/workqueue.c:3390\n kthread+0x2f0/0x390 kernel/kthread.c:389\n ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

In the Linux kernel, the following vulnerability has been resolved:\n\nmm: page_ref: remove folio_try_get_rcu()\n\nThe below bug was reported on a non-SMP kernel:\n\n[ 275.267158][ T4335] ------------[ cut here ]------------\n[ 275.267949][ T4335] kernel BUG at include/linux/page_ref.h:275!\n[ 275.268526][ T4335] invalid opcode: 0000 [#1] KASAN PTI\n[ 275.269001][ T4335] CPU: 0 PID: 4335 Comm: trinity-c3 Not tainted 6.7.0-rc4-00061-gefa7df3e3bb5 #1\n[ 275.269787][ T4335] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\n[ 275.270679][ T4335] RIP: 0010:try_get_folio (include/linux/page_ref.h:275 (discriminator 3) mm/gup.c:79 (discriminator 3))\n[ 275.272813][ T4335] RSP: 0018:ffffc90005dcf650 EFLAGS: 00010202\n[ 275.273346][ T4335] RAX: 0000000000000246 RBX: ffffea00066e0000 RCX: 0000000000000000\n[ 275.274032][ T4335] RDX: fffff94000cdc007 RSI: 0000000000000004 RDI: ffffea00066e0034\n[ 275.274719][ T4335] RBP: ffffea00066e0000 R08: 0000000000000000 R09: fffff94000cdc006\n[ 275.275404][ T4335] R10: ffffea00066e0037 R11: 0000000000000000 R12: 0000000000000136\n[ 275.276106][ T4335] R13: ffffea00066e0034 R14: dffffc0000000000 R15: ffffea00066e0008\n[ 275.276790][ T4335] FS: 00007fa2f9b61740(0000) GS:ffffffff89d0d000(0000) knlGS:0000000000000000\n[ 275.277570][ T4335] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 275.278143][ T4335] CR2: 00007fa2f6c00000 CR3: 0000000134b04000 CR4: 00000000000406f0\n[ 275.278833][ T4335] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 275.279521][ T4335] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 275.280201][ T4335] Call Trace:\n[ 275.280499][ T4335] <TASK>\n[ 275.280751][ T4335] ? die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434 arch/x86/kernel/dumpstack.c:447)\n[ 275.281087][ T4335] ? do_trap (arch/x86/kernel/traps.c:112 arch/x86/kernel/traps.c:153)\n[ 275.281463][ T4335] ? try_get_folio (include/linux/page_ref.h:275 (discriminator 3) mm/gup.c:79 (discriminator 3))\n[ 275.281884][ T4335] ? try_get_folio (include/linux/page_ref.h:275 (discriminator 3) mm/gup.c:79 (discriminator 3))\n[ 275.282300][ T4335] ? do_error_trap (arch/x86/kernel/traps.c:174)\n[ 275.282711][ T4335] ? try_get_folio (include/linux/page_ref.h:275 (discriminator 3) mm/gup.c:79 (discriminator 3))\n[ 275.283129][ T4335] ? handle_invalid_op (arch/x86/kernel/traps.c:212)\n[ 275.283561][ T4335] ? try_get_folio (include/linux/page_ref.h:275 (discriminator 3) mm/gup.c:79 (discriminator 3))\n[ 275.283990][ T4335] ? exc_invalid_op (arch/x86/kernel/traps.c:264)\n[ 275.284415][ T4335] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:568)\n[ 275.284859][ T4335] ? try_get_folio (include/linux/page_ref.h:275 (discriminator 3) mm/gup.c:79 (discriminator 3))\n[ 275.285278][ T4335] try_grab_folio (mm/gup.c:148)\n[ 275.285684][ T4335] __get_user_pages (mm/gup.c:1297 (discriminator 1))\n[ 275.286111][ T4335] ? __pfx___get_user_pages (mm/gup.c:1188)\n[ 275.286579][ T4335] ? __pfx_validate_chain (kernel/locking/lockdep.c:3825)\n[ 275.287034][ T4335] ? mark_lock (kernel/locking/lockdep.c:4656 (discriminator 1))\n[ 275.287416][ T4335] __gup_longterm_locked (mm/gup.c:1509 mm/gup.c:2209)\n[ 275.288192][ T4335] ? __pfx___gup_longterm_locked (mm/gup.c:2204)\n[ 275.288697][ T4335] ? __pfx_lock_acquire (kernel/locking/lockdep.c:5722)\n[ 275.289135][ T4335] ? __pfx___might_resched (kernel/sched/core.c:10106)\n[ 275.289595][ T4335] pin_user_pages_remote (mm/gup.c:3350)\n[ 275.290041][ T4335] ? __pfx_pin_user_pages_remote (mm/gup.c:3350)\n[ 275.290545][ T4335] ? find_held_lock (kernel/locking/lockdep.c:5244 (discriminator 1))\n[ 275.290961][ T4335] ? mm_access (kernel/fork.c:1573)\n[ 275.291353][ T4335] process_vm_rw_single_vec+0x142/0x360\n[ 275.291900][ T4335] ? __pfx_process_vm_rw_single_vec+0x10/0x10\n[ 275.292471][ T4335] ? mm_access (kernel/fork.c:1573)\n[ 275.292859][ T4335] process_vm_rw_core+0x272/0x4e0\n[ 275.293384][ T4335] ? hlock_class (arch/x86/include/asm/bitops.h:227 arch/x86/include/asm/bitops.h:239 include/asm-generic/bitops/instrumented-non-atomic.h:142 kernel/locking/lockdep.c:228)\n[ 275.293780][ T4335] ? __pfx_process_vm_rw_core+0x10/0x10\n[ 275.294350][ T4335] process_vm_rw (mm/process_vm_access.c:284)\n[ 275.294748][ T4335] ? __pfx_process_vm_rw (mm/process_vm_access.c:259)\n[ 275.295197][ T4335] ? __task_pid_nr_ns (include/linux/rcupdate.h:306 (discriminator 1) include/linux/rcupdate.h:780 (discriminator 1) kernel/pid.c:504 (discriminator 1))\n[ 275.295634][ T4335] __x64_sys_process_vm_readv (mm/process_vm_access.c:291)\n[ 275.296139][ T4335] ? syscall_enter_from_user_mode (kernel/entry/common.c:94 kernel/entry/common.c:112)\n[ 275.296642][ T4335] do_syscall_64 (arch/x86/entry/common.c:51 (discriminator 1) arch/x86/entry/common.c:82 (discriminator 1))\n[ 275.297032][ T4335] ? __task_pid_nr_ns (include/linux/rcupdate.h:306 (discriminator 1) include/linux/rcupdate.h:780 (discriminator 1) kernel/pid.c:504 (discriminator 1))\n[ 275.297470][ T4335] ? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4300 kernel/locking/lockdep.c:4359)\n[ 275.297988][ T4335] ? do_syscall_64 (arch/x86/include/asm/cpufeature.h:171 arch/x86/entry/common.c:97)\n[ 275.298389][ T4335] ? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4300 kernel/locking/lockdep.c:4359)\n[ 275.298906][ T4335] ? do_syscall_64 (arch/x86/include/asm/cpufeature.h:171 arch/x86/entry/common.c:97)\n[ 275.299304][ T4335] ? do_syscall_64 (arch/x86/include/asm/cpufeature.h:171 arch/x86/entry/common.c:97)\n[ 275.299703][ T4335] ? do_syscall_64 (arch/x86/include/asm/cpufeature.h:171 arch/x86/entry/common.c:97)\n[ 275.300115][ T4335] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)\n\nThis BUG is the VM_BUG_ON(!in_atomic() && !irqs_disabled()) assertion in\nfolio_ref_try_add_rcu() for non-SMP kernel.\n\nThe process_vm_readv() calls GUP to pin the THP. An optimization for\npinning THP instroduced by commit 57edfcfd3419 ("mm/gup: accelerate thp\ngup even for "pages != NULL"") calls try_grab_folio() to pin the THP,\nbut try_grab_folio() is supposed to be called in atomic context for\nnon-SMP kernel, for example, irq disabled or preemption disabled, due to\nthe optimization introduced by commit e286781d5f2e ("mm: speculative\npage references").\n\nThe commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP\nboundaries") is not actually the root cause although it was bisected to.\nIt just makes the problem exposed more likely.\n\nThe follow up discussion suggested the optimization for non-SMP kernel\nmay be out-dated and not worth it anymore [1]. So removing the\noptimization to silence the BUG.\n\nHowever calling try_grab_folio() in GUP slow path actually is\nunnecessary, so the following patch will clean this up.\n\n[1] https://lore.kernel.org/linux-mm/821cf1d6-92b9-4ac4-bacc-d8f2364ac14f@paulmck-laptop/

In the Linux kernel, the following vulnerability has been resolved:\n\ncachefiles: add missing lock protection when polling\n\nAdd missing lock protection in poll routine when iterating xarray,\notherwise:\n\nEven with RCU read lock held, only the slot of the radix tree is\nensured to be pinned there, while the data structure (e.g. struct\ncachefiles_req) stored in the slot has no such guarantee. The poll\nroutine will iterate the radix tree and dereference cachefiles_req\naccordingly. Thus RCU read lock is not adequate in this case and\nspinlock is needed here.

In the Linux kernel, the following vulnerability has been resolved:\n\nspi: don't unoptimize message in spi_async()\n\nCalling spi_maybe_unoptimize_message() in spi_async() is wrong because\nthe message is likely to be in the queue and not transferred yet. This\ncan corrupt the message while it is being used by the controller driver.\n\nspi_maybe_unoptimize_message() is already called in the correct place\nin spi_finalize_current_message() to balance the call to\nspi_maybe_optimize_message() in spi_async().

In the Linux kernel, the following vulnerability has been resolved:\n\ntty: serial: ma35d1: Add a NULL check for of_node\n\nThe pdev->dev.of_node can be NULL if the "serial" node is absent.\nAdd a NULL check to return an error in such cases.

In the Linux kernel, the following vulnerability has been resolved:\n\nRevert "sched/fair: Make sure to try to detach at least one movable task"\n\nThis reverts commit b0defa7ae03ecf91b8bfd10ede430cff12fcbd06.\n\nb0defa7ae03ec changed the load balancing logic to ignore env.max_loop if\nall tasks examined to that point were pinned. The goal of the patch was\nto make it more likely to be able to detach a task buried in a long list\nof pinned tasks. However, this has the unfortunate side effect of\ncreating an O(n) iteration in detach_tasks(), as we now must fully\niterate every task on a cpu if all or most are pinned. Since this load\nbalance code is done with rq lock held, and often in softirq context, it\nis very easy to trigger hard lockups. We observed such hard lockups with\na user who affined O(10k) threads to a single cpu.\n\nWhen I discussed this with Vincent he initially suggested that we keep\nthe limit on the number of tasks to detach, but increase the number of\ntasks we can search. However, after some back and forth on the mailing\nlist, he recommended we instead revert the original patch, as it seems\nlikely no one was actually getting hit by the original issue.

In the Linux kernel, the following vulnerability has been resolved:\n\nmmc: sdhci: Fix max_seg_size for 64KiB PAGE_SIZE\n\nblk_queue_max_segment_size() ensured:\n\n if (max_size < PAGE_SIZE)\n max_size = PAGE_SIZE;\n\nwhereas:\n\nblk_validate_limits() makes it an error:\n\n if (WARN_ON_ONCE(lim->max_segment_size < PAGE_SIZE))\n return -EINVAL;\n\nThe change from one to the other, exposed sdhci which was setting maximum\nsegment size too low in some circumstances.\n\nFix the maximum segment size when it is too low.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm/shmem: disable PMD-sized page cache if needed\n\nFor shmem files, it's possible that PMD-sized page cache can't be\nsupported by xarray. For example, 512MB page cache on ARM64 when the base\npage size is 64KB can't be supported by xarray. It leads to errors as the\nfollowing messages indicate when this sort of xarray entry is split.\n\nWARNING: CPU: 34 PID: 7578 at lib/xarray.c:1025 xas_split_alloc+0xf8/0x128\nModules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 \\\nnft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject \\\nnft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 \\\nip_set rfkill nf_tables nfnetlink vfat fat virtio_balloon drm fuse xfs \\\nlibcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce virtio_net \\\nnet_failover virtio_console virtio_blk failover dimlib virtio_mmio\nCPU: 34 PID: 7578 Comm: test Kdump: loaded Tainted: G W 6.10.0-rc5-gavin+ #9\nHardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024\npstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)\npc : xas_split_alloc+0xf8/0x128\nlr : split_huge_page_to_list_to_order+0x1c4/0x720\nsp : ffff8000882af5f0\nx29: ffff8000882af5f0 x28: ffff8000882af650 x27: ffff8000882af768\nx26: 0000000000000cc0 x25: 000000000000000d x24: ffff00010625b858\nx23: ffff8000882af650 x22: ffffffdfc0900000 x21: 0000000000000000\nx20: 0000000000000000 x19: ffffffdfc0900000 x18: 0000000000000000\nx17: 0000000000000000 x16: 0000018000000000 x15: 52f8004000000000\nx14: 0000e00000000000 x13: 0000000000002000 x12: 0000000000000020\nx11: 52f8000000000000 x10: 52f8e1c0ffff6000 x9 : ffffbeb9619a681c\nx8 : 0000000000000003 x7 : 0000000000000000 x6 : ffff00010b02ddb0\nx5 : ffffbeb96395e378 x4 : 0000000000000000 x3 : 0000000000000cc0\nx2 : 000000000000000d x1 : 000000000000000c x0 : 0000000000000000\nCall trace:\n xas_split_alloc+0xf8/0x128\n split_huge_page_to_list_to_order+0x1c4/0x720\n truncate_inode_partial_folio+0xdc/0x160\n shmem_undo_range+0x2bc/0x6a8\n shmem_fallocate+0x134/0x430\n vfs_fallocate+0x124/0x2e8\n ksys_fallocate+0x4c/0xa0\n __arm64_sys_fallocate+0x24/0x38\n invoke_syscall.constprop.0+0x7c/0xd8\n do_el0_svc+0xb4/0xd0\n el0_svc+0x44/0x1d8\n el0t_64_sync_handler+0x134/0x150\n el0t_64_sync+0x17c/0x180\n\nFix it by disabling PMD-sized page cache when HPAGE_PMD_ORDER is larger\nthan MAX_PAGECACHE_ORDER. As Matthew Wilcox pointed, the page cache in a\nshmem file isn't represented by a multi-index entry and doesn't have this\nlimitation when the xarry entry is split until commit 6b24ca4a1a8d ("mm:\nUse multi-index entries in the page cache").

In the Linux kernel, the following vulnerability has been resolved:\n\ns390/mm: Add NULL pointer check to crst_table_free() base_crst_free()\n\ncrst_table_free() used to work with NULL pointers before the conversion\nto ptdescs. Since crst_table_free() can be called with a NULL pointer\n(error handling in crst_table_upgrade() add an explicit check.\n\nAlso add the same check to base_crst_free() for consistency reasons.\n\nIn real life this should not happen, since order two GFP_KERNEL\nallocations will not fail, unless FAIL_PAGE_ALLOC is enabled and used.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm: fix crashes from deferred split racing folio migration\n\nEven on 6.10-rc6, I've been seeing elusive "Bad page state"s (often on\nflags when freeing, yet the flags shown are not bad: PG_locked had been\nset and cleared??), and VM_BUG_ON_PAGE(page_ref_count(page) == 0)s from\ndeferred_split_scan()'s folio_put(), and a variety of other BUG and WARN\nsymptoms implying double free by deferred split and large folio migration.\n\n6.7 commit 9bcef5973e31 ("mm: memcg: fix split queue list crash when large\nfolio migration") was right to fix the memcg-dependent locking broken in\n85ce2c517ade ("memcontrol: only transfer the memcg data for migration"),\nbut missed a subtlety of deferred_split_scan(): it moves folios to its own\nlocal list to work on them without split_queue_lock, during which time\nfolio->_deferred_list is not empty, but even the "right" lock does nothing\nto secure the folio and the list it is on.\n\nFortunately, deferred_split_scan() is careful to use folio_try_get(): so\nfolio_migrate_mapping() can avoid the race by folio_undo_large_rmappable()\nwhile the old folio's reference count is temporarily frozen to 0 - adding\nsuch a freeze in the !mapping case too (originally, folio lock and\nunmapping and no swap cache left an anon folio unreachable, so no freezing\nwas needed there: but the deferred split queue offers a way to reach it).

In the Linux kernel, the following vulnerability has been resolved:\n\nfilemap: replace pte_offset_map() with pte_offset_map_nolock()\n\nThe vmf->ptl in filemap_fault_recheck_pte_none() is still set from\nhandle_pte_fault(). But at the same time, we did a pte_unmap(vmf->pte). \nAfter a pte_unmap(vmf->pte) unmap and rcu_read_unlock(), the page table\nmay be racily changed and vmf->ptl maybe fails to protect the actual page\ntable. Fix this by replacing pte_offset_map() with\npte_offset_map_nolock().\n\nAs David said, the PTL pointer might be stale so if we continue to use\nit infilemap_fault_recheck_pte_none(), it might trigger UAF. Also, if\nthe PTL fails, the issue fixed by commit 58f327f2ce80 ("filemap: avoid\nunnecessary major faults in filemap_fault()") might reappear.

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: zoned: fix calc_available_free_space() for zoned mode\n\ncalc_available_free_space() returns the total size of metadata (or\nsystem) block groups, which can be allocated from unallocated disk\nspace. The logic is wrong on zoned mode in two places.\n\nFirst, the calculation of data_chunk_size is wrong. We always allocate\none zone as one chunk, and no partial allocation of a zone. So, we\nshould use zone_size (= data_sinfo->chunk_size) as it is.\n\nSecond, the result "avail" may not be zone aligned. Since we always\nallocate one zone as one chunk on zoned mode, returning non-zone size\naligned bytes will result in less pressure on the async metadata reclaim\nprocess.\n\nThis is serious for the nearly full state with a large zone size device.\nAllowing over-commit too much will result in less async reclaim work and\nend up in ENOSPC. We can align down to the zone size to avoid that.

In the Linux kernel, the following vulnerability has been resolved:\n\ni2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isr\n\nWhen del_timer_sync() is called in an interrupt context it throws a warning\nbecause of potential deadlock. The timer is used only to exit from\nwait_for_completion() after a timeout so replacing the call with\nwait_for_completion_timeout() allows to remove the problematic timer and\nits related functions altogether.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: txgbe: remove separate irq request for MSI and INTx\n\nWhen using MSI or INTx interrupts, request_irq() for pdev->irq will\nconflict with request_threaded_irq() for txgbe->misc.irq, to cause\nsystem crash. So remove txgbe_request_irq() for MSI/INTx case, and\nrename txgbe_request_msix_irqs() since it only request for queue irqs.\n\nAdd wx->misc_irq_domain to determine whether the driver creates an IRQ\ndomain and threaded request the IRQs.

In the Linux kernel, the following vulnerability has been resolved:\n\nfs: don't misleadingly warn during thaw operations\n\nThe block device may have been frozen before it was claimed by a\nfilesystem. Concurrently another process might try to mount that\nfrozen block device and has temporarily claimed the block device for\nthat purpose causing a concurrent fs_bdev_thaw() to end up here. The\nmounter is already about to abort mounting because they still saw an\nelevanted bdev->bd_fsfreeze_count so get_bdev_super() will return\nNULL in that case.\n\nFor example, P1 calls dm_suspend() which calls into bdev_freeze() before\nthe block device has been claimed by the filesystem. This brings\nbdev->bd_fsfreeze_count to 1 and no call into fs_bdev_freeze() is\nrequired.\n\nNow P2 tries to mount that frozen block device. It claims it and checks\nbdev->bd_fsfreeze_count. As it's elevated it aborts mounting.\n\nIn the meantime P3 called dm_resume(). P3 sees that the block device is\nalready claimed by a filesystem and calls into fs_bdev_thaw().\n\nP3 takes a passive reference and realizes that the filesystem isn't\nready yet. P3 puts itself to sleep to wait for the filesystem to become\nready.\n\nP2 now puts the last active reference to the filesystem and marks it as\ndying. P3 gets woken, sees that the filesystem is dying and\nget_bdev_super() fails.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: E-switch, Create ingress ACL when needed\n\nCurrently, ingress acl is used for three features. It is created only\nwhen vport metadata match and prio tag are enabled. But active-backup\nlag mode also uses it. It is independent of vport metadata match and\nprio tag. And vport metadata match can be disabled using the\nfollowing devlink command:\n\n # devlink dev param set pci/0000:08:00.0 name esw_port_metadata \\\n value false cmode runtime\n\nIf ingress acl is not created, will hit panic when creating drop rule\nfor active-backup lag mode. If always create it, there will be about\n5% performance degradation.\n\nFix it by creating ingress acl when needed. If esw_port_metadata is\ntrue, ingress acl exists, then create drop rule using existing\ningress acl. If esw_port_metadata is false, create ingress acl and\nthen create drop rule.

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: ISO: Check socket flag instead of hcon\n\nThis fixes the following Smatch static checker warning:\n\nnet/bluetooth/iso.c:1364 iso_sock_recvmsg()\nerror: we previously assumed 'pi->conn->hcon' could be null (line 1359)\n\nnet/bluetooth/iso.c\n1347 static int iso_sock_recvmsg(struct socket *sock, struct msghdr *msg,\n1348 size_t len, int flags)\n1349 {\n1350 struct sock *sk = sock->sk;\n1351 struct iso_pinfo *pi = iso_pi(sk);\n1352\n1353 BT_DBG("sk %p", sk);\n1354\n1355 if (test_and_clear_bit(BT_SK_DEFER_SETUP,\n &bt_sk(sk)->flags)) {\n1356 lock_sock(sk);\n1357 switch (sk->sk_state) {\n1358 case BT_CONNECT2:\n1359 if (pi->conn->hcon &&\n ^^^^^^^^^^^^^^ If ->hcon is NULL\n\n1360 test_bit(HCI_CONN_PA_SYNC,\n &pi->conn->hcon->flags)) {\n1361 iso_conn_big_sync(sk);\n1362 sk->sk_state = BT_LISTEN;\n1363 } else {\n--> 1364 iso_conn_defer_accept(pi->conn->hcon);\n ^^^^^^^^^^^^^^\n then we're toast\n\n1365 sk->sk_state = BT_CONFIG;\n1366 }\n1367 release_sock(sk);\n1368 return 0;\n1369 case BT_CONNECTED:\n1370 if (test_bit(BT_SK_PA_SYNC,

In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: kexec: Avoid deadlock in kexec crash path\n\nIf the kexec crash code is called in the interrupt context, the\nmachine_kexec_mask_interrupts() function will trigger a deadlock while\ntrying to acquire the irqdesc spinlock and then deactivate irqchip in\nirq_set_irqchip_state() function.\n\nUnlike arm64, riscv only requires irq_eoi handler to complete EOI and\nkeeping irq_set_irqchip_state() will only leave this possible deadlock\nwithout any use. So we simply remove it.

In the Linux kernel, the following vulnerability has been resolved:\n\nmlxsw: core_linecards: Fix double memory deallocation in case of invalid INI file\n\nIn case of invalid INI file mlxsw_linecard_types_init() deallocates memory\nbut doesn't reset pointer to NULL and returns 0. In case of any error\noccurred after mlxsw_linecard_types_init() call, mlxsw_linecards_init()\ncalls mlxsw_linecard_types_fini() which performs memory deallocation again.\n\nAdd pointer reset to NULL.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Ignore too large handle values in BIG\n\nhci_le_big_sync_established_evt is necessary to filter out cases where the\nhandle value is belonging to ida id range, otherwise ida will be erroneously\nreleased in hci_conn_cleanup.

In the Linux kernel, the following vulnerability has been resolved:\n\nbluetooth/hci: disallow setting handle bigger than HCI_CONN_HANDLE_MAX\n\nSyzbot hit warning in hci_conn_del() caused by freeing handle that was\nnot allocated using ida allocator.\n\nThis is caused by handle bigger than HCI_CONN_HANDLE_MAX passed by\nhci_le_big_sync_established_evt(), which makes code think it's unset\nconnection.\n\nAdd same check for handle upper bound as in hci_conn_set_handle() to\nprevent warning.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: txgbe: initialize num_q_vectors for MSI/INTx interrupts\n\nWhen using MSI/INTx interrupts, wx->num_q_vectors is uninitialized.\nThus there will be kernel panic in wx_alloc_q_vectors() to allocate\nqueue vectors.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: txgbe: free isb resources at the right time\n\nWhen using MSI/INTx interrupt, the shared interrupts are still being\nhandled in the device remove routine, before free IRQs. So isb memory\nis still read after it is freed. Thus move wx_free_isb_resources()\nfrom txgbe_close() to txgbe_remove(). And fix the improper isb free\naction in txgbe_open() error handling path.

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: always do the basic checks for btrfs_qgroup_inherit structure\n\n[BUG]\nSyzbot reports the following regression detected by KASAN:\n\n BUG: KASAN: slab-out-of-bounds in btrfs_qgroup_inherit+0x42e/0x2e20 fs/btrfs/qgroup.c:3277\n Read of size 8 at addr ffff88814628ca50 by task syz-executor318/5171\n\n CPU: 0 PID: 5171 Comm: syz-executor318 Not tainted 6.10.0-rc2-syzkaller-00010-g2ab795141095 #0\n Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\n Call Trace:\n \n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n btrfs_qgroup_inherit+0x42e/0x2e20 fs/btrfs/qgroup.c:3277\n create_pending_snapshot+0x1359/0x29b0 fs/btrfs/transaction.c:1854\n create_pending_snapshots+0x195/0x1d0 fs/btrfs/transaction.c:1922\n btrfs_commit_transaction+0xf20/0x3740 fs/btrfs/transaction.c:2382\n create_snapshot+0x6a1/0x9e0 fs/btrfs/ioctl.c:875\n btrfs_mksubvol+0x58f/0x710 fs/btrfs/ioctl.c:1029\n btrfs_mksnapshot+0xb5/0xf0 fs/btrfs/ioctl.c:1075\n __btrfs_ioctl_snap_create+0x387/0x4b0 fs/btrfs/ioctl.c:1340\n btrfs_ioctl_snap_create_v2+0x1f2/0x3a0 fs/btrfs/ioctl.c:1422\n btrfs_ioctl+0x99e/0xc60\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:907 [inline]\n __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n RIP: 0033:0x7fcbf1992509\n RSP: 002b:00007fcbf1928218 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\n RAX: ffffffffffffffda RBX: 00007fcbf1a1f618 RCX: 00007fcbf1992509\n RDX: 0000000020000280 RSI: 0000000050009417 RDI: 0000000000000003\n RBP: 00007fcbf1a1f610 R08: 00007ffea1298e97 R09: 0000000000000000\n R10: 0000000000000000 R11: 0000000000000246 R12: 00007fcbf19eb660\n R13: 00000000200002b8 R14: 00007fcbf19e60c0 R15: 0030656c69662f2e\n \n\nAnd it also pinned it down to commit b5357cb268c4 ("btrfs: qgroup: do not\ncheck qgroup inherit if qgroup is disabled").\n\n[CAUSE]\nThat offending commit skips the whole qgroup inherit check if qgroup is\nnot enabled.\n\nBut that also skips the very basic checks like\nnum_ref_copies/num_excl_copies and the structure size checks.\n\nMeaning if a qgroup enable/disable race is happening at the background,\nand we pass a btrfs_qgroup_inherit structure when the qgroup is\ndisabled, the check would be completely skipped.\n\nThen at the time of transaction commitment, qgroup is re-enabled and\nbtrfs_qgroup_inherit() is going to use the incorrect structure and\ncausing the above KASAN error.\n\n[FIX]\nMake btrfs_qgroup_check_inherit() only skip the source qgroup checks.\nSo that even if invalid btrfs_qgroup_inherit structure is passed in, we\ncan still reject invalid ones no matter if qgroup is enabled or not.\n\nFurthermore we do already have an extra safety inside\nbtrfs_qgroup_inherit(), which would just ignore invalid qgroup sources,\nso even if we only skip the qgroup source check we're still safe.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: unconditionally flush pending work before notifier\n\nsyzbot reports:\n\nKASAN: slab-uaf in nft_ctx_update include/net/netfilter/nf_tables.h:1831\nKASAN: slab-uaf in nft_commit_release net/netfilter/nf_tables_api.c:9530\nKASAN: slab-uaf int nf_tables_trans_destroy_work+0x152b/0x1750 net/netfilter/nf_tables_api.c:9597\nRead of size 2 at addr ffff88802b0051c4 by task kworker/1:1/45\n[..]\nWorkqueue: events nf_tables_trans_destroy_work\nCall Trace:\n nft_ctx_update include/net/netfilter/nf_tables.h:1831 [inline]\n nft_commit_release net/netfilter/nf_tables_api.c:9530 [inline]\n nf_tables_trans_destroy_work+0x152b/0x1750 net/netfilter/nf_tables_api.c:9597\n\nProblem is that the notifier does a conditional flush, but its possible\nthat the table-to-be-removed is still referenced by transactions being\nprocessed by the worker, so we need to flush unconditionally.\n\nWe could make the flush_work depend on whether we found a table to delete\nin nf-next to avoid the flush for most cases.\n\nAFAICS this problem is only exposed in nf-next, with\ncommit e169285f8c56 ("netfilter: nf_tables: do not store nft_ctx in transaction objects"),\nwith this commit applied there is an unconditional fetch of\ntable->family which is whats triggering the above splat.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: rswitch: Avoid use-after-free in rswitch_poll()\n\nThe use-after-free is actually in rswitch_tx_free(), which is inlined in\nrswitch_poll(). Since `skb` and `gq->skbs[gq->dirty]` are in fact the\nsame pointer, the skb is first freed using dev_kfree_skb_any(), then the\nvalue in skb->len is used to update the interface statistics.\n\nLet's move around the instructions to use skb->len before the skb is\nfreed.\n\nThis bug is trivial to reproduce using KFENCE. It will trigger a splat\nevery few packets. A simple ARP request or ICMP echo request is enough.

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix adding block group to a reclaim list and the unused list during reclaim\n\nThere is a potential parallel list adding for retrying in\nbtrfs_reclaim_bgs_work and adding to the unused list. Since the block\ngroup is removed from the reclaim list and it is on a relocation work,\nit can be added into the unused list in parallel. When that happens,\nadding it to the reclaim list will corrupt the list head and trigger\nlist corruption like below.\n\nFix it by taking fs_info->unused_bgs_lock.\n\n [177.504][T2585409] BTRFS error (device nullb1): error relocating ch= unk 2415919104\n [177.514][T2585409] list_del corruption. next->prev should be ff1100= 0344b119c0, but was ff11000377e87c70. (next=3Dff110002390cd9c0)\n [177.529][T2585409] ------------[ cut here ]------------\n [177.537][T2585409] kernel BUG at lib/list_debug.c:65!\n [177.545][T2585409] Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI\n [177.555][T2585409] CPU: 9 PID: 2585409 Comm: kworker/u128:2 Tainted: G W 6.10.0-rc5-kts #1\n [177.568][T2585409] Hardware name: Supermicro SYS-520P-WTR/X12SPW-TF, BIOS 1.2 02/14/2022\n [177.579][T2585409] Workqueue: events_unbound btrfs_reclaim_bgs_work[btrfs]\n [177.589][T2585409] RIP: 0010:__list_del_entry_valid_or_report.cold+0x70/0x72\n [177.624][T2585409] RSP: 0018:ff11000377e87a70 EFLAGS: 00010286\n [177.633][T2585409] RAX: 000000000000006d RBX: ff11000344b119c0 RCX:0000000000000000\n [177.644][T2585409] RDX: 000000000000006d RSI: 0000000000000008 RDI:ffe21c006efd0f40\n [177.655][T2585409] RBP: ff110002e0509f78 R08: 0000000000000001 R09:ffe21c006efd0f08\n [177.665][T2585409] R10: ff11000377e87847 R11: 0000000000000000 R12:ff110002390cd9c0\n [177.676][T2585409] R13: ff11000344b119c0 R14: ff110002e0508000 R15:dffffc0000000000\n [177.687][T2585409] FS: 0000000000000000(0000) GS:ff11000fec880000(0000) knlGS:0000000000000000\n [177.700][T2585409] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n [177.709][T2585409] CR2: 00007f06bc7b1978 CR3: 0000001021e86005 CR4:0000000000771ef0\n [177.720][T2585409] DR0: 0000000000000000 DR1: 0000000000000000 DR2:0000000000000000\n [177.731][T2585409] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:0000000000000400\n [177.742][T2585409] PKRU: 55555554\n [177.748][T2585409] Call Trace:\n [177.753][T2585409] \n [177.759][T2585409] ? __die_body.cold+0x19/0x27\n [177.766][T2585409] ? die+0x2e/0x50\n [177.772][T2585409] ? do_trap+0x1ea/0x2d0\n [177.779][T2585409] ? __list_del_entry_valid_or_report.cold+0x70/0x72\n [177.788][T2585409] ? do_error_trap+0xa3/0x160\n [177.795][T2585409] ? __list_del_entry_valid_or_report.cold+0x70/0x72\n [177.805][T2585409] ? handle_invalid_op+0x2c/0x40\n [177.812][T2585409] ? __list_del_entry_valid_or_report.cold+0x70/0x72\n [177.820][T2585409] ? exc_invalid_op+0x2d/0x40\n [177.827][T2585409] ? asm_exc_invalid_op+0x1a/0x20\n [177.834][T2585409] ? __list_del_entry_valid_or_report.cold+0x70/0x72\n [177.843][T2585409] btrfs_delete_unused_bgs+0x3d9/0x14c0 [btrfs]\n\nThere is a similar retry_list code in btrfs_delete_unused_bgs(), but it is\nsafe, AFAICS. Since the block group was in the unused list, the used bytes\nshould be 0 when it was added to the unused list. Then, it checks\nblock_group->{used,reserved,pinned} are still 0 under the\nblock_group->lock. So, they should be still eligible for the unused list,\nnot the reclaim list.\n\nThe reason it is safe there it's because because we're holding\nspace_info->groups_sem in write mode.\n\nThat means no other task can allocate from the block group, so while we\nare at deleted_unused_bgs() it's not possible for other tasks to\nallocate and deallocate extents from the block group, so it can't be\nadded to the unused list or the reclaim list by anyone else.\n\nThe bug can be reproduced by btrfs/166 after a few rounds. In practice\nthis can be hit when relocation cannot find more chunk space and ends\nwith ENOSPC.

In the Linux kernel, the following vulnerability has been resolved:\n\nRevert "mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again"\n\nPatch series "mm: Avoid possible overflows in dirty throttling".\n\nDirty throttling logic assumes dirty limits in page units fit into\n32-bits. This patch series makes sure this is true (see patch 2/2 for\nmore details).\n\n\nThis patch (of 2):\n\nThis reverts commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78.\n\nThe commit is broken in several ways. Firstly, the removed (u64) cast\nfrom the multiplication will introduce a multiplication overflow on 32-bit\narchs if wb_thresh * bg_thresh >= 1<<32 (which is actually common - the\ndefault settings with 4GB of RAM will trigger this). Secondly, the\ndiv64_u64() is unnecessarily expensive on 32-bit archs. We have\ndiv64_ul() in case we want to be safe & cheap. Thirdly, if dirty\nthresholds are larger than 1<<32 pages, then dirty balancing is going to\nblow up in many other spectacular ways anyway so trying to fix one\npossible overflow is just moot.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau: fix null pointer dereference in nouveau_connector_get_modes\n\nIn nouveau_connector_get_modes(), the return value of drm_mode_duplicate()\nis assigned to mode, which will lead to a possible NULL pointer\ndereference on failure of drm_mode_duplicate(). Add a check to avoid npd.

In the Linux kernel, the following vulnerability has been resolved:\n\nclk: sunxi-ng: common: Don't call hw_to_ccu_common on hw without common\n\nIn order to set the rate range of a hw sunxi_ccu_probe calls\nhw_to_ccu_common() assuming all entries in desc->ccu_clks are contained\nin a ccu_common struct. This assumption is incorrect and, in\nconsequence, causes invalid pointer de-references.\n\nRemove the faulty call. Instead, add one more loop that iterates over\nthe ccu_clks and sets the rate range, if required.

In the Linux kernel, the following vulnerability has been resolved:\n\ns390/dasd: Fix invalid dereferencing of indirect CCW data pointer\n\nFix invalid dereferencing of indirect CCW data pointer in\ndasd_eckd_dump_sense() that leads to a kernel panic in error cases.\n\nWhen using indirect addressing for DASD CCWs (IDAW) the CCW CDA pointer\ndoes not contain the data address itself but a pointer to the IDAL.\nThis needs to be translated from physical to virtual as well before\nusing it.\n\nThis dereferencing is also used for dasd_page_cache and also fixed\nalthough it is very unlikely that this code path ever gets used.

In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: mediatek: mt8195: Add platform entry for ETDM1_OUT_BE dai link\n\nCommit e70b8dd26711 ("ASoC: mediatek: mt8195: Remove afe-dai component\nand rework codec link") removed the codec entry for the ETDM1_OUT_BE\ndai link entirely instead of replacing it with COMP_EMPTY(). This worked\nby accident as the remaining COMP_EMPTY() platform entry became the codec\nentry, and the platform entry became completely empty, effectively the\nsame as COMP_DUMMY() since snd_soc_fill_dummy_dai() doesn't do anything\nfor platform entries.\n\nThis causes a KASAN out-of-bounds warning in mtk_soundcard_common_probe()\nin sound/soc/mediatek/common/mtk-soundcard-driver.c:\n\n for_each_card_prelinks(card, i, dai_link) {\n if (adsp_node && !strncmp(dai_link->name, "AFE_SOF", strlen("AFE_SOF")))\n dai_link->platforms->of_node = adsp_node;\n else if (!dai_link->platforms->name && !dai_link->platforms->of_node)\n dai_link->platforms->of_node = platform_node;\n }\n\nwhere the code expects the platforms array to have space for at least one entry.\n\nAdd an COMP_EMPTY() entry so that dai_link->platforms has space.

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: dwc3: core: remove lock of otg mode during gadget suspend/resume to avoid deadlock\n\nWhen config CONFIG_USB_DWC3_DUAL_ROLE is selected, and trigger system\nto enter suspend status with below command:\necho mem > /sys/power/state\nThere will be a deadlock issue occurring. Detailed invoking path as\nbelow:\ndwc3_suspend_common()\n spin_lock_irqsave(&dwc->lock, flags); <-- 1st\n dwc3_gadget_suspend(dwc);\n dwc3_gadget_soft_disconnect(dwc);\n spin_lock_irqsave(&dwc->lock, flags); <-- 2nd\nThis issue is exposed by commit c7ebd8149ee5 ("usb: dwc3: gadget: Fix\nNULL pointer dereference in dwc3_gadget_suspend") that removes the code\nof checking whether dwc->gadget_driver is NULL or not. It causes the\nfollowing code is executed and deadlock occurs when trying to get the\nspinlock. In fact, the root cause is the commit 5265397f9442("usb: dwc3:\nRemove DWC3 locking during gadget suspend/resume") that forgot to remove\nthe lock of otg mode. So, remove the redundant lock of otg mode during\ngadget suspend/resume.

In the Linux kernel, the following vulnerability has been resolved:\n\nionic: fix kernel panic due to multi-buffer handling\n\nCurrently, the ionic_run_xdp() doesn't handle multi-buffer packets\nproperly for XDP_TX and XDP_REDIRECT.\nWhen a jumbo frame is received, the ionic_run_xdp() first makes xdp\nframe with all necessary pages in the rx descriptor.\nAnd if the action is either XDP_TX or XDP_REDIRECT, it should unmap\ndma-mapping and reset page pointer to NULL for all pages, not only the\nfirst page.\nBut it doesn't for SG pages. So, SG pages unexpectedly will be reused.\nIt eventually causes kernel panic.\n\nOops: general protection fault, probably for non-canonical address 0x504f4e4dbebc64ff: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.10.0-rc3+ #25\nRIP: 0010:xdp_return_frame+0x42/0x90\nCode: 01 75 12 5b 4c 89 e6 5d 31 c9 41 5c 31 d2 41 5d e9 73 fd ff ff 44 8b 6b 20 0f b7 43 0a 49 81 ed 68 01 00 00 49 29 c5 49 01 fd <41> 80 7d0\nRSP: 0018:ffff99d00122ce08 EFLAGS: 00010202\nRAX: 0000000000005453 RBX: ffff8d325f904000 RCX: 0000000000000001\nRDX: 00000000670e1000 RSI: 000000011f90d000 RDI: 504f4e4d4c4b4a49\nRBP: ffff99d003907740 R08: 0000000000000000 R09: 0000000000000000\nR10: 000000011f90d000 R11: 0000000000000000 R12: ffff8d325f904010\nR13: 504f4e4dbebc64fd R14: ffff8d3242b070c8 R15: ffff99d0039077c0\nFS: 0000000000000000(0000) GS:ffff8d399f780000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f41f6c85e38 CR3: 000000037ac30000 CR4: 00000000007506f0\nPKRU: 55555554\nCall Trace:\n \n ? die_addr+0x33/0x90\n ? exc_general_protection+0x251/0x2f0\n ? asm_exc_general_protection+0x22/0x30\n ? xdp_return_frame+0x42/0x90\n ionic_tx_clean+0x211/0x280 [ionic 15881354510e6a9c655c59c54812b319ed2cd015]\n ionic_tx_cq_service+0xd3/0x210 [ionic 15881354510e6a9c655c59c54812b319ed2cd015]\n ionic_txrx_napi+0x41/0x1b0 [ionic 15881354510e6a9c655c59c54812b319ed2cd015]\n __napi_poll.constprop.0+0x29/0x1b0\n net_rx_action+0x2c4/0x350\n handle_softirqs+0xf4/0x320\n irq_exit_rcu+0x78/0xa0\n common_interrupt+0x77/0x90

In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: initialise nfsd_info.mutex early.\n\nnfsd_info.mutex can be dereferenced by svc_pool_stats_start()\nimmediately after the new netns is created. Currently this can\ntrigger an oops.\n\nMove the initialisation earlier before it can possibly be dereferenced.

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix remap of arena.\n\nThe bpf arena logic didn't account for mremap operation. Add a refcnt for\nmultiple mmap events to prevent use-after-free in arena_vm_close.

In the Linux kernel, the following vulnerability has been resolved:\n\nmlxsw: spectrum_buffers: Fix memory corruptions on Spectrum-4 systems\n\nThe following two shared buffer operations make use of the Shared Buffer\nStatus Register (SBSR):\n\n # devlink sb occupancy snapshot pci/0000:01:00.0\n # devlink sb occupancy clearmax pci/0000:01:00.0\n\nThe register has two masks of 256 bits to denote on which ingress /\negress ports the register should operate on. Spectrum-4 has more than\n256 ports, so the register was extended by cited commit with a new\n'port_page' field.\n\nHowever, when filling the register's payload, the driver specifies the\nports as absolute numbers and not relative to the first port of the port\npage, resulting in memory corruptions [1].\n\nFix by specifying the ports relative to the first port of the port page.\n\n[1]\nBUG: KASAN: slab-use-after-free in mlxsw_sp_sb_occ_snapshot+0xb6d/0xbc0\nRead of size 1 at addr ffff8881068cb00f by task devlink/1566\n[...]\nCall Trace:\n \n dump_stack_lvl+0xc6/0x120\n print_report+0xce/0x670\n kasan_report+0xd7/0x110\n mlxsw_sp_sb_occ_snapshot+0xb6d/0xbc0\n mlxsw_devlink_sb_occ_snapshot+0x75/0xb0\n devlink_nl_sb_occ_snapshot_doit+0x1f9/0x2a0\n genl_family_rcv_msg_doit+0x20c/0x300\n genl_rcv_msg+0x567/0x800\n netlink_rcv_skb+0x170/0x450\n genl_rcv+0x2d/0x40\n netlink_unicast+0x547/0x830\n netlink_sendmsg+0x8d4/0xdb0\n __sys_sendto+0x49b/0x510\n __x64_sys_sendto+0xe5/0x1c0\n do_syscall_64+0xc1/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[...]\nAllocated by task 1:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0x8f/0xa0\n copy_verifier_state+0xbc2/0xfb0\n do_check_common+0x2c51/0xc7e0\n bpf_check+0x5107/0x9960\n bpf_prog_load+0xf0e/0x2690\n __sys_bpf+0x1a61/0x49d0\n __x64_sys_bpf+0x7d/0xc0\n do_syscall_64+0xc1/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nFreed by task 1:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n kasan_save_free_info+0x3b/0x60\n poison_slab_object+0x109/0x170\n __kasan_slab_free+0x14/0x30\n kfree+0xca/0x2b0\n free_verifier_state+0xce/0x270\n do_check_common+0x4828/0xc7e0\n bpf_check+0x5107/0x9960\n bpf_prog_load+0xf0e/0x2690\n __sys_bpf+0x1a61/0x49d0\n __x64_sys_bpf+0x7d/0xc0\n do_syscall_64+0xc1/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix may_goto with negative offset.\n\nZac's syzbot crafted a bpf prog that exposed two bugs in may_goto.\nThe 1st bug is the way may_goto is patched. When offset is negative\nit should be patched differently.\nThe 2nd bug is in the verifier:\nwhen current state may_goto_depth is equal to visited state may_goto_depth\nit means there is an actual infinite loop. It's not correct to prune\nexploration of the program at this point.\nNote, that this check doesn't limit the program to only one may_goto insn,\nsince 2nd and any further may_goto will increment may_goto_depth only\nin the queued state pushed for future exploration. The current state\nwill have may_goto_depth == 0 regardless of number of may_goto insns\nand the verifier has to explore the program until bpf_exit.