In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: btsdio: fix use after free bug in btsdio_remove due to race condition\n\nIn btsdio_probe, the data->work is bound with btsdio_work. It will be\nstarted in btsdio_send_frame.\n\nIf the btsdio_remove runs with a unfinished work, there may be a race\ncondition that hdev is freed but used in btsdio_work. Fix it by\ncanceling the work before do cleanup in btsdio_remove.

In the Linux kernel, the following vulnerability has been resolved:\n\nerofs: fix wrong kunmap when using LZMA on HIGHMEM platforms\n\nAs the call trace shown, the root cause is kunmap incorrect pages:\n\n BUG: kernel NULL pointer dereference, address: 00000000\n CPU: 1 PID: 40 Comm: kworker/u5:0 Not tainted 6.2.0-rc5 #4\n Workqueue: erofs_worker z_erofs_decompressqueue_work\n EIP: z_erofs_lzma_decompress+0x34b/0x8ac\n z_erofs_decompress+0x12/0x14\n z_erofs_decompress_queue+0x7e7/0xb1c\n z_erofs_decompressqueue_work+0x32/0x60\n process_one_work+0x24b/0x4d8\n ? process_one_work+0x1a4/0x4d8\n worker_thread+0x14c/0x3fc\n kthread+0xe6/0x10c\n ? rescuer_thread+0x358/0x358\n ? kthread_complete_and_exit+0x18/0x18\n ret_from_fork+0x1c/0x28\n ---[ end trace 0000000000000000 ]---\n\nThe bug is trivial and should be fixed now. It has no impact on\n!HIGHMEM platforms.

In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix another off-by-one fsmap error on 1k block filesystems\n\nApparently syzbot figured out that issuing this FSMAP call:\n\nstruct fsmap_head cmd = {\n .fmh_count = ...;\n .fmh_keys = {\n { .fmr_device = /* ext4 dev */, .fmr_physical = 0, },\n { .fmr_device = /* ext4 dev */, .fmr_physical = 0, },\n },\n...\n};\nret = ioctl(fd, FS_IOC_GETFSMAP, &cmd);\n\nProduces this crash if the underlying filesystem is a 1k-block ext4\nfilesystem:\n\nkernel BUG at fs/ext4/ext4.h:3331!\ninvalid opcode: 0000 [#1] PREEMPT SMP\nCPU: 3 PID: 3227965 Comm: xfs_io Tainted: G W O 6.2.0-rc8-achx\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014\nRIP: 0010:ext4_mb_load_buddy_gfp+0x47c/0x570 [ext4]\nRSP: 0018:ffffc90007c03998 EFLAGS: 00010246\nRAX: ffff888004978000 RBX: ffffc90007c03a20 RCX: ffff888041618000\nRDX: 0000000000000000 RSI: 00000000000005a4 RDI: ffffffffa0c99b11\nRBP: ffff888012330000 R08: ffffffffa0c2b7d0 R09: 0000000000000400\nR10: ffffc90007c03950 R11: 0000000000000000 R12: 0000000000000001\nR13: 00000000ffffffff R14: 0000000000000c40 R15: ffff88802678c398\nFS: 00007fdf2020c880(0000) GS:ffff88807e100000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007ffd318a5fe8 CR3: 000000007f80f001 CR4: 00000000001706e0\nCall Trace:\n \n ext4_mballoc_query_range+0x4b/0x210 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]\n ext4_getfsmap_datadev+0x713/0x890 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]\n ext4_getfsmap+0x2b7/0x330 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]\n ext4_ioc_getfsmap+0x153/0x2b0 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]\n __ext4_ioctl+0x2a7/0x17e0 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]\n __x64_sys_ioctl+0x82/0xa0\n do_syscall_64+0x2b/0x80\n entry_SYSCALL_64_after_hwframe+0x46/0xb0\nRIP: 0033:0x7fdf20558aff\nRSP: 002b:00007ffd318a9e30 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\nRAX: ffffffffffffffda RBX: 00000000000200c0 RCX: 00007fdf20558aff\nRDX: 00007fdf1feb2010 RSI: 00000000c0c0583b RDI: 0000000000000003\nRBP: 00005625c0634be0 R08: 00005625c0634c40 R09: 0000000000000001\nR10: 0000000000000000 R11: 0000000000000246 R12: 00007fdf1feb2010\nR13: 00005625be70d994 R14: 0000000000000800 R15: 0000000000000000\n\nFor GETFSMAP calls, the caller selects a physical block device by\nwriting its block number into fsmap_head.fmh_keys[01].fmr_device.\nTo query mappings for a subrange of the device, the starting byte of the\nrange is written to fsmap_head.fmh_keys[0].fmr_physical and the last\nbyte of the range goes in fsmap_head.fmh_keys[1].fmr_physical.\n\nIOWs, to query what mappings overlap with bytes 3-14 of /dev/sda, you'd\nset the inputs as follows:\n\n fmh_keys[0] = { .fmr_device = major(8, 0), .fmr_physical = 3},\n fmh_keys[1] = { .fmr_device = major(8, 0), .fmr_physical = 14},\n\nWhich would return you whatever is mapped in the 12 bytes starting at\nphysical offset 3.\n\nThe crash is due to insufficient range validation of keys[1] in\next4_getfsmap_datadev. On 1k-block filesystems, block 0 is not part of\nthe filesystem, which means that s_first_data_block is nonzero.\next4_get_group_no_and_offset subtracts this quantity from the blocknr\nargument before cracking it into a group number and a block number\nwithin a group. IOWs, block group 0 spans blocks 1-8192 (1-based)\ninstead of 0-8191 (0-based) like what happens with larger blocksizes.\n\nThe net result of this encoding is that blocknr < s_first_data_block is\nnot a valid input to this function. The end_fsb variable is set from\nthe keys that are copied from userspace, which means that in the above\nexample, its value is zero. That leads to an underflow here:\n\n blocknr = blocknr - le32_to_cpu(es->s_first_data_block);\n\nThe division then operates on -1:\n\n offset = do_div(blocknr, EXT4_BLOCKS_PER_GROUP(sb)) >>\n EXT4_SB(sb)->s_cluster_bits;\n\nLeaving an impossibly large group number (2^32-1) in blocknr.\next4_getfsmap_check_keys checked that keys[0\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nice: copy last block omitted in ice_get_module_eeprom()\n\nice_get_module_eeprom() is broken since commit e9c9692c8a81 ("ice:\nReimplement module reads used by ethtool") In this refactor,\nice_get_module_eeprom() reads the eeprom in blocks of size 8.\nBut the condition that should protect the buffer overflow\nignores the last block. The last block always contains zeros.\n\nBug uncovered by ethtool upstream commit 9538f384b535\n("netlink: eeprom: Defer page requests to individual parsers")\nAfter this commit, ethtool reads a block with length = 1;\nto read the SFF-8024 identifier value.\n\nunpatched driver:\n$ ethtool -m enp65s0f0np0 offset 0x90 length 8\nOffset Values\n------ ------\n0x0090: 00 00 00 00 00 00 00 00\n$ ethtool -m enp65s0f0np0 offset 0x90 length 12\nOffset Values\n------ ------\n0x0090: 00 00 01 a0 4d 65 6c 6c 00 00 00 00\n$\n\n$ ethtool -m enp65s0f0np0\nOffset Values\n------ ------\n0x0000: 11 06 06 00 00 00 00 00 00 00 00 00 00 00 00 00\n0x0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n0x0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n0x0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n0x0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n0x0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n0x0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 08 00\n0x0070: 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n\npatched driver:\n$ ethtool -m enp65s0f0np0 offset 0x90 length 8\nOffset Values\n------ ------\n0x0090: 00 00 01 a0 4d 65 6c 6c\n$ ethtool -m enp65s0f0np0 offset 0x90 length 12\nOffset Values\n------ ------\n0x0090: 00 00 01 a0 4d 65 6c 6c 61 6e 6f 78\n$ ethtool -m enp65s0f0np0\n Identifier : 0x11 (QSFP28)\n Extended identifier : 0x00\n Extended identifier description : 1.5W max. Power consumption\n Extended identifier description : No CDR in TX, No CDR in RX\n Extended identifier description : High Power Class (> 3.5 W) not enabled\n Connector : 0x23 (No separable connector)\n Transceiver codes : 0x88 0x00 0x00 0x00 0x00 0x00 0x00 0x00\n Transceiver type : 40G Ethernet: 40G Base-CR4\n Transceiver type : 25G Ethernet: 25G Base-CR CA-N\n Encoding : 0x05 (64B/66B)\n BR, Nominal : 25500Mbps\n Rate identifier : 0x00\n Length (SMF,km) : 0km\n Length (OM3 50um) : 0m\n Length (OM2 50um) : 0m\n Length (OM1 62.5um) : 0m\n Length (Copper or Active cable) : 1m\n Transmitter technology : 0xa0 (Copper cable unequalized)\n Attenuation at 2.5GHz : 4db\n Attenuation at 5.0GHz : 5db\n Attenuation at 7.0GHz : 7db\n Attenuation at 12.9GHz : 10db\n ........\n ....

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: core: Remove the /proc/scsi/${proc_name} directory earlier\n\nRemove the /proc/scsi/${proc_name} directory earlier to fix a race\ncondition between unloading and reloading kernel modules. This fixes a bug\nintroduced in 2009 by commit 77c019768f06 ("[SCSI] fix /proc memory leak in\nthe SCSI core").\n\nFix the following kernel warning:\n\nproc_dir_entry 'scsi/scsi_debug' already registered\nWARNING: CPU: 19 PID: 27986 at fs/proc/generic.c:376 proc_register+0x27d/0x2e0\nCall Trace:\n proc_mkdir+0xb5/0xe0\n scsi_proc_hostdir_add+0xb5/0x170\n scsi_host_alloc+0x683/0x6c0\n sdebug_driver_probe+0x6b/0x2d0 [scsi_debug]\n really_probe+0x159/0x540\n __driver_probe_device+0xdc/0x230\n driver_probe_device+0x4f/0x120\n __device_attach_driver+0xef/0x180\n bus_for_each_drv+0xe5/0x130\n __device_attach+0x127/0x290\n device_initial_probe+0x17/0x20\n bus_probe_device+0x110/0x130\n device_add+0x673/0xc80\n device_register+0x1e/0x30\n sdebug_add_host_helper+0x1a7/0x3b0 [scsi_debug]\n scsi_debug_init+0x64f/0x1000 [scsi_debug]\n do_one_initcall+0xd7/0x470\n do_init_module+0xe7/0x330\n load_module+0x122a/0x12c0\n __do_sys_finit_module+0x124/0x1a0\n __x64_sys_finit_module+0x46/0x50\n do_syscall_64+0x38/0x80\n entry_SYSCALL_64_after_hwframe+0x46/0xb0

In the Linux kernel, the following vulnerability has been resolved:\n\nnfc: fdp: add null check of devm_kmalloc_array in fdp_nci_i2c_read_device_properties\n\ndevm_kmalloc_array may fails, *fw_vsc_cfg might be null and cause\nout-of-bounds write in device_property_read_u8_array later.

In the Linux kernel, the following vulnerability has been resolved:\n\next4: Fix possible corruption when moving a directory\n\nWhen we are renaming a directory to a different directory, we need to\nupdate '..' entry in the moved directory. However nothing prevents moved\ndirectory from being modified and even converted from the inline format\nto the normal format. When such race happens the rename code gets\nconfused and we crash. Fix the problem by locking the moved directory.

In the Linux kernel, the following vulnerability has been resolved:\n\naf_unix: fix struct pid leaks in OOB support\n\nsyzbot reported struct pid leak [1].\n\nIssue is that queue_oob() calls maybe_add_creds() which potentially\nholds a reference on a pid.\n\nBut skb->destructor is not set (either directly or by calling\nunix_scm_to_skb())\n\nThis means that subsequent kfree_skb() or consume_skb() would leak\nthis reference.\n\nIn this fix, I chose to fully support scm even for the OOB message.\n\n[1]\nBUG: memory leak\nunreferenced object 0xffff8881053e7f80 (size 128):\ncomm "syz-executor242", pid 5066, jiffies 4294946079 (age 13.220s)\nhex dump (first 32 bytes):\n01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\nbacktrace:\n[] alloc_pid+0x6a/0x560 kernel/pid.c:180\n[] copy_process+0x169f/0x26c0 kernel/fork.c:2285\n[] kernel_clone+0xf7/0x610 kernel/fork.c:2684\n[] __do_sys_clone+0x7c/0xb0 kernel/fork.c:2825\n[] do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n[] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80\n[] entry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Fix an infinite loop error when len is 0 in tcp_bpf_recvmsg_parser()\n\nWhen the buffer length of the recvmsg system call is 0, we got the\nflollowing soft lockup problem:\n\nwatchdog: BUG: soft lockup - CPU#3 stuck for 27s! [a.out:6149]\nCPU: 3 PID: 6149 Comm: a.out Kdump: loaded Not tainted 6.2.0+ #30\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014\nRIP: 0010:remove_wait_queue+0xb/0xc0\nCode: 5e 41 5f c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 57 <41> 56 41 55 41 54 55 48 89 fd 53 48 89 f3 4c 8d 6b 18 4c 8d 73 20\nRSP: 0018:ffff88811b5978b8 EFLAGS: 00000246\nRAX: 0000000000000000 RBX: ffff88811a7d3780 RCX: ffffffffb7a4d768\nRDX: dffffc0000000000 RSI: ffff88811b597908 RDI: ffff888115408040\nRBP: 1ffff110236b2f1b R08: 0000000000000000 R09: ffff88811a7d37e7\nR10: ffffed10234fa6fc R11: 0000000000000001 R12: ffff88811179b800\nR13: 0000000000000001 R14: ffff88811a7d38a8 R15: ffff88811a7d37e0\nFS: 00007f6fb5398740(0000) GS:ffff888237180000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000020000000 CR3: 000000010b6ba002 CR4: 0000000000370ee0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \n tcp_msg_wait_data+0x279/0x2f0\n tcp_bpf_recvmsg_parser+0x3c6/0x490\n inet_recvmsg+0x280/0x290\n sock_recvmsg+0xfc/0x120\n ____sys_recvmsg+0x160/0x3d0\n ___sys_recvmsg+0xf0/0x180\n __sys_recvmsg+0xea/0x1a0\n do_syscall_64+0x3f/0x90\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\n\nThe logic in tcp_bpf_recvmsg_parser is as follows:\n\nmsg_bytes_ready:\n copied = sk_msg_recvmsg(sk, psock, msg, len, flags);\n if (!copied) {\n wait data;\n goto msg_bytes_ready;\n }\n\nIn this case, "copied" always is 0, the infinite loop occurs.\n\nAccording to the Linux system call man page, 0 should be returned in this\ncase. Therefore, in tcp_bpf_recvmsg_parser(), if the length is 0, directly\nreturn. Also modify several other functions with the same problem.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: mpi3mr: Fix mpi3mr_hba_port memory leak in mpi3mr_remove()\n\nFree mpi3mr_hba_port at .remove.

In the Linux kernel, the following vulnerability has been resolved:\n\nSUNRPC: Fix a server shutdown leak\n\nFix a race where kthread_stop() may prevent the threadfn from ever getting\ncalled. If that happens the svc_rqst will not be cleaned up.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: mpi3mr: Fix throttle_groups memory leak\n\nAdd a missing kfree().

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: mpi3mr: Fix expander node leak in mpi3mr_remove()\n\nAdd a missing resource clean up in .remove.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: mpi3mr: Fix sas_hba.phy memory leak in mpi3mr_remove()\n\nFree mrioc->sas_hba.phy at .remove.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: smsc75xx: Limit packet length to skb->len\n\nPacket length retrieved from skb data may be larger than\nthe actual socket buffer length (up to 9026 bytes). In such\ncase the cloned skb passed up the network stack will leak\nkernel memory contents.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: mpt3sas: Fix NULL pointer access in mpt3sas_transport_port_add()\n\nPort is allocated by sas_port_alloc_num() and rphy is allocated by either\nsas_end_device_alloc() or sas_expander_alloc(), all of which may return\nNULL. So we need to check the rphy to avoid possible NULL pointer access.\n\nIf sas_rphy_add() returned with failure, rphy is set to NULL. We would\naccess the rphy in the following lines which would also result NULL pointer\naccess.

In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: s390: Fix use-after-free of PCI resources with per-function hotplug\n\nOn s390 PCI functions may be hotplugged individually even when they\nbelong to a multi-function device. In particular on an SR-IOV device VFs\nmay be removed and later re-added.\n\nIn commit a50297cf8235 ("s390/pci: separate zbus creation from\nscanning") it was missed however that struct pci_bus and struct\nzpci_bus's resource list retained a reference to the PCI functions MMIO\nresources even though those resources are released and freed on\nhot-unplug. These stale resources may subsequently be claimed when the\nPCI function re-appears resulting in use-after-free.\n\nOne idea of fixing this use-after-free in s390 specific code that was\ninvestigated was to simply keep resources around from the moment a PCI\nfunction first appeared until the whole virtual PCI bus created for\na multi-function device disappears. The problem with this however is\nthat due to the requirement of artificial MMIO addreesses (address\ncookies) extra logic is then needed to keep the address cookies\ncompatible on re-plug. At the same time the MMIO resources semantically\nbelong to the PCI function so tying their lifecycle to the function\nseems more logical.\n\nInstead a simpler approach is to remove the resources of an individually\nhot-unplugged PCI function from the PCI bus's resource list while\nkeeping the resources of other PCI functions on the PCI bus untouched.\n\nThis is done by introducing pci_bus_remove_resource() to remove an\nindividual resource. Similarly the resource also needs to be removed\nfrom the struct zpci_bus's resource list. It turns out however, that\nthere is really no need to add the MMIO resources to the struct\nzpci_bus's resource list at all and instead we can simply use the\nzpci_bar_struct's resource pointer directly.

In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: tcp_make_synack() can be called from process context\n\ntcp_rtx_synack() now could be called in process context as explained in\n0a375c822497 ("tcp: tcp_rtx_synack() can be called from process\ncontext").\n\ntcp_rtx_synack() might call tcp_make_synack(), which will touch per-CPU\nvariables with preemption enabled. This causes the following BUG:\n\n BUG: using __this_cpu_add() in preemptible [00000000] code: ThriftIO1/5464\n caller is tcp_make_synack+0x841/0xac0\n Call Trace:\n \n dump_stack_lvl+0x10d/0x1a0\n check_preemption_disabled+0x104/0x110\n tcp_make_synack+0x841/0xac0\n tcp_v6_send_synack+0x5c/0x450\n tcp_rtx_synack+0xeb/0x1f0\n inet_rtx_syn_ack+0x34/0x60\n tcp_check_req+0x3af/0x9e0\n tcp_rcv_state_process+0x59b/0x2030\n tcp_v6_do_rcv+0x5f5/0x700\n release_sock+0x3a/0xf0\n tcp_sendmsg+0x33/0x40\n ____sys_sendmsg+0x2f2/0x490\n __sys_sendmsg+0x184/0x230\n do_syscall_64+0x3d/0x90\n\nAvoid calling __TCP_INC_STATS() with will touch per-cpu variables. Use\nTCP_INC_STATS() which is safe to be called from context switch.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: mpi3mr: Fix config page DMA memory leak\n\nA fix for:\n\nDMA-API: pci 0000:83:00.0: device driver has pending DMA allocations while released from device [count=1]

In the Linux kernel, the following vulnerability has been resolved:\n\nnfc: pn533: initialize struct pn533_out_arg properly\n\nstruct pn533_out_arg used as a temporary context for out_urb is not\ninitialized properly. Its uninitialized 'phy' field can be dereferenced in\nerror cases inside pn533_out_complete() callback function. It causes the\nfollowing failure:\n\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nCPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.2.0-rc3-next-20230110-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022\nRIP: 0010:pn533_out_complete.cold+0x15/0x44 drivers/nfc/pn533/usb.c:441\nCall Trace:\n \n __usb_hcd_giveback_urb+0x2b6/0x5c0 drivers/usb/core/hcd.c:1671\n usb_hcd_giveback_urb+0x384/0x430 drivers/usb/core/hcd.c:1754\n dummy_timer+0x1203/0x32d0 drivers/usb/gadget/udc/dummy_hcd.c:1988\n call_timer_fn+0x1da/0x800 kernel/time/timer.c:1700\n expire_timers+0x234/0x330 kernel/time/timer.c:1751\n __run_timers kernel/time/timer.c:2022 [inline]\n __run_timers kernel/time/timer.c:1995 [inline]\n run_timer_softirq+0x326/0x910 kernel/time/timer.c:2035\n __do_softirq+0x1fb/0xaf6 kernel/softirq.c:571\n invoke_softirq kernel/softirq.c:445 [inline]\n __irq_exit_rcu+0x123/0x180 kernel/softirq.c:650\n irq_exit_rcu+0x9/0x20 kernel/softirq.c:662\n sysvec_apic_timer_interrupt+0x97/0xc0 arch/x86/kernel/apic/apic.c:1107\n\nInitialize the field with the pn533_usb_phy currently used.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: core: Fix a procfs host directory removal regression\n\nscsi_proc_hostdir_rm() decreases a reference counter and hence must only be\ncalled once per host that is removed. This change does not require a\nscsi_add_host_with_dma() change since scsi_add_host_with_dma() will return\n0 (success) if scsi_proc_host_add() is called.

In the Linux kernel, the following vulnerability has been resolved:\n\nfs: prevent out-of-bounds array speculation when closing a file descriptor\n\nGoogle-Bug-Id: 114199369

In the Linux kernel, the following vulnerability has been resolved:\n\nnvmet: avoid potential UAF in nvmet_req_complete()\n\nAn nvme target ->queue_response() operation implementation may free the\nrequest passed as argument. Such implementation potentially could result\nin a use after free of the request pointer when percpu_ref_put() is\ncalled in nvmet_req_complete().\n\nAvoid such problem by using a local variable to save the sq pointer\nbefore calling __nvmet_req_complete(), thus avoiding dereferencing the\nreq pointer after that function call.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: mpi3mr: Fix memory leaks in mpi3mr_init_ioc()\n\nDon't allocate memory again when IOC is being reinitialized.

In the Linux kernel, the following vulnerability has been resolved:\n\ni40e: Fix kernel crash during reboot when adapter is in recovery mode\n\nIf the driver detects during probe that firmware is in recovery\nmode then i40e_init_recovery_mode() is called and the rest of\nprobe function is skipped including pci_set_drvdata(). Subsequent\ni40e_shutdown() called during shutdown/reboot dereferences NULL\npointer as pci_get_drvdata() returns NULL.\n\nTo fix call pci_set_drvdata() also during entering to recovery mode.\n\nReproducer:\n1) Lets have i40e NIC with firmware in recovery mode\n2) Run reboot\n\nResult:\n[ 139.084698] i40e: Intel(R) Ethernet Connection XL710 Network Driver\n[ 139.090959] i40e: Copyright (c) 2013 - 2019 Intel Corporation.\n[ 139.108438] i40e 0000:02:00.0: Firmware recovery mode detected. Limiting functionality.\n[ 139.116439] i40e 0000:02:00.0: Refer to the Intel(R) Ethernet Adapters and Devices User Guide for details on firmware recovery mode.\n[ 139.129499] i40e 0000:02:00.0: fw 8.3.64775 api 1.13 nvm 8.30 0x8000b78d 1.3106.0 [8086:1583] [15d9:084a]\n[ 139.215932] i40e 0000:02:00.0 enp2s0f0: renamed from eth0\n[ 139.223292] i40e 0000:02:00.1: Firmware recovery mode detected. Limiting functionality.\n[ 139.231292] i40e 0000:02:00.1: Refer to the Intel(R) Ethernet Adapters and Devices User Guide for details on firmware recovery mode.\n[ 139.244406] i40e 0000:02:00.1: fw 8.3.64775 api 1.13 nvm 8.30 0x8000b78d 1.3106.0 [8086:1583] [15d9:084a]\n[ 139.329209] i40e 0000:02:00.1 enp2s0f1: renamed from eth0\n...\n[ 156.311376] BUG: kernel NULL pointer dereference, address: 00000000000006c2\n[ 156.318330] #PF: supervisor write access in kernel mode\n[ 156.323546] #PF: error_code(0x0002) - not-present page\n[ 156.328679] PGD 0 P4D 0\n[ 156.331210] Oops: 0002 [#1] PREEMPT SMP NOPTI\n[ 156.335567] CPU: 26 PID: 15119 Comm: reboot Tainted: G E 6.2.0+ #1\n[ 156.343126] Hardware name: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.4 04/13/2022\n[ 156.353369] RIP: 0010:i40e_shutdown+0x15/0x130 [i40e]\n[ 156.358430] Code: c1 fc ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 55 48 89 fd 53 48 8b 9f 48 01 00 00 80 8b c2 06 00 00 04 f0 80 8b c0 06 00 00 08 48 8d bb 08 08 00\n[ 156.377168] RSP: 0018:ffffb223c8447d90 EFLAGS: 00010282\n[ 156.382384] RAX: ffffffffc073ee70 RBX: 0000000000000000 RCX: 0000000000000001\n[ 156.389510] RDX: 0000000080000001 RSI: 0000000000000246 RDI: ffff95db49988000\n[ 156.396634] RBP: ffff95db49988000 R08: ffffffffffffffff R09: ffffffff8bd17d40\n[ 156.403759] R10: 0000000000000001 R11: ffffffff8a5e3d28 R12: ffff95db49988000\n[ 156.410882] R13: ffffffff89a6fe17 R14: ffff95db49988150 R15: 0000000000000000\n[ 156.418007] FS: 00007fe7c0cc3980(0000) GS:ffff95ea8ee80000(0000) knlGS:0000000000000000\n[ 156.426083] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 156.431819] CR2: 00000000000006c2 CR3: 00000003092fc005 CR4: 0000000000770ee0\n[ 156.438944] PKRU: 55555554\n[ 156.441647] Call Trace:\n[ 156.444096] \n[ 156.446199] pci_device_shutdown+0x38/0x60\n[ 156.450297] device_shutdown+0x163/0x210\n[ 156.454215] kernel_restart+0x12/0x70\n[ 156.457872] __do_sys_reboot+0x1ab/0x230\n[ 156.461789] ? vfs_writev+0xa6/0x1a0\n[ 156.465362] ? __pfx_file_free_rcu+0x10/0x10\n[ 156.469635] ? __call_rcu_common.constprop.85+0x109/0x5a0\n[ 156.475034] do_syscall_64+0x3e/0x90\n[ 156.478611] entry_SYSCALL_64_after_hwframe+0x72/0xdc\n[ 156.483658] RIP: 0033:0x7fe7bff37ab7

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: nl80211: fix NULL-ptr deref in offchan check\n\nIf, e.g. in AP mode, the link was already created by userspace\nbut not activated yet, it has a chandef but the chandef isn't\nvalid and has no channel. Check for this and ignore this link.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/sseu: fix max_subslices array-index-out-of-bounds access\n\nIt seems that commit bc3c5e0809ae ("drm/i915/sseu: Don't try to store EU\nmask internally in UAPI format") exposed a potential out-of-bounds\naccess, reported by UBSAN as following on a laptop with a gen 11 i915\ncard:\n\n UBSAN: array-index-out-of-bounds in drivers/gpu/drm/i915/gt/intel_sseu.c:65:27\n index 6 is out of range for type 'u16 [6]'\n CPU: 2 PID: 165 Comm: systemd-udevd Not tainted 6.2.0-9-generic #9-Ubuntu\n Hardware name: Dell Inc. XPS 13 9300/077Y9N, BIOS 1.11.0 03/22/2022\n Call Trace:\n \n show_stack+0x4e/0x61\n dump_stack_lvl+0x4a/0x6f\n dump_stack+0x10/0x18\n ubsan_epilogue+0x9/0x3a\n __ubsan_handle_out_of_bounds.cold+0x42/0x47\n gen11_compute_sseu_info+0x121/0x130 [i915]\n intel_sseu_info_init+0x15d/0x2b0 [i915]\n intel_gt_init_mmio+0x23/0x40 [i915]\n i915_driver_mmio_probe+0x129/0x400 [i915]\n ? intel_gt_probe_all+0x91/0x2e0 [i915]\n i915_driver_probe+0xe1/0x3f0 [i915]\n ? drm_privacy_screen_get+0x16d/0x190 [drm]\n ? acpi_dev_found+0x64/0x80\n i915_pci_probe+0xac/0x1b0 [i915]\n ...\n\nAccording to the definition of sseu_dev_info, eu_mask->hsw is limited to\na maximum of GEN_MAX_SS_PER_HSW_SLICE (6) sub-slices, but\ngen11_sseu_info_init() can potentially set 8 sub-slices, in the\n!IS_JSL_EHL(gt->i915) case.\n\nFix this by reserving up to 8 slots for max_subslices in the eu_mask\nstruct.\n\n(cherry picked from commit 3cba09a6ac86ea1d456909626eb2685596c07822)

In the Linux kernel, the following vulnerability has been resolved:\n\nloop: Fix use-after-free issues\n\ndo_req_filebacked() calls blk_mq_complete_request() synchronously or\nasynchronously when using asynchronous I/O unless memory allocation fails.\nHence, modify loop_handle_cmd() such that it does not dereference 'cmd' nor\n'rq' after do_req_filebacked() finished unless we are sure that the request\nhas not yet been completed. This patch fixes the following kernel crash:\n\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000054\nCall trace:\n css_put.42938+0x1c/0x1ac\n loop_process_work+0xc8c/0xfd4\n loop_rootcg_workfn+0x24/0x34\n process_one_work+0x244/0x558\n worker_thread+0x400/0x8fc\n kthread+0x16c/0x1e0\n ret_from_fork+0x10/0x20

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: fix NULL sndbuf_desc in smc_cdc_tx_handler()\n\nWhen performing a stress test on SMC-R by rmmod mlx5_ib driver\nduring the wrk/nginx test, we found that there is a probability\nof triggering a panic while terminating all link groups.\n\nThis issue dues to the race between smc_smcr_terminate_all()\nand smc_buf_create().\n\n smc_smcr_terminate_all\n\nsmc_buf_create\n/* init */\nconn->sndbuf_desc = NULL;\n...\n\n __smc_lgr_terminate\n smc_conn_kill\n smc_close_abort\n smc_cdc_get_slot_and_msg_send\n\n __softirqentry_text_start\n smc_wr_tx_process_cqe\n smc_cdc_tx_handler\n READ(conn->sndbuf_desc->len);\n /* panic dues to NULL sndbuf_desc */\n\nconn->sndbuf_desc = xxx;\n\nThis patch tries to fix the issue by always to check the sndbuf_desc\nbefore send any cdc msg, to make sure that no null pointer is\nseen during cqe processing.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: tunnels: annotate lockless accesses to dev->needed_headroom\n\nIP tunnels can apparently update dev->needed_headroom\nin their xmit path.\n\nThis patch takes care of three tunnels xmit, and also the\ncore LL_RESERVED_SPACE() and LL_RESERVED_SPACE_EXTRA()\nhelpers.\n\nMore changes might be needed for completeness.\n\nBUG: KCSAN: data-race in ip_tunnel_xmit / ip_tunnel_xmit\n\nread to 0xffff88815b9da0ec of 2 bytes by task 888 on cpu 1:\nip_tunnel_xmit+0x1270/0x1730 net/ipv4/ip_tunnel.c:803\n__gre_xmit net/ipv4/ip_gre.c:469 [inline]\nipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661\n__netdev_start_xmit include/linux/netdevice.h:4881 [inline]\nnetdev_start_xmit include/linux/netdevice.h:4895 [inline]\nxmit_one net/core/dev.c:3580 [inline]\ndev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596\n__dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246\ndev_queue_xmit include/linux/netdevice.h:3051 [inline]\nneigh_direct_output+0x17/0x20 net/core/neighbour.c:1623\nneigh_output include/net/neighbour.h:546 [inline]\nip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228\nip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316\nNF_HOOK_COND include/linux/netfilter.h:291 [inline]\nip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430\ndst_output include/net/dst.h:444 [inline]\nip_local_out+0x64/0x80 net/ipv4/ip_output.c:126\niptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82\nip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813\n__gre_xmit net/ipv4/ip_gre.c:469 [inline]\nipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661\n__netdev_start_xmit include/linux/netdevice.h:4881 [inline]\nnetdev_start_xmit include/linux/netdevice.h:4895 [inline]\nxmit_one net/core/dev.c:3580 [inline]\ndev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596\n__dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246\ndev_queue_xmit include/linux/netdevice.h:3051 [inline]\nneigh_direct_output+0x17/0x20 net/core/neighbour.c:1623\nneigh_output include/net/neighbour.h:546 [inline]\nip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228\nip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316\nNF_HOOK_COND include/linux/netfilter.h:291 [inline]\nip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430\ndst_output include/net/dst.h:444 [inline]\nip_local_out+0x64/0x80 net/ipv4/ip_output.c:126\niptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82\nip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813\n__gre_xmit net/ipv4/ip_gre.c:469 [inline]\nipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661\n__netdev_start_xmit include/linux/netdevice.h:4881 [inline]\nnetdev_start_xmit include/linux/netdevice.h:4895 [inline]\nxmit_one net/core/dev.c:3580 [inline]\ndev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596\n__dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246\ndev_queue_xmit include/linux/netdevice.h:3051 [inline]\nneigh_direct_output+0x17/0x20 net/core/neighbour.c:1623\nneigh_output include/net/neighbour.h:546 [inline]\nip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228\nip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316\nNF_HOOK_COND include/linux/netfilter.h:291 [inline]\nip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430\ndst_output include/net/dst.h:444 [inline]\nip_local_out+0x64/0x80 net/ipv4/ip_output.c:126\niptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82\nip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813\n__gre_xmit net/ipv4/ip_gre.c:469 [inline]\nipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661\n__netdev_start_xmit include/linux/netdevice.h:4881 [inline]\nnetdev_start_xmit include/linux/netdevice.h:4895 [inline]\nxmit_one net/core/dev.c:3580 [inline]\ndev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596\n__dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246\ndev_queue_xmit include/linux/netdevice.h:3051 [inline]\nneigh_direct_output+0x17/0x20 net/core/neighbour.c:1623\nneigh_output include/net/neighbour.h:546 [inline]\nip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228\nip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316\nNF_HOOK_COND include/linux/netfilter.h:291 [inline]\nip_output+0xe5/0x1b0 net/i\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix cleanup null-ptr deref on encap lock\n\nDuring module is unloaded while a peer tc flow is still offloaded,\nfirst the peer uplink rep profile is changed to a nic profile, and so\nneigh encap lock is destroyed. Next during unload, the VF reps netdevs\nare unregistered which causes the original non-peer tc flow to be deleted,\nwhich deletes the peer flow. The peer flow deletion detaches the encap\nentry and try to take the already destroyed encap lock, causing the\nbelow trace.\n\nFix this by clearing peer flows during tc eswitch cleanup\n(mlx5e_tc_esw_cleanup()).\n\nRelevant trace:\n[ 4316.837128] BUG: kernel NULL pointer dereference, address: 00000000000001d8\n[ 4316.842239] RIP: 0010:__mutex_lock+0xb5/0xc40\n[ 4316.851897] Call Trace:\n[ 4316.852481] \n[ 4316.857214] mlx5e_rep_neigh_entry_release+0x93/0x790 [mlx5_core]\n[ 4316.858258] mlx5e_rep_encap_entry_detach+0xa7/0xf0 [mlx5_core]\n[ 4316.859134] mlx5e_encap_dealloc+0xa3/0xf0 [mlx5_core]\n[ 4316.859867] clean_encap_dests.part.0+0x5c/0xe0 [mlx5_core]\n[ 4316.860605] mlx5e_tc_del_fdb_flow+0x32a/0x810 [mlx5_core]\n[ 4316.862609] __mlx5e_tc_del_fdb_peer_flow+0x1a2/0x250 [mlx5_core]\n[ 4316.863394] mlx5e_tc_del_flow+0x(/0x630 [mlx5_core]\n[ 4316.864090] mlx5e_flow_put+0x5f/0x100 [mlx5_core]\n[ 4316.864771] mlx5e_delete_flower+0x4de/0xa40 [mlx5_core]\n[ 4316.865486] tc_setup_cb_reoffload+0x20/0x80\n[ 4316.865905] fl_reoffload+0x47c/0x510 [cls_flower]\n[ 4316.869181] tcf_block_playback_offloads+0x91/0x1d0\n[ 4316.869649] tcf_block_unbind+0xe7/0x1b0\n[ 4316.870049] tcf_block_offload_cmd.isra.0+0x1ee/0x270\n[ 4316.879266] tcf_block_offload_unbind+0x61/0xa0\n[ 4316.879711] __tcf_block_put+0xa4/0x310

In the Linux kernel, the following vulnerability has been resolved:\n\nbonding: restore bond's IFF_SLAVE flag if a non-eth dev enslave fails\n\nsyzbot reported a warning[1] where the bond device itself is a slave and\nwe try to enslave a non-ethernet device as the first slave which fails\nbut then in the error path when ether_setup() restores the bond device\nit also clears all flags. In my previous fix[2] I restored the\nIFF_MASTER flag, but I didn't consider the case that the bond device\nitself might also be a slave with IFF_SLAVE set, so we need to restore\nthat flag as well. Use the bond_ether_setup helper which does the right\nthing and restores the bond's flags properly.\n\nSteps to reproduce using a nlmon dev:\n $ ip l add nlmon0 type nlmon\n $ ip l add bond1 type bond\n $ ip l add bond2 type bond\n $ ip l set bond1 master bond2\n $ ip l set dev nlmon0 master bond1\n $ ip -d l sh dev bond1\n 22: bond1: mtu 1500 qdisc noqueue master bond2 state DOWN mode DEFAULT group default qlen 1000\n (now bond1's IFF_SLAVE flag is gone and we'll hit a warning[3] if we\n try to delete it)\n\n[1] https://syzkaller.appspot.com/bug?id=391c7b1f6522182899efba27d891f1743e8eb3ef\n[2] commit 7d5cd2ce5292 ("bonding: correctly handle bonding type change on enslave failure")\n[3] example warning:\n [ 27.008664] bond1: (slave nlmon0): The slave device specified does not support setting the MAC address\n [ 27.008692] bond1: (slave nlmon0): Error -95 calling set_mac_address\n [ 32.464639] bond1 (unregistering): Released all slaves\n [ 32.464685] ------------[ cut here ]------------\n [ 32.464686] WARNING: CPU: 1 PID: 2004 at net/core/dev.c:10829 unregister_netdevice_many+0x72a/0x780\n [ 32.464694] Modules linked in: br_netfilter bridge bonding virtio_net\n [ 32.464699] CPU: 1 PID: 2004 Comm: ip Kdump: loaded Not tainted 5.18.0-rc3+ #47\n [ 32.464703] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc37 04/01/2014\n [ 32.464704] RIP: 0010:unregister_netdevice_many+0x72a/0x780\n [ 32.464707] Code: 99 fd ff ff ba 90 1a 00 00 48 c7 c6 f4 02 66 96 48 c7 c7 20 4d 35 96 c6 05 fa c7 2b 02 01 e8 be 6f 4a 00 0f 0b e9 73 fd ff ff <0f> 0b e9 5f fd ff ff 80 3d e3 c7 2b 02 00 0f 85 3b fd ff ff ba 59\n [ 32.464710] RSP: 0018:ffffa006422d7820 EFLAGS: 00010206\n [ 32.464712] RAX: ffff8f6e077140a0 RBX: ffffa006422d7888 RCX: 0000000000000000\n [ 32.464714] RDX: ffff8f6e12edbe58 RSI: 0000000000000296 RDI: ffffffff96d4a520\n [ 32.464716] RBP: ffff8f6e07714000 R08: ffffffff96d63600 R09: ffffa006422d7728\n [ 32.464717] R10: 0000000000000ec0 R11: ffffffff9698c988 R12: ffff8f6e12edb140\n [ 32.464719] R13: dead000000000122 R14: dead000000000100 R15: ffff8f6e12edb140\n [ 32.464723] FS: 00007f297c2f1740(0000) GS:ffff8f6e5d900000(0000) knlGS:0000000000000000\n [ 32.464725] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n [ 32.464726] CR2: 00007f297bf1c800 CR3: 00000000115e8000 CR4: 0000000000350ee0\n [ 32.464730] Call Trace:\n [ 32.464763] \n [ 32.464767] rtnl_dellink+0x13e/0x380\n [ 32.464776] ? cred_has_capability.isra.0+0x68/0x100\n [ 32.464780] ? __rtnl_unlock+0x33/0x60\n [ 32.464783] ? bpf_lsm_capset+0x10/0x10\n [ 32.464786] ? security_capable+0x36/0x50\n [ 32.464790] rtnetlink_rcv_msg+0x14e/0x3b0\n [ 32.464792] ? _copy_to_iter+0xb1/0x790\n [ 32.464796] ? post_alloc_hook+0xa0/0x160\n [ 32.464799] ? rtnl_calcit.isra.0+0x110/0x110\n [ 32.464802] netlink_rcv_skb+0x50/0xf0\n [ 32.464806] netlink_unicast+0x216/0x340\n [ 32.464809] netlink_sendmsg+0x23f/0x480\n [ 32.464812] sock_sendmsg+0x5e/0x60\n [ 32.464815] ____sys_sendmsg+0x22c/0x270\n [ 32.464818] ? import_iovec+0x17/0x20\n [ 32.464821] ? sendmsg_copy_msghdr+0x59/0x90\n [ 32.464823] ? do_set_pte+0xa0/0xe0\n [ 32.464828] ___sys_sendmsg+0x81/0xc0\n [ 32.464832] ? mod_objcg_state+0xc6/0x300\n [ 32.464835] ? refill_obj_stock+0xa9/0x160\n [ 32.464838] ? memcg_slab_free_hook+0x1a5/0x1f0\n [ 32.464842] __sys_sendm\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nice: xsk: disable txq irq before flushing hw\n\nice_qp_dis() intends to stop a given queue pair that is a target of xsk\npool attach/detach. One of the steps is to disable interrupts on these\nqueues. It currently is broken in a way that txq irq is turned off\n*after* HW flush which in turn takes no effect.\n\nice_qp_dis():\n-> ice_qvec_dis_irq()\n--> disable rxq irq\n--> flush hw\n-> ice_vsi_stop_tx_ring()\n-->disable txq irq\n\nBelow splat can be triggered by following steps:\n- start xdpsock WITHOUT loading xdp prog\n- run xdp_rxq_info with XDP_TX action on this interface\n- start traffic\n- terminate xdpsock\n\n[ 256.312485] BUG: kernel NULL pointer dereference, address: 0000000000000018\n[ 256.319560] #PF: supervisor read access in kernel mode\n[ 256.324775] #PF: error_code(0x0000) - not-present page\n[ 256.329994] PGD 0 P4D 0\n[ 256.332574] Oops: 0000 [#1] PREEMPT SMP NOPTI\n[ 256.337006] CPU: 3 PID: 32 Comm: ksoftirqd/3 Tainted: G OE 6.2.0-rc5+ #51\n[ 256.345218] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019\n[ 256.355807] RIP: 0010:ice_clean_rx_irq_zc+0x9c/0x7d0 [ice]\n[ 256.361423] Code: b7 8f 8a 00 00 00 66 39 ca 0f 84 f1 04 00 00 49 8b 47 40 4c 8b 24 d0 41 0f b7 45 04 66 25 ff 3f 66 89 04 24 0f 84 85 02 00 00 <49> 8b 44 24 18 0f b7 14 24 48 05 00 01 00 00 49 89 04 24 49 89 44\n[ 256.380463] RSP: 0018:ffffc900088bfd20 EFLAGS: 00010206\n[ 256.385765] RAX: 000000000000003c RBX: 0000000000000035 RCX: 000000000000067f\n[ 256.393012] RDX: 0000000000000775 RSI: 0000000000000000 RDI: ffff8881deb3ac80\n[ 256.400256] RBP: 000000000000003c R08: ffff889847982710 R09: 0000000000010000\n[ 256.407500] R10: ffffffff82c060c0 R11: 0000000000000004 R12: 0000000000000000\n[ 256.414746] R13: ffff88811165eea0 R14: ffffc9000d255000 R15: ffff888119b37600\n[ 256.421990] FS: 0000000000000000(0000) GS:ffff8897e0cc0000(0000) knlGS:0000000000000000\n[ 256.430207] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 256.436036] CR2: 0000000000000018 CR3: 0000000005c0a006 CR4: 00000000007706e0\n[ 256.443283] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 256.450527] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 256.457770] PKRU: 55555554\n[ 256.460529] Call Trace:\n[ 256.463015] \n[ 256.465157] ? ice_xmit_zc+0x6e/0x150 [ice]\n[ 256.469437] ice_napi_poll+0x46d/0x680 [ice]\n[ 256.473815] ? _raw_spin_unlock_irqrestore+0x1b/0x40\n[ 256.478863] __napi_poll+0x29/0x160\n[ 256.482409] net_rx_action+0x136/0x260\n[ 256.486222] __do_softirq+0xe8/0x2e5\n[ 256.489853] ? smpboot_thread_fn+0x2c/0x270\n[ 256.494108] run_ksoftirqd+0x2a/0x50\n[ 256.497747] smpboot_thread_fn+0x1c1/0x270\n[ 256.501907] ? __pfx_smpboot_thread_fn+0x10/0x10\n[ 256.506594] kthread+0xea/0x120\n[ 256.509785] ? __pfx_kthread+0x10/0x10\n[ 256.513597] ret_from_fork+0x29/0x50\n[ 256.517238] \n\nIn fact, irqs were not disabled and napi managed to be scheduled and run\nwhile xsk_pool pointer was still valid, but SW ring of xdp_buff pointers\nwas already freed.\n\nTo fix this, call ice_qvec_dis_irq() after ice_vsi_stop_tx_ring(). Also\nwhile at it, remove redundant ice_clean_rx_ring() call - this is handled\nin ice_qp_clean_rings().

In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix WARNING in ext4_update_inline_data\n\nSyzbot found the following issue:\nEXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 without journal. Quota mode: none.\nfscrypt: AES-256-CTS-CBC using implementation "cts-cbc-aes-aesni"\nfscrypt: AES-256-XTS using implementation "xts-aes-aesni"\n------------[ cut here ]------------\nWARNING: CPU: 0 PID: 5071 at mm/page_alloc.c:5525 __alloc_pages+0x30a/0x560 mm/page_alloc.c:5525\nModules linked in:\nCPU: 1 PID: 5071 Comm: syz-executor263 Not tainted 6.2.0-rc1-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022\nRIP: 0010:__alloc_pages+0x30a/0x560 mm/page_alloc.c:5525\nRSP: 0018:ffffc90003c2f1c0 EFLAGS: 00010246\nRAX: ffffc90003c2f220 RBX: 0000000000000014 RCX: 0000000000000000\nRDX: 0000000000000028 RSI: 0000000000000000 RDI: ffffc90003c2f248\nRBP: ffffc90003c2f2d8 R08: dffffc0000000000 R09: ffffc90003c2f220\nR10: fffff52000785e49 R11: 1ffff92000785e44 R12: 0000000000040d40\nR13: 1ffff92000785e40 R14: dffffc0000000000 R15: 1ffff92000785e3c\nFS: 0000555556c0d300(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f95d5e04138 CR3: 00000000793aa000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \n __alloc_pages_node include/linux/gfp.h:237 [inline]\n alloc_pages_node include/linux/gfp.h:260 [inline]\n __kmalloc_large_node+0x95/0x1e0 mm/slab_common.c:1113\n __do_kmalloc_node mm/slab_common.c:956 [inline]\n __kmalloc+0xfe/0x190 mm/slab_common.c:981\n kmalloc include/linux/slab.h:584 [inline]\n kzalloc include/linux/slab.h:720 [inline]\n ext4_update_inline_data+0x236/0x6b0 fs/ext4/inline.c:346\n ext4_update_inline_dir fs/ext4/inline.c:1115 [inline]\n ext4_try_add_inline_entry+0x328/0x990 fs/ext4/inline.c:1307\n ext4_add_entry+0x5a4/0xeb0 fs/ext4/namei.c:2385\n ext4_add_nondir+0x96/0x260 fs/ext4/namei.c:2772\n ext4_create+0x36c/0x560 fs/ext4/namei.c:2817\n lookup_open fs/namei.c:3413 [inline]\n open_last_lookups fs/namei.c:3481 [inline]\n path_openat+0x12ac/0x2dd0 fs/namei.c:3711\n do_filp_open+0x264/0x4f0 fs/namei.c:3741\n do_sys_openat2+0x124/0x4e0 fs/open.c:1310\n do_sys_open fs/open.c:1326 [inline]\n __do_sys_openat fs/open.c:1342 [inline]\n __se_sys_openat fs/open.c:1337 [inline]\n __x64_sys_openat+0x243/0x290 fs/open.c:1337\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nAbove issue happens as follows:\next4_iget\n ext4_find_inline_data_nolock ->i_inline_off=164 i_inline_size=60\next4_try_add_inline_entry\n __ext4_mark_inode_dirty\n ext4_expand_extra_isize_ea ->i_extra_isize=32 s_want_extra_isize=44\n ext4_xattr_shift_entries\n ->after shift i_inline_off is incorrect, actually is change to 176\next4_try_add_inline_entry\n ext4_update_inline_dir\n get_max_inline_xattr_value_size\n if (EXT4_I(inode)->i_inline_off)\n entry = (struct ext4_xattr_entry *)((void *)raw_inode +\n EXT4_I(inode)->i_inline_off);\n free += EXT4_XATTR_SIZE(le32_to_cpu(entry->e_value_size));\n ->As entry is incorrect, then 'free' may be negative\n ext4_update_inline_data\n value = kzalloc(len, GFP_NOFS);\n -> len is unsigned int, maybe very large, then trigger warning when\n 'kzalloc()'\n\nTo resolve the above issue we need to update 'i_inline_off' after\n'ext4_xattr_shift_entries()'. We do not need to set\nEXT4_STATE_MAY_INLINE_DATA flag here, since ext4_mark_inode_dirty()\nalready sets this flag if needed. Setting EXT4_STATE_MAY_INLINE_DATA\nwhen it is needed may trigger a BUG_ON in ext4_writepages().

In the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: xilinx: don't make a sleepable memory allocation from an atomic context\n\nThe following issue was discovered using lockdep:\n[ 6.691371] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:209\n[ 6.694602] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 1, name: swapper/0\n[ 6.702431] 2 locks held by swapper/0/1:\n[ 6.706300] #0: ffffff8800f6f188 (&dev->mutex){....}-{3:3}, at: __device_driver_lock+0x4c/0x90\n[ 6.714900] #1: ffffffc009a2abb8 (enable_lock){....}-{2:2}, at: clk_enable_lock+0x4c/0x140\n[ 6.723156] irq event stamp: 304030\n[ 6.726596] hardirqs last enabled at (304029): [] _raw_spin_unlock_irqrestore+0xc0/0xd0\n[ 6.736142] hardirqs last disabled at (304030): [] clk_enable_lock+0xfc/0x140\n[ 6.744742] softirqs last enabled at (303958): [] _stext+0x4f0/0x894\n[ 6.752655] softirqs last disabled at (303951): [] irq_exit+0x238/0x280\n[ 6.760744] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G U 5.15.36 #2\n[ 6.768048] Hardware name: xlnx,zynqmp (DT)\n[ 6.772179] Call trace:\n[ 6.774584] dump_backtrace+0x0/0x300\n[ 6.778197] show_stack+0x18/0x30\n[ 6.781465] dump_stack_lvl+0xb8/0xec\n[ 6.785077] dump_stack+0x1c/0x38\n[ 6.788345] ___might_sleep+0x1a8/0x2a0\n[ 6.792129] __might_sleep+0x6c/0xd0\n[ 6.795655] kmem_cache_alloc_trace+0x270/0x3d0\n[ 6.800127] do_feature_check_call+0x100/0x220\n[ 6.804513] zynqmp_pm_invoke_fn+0x8c/0xb0\n[ 6.808555] zynqmp_pm_clock_getstate+0x90/0xe0\n[ 6.813027] zynqmp_pll_is_enabled+0x8c/0x120\n[ 6.817327] zynqmp_pll_enable+0x38/0xc0\n[ 6.821197] clk_core_enable+0x144/0x400\n[ 6.825067] clk_core_enable+0xd4/0x400\n[ 6.828851] clk_core_enable+0xd4/0x400\n[ 6.832635] clk_core_enable+0xd4/0x400\n[ 6.836419] clk_core_enable+0xd4/0x400\n[ 6.840203] clk_core_enable+0xd4/0x400\n[ 6.843987] clk_core_enable+0xd4/0x400\n[ 6.847771] clk_core_enable+0xd4/0x400\n[ 6.851555] clk_core_enable_lock+0x24/0x50\n[ 6.855683] clk_enable+0x24/0x40\n[ 6.858952] fclk_probe+0x84/0xf0\n[ 6.862220] platform_probe+0x8c/0x110\n[ 6.865918] really_probe+0x110/0x5f0\n[ 6.869530] __driver_probe_device+0xcc/0x210\n[ 6.873830] driver_probe_device+0x64/0x140\n[ 6.877958] __driver_attach+0x114/0x1f0\n[ 6.881828] bus_for_each_dev+0xe8/0x160\n[ 6.885698] driver_attach+0x34/0x50\n[ 6.889224] bus_add_driver+0x228/0x300\n[ 6.893008] driver_register+0xc0/0x1e0\n[ 6.896792] __platform_driver_register+0x44/0x60\n[ 6.901436] fclk_driver_init+0x1c/0x28\n[ 6.905220] do_one_initcall+0x104/0x590\n[ 6.909091] kernel_init_freeable+0x254/0x2bc\n[ 6.913390] kernel_init+0x24/0x130\n[ 6.916831] ret_from_fork+0x10/0x20\n\nFix it by passing the GFP_ATOMIC gfp flag for the corresponding\nmemory allocation.

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: rc: gpio-ir-recv: add remove function\n\nIn case runtime PM is enabled, do runtime PM clean up to remove\ncpu latency qos request, otherwise driver removal may have below\nkernel dump:\n\n[ 19.463299] Unable to handle kernel NULL pointer dereference at\nvirtual address 0000000000000048\n[ 19.472161] Mem abort info:\n[ 19.474985] ESR = 0x0000000096000004\n[ 19.478754] EC = 0x25: DABT (current EL), IL = 32 bits\n[ 19.484081] SET = 0, FnV = 0\n[ 19.487149] EA = 0, S1PTW = 0\n[ 19.490361] FSC = 0x04: level 0 translation fault\n[ 19.495256] Data abort info:\n[ 19.498149] ISV = 0, ISS = 0x00000004\n[ 19.501997] CM = 0, WnR = 0\n[ 19.504977] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000049f81000\n[ 19.511432] [0000000000000048] pgd=0000000000000000,\np4d=0000000000000000\n[ 19.518245] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n[ 19.524520] Modules linked in: gpio_ir_recv(+) rc_core [last\nunloaded: rc_core]\n[ 19.531845] CPU: 0 PID: 445 Comm: insmod Not tainted\n6.2.0-rc1-00028-g2c397a46d47c #72\n[ 19.531854] Hardware name: FSL i.MX8MM EVK board (DT)\n[ 19.531859] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS\nBTYPE=--)\n[ 19.551777] pc : cpu_latency_qos_remove_request+0x20/0x110\n[ 19.557277] lr : gpio_ir_recv_runtime_suspend+0x18/0x30\n[gpio_ir_recv]\n[ 19.557294] sp : ffff800008ce3740\n[ 19.557297] x29: ffff800008ce3740 x28: 0000000000000000 x27:\nffff800008ce3d50\n[ 19.574270] x26: ffffc7e3e9cea100 x25: 00000000000f4240 x24:\nffffc7e3f9ef0e30\n[ 19.574284] x23: 0000000000000000 x22: ffff0061803820f4 x21:\n0000000000000008\n[ 19.574296] x20: ffffc7e3fa75df30 x19: 0000000000000020 x18:\nffffffffffffffff\n[ 19.588570] x17: 0000000000000000 x16: ffffc7e3f9efab70 x15:\nffffffffffffffff\n[ 19.595712] x14: ffff800008ce37b8 x13: ffff800008ce37aa x12:\n0000000000000001\n[ 19.602853] x11: 0000000000000001 x10: ffffcbe3ec0dff87 x9 :\n0000000000000008\n[ 19.609991] x8 : 0101010101010101 x7 : 0000000000000000 x6 :\n000000000f0bfe9f\n[ 19.624261] x5 : 00ffffffffffffff x4 : 0025ab8e00000000 x3 :\nffff006180382010\n[ 19.631405] x2 : ffffc7e3e9ce8030 x1 : ffffc7e3fc3eb810 x0 :\n0000000000000020\n[ 19.638548] Call trace:\n[ 19.640995] cpu_latency_qos_remove_request+0x20/0x110\n[ 19.646142] gpio_ir_recv_runtime_suspend+0x18/0x30 [gpio_ir_recv]\n[ 19.652339] pm_generic_runtime_suspend+0x2c/0x44\n[ 19.657055] __rpm_callback+0x48/0x1dc\n[ 19.660807] rpm_callback+0x6c/0x80\n[ 19.664301] rpm_suspend+0x10c/0x640\n[ 19.667880] rpm_idle+0x250/0x2d0\n[ 19.671198] update_autosuspend+0x38/0xe0\n[ 19.675213] pm_runtime_set_autosuspend_delay+0x40/0x60\n[ 19.680442] gpio_ir_recv_probe+0x1b4/0x21c [gpio_ir_recv]\n[ 19.685941] platform_probe+0x68/0xc0\n[ 19.689610] really_probe+0xc0/0x3dc\n[ 19.693189] __driver_probe_device+0x7c/0x190\n[ 19.697550] driver_probe_device+0x3c/0x110\n[ 19.701739] __driver_attach+0xf4/0x200\n[ 19.705578] bus_for_each_dev+0x70/0xd0\n[ 19.709417] driver_attach+0x24/0x30\n[ 19.712998] bus_add_driver+0x17c/0x240\n[ 19.716834] driver_register+0x78/0x130\n[ 19.720676] __platform_driver_register+0x28/0x34\n[ 19.725386] gpio_ir_recv_driver_init+0x20/0x1000 [gpio_ir_recv]\n[ 19.731404] do_one_initcall+0x44/0x2ac\n[ 19.735243] do_init_module+0x48/0x1d0\n[ 19.739003] load_module+0x19fc/0x2034\n[ 19.742759] __do_sys_finit_module+0xac/0x12c\n[ 19.747124] __arm64_sys_finit_module+0x20/0x30\n[ 19.751664] invoke_syscall+0x48/0x114\n[ 19.755420] el0_svc_common.constprop.0+0xcc/0xec\n[ 19.760132] do_el0_svc+0x38/0xb0\n[ 19.763456] el0_svc+0x2c/0x84\n[ 19.766516] el0t_64_sync_handler+0xf4/0x120\n[ 19.770789] el0t_64_sync+0x190/0x194\n[ 19.774460] Code: 910003fd a90153f3 aa0003f3 91204021 (f9401400)\n[ 19.780556] ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/iommu: fix memory leak with using debugfs_lookup()\n\nWhen calling debugfs_lookup() the result must have dput() called on it,\notherwise the memory will leak over time. To make things simpler, just\ncall debugfs_lookup_and_remove() instead which handles all of the logic\nat once.

In the Linux kernel, the following vulnerability has been resolved:\n\ninterconnect: fix mem leak when freeing nodes\n\nThe node link array is allocated when adding links to a node but is not\ndeallocated when nodes are destroyed.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/ttm: Fix a NULL pointer dereference\n\nThe LRU mechanism may look up a resource in the process of being removed\nfrom an object. The locking rules here are a bit unclear but it looks\ncurrently like res->bo assignment is protected by the LRU lock, whereas\nbo->resource is protected by the object lock, while *clearing* of\nbo->resource is also protected by the LRU lock. This means that if\nwe check that bo->resource points to the LRU resource under the LRU\nlock we should be safe.\nSo perform that check before deciding to swap out a bo. That avoids\ndereferencing a NULL bo->resource in ttm_bo_swapout().

In the Linux kernel, the following vulnerability has been resolved:\n\ntty: serial: fsl_lpuart: fix race on RX DMA shutdown\n\nFrom time to time DMA completion can come in the middle of DMA shutdown:\n\n: :\nlpuart32_shutdown()\n lpuart_dma_shutdown()\n del_timer_sync()\n lpuart_dma_rx_complete()\n lpuart_copy_rx_to_tty()\n mod_timer()\n lpuart_dma_rx_free()\n\nWhen the timer fires a bit later, sport->dma_rx_desc is NULL:\n\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000004\npc : lpuart_copy_rx_to_tty+0xcc/0x5bc\nlr : lpuart_timer_func+0x1c/0x2c\nCall trace:\n lpuart_copy_rx_to_tty\n lpuart_timer_func\n call_timer_fn\n __run_timers.part.0\n run_timer_softirq\n __do_softirq\n __irq_exit_rcu\n irq_exit\n handle_domain_irq\n gic_handle_irq\n call_on_irq_stack\n do_interrupt_handler\n ...\n\nTo fix this fold del_timer_sync() into lpuart_dma_rx_free() after\ndmaengine_terminate_sync() to make sure timer will not be re-started in\nlpuart_copy_rx_to_tty() <= lpuart_dma_rx_complete().

In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Do not let histogram values have some modifiers\n\nHistogram values can not be strings, stacktraces, graphs, symbols,\nsyscalls, or grouped in buckets or log. Give an error if a value is set to\ndo so.\n\nNote, the histogram code was not prepared to handle these modifiers for\nhistograms and caused a bug.\n\nMark Rutland reported:\n\n # echo 'p:copy_to_user __arch_copy_to_user n=$arg2' >> /sys/kernel/tracing/kprobe_events\n # echo 'hist:keys=n:vals=hitcount.buckets=8:sort=hitcount' > /sys/kernel/tracing/events/kprobes/copy_to_user/trigger\n # cat /sys/kernel/tracing/events/kprobes/copy_to_user/hist\n[ 143.694628] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n[ 143.695190] Mem abort info:\n[ 143.695362] ESR = 0x0000000096000004\n[ 143.695604] EC = 0x25: DABT (current EL), IL = 32 bits\n[ 143.695889] SET = 0, FnV = 0\n[ 143.696077] EA = 0, S1PTW = 0\n[ 143.696302] FSC = 0x04: level 0 translation fault\n[ 143.702381] Data abort info:\n[ 143.702614] ISV = 0, ISS = 0x00000004\n[ 143.702832] CM = 0, WnR = 0\n[ 143.703087] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000448f9000\n[ 143.703407] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000\n[ 143.704137] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n[ 143.704714] Modules linked in:\n[ 143.705273] CPU: 0 PID: 133 Comm: cat Not tainted 6.2.0-00003-g6fc512c10a7c #3\n[ 143.706138] Hardware name: linux,dummy-virt (DT)\n[ 143.706723] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 143.707120] pc : hist_field_name.part.0+0x14/0x140\n[ 143.707504] lr : hist_field_name.part.0+0x104/0x140\n[ 143.707774] sp : ffff800008333a30\n[ 143.707952] x29: ffff800008333a30 x28: 0000000000000001 x27: 0000000000400cc0\n[ 143.708429] x26: ffffd7a653b20260 x25: 0000000000000000 x24: ffff10d303ee5800\n[ 143.708776] x23: ffffd7a6539b27b0 x22: ffff10d303fb8c00 x21: 0000000000000001\n[ 143.709127] x20: ffff10d303ec2000 x19: 0000000000000000 x18: 0000000000000000\n[ 143.709478] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\n[ 143.709824] x14: 0000000000000000 x13: 203a6f666e692072 x12: 6567676972742023\n[ 143.710179] x11: 0a230a6d6172676f x10: 000000000000002c x9 : ffffd7a6521e018c\n[ 143.710584] x8 : 000000000000002c x7 : 7f7f7f7f7f7f7f7f x6 : 000000000000002c\n[ 143.710915] x5 : ffff10d303b0103e x4 : ffffd7a653b20261 x3 : 000000000000003d\n[ 143.711239] x2 : 0000000000020001 x1 : 0000000000000001 x0 : 0000000000000000\n[ 143.711746] Call trace:\n[ 143.712115] hist_field_name.part.0+0x14/0x140\n[ 143.712642] hist_field_name.part.0+0x104/0x140\n[ 143.712925] hist_field_print+0x28/0x140\n[ 143.713125] event_hist_trigger_print+0x174/0x4d0\n[ 143.713348] hist_show+0xf8/0x980\n[ 143.713521] seq_read_iter+0x1bc/0x4b0\n[ 143.713711] seq_read+0x8c/0xc4\n[ 143.713876] vfs_read+0xc8/0x2a4\n[ 143.714043] ksys_read+0x70/0xfc\n[ 143.714218] __arm64_sys_read+0x24/0x30\n[ 143.714400] invoke_syscall+0x50/0x120\n[ 143.714587] el0_svc_common.constprop.0+0x4c/0x100\n[ 143.714807] do_el0_svc+0x44/0xd0\n[ 143.714970] el0_svc+0x2c/0x84\n[ 143.715134] el0t_64_sync_handler+0xbc/0x140\n[ 143.715334] el0t_64_sync+0x190/0x194\n[ 143.715742] Code: a9bd7bfd 910003fd a90153f3 aa0003f3 (f9400000)\n[ 143.716510] ---[ end trace 0000000000000000 ]---\nSegmentation fault

In the Linux kernel, the following vulnerability has been resolved:\n\ninterconnect: exynos: fix node leak in probe PM QoS error path\n\nMake sure to add the newly allocated interconnect node to the provider\nbefore adding the PM QoS request so that the node is freed on errors.

In the Linux kernel, the following vulnerability has been resolved:\n\next4: update s_journal_inum if it changes after journal replay\n\nWhen mounting a crafted ext4 image, s_journal_inum may change after journal\nreplay, which is obviously unreasonable because we have successfully loaded\nand replayed the journal through the old s_journal_inum. And the new\ns_journal_inum bypasses some of the checks in ext4_get_journal(), which\nmay trigger a null pointer dereference problem. So if s_journal_inum\nchanges after the journal replay, we ignore the change, and rewrite the\ncurrent journal_inum to the superblock.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: Fix an illegal memory access\n\nIn the kfd_wait_on_events() function, the kfd_event_waiter structure is\nallocated by alloc_event_waiters(), but the event field of the waiter\nstructure is not initialized; When copy_from_user() fails in the\nkfd_wait_on_events() function, it will enter exception handling to\nrelease the previously allocated memory of the waiter structure;\nDue to the event field of the waiters structure being accessed\nin the free_waiters() function, this results in illegal memory access\nand system crash, here is the crash log:\n\nlocalhost kernel: RIP: 0010:native_queued_spin_lock_slowpath+0x185/0x1e0\nlocalhost kernel: RSP: 0018:ffffaa53c362bd60 EFLAGS: 00010082\nlocalhost kernel: RAX: ff3d3d6bff4007cb RBX: 0000000000000282 RCX: 00000000002c0000\nlocalhost kernel: RDX: ffff9e855eeacb80 RSI: 000000000000279c RDI: ffffe7088f6a21d0\nlocalhost kernel: RBP: ffffe7088f6a21d0 R08: 00000000002c0000 R09: ffffaa53c362be64\nlocalhost kernel: R10: ffffaa53c362bbd8 R11: 0000000000000001 R12: 0000000000000002\nlocalhost kernel: R13: ffff9e7ead15d600 R14: 0000000000000000 R15: ffff9e7ead15d698\nlocalhost kernel: FS: 0000152a3d111700(0000) GS:ffff9e855ee80000(0000) knlGS:0000000000000000\nlocalhost kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nlocalhost kernel: CR2: 0000152938000010 CR3: 000000044d7a4000 CR4: 00000000003506e0\nlocalhost kernel: Call Trace:\nlocalhost kernel: _raw_spin_lock_irqsave+0x30/0x40\nlocalhost kernel: remove_wait_queue+0x12/0x50\nlocalhost kernel: kfd_wait_on_events+0x1b6/0x490 [hydcu]\nlocalhost kernel: ? ftrace_graph_caller+0xa0/0xa0\nlocalhost kernel: kfd_ioctl+0x38c/0x4a0 [hydcu]\nlocalhost kernel: ? kfd_ioctl_set_trap_handler+0x70/0x70 [hydcu]\nlocalhost kernel: ? kfd_ioctl_create_queue+0x5a0/0x5a0 [hydcu]\nlocalhost kernel: ? ftrace_graph_caller+0xa0/0xa0\nlocalhost kernel: __x64_sys_ioctl+0x8e/0xd0\nlocalhost kernel: ? syscall_trace_enter.isra.18+0x143/0x1b0\nlocalhost kernel: do_syscall_64+0x33/0x80\nlocalhost kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9\nlocalhost kernel: RIP: 0033:0x152a4dff68d7\n\nAllocate the structure with kcalloc, and remove redundant 0-initialization\nand a redundant loop condition check.

In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix task hung in ext4_xattr_delete_inode\n\nSyzbot reported a hung task problem:\n==================================================================\nINFO: task syz-executor232:5073 blocked for more than 143 seconds.\n Not tainted 6.2.0-rc2-syzkaller-00024-g512dee0c00ad #0\n"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.\ntask:syz-exec232 state:D stack:21024 pid:5073 ppid:5072 flags:0x00004004\nCall Trace:\n \n context_switch kernel/sched/core.c:5244 [inline]\n __schedule+0x995/0xe20 kernel/sched/core.c:6555\n schedule+0xcb/0x190 kernel/sched/core.c:6631\n __wait_on_freeing_inode fs/inode.c:2196 [inline]\n find_inode_fast+0x35a/0x4c0 fs/inode.c:950\n iget_locked+0xb1/0x830 fs/inode.c:1273\n __ext4_iget+0x22e/0x3ed0 fs/ext4/inode.c:4861\n ext4_xattr_inode_iget+0x68/0x4e0 fs/ext4/xattr.c:389\n ext4_xattr_inode_dec_ref_all+0x1a7/0xe50 fs/ext4/xattr.c:1148\n ext4_xattr_delete_inode+0xb04/0xcd0 fs/ext4/xattr.c:2880\n ext4_evict_inode+0xd7c/0x10b0 fs/ext4/inode.c:296\n evict+0x2a4/0x620 fs/inode.c:664\n ext4_orphan_cleanup+0xb60/0x1340 fs/ext4/orphan.c:474\n __ext4_fill_super fs/ext4/super.c:5516 [inline]\n ext4_fill_super+0x81cd/0x8700 fs/ext4/super.c:5644\n get_tree_bdev+0x400/0x620 fs/super.c:1282\n vfs_get_tree+0x88/0x270 fs/super.c:1489\n do_new_mount+0x289/0xad0 fs/namespace.c:3145\n do_mount fs/namespace.c:3488 [inline]\n __do_sys_mount fs/namespace.c:3697 [inline]\n __se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3674\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\nRIP: 0033:0x7fa5406fd5ea\nRSP: 002b:00007ffc7232f968 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5\nRAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fa5406fd5ea\nRDX: 0000000020000440 RSI: 0000000020000000 RDI: 00007ffc7232f970\nRBP: 00007ffc7232f970 R08: 00007ffc7232f9b0 R09: 0000000000000432\nR10: 0000000000804a03 R11: 0000000000000202 R12: 0000000000000004\nR13: 0000555556a7a2c0 R14: 00007ffc7232f9b0 R15: 0000000000000000\n \n==================================================================\n\nThe problem is that the inode contains an xattr entry with ea_inum of 15\nwhen cleaning up an orphan inode <15>. When evict inode <15>, the reference\ncounting of the corresponding EA inode is decreased. When EA inode <15> is\nfound by find_inode_fast() in __ext4_iget(), it is found that the EA inode\nholds the I_FREEING flag and waits for the EA inode to complete deletion.\nAs a result, when inode <15> is being deleted, we wait for inode <15> to\ncomplete the deletion, resulting in an infinite loop and triggering Hung\nTask. To solve this problem, we only need to check whether the ino of EA\ninode and parent is the same before getting EA inode.

In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix UaF in listener shutdown\n\nAs reported by Christoph after having refactored the passive\nsocket initialization, the mptcp listener shutdown path is prone\nto an UaF issue.\n\n BUG: KASAN: use-after-free in _raw_spin_lock_bh+0x73/0xe0\n Write of size 4 at addr ffff88810cb23098 by task syz-executor731/1266\n\n CPU: 1 PID: 1266 Comm: syz-executor731 Not tainted 6.2.0-rc59af4eaa31c1f6c00c8f1e448ed99a45c66340dd5 #6\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n Call Trace:\n \n dump_stack_lvl+0x6e/0x91\n print_report+0x16a/0x46f\n kasan_report+0xad/0x130\n kasan_check_range+0x14a/0x1a0\n _raw_spin_lock_bh+0x73/0xe0\n subflow_error_report+0x6d/0x110\n sk_error_report+0x3b/0x190\n tcp_disconnect+0x138c/0x1aa0\n inet_child_forget+0x6f/0x2e0\n inet_csk_listen_stop+0x209/0x1060\n __mptcp_close_ssk+0x52d/0x610\n mptcp_destroy_common+0x165/0x640\n mptcp_destroy+0x13/0x80\n __mptcp_destroy_sock+0xe7/0x270\n __mptcp_close+0x70e/0x9b0\n mptcp_close+0x2b/0x150\n inet_release+0xe9/0x1f0\n __sock_release+0xd2/0x280\n sock_close+0x15/0x20\n __fput+0x252/0xa20\n task_work_run+0x169/0x250\n exit_to_user_mode_prepare+0x113/0x120\n syscall_exit_to_user_mode+0x1d/0x40\n do_syscall_64+0x48/0x90\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\n\nThe msk grace period can legitly expire in between the last\nreference count dropped in mptcp_subflow_queue_clean() and\nthe later eventual access in inet_csk_listen_stop()\n\nAfter the previous patch we don't need anymore special-casing\nmsk listener socket cleanup: the mptcp worker will process each\nof the unaccepted msk sockets.\n\nJust drop the now unnecessary code.\n\nPlease note this commit depends on the two parent ones:\n\n mptcp: refactor passive socket initialization\n mptcp: use the workqueue to destroy unaccepted sockets

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/active: Fix misuse of non-idle barriers as fence trackers\n\nUsers reported oopses on list corruptions when using i915 perf with a\nnumber of concurrently running graphics applications. Root cause analysis\npointed at an issue in barrier processing code -- a race among perf open /\nclose replacing active barriers with perf requests on kernel context and\nconcurrent barrier preallocate / acquire operations performed during user\ncontext first pin / last unpin.\n\nWhen adding a request to a composite tracker, we try to reuse an existing\nfence tracker, already allocated and registered with that composite. The\ntracker we obtain may already track another fence, may be an idle barrier,\nor an active barrier.\n\nIf the tracker we get occurs a non-idle barrier then we try to delete that\nbarrier from a list of barrier tasks it belongs to. However, while doing\nthat we don't respect return value from a function that performs the\nbarrier deletion. Should the deletion ever fail, we would end up reusing\nthe tracker still registered as a barrier task. Since the same structure\nfield is reused with both fence callback lists and barrier tasks list,\nlist corruptions would likely occur.\n\nBarriers are now deleted from a barrier tasks list by temporarily removing\nthe list content, traversing that content with skip over the node to be\ndeleted, then populating the list back with the modified content. Should\nthat intentionally racy concurrent deletion attempts be not serialized,\none or more of those may fail because of the list being temporary empty.\n\nRelated code that ignores the results of barrier deletion was initially\nintroduced in v5.4 by commit d8af05ff38ae ("drm/i915: Allow sharing the\nidle-barrier from other kernel requests"). However, all users of the\nbarrier deletion routine were apparently serialized at that time, then the\nissue didn't exhibit itself. Results of git bisect with help of a newly\ndeveloped igt@gem_barrier_race@remote-request IGT test indicate that list\ncorruptions might start to appear after commit 311770173fac ("drm/i915/gt:\nSchedule request retirement when timeline idles"), introduced in v5.5.\n\nRespect results of barrier deletion attempts -- mark the barrier as idle\nonly if successfully deleted from the list. Then, before proceeding with\nsetting our fence as the one currently tracked, make sure that the tracker\nwe've got is not a non-idle barrier. If that check fails then don't use\nthat tracker but go back and try to acquire a new, usable one.\n\nv3: use unlikely() to document what outcome we expect (Andi),\n - fix bad grammar in commit description.\nv2: no code changes,\n - blame commit 311770173fac ("drm/i915/gt: Schedule request retirement\n when timeline idles"), v5.5, not commit d8af05ff38ae ("drm/i915: Allow\n sharing the idle-barrier from other kernel requests"), v5.4,\n - reword commit description.\n\n(cherry picked from commit 506006055769b10d1b2b4e22f636f3b45e0e9fc7)

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mt76: connac: do not check WED status for non-mmio devices\n\nWED is supported just for mmio devices, so do not check it for usb or\nsdio devices. This patch fixes the crash reported below:\n\n[ 21.946627] wlp0s3u1i3: authenticate with c4:41:1e:f5:2b:1d\n[ 22.525298] wlp0s3u1i3: send auth to c4:41:1e:f5:2b:1d (try 1/3)\n[ 22.548274] wlp0s3u1i3: authenticate with c4:41:1e:f5:2b:1d\n[ 22.557694] wlp0s3u1i3: send auth to c4:41:1e:f5:2b:1d (try 1/3)\n[ 22.565885] wlp0s3u1i3: authenticated\n[ 22.569502] wlp0s3u1i3: associate with c4:41:1e:f5:2b:1d (try 1/3)\n[ 22.578966] wlp0s3u1i3: RX AssocResp from c4:41:1e:f5:2b:1d (capab=0x11 status=30 aid=3)\n[ 22.579113] wlp0s3u1i3: c4:41:1e:f5:2b:1d rejected association temporarily; comeback duration 1000 TU (1024 ms)\n[ 23.649518] wlp0s3u1i3: associate with c4:41:1e:f5:2b:1d (try 2/3)\n[ 23.752528] wlp0s3u1i3: RX AssocResp from c4:41:1e:f5:2b:1d (capab=0x11 status=0 aid=3)\n[ 23.797450] wlp0s3u1i3: associated\n[ 24.959527] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)\n[ 24.959640] BUG: unable to handle page fault for address: ffff88800c223200\n[ 24.959706] #PF: supervisor instruction fetch in kernel mode\n[ 24.959788] #PF: error_code(0x0011) - permissions violation\n[ 24.959846] PGD 2c01067 P4D 2c01067 PUD 2c02067 PMD c2a8063 PTE 800000000c223163\n[ 24.959957] Oops: 0011 [#1] PREEMPT SMP\n[ 24.960009] CPU: 0 PID: 391 Comm: wpa_supplicant Not tainted 6.2.0-kvm #18\n[ 24.960089] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc37 04/01/2014\n[ 24.960191] RIP: 0010:0xffff88800c223200\n[ 24.960446] RSP: 0018:ffffc90000ff7698 EFLAGS: 00010282\n[ 24.960513] RAX: ffff888028397010 RBX: ffff88800c26e630 RCX: 0000000000000058\n[ 24.960598] RDX: ffff88800c26f844 RSI: 0000000000000006 RDI: ffff888028397010\n[ 24.960682] RBP: ffff88800ea72f00 R08: 18b873fbab2b964c R09: be06b38235f3c63c\n[ 24.960766] R10: 18b873fbab2b964c R11: be06b38235f3c63c R12: 0000000000000001\n[ 24.960853] R13: ffff88800c26f84c R14: ffff8880063f0ff8 R15: ffff88800c26e644\n[ 24.960950] FS: 00007effcea327c0(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000\n[ 24.961036] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 24.961106] CR2: ffff88800c223200 CR3: 000000000eaa2000 CR4: 00000000000006b0\n[ 24.961190] Call Trace:\n[ 24.961219] \n[ 24.961245] ? mt76_connac_mcu_add_key+0x2cf/0x310\n[ 24.961313] ? mt7921_set_key+0x150/0x200\n[ 24.961365] ? drv_set_key+0xa9/0x1b0\n[ 24.961418] ? ieee80211_key_enable_hw_accel+0xd9/0x240\n[ 24.961485] ? ieee80211_key_replace+0x3f3/0x730\n[ 24.961541] ? crypto_shash_setkey+0x89/0xd0\n[ 24.961597] ? ieee80211_key_link+0x2d7/0x3a0\n[ 24.961664] ? crypto_aead_setauthsize+0x31/0x50\n[ 24.961730] ? sta_info_hash_lookup+0xa6/0xf0\n[ 24.961785] ? ieee80211_add_key+0x1fc/0x250\n[ 24.961842] ? rdev_add_key+0x41/0x140\n[ 24.961882] ? nl80211_parse_key+0x6c/0x2f0\n[ 24.961940] ? nl80211_new_key+0x24a/0x290\n[ 24.961984] ? genl_rcv_msg+0x36c/0x3a0\n[ 24.962036] ? rdev_mod_link_station+0xe0/0xe0\n[ 24.962102] ? nl80211_set_key+0x410/0x410\n[ 24.962143] ? nl80211_pre_doit+0x200/0x200\n[ 24.962187] ? genl_bind+0xc0/0xc0\n[ 24.962217] ? netlink_rcv_skb+0xaa/0xd0\n[ 24.962259] ? genl_rcv+0x24/0x40\n[ 24.962300] ? netlink_unicast+0x224/0x2f0\n[ 24.962345] ? netlink_sendmsg+0x30b/0x3d0\n[ 24.962388] ? ____sys_sendmsg+0x109/0x1b0\n[ 24.962388] ? ____sys_sendmsg+0x109/0x1b0\n[ 24.962440] ? __import_iovec+0x2e/0x110\n[ 24.962482] ? ___sys_sendmsg+0xbe/0xe0\n[ 24.962525] ? mod_objcg_state+0x25c/0x330\n[ 24.962576] ? __dentry_kill+0x19e/0x1d0\n[ 24.962618] ? call_rcu+0x18f/0x270\n[ 24.962660] ? __dentry_kill+0x19e/0x1d0\n[ 24.962702] ? __x64_sys_sendmsg+0x70/0x90\n[ 24.962744] ? do_syscall_64+0x3d/0x80\n[ 24.962796] ? exit_to_user_mode_prepare+0x1b/0x70\n[ 24.962852] ? entry_SYSCA\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/edid: fix info leak when failing to get panel id\n\nMake sure to clear the transfer buffer before fetching the EDID to\navoid leaking slab data to the logs on errors that leave the buffer\nunchanged.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/shmem-helper: Remove another errant put in error path\n\ndrm_gem_shmem_mmap() doesn't own reference in error code path, resulting\nin the dma-buf shmem GEM object getting prematurely freed leading to a\nlater use-after-free.

In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: don't replace page in rq_pages if it's a continuation of last page\n\nThe splice read calls nfsd_splice_actor to put the pages containing file\ndata into the svc_rqst->rq_pages array. It's possible however to get a\nsplice result that only has a partial page at the end, if (e.g.) the\nfilesystem hands back a short read that doesn't cover the whole page.\n\nnfsd_splice_actor will plop the partial page into its rq_pages array and\nreturn. Then later, when nfsd_splice_actor is called again, the\nremainder of the page may end up being filled out. At this point,\nnfsd_splice_actor will put the page into the array _again_ corrupting\nthe reply. If this is done enough times, rq_next_page will overrun the\narray and corrupt the trailing fields -- the rq_respages and\nrq_next_page pointers themselves.\n\nIf we've already added the page to the array in the last pass, don't add\nit to the array a second time when dealing with a splice continuation.\nThis was originally handled properly in nfsd_splice_actor, but commit\n91e23b1c3982 ("NFSD: Clean up nfsd_splice_actor()") removed the check\nfor it.

In the Linux kernel, the following vulnerability has been resolved:\n\nvp_vdpa: fix the crash in hot unplug with vp_vdpa\n\nWhile unplugging the vp_vdpa device, it triggers a kernel panic\nThe root cause is: vdpa_mgmtdev_unregister() will accesses modern\ndevices which will cause a use after free.\nSo need to change the sequence in vp_vdpa_remove\n\n[ 195.003359] BUG: unable to handle page fault for address: ff4e8beb80199014\n[ 195.004012] #PF: supervisor read access in kernel mode\n[ 195.004486] #PF: error_code(0x0000) - not-present page\n[ 195.004960] PGD 100000067 P4D 1001b6067 PUD 1001b7067 PMD 1001b8067 PTE 0\n[ 195.005578] Oops: 0000 1 PREEMPT SMP PTI\n[ 195.005968] CPU: 13 PID: 164 Comm: kworker/u56:10 Kdump: loaded Not tainted 5.14.0-252.el9.x86_64 #1\n[ 195.006792] Hardware name: Red Hat KVM/RHEL, BIOS edk2-20221207gitfff6d81270b5-2.el9 unknown\n[ 195.007556] Workqueue: kacpi_hotplug acpi_hotplug_work_fn\n[ 195.008059] RIP: 0010:ioread8+0x31/0x80\n[ 195.008418] Code: 77 28 48 81 ff 00 00 01 00 76 0b 89 fa ec 0f b6 c0 c3 cc cc cc cc 8b 15 ad 72 93 01 b8 ff 00 00 00 85 d2 75 0f c3 cc cc cc cc <8a> 07 0f b6 c0 c3 cc cc cc cc 83 ea 01 48 83 ec 08 48 89 fe 48 c7\n[ 195.010104] RSP: 0018:ff4e8beb8067bab8 EFLAGS: 00010292\n[ 195.010584] RAX: ffffffffc05834a0 RBX: ffffffffc05843c0 RCX: ff4e8beb8067bae0\n[ 195.011233] RDX: ff1bcbd580f88000 RSI: 0000000000000246 RDI: ff4e8beb80199014\n[ 195.011881] RBP: ff1bcbd587e39000 R08: ffffffff916fa2d0 R09: ff4e8beb8067ba68\n[ 195.012527] R10: 000000000000001c R11: 0000000000000000 R12: ff1bcbd5a3de9120\n[ 195.013179] R13: ffffffffc062d000 R14: 0000000000000080 R15: ff1bcbe402bc7805\n[ 195.013826] FS: 0000000000000000(0000) GS:ff1bcbe402740000(0000) knlGS:0000000000000000\n[ 195.014564] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 195.015093] CR2: ff4e8beb80199014 CR3: 0000000107dea002 CR4: 0000000000771ee0\n[ 195.015741] PKRU: 55555554\n[ 195.016001] Call Trace:\n[ 195.016233] \n[ 195.016434] vp_modern_get_status+0x12/0x20\n[ 195.016823] vp_vdpa_reset+0x1b/0x50 [vp_vdpa]\n[ 195.017238] virtio_vdpa_reset+0x3c/0x48 [virtio_vdpa]\n[ 195.017709] remove_vq_common+0x1f/0x3a0 [virtio_net]\n[ 195.018178] virtnet_remove+0x5d/0x70 [virtio_net]\n[ 195.018618] virtio_dev_remove+0x3d/0x90\n[ 195.018986] device_release_driver_internal+0x1aa/0x230\n[ 195.019466] bus_remove_device+0xd8/0x150\n[ 195.019841] device_del+0x18b/0x3f0\n[ 195.020167] ? kernfs_find_ns+0x35/0xd0\n[ 195.020526] device_unregister+0x13/0x60\n[ 195.020894] unregister_virtio_device+0x11/0x20\n[ 195.021311] device_release_driver_internal+0x1aa/0x230\n[ 195.021790] bus_remove_device+0xd8/0x150\n[ 195.022162] device_del+0x18b/0x3f0\n[ 195.022487] device_unregister+0x13/0x60\n[ 195.022852] ? vdpa_dev_remove+0x30/0x30 [vdpa]\n[ 195.023270] vp_vdpa_dev_del+0x12/0x20 [vp_vdpa]\n[ 195.023694] vdpa_match_remove+0x2b/0x40 [vdpa]\n[ 195.024115] bus_for_each_dev+0x78/0xc0\n[ 195.024471] vdpa_mgmtdev_unregister+0x65/0x80 [vdpa]\n[ 195.024937] vp_vdpa_remove+0x23/0x40 [vp_vdpa]\n[ 195.025353] pci_device_remove+0x36/0xa0\n[ 195.025719] device_release_driver_internal+0x1aa/0x230\n[ 195.026201] pci_stop_bus_device+0x6c/0x90\n[ 195.026580] pci_stop_and_remove_bus_device+0xe/0x20\n[ 195.027039] disable_slot+0x49/0x90\n[ 195.027366] acpiphp_disable_and_eject_slot+0x15/0x90\n[ 195.027832] hotplug_event+0xea/0x210\n[ 195.028171] ? hotplug_event+0x210/0x210\n[ 195.028535] acpiphp_hotplug_notify+0x22/0x80\n[ 195.028942] ? hotplug_event+0x210/0x210\n[ 195.029303] acpi_device_hotplug+0x8a/0x1d0\n[ 195.029690] acpi_hotplug_work_fn+0x1a/0x30\n[ 195.030077] process_one_work+0x1e8/0x3c0\n[ 195.030451] worker_thread+0x50/0x3b0\n[ 195.030791] ? rescuer_thread+0x3a0/0x3a0\n[ 195.031165] kthread+0xd9/0x100\n[ 195.031459] ? kthread_complete_and_exit+0x20/0x20\n[ 195.031899] ret_from_fork+0x22/0x30\n[ 195.032233]

In the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix data corruption after failed write\n\nWhen buffered write fails to copy data into underlying page cache page,\nocfs2_write_end_nolock() just zeroes out and dirties the page. This can\nleave dirty page beyond EOF and if page writeback tries to write this page\nbefore write succeeds and expands i_size, page gets into inconsistent\nstate where page dirty bit is clear but buffer dirty bits stay set\nresulting in page data never getting written and so data copied to the\npage is lost. Fix the problem by invalidating page beyond EOF after\nfailed write.

In the Linux kernel, the following vulnerability has been resolved:\n\nxsk: Add missing overflow check in xdp_umem_reg\n\nThe number of chunks can overflow u32. Make sure to return -EINVAL on\noverflow. Also remove a redundant u32 cast assigning umem->npgs.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Fix steering rules cleanup\n\nvport's mc, uc and multicast rules are not deleted in teardown path when\nEEH happens. Since the vport's promisc settings(uc, mc and all) in\nfirmware are reset after EEH, mlx5 driver will try to delete the above\nrules in the initialization path. This cause kernel crash because these\nsoftware rules are no longer valid.\n\nFix by nullifying these rules right after delete to avoid accessing any dangling\npointers.\n\nCall Trace:\n__list_del_entry_valid+0xcc/0x100 (unreliable)\ntree_put_node+0xf4/0x1b0 [mlx5_core]\ntree_remove_node+0x30/0x70 [mlx5_core]\nmlx5_del_flow_rules+0x14c/0x1f0 [mlx5_core]\nesw_apply_vport_rx_mode+0x10c/0x200 [mlx5_core]\nesw_update_vport_rx_mode+0xb4/0x180 [mlx5_core]\nesw_vport_change_handle_locked+0x1ec/0x230 [mlx5_core]\nesw_enable_vport+0x130/0x260 [mlx5_core]\nmlx5_eswitch_enable_sriov+0x2a0/0x2f0 [mlx5_core]\nmlx5_device_enable_sriov+0x74/0x440 [mlx5_core]\nmlx5_load_one+0x114c/0x1550 [mlx5_core]\nmlx5_pci_resume+0x68/0xf0 [mlx5_core]\neeh_report_resume+0x1a4/0x230\neeh_pe_dev_traverse+0x98/0x170\neeh_handle_normal_event+0x3e4/0x640\neeh_handle_event+0x4c/0x370\neeh_event_handler+0x14c/0x210\nkthread+0x168/0x1b0\nret_from_kernel_thread+0x5c/0x84

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: scsi_dh_alua: Fix memleak for 'qdata' in alua_activate()\n\nIf alua_rtpg_queue() failed from alua_activate(), then 'qdata' is not\nfreed, which will cause following memleak:\n\nunreferenced object 0xffff88810b2c6980 (size 32):\n comm "kworker/u16:2", pid 635322, jiffies 4355801099 (age 1216426.076s)\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 40 39 24 c1 ff ff ff ff 00 f8 ea 0a 81 88 ff ff @9$.............\n backtrace:\n [<0000000098f3a26d>] alua_activate+0xb0/0x320\n [<000000003b529641>] scsi_dh_activate+0xb2/0x140\n [<000000007b296db3>] activate_path_work+0xc6/0xe0 [dm_multipath]\n [<000000007adc9ace>] process_one_work+0x3c5/0x730\n [<00000000c457a985>] worker_thread+0x93/0x650\n [<00000000cb80e628>] kthread+0x1ba/0x210\n [<00000000a1e61077>] ret_from_fork+0x22/0x30\n\nFix the problem by freeing 'qdata' in error path.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: fix shift-out-of-bounds in CalculateVMAndRowBytes\n\n[WHY]\nWhen PTEBufferSizeInRequests is zero, UBSAN reports the following\nwarning because dml_log2 returns an unexpected negative value:\n\n shift exponent 4294966273 is too large for 32-bit type 'int'\n\n[HOW]\n\nIn the case PTEBufferSizeInRequests is zero, skip the dml_log2() and\nassign the result directly.

In the Linux kernel, the following vulnerability has been resolved:\n\nftrace: Fix invalid address access in lookup_rec() when index is 0\n\nKASAN reported follow problem:\n\n BUG: KASAN: use-after-free in lookup_rec\n Read of size 8 at addr ffff000199270ff0 by task modprobe\n CPU: 2 Comm: modprobe\n Call trace:\n kasan_report\n __asan_load8\n lookup_rec\n ftrace_location\n arch_check_ftrace_location\n check_kprobe_address_safe\n register_kprobe\n\nWhen checking pg->records[pg->index - 1].ip in lookup_rec(), it can get a\npg which is newly added to ftrace_pages_start in ftrace_process_locs().\nBefore the first pg->index++, index is 0 and accessing pg->records[-1].ip\nwill cause this problem.\n\nDon't check the ip when pg->index is 0.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: fix ttm_bo calltrace warning in psp_hw_fini\n\nThe call trace occurs when the amdgpu is removed after\nthe mode1 reset. During mode1 reset, from suspend to resume,\nthere is no need to reinitialize the ta firmware buffer\nwhich caused the bo pin_count increase redundantly.\n\n[ 489.885525] Call Trace:\n[ 489.885525] \n[ 489.885526] amdttm_bo_put+0x34/0x50 [amdttm]\n[ 489.885529] amdgpu_bo_free_kernel+0xe8/0x130 [amdgpu]\n[ 489.885620] psp_free_shared_bufs+0xb7/0x150 [amdgpu]\n[ 489.885720] psp_hw_fini+0xce/0x170 [amdgpu]\n[ 489.885815] amdgpu_device_fini_hw+0x2ff/0x413 [amdgpu]\n[ 489.885960] ? blocking_notifier_chain_unregister+0x56/0xb0\n[ 489.885962] amdgpu_driver_unload_kms+0x51/0x60 [amdgpu]\n[ 489.886049] amdgpu_pci_remove+0x5a/0x140 [amdgpu]\n[ 489.886132] ? __pm_runtime_resume+0x60/0x90\n[ 489.886134] pci_device_remove+0x3e/0xb0\n[ 489.886135] __device_release_driver+0x1ab/0x2a0\n[ 489.886137] driver_detach+0xf3/0x140\n[ 489.886138] bus_remove_driver+0x6c/0xf0\n[ 489.886140] driver_unregister+0x31/0x60\n[ 489.886141] pci_unregister_driver+0x40/0x90\n[ 489.886142] amdgpu_exit+0x15/0x451 [amdgpu]

In the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86/amd/core: Always clear status for idx\n\nThe variable 'status' (which contains the unhandled overflow bits) is\nnot being properly masked in some cases, displaying the following\nwarning:\n\n WARNING: CPU: 156 PID: 475601 at arch/x86/events/amd/core.c:972 amd_pmu_v2_handle_irq+0x216/0x270\n\nThis seems to be happening because the loop is being continued before\nthe status bit being unset, in case x86_perf_event_set_period()\nreturns 0. This is also causing an inconsistency because the "handled"\ncounter is incremented, but the status bit is not cleaned.\n\nMove the bit cleaning together above, together when the "handled"\ncounter is incremented.

In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: use the workqueue to destroy unaccepted sockets\n\nChristoph reported a UaF at token lookup time after having\nrefactored the passive socket initialization part:\n\n BUG: KASAN: use-after-free in __token_bucket_busy+0x253/0x260\n Read of size 4 at addr ffff88810698d5b0 by task syz-executor653/3198\n\n CPU: 1 PID: 3198 Comm: syz-executor653 Not tainted 6.2.0-rc59af4eaa31c1f6c00c8f1e448ed99a45c66340dd5 #6\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n Call Trace:\n \n dump_stack_lvl+0x6e/0x91\n print_report+0x16a/0x46f\n kasan_report+0xad/0x130\n __token_bucket_busy+0x253/0x260\n mptcp_token_new_connect+0x13d/0x490\n mptcp_connect+0x4ed/0x860\n __inet_stream_connect+0x80e/0xd90\n tcp_sendmsg_fastopen+0x3ce/0x710\n mptcp_sendmsg+0xff1/0x1a20\n inet_sendmsg+0x11d/0x140\n __sys_sendto+0x405/0x490\n __x64_sys_sendto+0xdc/0x1b0\n do_syscall_64+0x3b/0x90\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\n\nWe need to properly clean-up all the paired MPTCP-level\nresources and be sure to release the msk last, even when\nthe unaccepted subflow is destroyed by the TCP internals\nvia inet_child_forget().\n\nWe can re-use the existing MPTCP_WORK_CLOSE_SUBFLOW infra,\nexplicitly checking that for the critical scenario: the\nclosed subflow is the MPC one, the msk is not accepted and\neventually going through full cleanup.\n\nWith such change, __mptcp_destroy_sock() is always called\non msk sockets, even on accepted ones. We don't need anymore\nto transiently drop one sk reference at msk clone time.\n\nPlease note this commit depends on the parent one:\n\n mptcp: refactor passive socket initialization

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mt76: do not run mt76_unregister_device() on unregistered hw\n\nTrying to probe a mt7921e pci card without firmware results in a\nsuccessful probe where ieee80211_register_hw hasn't been called. When\nremoving the driver, ieee802111_unregister_hw is called unconditionally\nleading to a kernel NULL pointer dereference.\nFix the issue running mt76_unregister_device routine just for registered\nhw.

In the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-vf: Add missing free for alloc_percpu\n\nAdd the free_percpu for the allocated "vf->hw.lmt_info" in order to avoid\nmemory leak, same as the "pf->hw.lmt_info" in\n`drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c`.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: lan78xx: Limit packet length to skb->len\n\nPacket length retrieved from descriptor may be larger than\nthe actual socket buffer length. In such case the cloned\nskb passed up the network stack will leak kernel memory contents.\n\nAdditionally prevent integer underflow when size is less than\nETH_FCS_LEN.

In the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Only call get_timer_irq() once in constant_clockevent_init()\n\nUnder CONFIG_DEBUG_ATOMIC_SLEEP=y and CONFIG_DEBUG_PREEMPT=y, we can see\nthe following messages on LoongArch, this is because using might_sleep()\nin preemption disable context.\n\n[ 0.001127] smp: Bringing up secondary CPUs ...\n[ 0.001222] Booting CPU#1...\n[ 0.001244] 64-bit Loongson Processor probed (LA464 Core)\n[ 0.001247] CPU1 revision is: 0014c012 (Loongson-64bit)\n[ 0.001250] FPU1 revision is: 00000000\n[ 0.001252] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:283\n[ 0.001255] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1\n[ 0.001257] preempt_count: 1, expected: 0\n[ 0.001258] RCU nest depth: 0, expected: 0\n[ 0.001259] Preemption disabled at:\n[ 0.001261] [<9000000000223800>] arch_dup_task_struct+0x20/0x110\n[ 0.001272] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.2.0-rc7+ #43\n[ 0.001275] Hardware name: Loongson Loongson-3A5000-7A1000-1w-A2101/Loongson-LS3A5000-7A1000-1w-A2101, BIOS vUDK2018-LoongArch-V4.0.05132-beta10 12/13/202\n[ 0.001277] Stack : 0072617764726148 0000000000000000 9000000000222f1c 90000001001e0000\n[ 0.001286] 90000001001e3be0 90000001001e3be8 0000000000000000 0000000000000000\n[ 0.001292] 90000001001e3be8 0000000000000040 90000001001e3cb8 90000001001e3a50\n[ 0.001297] 9000000001642000 90000001001e3be8 be694d10ce4139dd 9000000100174500\n[ 0.001303] 0000000000000001 0000000000000001 00000000ffffe0a2 0000000000000020\n[ 0.001309] 000000000000002f 9000000001354116 00000000056b0000 ffffffffffffffff\n[ 0.001314] 0000000000000000 0000000000000000 90000000014f6e90 9000000001642000\n[ 0.001320] 900000000022b69c 0000000000000001 0000000000000000 9000000001736a90\n[ 0.001325] 9000000100038000 0000000000000000 9000000000222f34 0000000000000000\n[ 0.001331] 00000000000000b0 0000000000000004 0000000000000000 0000000000070000\n[ 0.001337] ...\n[ 0.001339] Call Trace:\n[ 0.001342] [<9000000000222f34>] show_stack+0x5c/0x180\n[ 0.001346] [<90000000010bdd80>] dump_stack_lvl+0x60/0x88\n[ 0.001352] [<9000000000266418>] __might_resched+0x180/0x1cc\n[ 0.001356] [<90000000010c742c>] mutex_lock+0x20/0x64\n[ 0.001359] [<90000000002a8ccc>] irq_find_matching_fwspec+0x48/0x124\n[ 0.001364] [<90000000002259c4>] constant_clockevent_init+0x68/0x204\n[ 0.001368] [<900000000022acf4>] start_secondary+0x40/0xa8\n[ 0.001371] [<90000000010c0124>] smpboot_entry+0x60/0x64\n\nHere are the complete call chains:\n\nsmpboot_entry()\n start_secondary()\n constant_clockevent_init()\n get_timer_irq()\n irq_find_matching_fwnode()\n irq_find_matching_fwspec()\n mutex_lock()\n might_sleep()\n __might_sleep()\n __might_resched()\n\nIn order to avoid the above issue, we should break the call chains,\nusing timer_irq_installed variable as check condition to only call\nget_timer_irq() once in constant_clockevent_init() is a simple and\nproper way.

In the Linux kernel, the following vulnerability has been resolved:\n\nqed/qed_sriov: guard against NULL derefs from qed_iov_get_vf_info\n\nWe have to make sure that the info returned by the helper is valid\nbefore using it.\n\nFound by Linux Verification Center (linuxtesting.org) with the SVACE\nstatic analysis tool.

In the Linux kernel, the following vulnerability has been resolved:\n\nperf/core: Fix perf_output_begin parameter is incorrectly invoked in perf_event_bpf_output\n\nsyzkaller reportes a KASAN issue with stack-out-of-bounds.\nThe call trace is as follows:\n dump_stack+0x9c/0xd3\n print_address_description.constprop.0+0x19/0x170\n __kasan_report.cold+0x6c/0x84\n kasan_report+0x3a/0x50\n __perf_event_header__init_id+0x34/0x290\n perf_event_header__init_id+0x48/0x60\n perf_output_begin+0x4a4/0x560\n perf_event_bpf_output+0x161/0x1e0\n perf_iterate_sb_cpu+0x29e/0x340\n perf_iterate_sb+0x4c/0xc0\n perf_event_bpf_event+0x194/0x2c0\n __bpf_prog_put.constprop.0+0x55/0xf0\n __cls_bpf_delete_prog+0xea/0x120 [cls_bpf]\n cls_bpf_delete_prog_work+0x1c/0x30 [cls_bpf]\n process_one_work+0x3c2/0x730\n worker_thread+0x93/0x650\n kthread+0x1b8/0x210\n ret_from_fork+0x1f/0x30\n\ncommit 267fb27352b6 ("perf: Reduce stack usage of perf_output_begin()")\nuse on-stack struct perf_sample_data of the caller function.\n\nHowever, perf_event_bpf_output uses incorrect parameter to convert\nsmall-sized data (struct perf_bpf_event) into large-sized data\n(struct perf_sample_data), which causes memory overwriting occurs in\n__perf_event_header__init_id.

In the Linux kernel, the following vulnerability has been resolved:\n\niavf: fix hang on reboot with ice\n\nWhen a system with E810 with existing VFs gets rebooted the following\nhang may be observed.\n\n Pid 1 is hung in iavf_remove(), part of a network driver:\n PID: 1 TASK: ffff965400e5a340 CPU: 24 COMMAND: "systemd-shutdow"\n #0 [ffffaad04005fa50] __schedule at ffffffff8b3239cb\n #1 [ffffaad04005fae8] schedule at ffffffff8b323e2d\n #2 [ffffaad04005fb00] schedule_hrtimeout_range_clock at ffffffff8b32cebc\n #3 [ffffaad04005fb80] usleep_range_state at ffffffff8b32c930\n #4 [ffffaad04005fbb0] iavf_remove at ffffffffc12b9b4c [iavf]\n #5 [ffffaad04005fbf0] pci_device_remove at ffffffff8add7513\n #6 [ffffaad04005fc10] device_release_driver_internal at ffffffff8af08baa\n #7 [ffffaad04005fc40] pci_stop_bus_device at ffffffff8adcc5fc\n #8 [ffffaad04005fc60] pci_stop_and_remove_bus_device at ffffffff8adcc81e\n #9 [ffffaad04005fc70] pci_iov_remove_virtfn at ffffffff8adf9429\n #10 [ffffaad04005fca8] sriov_disable at ffffffff8adf98e4\n #11 [ffffaad04005fcc8] ice_free_vfs at ffffffffc04bb2c8 [ice]\n #12 [ffffaad04005fd10] ice_remove at ffffffffc04778fe [ice]\n #13 [ffffaad04005fd38] ice_shutdown at ffffffffc0477946 [ice]\n #14 [ffffaad04005fd50] pci_device_shutdown at ffffffff8add58f1\n #15 [ffffaad04005fd70] device_shutdown at ffffffff8af05386\n #16 [ffffaad04005fd98] kernel_restart at ffffffff8a92a870\n #17 [ffffaad04005fda8] __do_sys_reboot at ffffffff8a92abd6\n #18 [ffffaad04005fee0] do_syscall_64 at ffffffff8b317159\n #19 [ffffaad04005ff08] __context_tracking_enter at ffffffff8b31b6fc\n #20 [ffffaad04005ff18] syscall_exit_to_user_mode at ffffffff8b31b50d\n #21 [ffffaad04005ff28] do_syscall_64 at ffffffff8b317169\n #22 [ffffaad04005ff50] entry_SYSCALL_64_after_hwframe at ffffffff8b40009b\n RIP: 00007f1baa5c13d7 RSP: 00007fffbcc55a98 RFLAGS: 00000202\n RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1baa5c13d7\n RDX: 0000000001234567 RSI: 0000000028121969 RDI: 00000000fee1dead\n RBP: 00007fffbcc55ca0 R8: 0000000000000000 R9: 00007fffbcc54e90\n R10: 00007fffbcc55050 R11: 0000000000000202 R12: 0000000000000005\n R13: 0000000000000000 R14: 00007fffbcc55af0 R15: 0000000000000000\n ORIG_RAX: 00000000000000a9 CS: 0033 SS: 002b\n\nDuring reboot all drivers PM shutdown callbacks are invoked.\nIn iavf_shutdown() the adapter state is changed to __IAVF_REMOVE.\nIn ice_shutdown() the call chain above is executed, which at some point\ncalls iavf_remove(). However iavf_remove() expects the VF to be in one\nof the states __IAVF_RUNNING, __IAVF_DOWN or __IAVF_INIT_FAILED. If\nthat's not the case it sleeps forever.\nSo if iavf_shutdown() gets invoked before iavf_remove() the system will\nhang indefinitely because the adapter is already in state __IAVF_REMOVE.\n\nFix this by returning from iavf_remove() if the state is __IAVF_REMOVE,\nas we already went through iavf_shutdown().

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: smsc95xx: Limit packet length to skb->len\n\nPacket length retrieved from descriptor may be larger than\nthe actual socket buffer length. In such case the cloned\nskb passed up the network stack will leak kernel memory contents.

In the Linux kernel, the following vulnerability has been resolved:\n\nplatform/chrome: cros_ec_chardev: fix kernel data leak from ioctl\n\nIt is possible to peep kernel page's data by providing larger `insize`\nin struct cros_ec_command[1] when invoking EC host commands.\n\nFix it by using zeroed memory.\n\n[1]: https://elixir.bootlin.com/linux/v6.2/source/include/linux/platform_data/cros_ec_proto.h#L74

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: E-Switch, Fix an Oops in error handling code\n\nThe error handling dereferences "vport". There is nothing we can do if\nit is an error pointer except returning the error code.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Synchronize the IOCB count to be in order\n\nA system hang was observed with the following call trace:\n\nBUG: kernel NULL pointer dereference, address: 0000000000000000\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 15 PID: 86747 Comm: nvme Kdump: loaded Not tainted 6.2.0+ #1\nHardware name: Dell Inc. PowerEdge R6515/04F3CJ, BIOS 2.7.3 03/31/2022\nRIP: 0010:__wake_up_common+0x55/0x190\nCode: 41 f6 01 04 0f 85 b2 00 00 00 48 8b 43 08 4c 8d\n 40 e8 48 8d 43 08 48 89 04 24 48 89 c6\\\n 49 8d 40 18 48 39 c6 0f 84 e9 00 00 00 <49> 8b 40 18 89 6c 24 14 31\n ed 4c 8d 60 e8 41 8b 18 f6 c3 04 75 5d\nRSP: 0018:ffffb05a82afbba0 EFLAGS: 00010082\nRAX: 0000000000000000 RBX: ffff8f9b83a00018 RCX: 0000000000000000\nRDX: 0000000000000001 RSI: ffff8f9b83a00020 RDI: ffff8f9b83a00018\nRBP: 0000000000000001 R08: ffffffffffffffe8 R09: ffffb05a82afbbf8\nR10: 70735f7472617473 R11: 5f30307832616c71 R12: 0000000000000001\nR13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000\nFS: 00007f815cf4c740(0000) GS:ffff8f9eeed80000(0000)\n knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000000 CR3: 000000010633a000 CR4: 0000000000350ee0\nCall Trace:\n \n __wake_up_common_lock+0x83/0xd0\n qla_nvme_ls_req+0x21b/0x2b0 [qla2xxx]\n __nvme_fc_send_ls_req+0x1b5/0x350 [nvme_fc]\n nvme_fc_xmt_disconnect_assoc+0xca/0x110 [nvme_fc]\n nvme_fc_delete_association+0x1bf/0x220 [nvme_fc]\n ? nvme_remove_namespaces+0x9f/0x140 [nvme_core]\n nvme_do_delete_ctrl+0x5b/0xa0 [nvme_core]\n nvme_sysfs_delete+0x5f/0x70 [nvme_core]\n kernfs_fop_write_iter+0x12b/0x1c0\n vfs_write+0x2a3/0x3b0\n ksys_write+0x5f/0xe0\n do_syscall_64+0x5c/0x90\n ? syscall_exit_work+0x103/0x130\n ? syscall_exit_to_user_mode+0x12/0x30\n ? do_syscall_64+0x69/0x90\n ? exit_to_user_mode_loop+0xd0/0x130\n ? exit_to_user_mode_prepare+0xec/0x100\n ? syscall_exit_to_user_mode+0x12/0x30\n ? do_syscall_64+0x69/0x90\n ? syscall_exit_to_user_mode+0x12/0x30\n ? do_syscall_64+0x69/0x90\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\n RIP: 0033:0x7f815cd3eb97\n\nThe IOCB counts are out of order and that would block any commands from\ngoing out and subsequently hang the system. Synchronize the IOCB count to\nbe in correct order.

In the Linux kernel, the following vulnerability has been resolved:\n\nfscrypt: destroy keyring after security_sb_delete()\n\nfscrypt_destroy_keyring() must be called after all potentially-encrypted\ninodes were evicted; otherwise it cannot safely destroy the keyring.\nSince inodes that are in-use by the Landlock LSM don't get evicted until\nsecurity_sb_delete(), this means that fscrypt_destroy_keyring() must be\ncalled *after* security_sb_delete().\n\nThis fixes a WARN_ON followed by a NULL dereference, only possible if\nLandlock was being used on encrypted files.

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: dwc2: fix a devres leak in hw_enable upon suspend resume\n\nEach time the platform goes to low power, PM suspend / resume routines\ncall: __dwc2_lowlevel_hw_enable -> devm_add_action_or_reset().\nThis adds a new devres each time.\nThis may also happen at runtime, as dwc2_lowlevel_hw_enable() can be\ncalled from udc_start().\n\nThis can be seen with tracing:\n- echo 1 > /sys/kernel/debug/tracing/events/dev/devres_log/enable\n- go to low power\n- cat /sys/kernel/debug/tracing/trace\n\nA new "ADD" entry is found upon each low power cycle:\n... devres_log: 49000000.usb-otg ADD 82a13bba devm_action_release (8 bytes)\n... devres_log: 49000000.usb-otg ADD 49889daf devm_action_release (8 bytes)\n...\n\nA second issue is addressed here:\n- regulator_bulk_enable() is called upon each PM cycle (suspend/resume).\n- regulator_bulk_disable() never gets called.\n\nSo the reference count for these regulators constantly increase, by one\nupon each low power cycle, due to missing regulator_bulk_disable() call\nin __dwc2_lowlevel_hw_disable().\n\nThe original fix that introduced the devm_add_action_or_reset() call,\nfixed an issue during probe, that happens due to other errors in\ndwc2_driver_probe() -> dwc2_core_reset(). Then the probe fails without\ndisabling regulators, when dr_mode == USB_DR_MODE_PERIPHERAL.\n\nRather fix the error path: disable all the low level hardware in the\nerror path, by using the "hsotg->ll_hw_enabled" flag. Checking dr_mode\nhas been introduced to avoid a dual call to dwc2_lowlevel_hw_disable().\n"ll_hw_enabled" should achieve the same (and is used currently in the\nremove() routine).

In the Linux kernel, the following vulnerability has been resolved:\n\nerspan: do not use skb_mac_header() in ndo_start_xmit()\n\nDrivers should not assume skb_mac_header(skb) == skb->data in their\nndo_start_xmit().\n\nUse skb_network_offset() and skb_transport_offset() which\nbetter describe what is needed in erspan_fb_xmit() and\nip6erspan_tunnel_xmit()\n\nsyzbot reported:\nWARNING: CPU: 0 PID: 5083 at include/linux/skbuff.h:2873 skb_mac_header include/linux/skbuff.h:2873 [inline]\nWARNING: CPU: 0 PID: 5083 at include/linux/skbuff.h:2873 ip6erspan_tunnel_xmit+0x1d9c/0x2d90 net/ipv6/ip6_gre.c:962\nModules linked in:\nCPU: 0 PID: 5083 Comm: syz-executor406 Not tainted 6.3.0-rc2-syzkaller-00866-gd4671cb96fa3 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023\nRIP: 0010:skb_mac_header include/linux/skbuff.h:2873 [inline]\nRIP: 0010:ip6erspan_tunnel_xmit+0x1d9c/0x2d90 net/ipv6/ip6_gre.c:962\nCode: 04 02 41 01 de 84 c0 74 08 3c 03 0f 8e 1c 0a 00 00 45 89 b4 24 c8 00 00 00 c6 85 77 fe ff ff 01 e9 33 e7 ff ff e8 b4 27 a1 f8 <0f> 0b e9 b6 e7 ff ff e8 a8 27 a1 f8 49 8d bf f0 0c 00 00 48 b8 00\nRSP: 0018:ffffc90003b2f830 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: 000000000000ffff RCX: 0000000000000000\nRDX: ffff888021273a80 RSI: ffffffff88e1bd4c RDI: 0000000000000003\nRBP: ffffc90003b2f9d8 R08: 0000000000000003 R09: 000000000000ffff\nR10: 000000000000ffff R11: 0000000000000000 R12: ffff88802b28da00\nR13: 00000000000000d0 R14: ffff88807e25b6d0 R15: ffff888023408000\nFS: 0000555556a61300(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000055e5b11eb6e8 CR3: 0000000027c1b000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n\n__netdev_start_xmit include/linux/netdevice.h:4900 [inline]\nnetdev_start_xmit include/linux/netdevice.h:4914 [inline]\n__dev_direct_xmit+0x504/0x730 net/core/dev.c:4300\ndev_direct_xmit include/linux/netdevice.h:3088 [inline]\npacket_xmit+0x20a/0x390 net/packet/af_packet.c:285\npacket_snd net/packet/af_packet.c:3075 [inline]\npacket_sendmsg+0x31a0/0x5150 net/packet/af_packet.c:3107\nsock_sendmsg_nosec net/socket.c:724 [inline]\nsock_sendmsg+0xde/0x190 net/socket.c:747\n__sys_sendto+0x23a/0x340 net/socket.c:2142\n__do_sys_sendto net/socket.c:2154 [inline]\n__se_sys_sendto net/socket.c:2150 [inline]\n__x64_sys_sendto+0xe1/0x1b0 net/socket.c:2150\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\nRIP: 0033:0x7f123aaa1039\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 14 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007ffc15d12058 EFLAGS: 00000246 ORIG_RAX: 000000000000002c\nRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f123aaa1039\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003\nRBP: 0000000000000000 R08: 0000000020000040 R09: 0000000000000014\nR10: 0000000000000000 R11: 0000000000000246 R12: 00007f123aa648c0\nR13: 431bde82d7b634db R14: 0000000000000000 R15: 0000000000000000

In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: fix use-after-free bug in refresh_cache_worker()\n\nThe UAF bug occurred because we were putting DFS root sessions in\ncifs_umount() while DFS cache refresher was being executed.\n\nMake DFS root sessions have same lifetime as DFS tcons so we can avoid\nthe use-after-free bug is DFS cache refresher and other places that\nrequire IPCs to get new DFS referrals on. Also, get rid of mount\ngroup handling in DFS cache as we no longer need it.\n\nThis fixes below use-after-free bug catched by KASAN\n\n[ 379.946955] BUG: KASAN: use-after-free in __refresh_tcon.isra.0+0x10b/0xc10 [cifs]\n[ 379.947642] Read of size 8 at addr ffff888018f57030 by task kworker/u4:3/56\n[ 379.948096]\n[ 379.948208] CPU: 0 PID: 56 Comm: kworker/u4:3 Not tainted 6.2.0-rc7-lku #23\n[ 379.948661] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS\nrel-1.16.0-0-gd239552-rebuilt.opensuse.org 04/01/2014\n[ 379.949368] Workqueue: cifs-dfscache refresh_cache_worker [cifs]\n[ 379.949942] Call Trace:\n[ 379.950113] \n[ 379.950260] dump_stack_lvl+0x50/0x67\n[ 379.950510] print_report+0x16a/0x48e\n[ 379.950759] ? __virt_addr_valid+0xd8/0x160\n[ 379.951040] ? __phys_addr+0x41/0x80\n[ 379.951285] kasan_report+0xdb/0x110\n[ 379.951533] ? __refresh_tcon.isra.0+0x10b/0xc10 [cifs]\n[ 379.952056] ? __refresh_tcon.isra.0+0x10b/0xc10 [cifs]\n[ 379.952585] __refresh_tcon.isra.0+0x10b/0xc10 [cifs]\n[ 379.953096] ? __pfx___refresh_tcon.isra.0+0x10/0x10 [cifs]\n[ 379.953637] ? __pfx___mutex_lock+0x10/0x10\n[ 379.953915] ? lock_release+0xb6/0x720\n[ 379.954167] ? __pfx_lock_acquire+0x10/0x10\n[ 379.954443] ? refresh_cache_worker+0x34e/0x6d0 [cifs]\n[ 379.954960] ? __pfx_wb_workfn+0x10/0x10\n[ 379.955239] refresh_cache_worker+0x4ad/0x6d0 [cifs]\n[ 379.955755] ? __pfx_refresh_cache_worker+0x10/0x10 [cifs]\n[ 379.956323] ? __pfx_lock_acquired+0x10/0x10\n[ 379.956615] ? read_word_at_a_time+0xe/0x20\n[ 379.956898] ? lockdep_hardirqs_on_prepare+0x12/0x220\n[ 379.957235] process_one_work+0x535/0x990\n[ 379.957509] ? __pfx_process_one_work+0x10/0x10\n[ 379.957812] ? lock_acquired+0xb7/0x5f0\n[ 379.958069] ? __list_add_valid+0x37/0xd0\n[ 379.958341] ? __list_add_valid+0x37/0xd0\n[ 379.958611] worker_thread+0x8e/0x630\n[ 379.958861] ? __pfx_worker_thread+0x10/0x10\n[ 379.959148] kthread+0x17d/0x1b0\n[ 379.959369] ? __pfx_kthread+0x10/0x10\n[ 379.959630] ret_from_fork+0x2c/0x50\n[ 379.959879]

In the Linux kernel, the following vulnerability has been resolved:\n\ndm crypt: add cond_resched() to dmcrypt_write()\n\nThe loop in dmcrypt_write may be running for unbounded amount of time,\nthus we need cond_resched() in it.\n\nThis commit fixes the following warning:\n\n[ 3391.153255][ C12] watchdog: BUG: soft lockup - CPU#12 stuck for 23s! [dmcrypt_write/2:2897]\n...\n[ 3391.387210][ C12] Call trace:\n[ 3391.390338][ C12] blk_attempt_bio_merge.part.6+0x38/0x158\n[ 3391.395970][ C12] blk_attempt_plug_merge+0xc0/0x1b0\n[ 3391.401085][ C12] blk_mq_submit_bio+0x398/0x550\n[ 3391.405856][ C12] submit_bio_noacct+0x308/0x380\n[ 3391.410630][ C12] dmcrypt_write+0x1e4/0x208 [dm_crypt]\n[ 3391.416005][ C12] kthread+0x130/0x138\n[ 3391.419911][ C12] ret_from_fork+0x10/0x18

In the Linux kernel, the following vulnerability has been resolved:\n\nthunderbolt: Fix memory leak in margining\n\nMemory for the usb4->margining needs to be relased for the upstream port\nof the router as well, even though the debugfs directory gets released\nwith the router device removal. Fix this.

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: ucsi: Fix NULL pointer deref in ucsi_connector_change()\n\nWhen ucsi_init() fails, ucsi->connector is NULL, yet in case of\nucsi_acpi we may still get events which cause the ucs_acpi code to call\nucsi_connector_change(), which then derefs the NULL ucsi->connector\npointer.\n\nFix this by not setting ucsi->ntfy inside ucsi_init() until ucsi_init()\nhas succeeded, so that ucsi_connector_change() ignores the events\nbecause UCSI_ENABLE_NTFY_CONNECTOR_CHANGE is not set in the ntfy mask.

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: tcpm: fix warning when handle discover_identity message\n\nSince both source and sink device can send discover_identity message in\nPD3, kernel may dump below warning:\n\n------------[ cut here ]------------\nWARNING: CPU: 0 PID: 169 at drivers/usb/typec/tcpm/tcpm.c:1446 tcpm_queue_vdm+0xe0/0xf0\nModules linked in:\nCPU: 0 PID: 169 Comm: 1-0050 Not tainted 6.1.1-00038-g6a3c36cf1da2-dirty #567\nHardware name: NXP i.MX8MPlus EVK board (DT)\npstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : tcpm_queue_vdm+0xe0/0xf0\nlr : tcpm_queue_vdm+0x2c/0xf0\nsp : ffff80000c19bcd0\nx29: ffff80000c19bcd0 x28: 0000000000000001 x27: ffff0000d11c8ab8\nx26: ffff0000d11cc000 x25: 0000000000000000 x24: 00000000ff008081\nx23: 0000000000000001 x22: 00000000ff00a081 x21: ffff80000c19bdbc\nx20: 0000000000000000 x19: ffff0000d11c8080 x18: ffffffffffffffff\nx17: 0000000000000000 x16: 0000000000000000 x15: ffff0000d716f580\nx14: 0000000000000001 x13: ffff0000d716f507 x12: 0000000000000001\nx11: 0000000000000000 x10: 0000000000000020 x9 : 00000000000ee098\nx8 : 00000000ffffffff x7 : 000000000000001c x6 : ffff0000d716f580\nx5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000\nx2 : ffff80000c19bdbc x1 : 00000000ff00a081 x0 : 0000000000000004\nCall trace:\ntcpm_queue_vdm+0xe0/0xf0\ntcpm_pd_rx_handler+0x340/0x1ab0\nkthread_worker_fn+0xcc/0x18c\nkthread+0x10c/0x110\nret_from_fork+0x10/0x20\n---[ end trace 0000000000000000 ]---\n\nBelow sequences may trigger this warning:\n\ntcpm_send_discover_work(work)\n tcpm_send_vdm(port, USB_SID_PD, CMD_DISCOVER_IDENT, NULL, 0);\n tcpm_queue_vdm(port, header, data, count);\n port->vdm_state = VDM_STATE_READY;\n\nvdm_state_machine_work(work);\n <-- received discover_identity from partner\n vdm_run_state_machine(port);\n port->vdm_state = VDM_STATE_SEND_MESSAGE;\n mod_vdm_delayed_work(port, x);\n\ntcpm_pd_rx_handler(work);\n tcpm_pd_data_request(port, msg);\n tcpm_handle_vdm_request(port, msg->payload, cnt);\n tcpm_queue_vdm(port, response[0], &response[1], rlen - 1);\n--> WARN_ON(port->vdm_state > VDM_STATE_DONE);\n\nFor this case, the state machine could still send out discover\nidentity message later if we skip current discover_identity message.\nSo we should handle the received message firstly and override the pending\ndiscover_identity message without warning in this case. Then, a delayed\nsend_discover work will send discover_identity message again.

In the Linux kernel, the following vulnerability has been resolved:\n\ntee: amdtee: fix race condition in amdtee_open_session\n\nThere is a potential race condition in amdtee_open_session that may\nlead to use-after-free. For instance, in amdtee_open_session() after\nsess->sess_mask is set, and before setting:\n\n sess->session_info[i] = session_info;\n\nif amdtee_close_session() closes this same session, then 'sess' data\nstructure will be released, causing kernel panic when 'sess' is\naccessed within amdtee_open_session().\n\nThe solution is to set the bit sess->sess_mask as the last step in\namdtee_open_session().

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Fix race condition in hci_cmd_sync_clear\n\nThere is a potential race condition in hci_cmd_sync_work and\nhci_cmd_sync_clear, and could lead to use-after-free. For instance,\nhci_cmd_sync_work is added to the 'req_workqueue' after cancel_work_sync\nThe entry of 'cmd_sync_work_list' may be freed in hci_cmd_sync_clear, and\ncausing kernel panic when it is used in 'hci_cmd_sync_work'.\n\nHere's the call trace:\n\ndump_stack_lvl+0x49/0x63\nprint_report.cold+0x5e/0x5d3\n? hci_cmd_sync_work+0x282/0x320\nkasan_report+0xaa/0x120\n? hci_cmd_sync_work+0x282/0x320\n__asan_report_load8_noabort+0x14/0x20\nhci_cmd_sync_work+0x282/0x320\nprocess_one_work+0x77b/0x11c0\n? _raw_spin_lock_irq+0x8e/0xf0\nworker_thread+0x544/0x1180\n? poll_idle+0x1e0/0x1e0\nkthread+0x285/0x320\n? process_one_work+0x11c0/0x11c0\n? kthread_complete_and_exit+0x30/0x30\nret_from_fork+0x22/0x30\n\n\nAllocated by task 266:\nkasan_save_stack+0x26/0x50\n__kasan_kmalloc+0xae/0xe0\nkmem_cache_alloc_trace+0x191/0x350\nhci_cmd_sync_queue+0x97/0x2b0\nhci_update_passive_scan+0x176/0x1d0\nle_conn_complete_evt+0x1b5/0x1a00\nhci_le_conn_complete_evt+0x234/0x340\nhci_le_meta_evt+0x231/0x4e0\nhci_event_packet+0x4c5/0xf00\nhci_rx_work+0x37d/0x880\nprocess_one_work+0x77b/0x11c0\nworker_thread+0x544/0x1180\nkthread+0x285/0x320\nret_from_fork+0x22/0x30\n\nFreed by task 269:\nkasan_save_stack+0x26/0x50\nkasan_set_track+0x25/0x40\nkasan_set_free_info+0x24/0x40\n____kasan_slab_free+0x176/0x1c0\n__kasan_slab_free+0x12/0x20\nslab_free_freelist_hook+0x95/0x1a0\nkfree+0xba/0x2f0\nhci_cmd_sync_clear+0x14c/0x210\nhci_unregister_dev+0xff/0x440\nvhci_release+0x7b/0xf0\n__fput+0x1f3/0x970\n____fput+0xe/0x20\ntask_work_run+0xd4/0x160\ndo_exit+0x8b0/0x22a0\ndo_group_exit+0xba/0x2a0\nget_signal+0x1e4a/0x25b0\narch_do_signal_or_restart+0x93/0x1f80\nexit_to_user_mode_prepare+0xf5/0x1a0\nsyscall_exit_to_user_mode+0x26/0x50\nret_from_fork+0x15/0x30

In the Linux kernel, the following vulnerability has been resolved:\n\ndm stats: check for and propagate alloc_percpu failure\n\nCheck alloc_precpu()'s return value and return an error from\ndm_stats_init() if it fails. Update alloc_dev() to fail if\ndm_stats_init() does.\n\nOtherwise, a NULL pointer dereference will occur in dm_stats_cleanup()\neven if dm-stats isn't being actively used.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Do not set DRR on pipe Commit\n\n[WHY]\nWriting to DRR registers such as OTG_V_TOTAL_MIN on the same frame as a\npipe commit can cause underflow.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Perform lockless command completion in abort path\n\nWhile adding and removing the controller, the following call trace was\nobserved:\n\nWARNING: CPU: 3 PID: 623596 at kernel/dma/mapping.c:532 dma_free_attrs+0x33/0x50\nCPU: 3 PID: 623596 Comm: sh Kdump: loaded Not tainted 5.14.0-96.el9.x86_64 #1\nRIP: 0010:dma_free_attrs+0x33/0x50\n\nCall Trace:\n qla2x00_async_sns_sp_done+0x107/0x1b0 [qla2xxx]\n qla2x00_abort_srb+0x8e/0x250 [qla2xxx]\n ? ql_dbg+0x70/0x100 [qla2xxx]\n __qla2x00_abort_all_cmds+0x108/0x190 [qla2xxx]\n qla2x00_abort_all_cmds+0x24/0x70 [qla2xxx]\n qla2x00_abort_isp_cleanup+0x305/0x3e0 [qla2xxx]\n qla2x00_remove_one+0x364/0x400 [qla2xxx]\n pci_device_remove+0x36/0xa0\n __device_release_driver+0x17a/0x230\n device_release_driver+0x24/0x30\n pci_stop_bus_device+0x68/0x90\n pci_stop_and_remove_bus_device_locked+0x16/0x30\n remove_store+0x75/0x90\n kernfs_fop_write_iter+0x11c/0x1b0\n new_sync_write+0x11f/0x1b0\n vfs_write+0x1eb/0x280\n ksys_write+0x5f/0xe0\n do_syscall_64+0x5c/0x80\n ? do_user_addr_fault+0x1d8/0x680\n ? do_syscall_64+0x69/0x80\n ? exc_page_fault+0x62/0x140\n ? asm_exc_page_fault+0x8/0x30\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nThe command was completed in the abort path during driver unload with a\nlock held, causing the warning in abort path. Hence complete the command\nwithout any lock held.

In the Linux kernel, the following vulnerability has been resolved:\n\nca8210: fix mac_len negative array access\n\nThis patch fixes a buffer overflow access of skb->data if\nieee802154_hdr_peek_addrs() fails.

In the Linux kernel, the following vulnerability has been resolved:\n\nHID: intel-ish-hid: ipc: Fix potential use-after-free in work function\n\nWhen a reset notify IPC message is received, the ISR schedules a work\nfunction and passes the ISHTP device to it via a global pointer\nishtp_dev. If ish_probe() fails, the devm-managed device resources\nincluding ishtp_dev are freed, but the work is not cancelled, causing a\nuse-after-free when the work function tries to access ishtp_dev. Use\ndevm_work_autocancel() instead, so that the work is automatically\ncancelled if probe fails.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: lpfc: Check kzalloc() in lpfc_sli4_cgn_params_read()\n\nIf kzalloc() fails in lpfc_sli4_cgn_params_read(), then we rely on\nlpfc_read_object()'s routine to NULL check pdata.\n\nCurrently, an early return error is thrown from lpfc_read_object() to\nprotect us from NULL ptr dereference, but the errno code is -ENODEV.\n\nChange the errno code to a more appropriate -ENOMEM.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: mpi3mr: Bad drive in topology results kernel crash\n\nWhen the SAS Transport Layer support is enabled and a device exposed to\nthe OS by the driver fails INQUIRY commands, the driver frees up the memory\nallocated for an internal HBA port data structure. However, in some places,\nthe reference to the freed memory is not cleared. When the firmware sends\nthe Device Info change event for the same device again, the freed memory is\naccessed and that leads to memory corruption and OS crash.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Fix call trace warning and hang when removing amdgpu device\n\nOn GPUs with RAS enabled, below call trace and hang are observed when\nshutting down device.\n\nv2: use DRM device unplugged flag instead of shutdown flag as the check to\nprevent memory wipe in shutdown stage.\n\n[ +0.000000] RIP: 0010:amdgpu_vram_mgr_fini+0x18d/0x1c0 [amdgpu]\n[ +0.000001] PKRU: 55555554\n[ +0.000001] Call Trace:\n[ +0.000001] \n[ +0.000002] amdgpu_ttm_fini+0x140/0x1c0 [amdgpu]\n[ +0.000183] amdgpu_bo_fini+0x27/0xa0 [amdgpu]\n[ +0.000184] gmc_v11_0_sw_fini+0x2b/0x40 [amdgpu]\n[ +0.000163] amdgpu_device_fini_sw+0xb6/0x510 [amdgpu]\n[ +0.000152] amdgpu_driver_release_kms+0x16/0x30 [amdgpu]\n[ +0.000090] drm_dev_release+0x28/0x50 [drm]\n[ +0.000016] devm_drm_dev_init_release+0x38/0x60 [drm]\n[ +0.000011] devm_action_release+0x15/0x20\n[ +0.000003] release_nodes+0x40/0xc0\n[ +0.000001] devres_release_all+0x9e/0xe0\n[ +0.000001] device_unbind_cleanup+0x12/0x80\n[ +0.000003] device_release_driver_internal+0xff/0x160\n[ +0.000001] driver_detach+0x4a/0x90\n[ +0.000001] bus_remove_driver+0x6c/0xf0\n[ +0.000001] driver_unregister+0x31/0x50\n[ +0.000001] pci_unregister_driver+0x40/0x90\n[ +0.000003] amdgpu_exit+0x15/0x120 [amdgpu]

In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix kernel-infoleak in nilfs_ioctl_wrap_copy()\n\nThe ioctl helper function nilfs_ioctl_wrap_copy(), which exchanges a\nmetadata array to/from user space, may copy uninitialized buffer regions\nto user space memory for read-only ioctl commands NILFS_IOCTL_GET_SUINFO\nand NILFS_IOCTL_GET_CPINFO.\n\nThis can occur when the element size of the user space metadata given by\nthe v_size member of the argument nilfs_argv structure is larger than the\nsize of the metadata element (nilfs_suinfo structure or nilfs_cpinfo\nstructure) on the file system side.\n\nKMSAN-enabled kernels detect this issue as follows:\n\n BUG: KMSAN: kernel-infoleak in instrument_copy_to_user\n include/linux/instrumented.h:121 [inline]\n BUG: KMSAN: kernel-infoleak in _copy_to_user+0xc0/0x100 lib/usercopy.c:33\n instrument_copy_to_user include/linux/instrumented.h:121 [inline]\n _copy_to_user+0xc0/0x100 lib/usercopy.c:33\n copy_to_user include/linux/uaccess.h:169 [inline]\n nilfs_ioctl_wrap_copy+0x6fa/0xc10 fs/nilfs2/ioctl.c:99\n nilfs_ioctl_get_info fs/nilfs2/ioctl.c:1173 [inline]\n nilfs_ioctl+0x2402/0x4450 fs/nilfs2/ioctl.c:1290\n nilfs_compat_ioctl+0x1b8/0x200 fs/nilfs2/ioctl.c:1343\n __do_compat_sys_ioctl fs/ioctl.c:968 [inline]\n __se_compat_sys_ioctl+0x7dd/0x1000 fs/ioctl.c:910\n __ia32_compat_sys_ioctl+0x93/0xd0 fs/ioctl.c:910\n do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]\n __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178\n do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203\n do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246\n entry_SYSENTER_compat_after_hwframe+0x70/0x82\n\n Uninit was created at:\n __alloc_pages+0x9f6/0xe90 mm/page_alloc.c:5572\n alloc_pages+0xab0/0xd80 mm/mempolicy.c:2287\n __get_free_pages+0x34/0xc0 mm/page_alloc.c:5599\n nilfs_ioctl_wrap_copy+0x223/0xc10 fs/nilfs2/ioctl.c:74\n nilfs_ioctl_get_info fs/nilfs2/ioctl.c:1173 [inline]\n nilfs_ioctl+0x2402/0x4450 fs/nilfs2/ioctl.c:1290\n nilfs_compat_ioctl+0x1b8/0x200 fs/nilfs2/ioctl.c:1343\n __do_compat_sys_ioctl fs/ioctl.c:968 [inline]\n __se_compat_sys_ioctl+0x7dd/0x1000 fs/ioctl.c:910\n __ia32_compat_sys_ioctl+0x93/0xd0 fs/ioctl.c:910\n do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]\n __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178\n do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203\n do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246\n entry_SYSENTER_compat_after_hwframe+0x70/0x82\n\n Bytes 16-127 of 3968 are uninitialized\n ...\n\nThis eliminates the leak issue by initializing the page allocated as\nbuffer using get_zeroed_page().