In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86/xen: Fix eventfd error handling in kvm_xen_eventfd_assign()\n\nShould not call eventfd_ctx_put() in case of error.\n\n[Introduce new goto target instead. - Paolo]

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Fix optc2_configure warning on dcn314\n\n[Why]\ndcn314 uses optc2_configure_crc() that wraps\noptc1_configure_crc() + set additional registers\nnot applicable to dcn314.\nIt's not critical but when used leads to warning like:\nWARNING: drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c\nCall Trace:\n\ngeneric_reg_set_ex+0x6d/0xe0 [amdgpu]\noptc2_configure_crc+0x60/0x80 [amdgpu]\ndc_stream_configure_crc+0x129/0x150 [amdgpu]\namdgpu_dm_crtc_configure_crc_source+0x5d/0xe0 [amdgpu]\n\n[How]\nUse optc1_configure_crc() directly

In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: Drop snd_BUG_ON() from snd_usbmidi_output_open()\n\nsnd_usbmidi_output_open() has a check of the NULL port with\nsnd_BUG_ON(). snd_BUG_ON() was used as this shouldn't have happened,\nbut in reality, the NULL port may be seen when the device gives an\ninvalid endpoint setup at the descriptor, hence the driver skips the\nallocation. That is, the check itself is valid and snd_BUG_ON()\nshould be dropped from there. Otherwise it's confusing as if it were\na real bug, as recently syzbot stumbled on it.

In the Linux kernel, the following vulnerability has been resolved:\n\ndm ioctl: fix misbehavior if list_versions races with module loading\n\n__list_versions will first estimate the required space using the\n"dm_target_iterate(list_version_get_needed, &needed)" call and then will\nfill the space using the "dm_target_iterate(list_version_get_info,\n&iter_info)" call. Each of these calls locks the targets using the\n"down_read(&_lock)" and "up_read(&_lock)" calls, however between the first\nand second "dm_target_iterate" there is no lock held and the target\nmodules can be loaded at this point, so the second "dm_target_iterate"\ncall may need more space than what was the first "dm_target_iterate"\nreturned.\n\nThe code tries to handle this overflow (see the beginning of\nlist_version_get_info), however this handling is incorrect.\n\nThe code sets "param->data_size = param->data_start + needed" and\n"iter_info.end = (char *)vers+len" - "needed" is the size returned by the\nfirst dm_target_iterate call; "len" is the size of the buffer allocated by\nuserspace.\n\n"len" may be greater than "needed"; in this case, the code will write up\nto "len" bytes into the buffer, however param->data_size is set to\n"needed", so it may write data past the param->data_size value. The ioctl\ninterface copies only up to param->data_size into userspace, thus part of\nthe result will be truncated.\n\nFix this bug by setting "iter_info.end = (char *)vers + needed;" - this\nguarantees that the second "dm_target_iterate" call will write only up to\nthe "needed" buffer and it will exit with "DM_BUFFER_FULL_FLAG" if it\noverflows the "needed" space - in this case, userspace will allocate a\nlarger buffer and retry.\n\nNote that there is also a bug in list_version_get_needed - we need to add\n"strlen(tt->name) + 1" to the needed size, not "strlen(tt->name)".

In the Linux kernel, the following vulnerability has been resolved:\n\nceph: avoid putting the realm twice when decoding snaps fails\n\nWhen decoding the snaps fails it maybe leaving the 'first_realm'\nand 'realm' pointing to the same snaprealm memory. And then it'll\nput it twice and could cause random use-after-free, BUG_ON, etc\nissues.

In the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: Check sb_bsize_shift after reading superblock\n\nFuzzers like to scribble over sb_bsize_shift but in reality it's very\nunlikely that this field would be corrupted on its own. Nevertheless it\nshould be checked to avoid the possibility of messy mount errors due to\nbad calculations. It's always a fixed value based on the block size so\nwe can just check that it's the expected value.\n\nTested with:\n\n mkfs.gfs2 -O -p lock_nolock /dev/vdb\n for i in 0 -1 64 65 32 33; do\n gfs2_edit -p sb field sb_bsize_shift $i /dev/vdb\n mount /dev/vdb /mnt/test && umount /mnt/test\n done\n\nBefore this patch we get a withdraw after\n\n[ 76.413681] gfs2: fsid=loop0.0: fatal: invalid metadata block\n[ 76.413681] bh = 19 (type: exp=5, found=4)\n[ 76.413681] function = gfs2_meta_buffer, file = fs/gfs2/meta_io.c, line = 492\n\nand with UBSAN configured we also get complaints like\n\n[ 76.373395] UBSAN: shift-out-of-bounds in fs/gfs2/ops_fstype.c:295:19\n[ 76.373815] shift exponent 4294967287 is too large for 64-bit type 'long unsigned int'\n\nAfter the patch, these complaints don't appear, mount fails immediately\nand we get an explanation in dmesg.

In the Linux kernel, the following vulnerability has been resolved:\n\n9p: trans_fd/p9_conn_cancel: drop client lock earlier\n\nsyzbot reported a double-lock here and we no longer need this\nlock after requests have been moved off to local list:\njust drop the lock earlier.

In the Linux kernel, the following vulnerability has been resolved:\n\n9p/trans_fd: always use O_NONBLOCK read/write\n\nsyzbot is reporting hung task at p9_fd_close() [1], for p9_mux_poll_stop()\n from p9_conn_destroy() from p9_fd_close() is failing to interrupt already\nstarted kernel_read() from p9_fd_read() from p9_read_work() and/or\nkernel_write() from p9_fd_write() from p9_write_work() requests.\n\nSince p9_socket_open() sets O_NONBLOCK flag, p9_mux_poll_stop() does not\nneed to interrupt kernel_read()/kernel_write(). However, since p9_fd_open()\ndoes not set O_NONBLOCK flag, but pipe blocks unless signal is pending,\np9_mux_poll_stop() needs to interrupt kernel_read()/kernel_write() when\nthe file descriptor refers to a pipe. In other words, pipe file descriptor\nneeds to be handled as if socket file descriptor.\n\nWe somehow need to interrupt kernel_read()/kernel_write() on pipes.\n\nA minimal change, which this patch is doing, is to set O_NONBLOCK flag\n from p9_fd_open(), for O_NONBLOCK flag does not affect reading/writing\nof regular files. But this approach changes O_NONBLOCK flag on userspace-\nsupplied file descriptors (which might break userspace programs), and\nO_NONBLOCK flag could be changed by userspace. It would be possible to set\nO_NONBLOCK flag every time p9_fd_read()/p9_fd_write() is invoked, but still\nremains small race window for clearing O_NONBLOCK flag.\n\nIf we don't want to manipulate O_NONBLOCK flag, we might be able to\nsurround kernel_read()/kernel_write() with set_thread_flag(TIF_SIGPENDING)\nand recalc_sigpending(). Since p9_read_work()/p9_write_work() works are\nprocessed by kernel threads which process global system_wq workqueue,\nsignals could not be delivered from remote threads when p9_mux_poll_stop()\n from p9_conn_destroy() from p9_fd_close() is called. Therefore, calling\nset_thread_flag(TIF_SIGPENDING)/recalc_sigpending() every time would be\nneeded if we count on signals for making kernel_read()/kernel_write()\nnon-blocking.\n\n[Dominique: add comment at Christian's suggestion]

In the Linux kernel, the following vulnerability has been resolved:\n\nnetlink: Bounds-check struct nlmsgerr creation\n\nIn preparation for FORTIFY_SOURCE doing bounds-check on memcpy(),\nswitch from __nlmsg_put to nlmsg_put(), and explain the bounds check\nfor dealing with the memcpy() across a composite flexible array struct.\nAvoids this future run-time warning:\n\n memcpy: detected field-spanning write (size 32) of single field "&errmsg->msg" at net/netlink/af_netlink.c:2447 (size 16)

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/9p: use a dedicated spinlock for trans_fd\n\nShamelessly copying the explanation from Tetsuo Handa's suggested\npatch[1] (slightly reworded):\nsyzbot is reporting inconsistent lock state in p9_req_put()[2],\nfor p9_tag_remove() from p9_req_put() from IRQ context is using\nspin_lock_irqsave() on "struct p9_client"->lock but trans_fd\n(not from IRQ context) is using spin_lock().\n\nSince the locks actually protect different things in client.c and in\ntrans_fd.c, just replace trans_fd.c's lock by a new one specific to the\ntransport (client.c's protect the idr for fid/tag allocations,\nwhile trans_fd.c's protects its own req list and request status field\nthat acts as the transport's state machine)

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Prevent bpf program recursion for raw tracepoint probes\n\nWe got report from sysbot [1] about warnings that were caused by\nbpf program attached to contention_begin raw tracepoint triggering\nthe same tracepoint by using bpf_trace_printk helper that takes\ntrace_printk_lock lock.\n\n Call Trace:\n \n ? trace_event_raw_event_bpf_trace_printk+0x5f/0x90\n bpf_trace_printk+0x2b/0xe0\n bpf_prog_a9aec6167c091eef_prog+0x1f/0x24\n bpf_trace_run2+0x26/0x90\n native_queued_spin_lock_slowpath+0x1c6/0x2b0\n _raw_spin_lock_irqsave+0x44/0x50\n bpf_trace_printk+0x3f/0xe0\n bpf_prog_a9aec6167c091eef_prog+0x1f/0x24\n bpf_trace_run2+0x26/0x90\n native_queued_spin_lock_slowpath+0x1c6/0x2b0\n _raw_spin_lock_irqsave+0x44/0x50\n bpf_trace_printk+0x3f/0xe0\n bpf_prog_a9aec6167c091eef_prog+0x1f/0x24\n bpf_trace_run2+0x26/0x90\n native_queued_spin_lock_slowpath+0x1c6/0x2b0\n _raw_spin_lock_irqsave+0x44/0x50\n bpf_trace_printk+0x3f/0xe0\n bpf_prog_a9aec6167c091eef_prog+0x1f/0x24\n bpf_trace_run2+0x26/0x90\n native_queued_spin_lock_slowpath+0x1c6/0x2b0\n _raw_spin_lock_irqsave+0x44/0x50\n __unfreeze_partials+0x5b/0x160\n ...\n\nThe can be reproduced by attaching bpf program as raw tracepoint on\ncontention_begin tracepoint. The bpf prog calls bpf_trace_printk\nhelper. Then by running perf bench the spin lock code is forced to\ntake slow path and call contention_begin tracepoint.\n\nFixing this by skipping execution of the bpf program if it's\nalready running, Using bpf prog 'active' field, which is being\ncurrently used by trampoline programs for the same reason.\n\nMoving bpf_prog_inc_misses_counter to syscall.c because\ntrampoline.c is compiled in just for CONFIG_BPF_JIT option.\n\n[1] https://lore.kernel.org/bpf/YxhFe3EwqchC%2FfYf@krava/T/#t

In the Linux kernel, the following vulnerability has been resolved:\n\nntfs: check overflow when iterating ATTR_RECORDs\n\nKernel iterates over ATTR_RECORDs in mft record in ntfs_attr_find(). \nBecause the ATTR_RECORDs are next to each other, kernel can get the next\nATTR_RECORD from end address of current ATTR_RECORD, through current\nATTR_RECORD length field.\n\nThe problem is that during iteration, when kernel calculates the end\naddress of current ATTR_RECORD, kernel may trigger an integer overflow bug\nin executing `a = (ATTR_RECORD*)((u8*)a + le32_to_cpu(a->length))`. This\nmay wrap, leading to a forever iteration on 32bit systems.\n\nThis patch solves it by adding some checks on calculating end address\nof current ATTR_RECORD during iteration.

In the Linux kernel, the following vulnerability has been resolved:\n\nVMCI: Use threaded irqs instead of tasklets\n\nThe vmci_dispatch_dgs() tasklet function calls vmci_read_data()\nwhich uses wait_event() resulting in invalid sleep in an atomic\ncontext (and therefore potentially in a deadlock).\n\nUse threaded irqs to fix this issue and completely remove usage\nof tasklets.\n\n[ 20.264639] BUG: sleeping function called from invalid context at drivers/misc/vmw_vmci/vmci_guest.c:145\n[ 20.264643] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 762, name: vmtoolsd\n[ 20.264645] preempt_count: 101, expected: 0\n[ 20.264646] RCU nest depth: 0, expected: 0\n[ 20.264647] 1 lock held by vmtoolsd/762:\n[ 20.264648] #0: ffff0000874ae440 (sk_lock-AF_VSOCK){+.+.}-{0:0}, at: vsock_connect+0x60/0x330 [vsock]\n[ 20.264658] Preemption disabled at:\n[ 20.264659] [] vmci_send_datagram+0x44/0xa0 [vmw_vmci]\n[ 20.264665] CPU: 0 PID: 762 Comm: vmtoolsd Not tainted 5.19.0-0.rc8.20220727git39c3c396f813.60.fc37.aarch64 #1\n[ 20.264667] Hardware name: VMware, Inc. VBSA/VBSA, BIOS VEFI 12/31/2020\n[ 20.264668] Call trace:\n[ 20.264669] dump_backtrace+0xc4/0x130\n[ 20.264672] show_stack+0x24/0x80\n[ 20.264673] dump_stack_lvl+0x88/0xb4\n[ 20.264676] dump_stack+0x18/0x34\n[ 20.264677] __might_resched+0x1a0/0x280\n[ 20.264679] __might_sleep+0x58/0x90\n[ 20.264681] vmci_read_data+0x74/0x120 [vmw_vmci]\n[ 20.264683] vmci_dispatch_dgs+0x64/0x204 [vmw_vmci]\n[ 20.264686] tasklet_action_common.constprop.0+0x13c/0x150\n[ 20.264688] tasklet_action+0x40/0x50\n[ 20.264689] __do_softirq+0x23c/0x6b4\n[ 20.264690] __irq_exit_rcu+0x104/0x214\n[ 20.264691] irq_exit_rcu+0x1c/0x50\n[ 20.264693] el1_interrupt+0x38/0x6c\n[ 20.264695] el1h_64_irq_handler+0x18/0x24\n[ 20.264696] el1h_64_irq+0x68/0x6c\n[ 20.264697] preempt_count_sub+0xa4/0xe0\n[ 20.264698] _raw_spin_unlock_irqrestore+0x64/0xb0\n[ 20.264701] vmci_send_datagram+0x7c/0xa0 [vmw_vmci]\n[ 20.264703] vmci_datagram_dispatch+0x84/0x100 [vmw_vmci]\n[ 20.264706] vmci_datagram_send+0x2c/0x40 [vmw_vmci]\n[ 20.264709] vmci_transport_send_control_pkt+0xb8/0x120 [vmw_vsock_vmci_transport]\n[ 20.264711] vmci_transport_connect+0x40/0x7c [vmw_vsock_vmci_transport]\n[ 20.264713] vsock_connect+0x278/0x330 [vsock]\n[ 20.264715] __sys_connect_file+0x8c/0xc0\n[ 20.264718] __sys_connect+0x84/0xb4\n[ 20.264720] __arm64_sys_connect+0x2c/0x3c\n[ 20.264721] invoke_syscall+0x78/0x100\n[ 20.264723] el0_svc_common.constprop.0+0x68/0x124\n[ 20.264724] do_el0_svc+0x38/0x4c\n[ 20.264725] el0_svc+0x60/0x180\n[ 20.264726] el0t_64_sync_handler+0x11c/0x150\n[ 20.264728] el0t_64_sync+0x190/0x194

In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: Fix double increment of client_count in dma_chan_get()\n\nThe first time dma_chan_get() is called for a channel the channel\nclient_count is incorrectly incremented twice for public channels,\nfirst in balance_ref_count(), and again prior to returning. This\nresults in an incorrect client count which will lead to the\nchannel resources not being freed when they should be. A simple\n test of repeated module load and unload of async_tx on a Dell\n Power Edge R7425 also shows this resulting in a kref underflow\n warning.\n\n[ 124.329662] async_tx: api initialized (async)\n[ 129.000627] async_tx: api initialized (async)\n[ 130.047839] ------------[ cut here ]------------\n[ 130.052472] refcount_t: underflow; use-after-free.\n[ 130.057279] WARNING: CPU: 3 PID: 19364 at lib/refcount.c:28\nrefcount_warn_saturate+0xba/0x110\n[ 130.065811] Modules linked in: async_tx(-) rfkill intel_rapl_msr\nintel_rapl_common amd64_edac edac_mce_amd ipmi_ssif kvm_amd dcdbas kvm\nmgag200 drm_shmem_helper acpi_ipmi irqbypass drm_kms_helper ipmi_si\nsyscopyarea sysfillrect rapl pcspkr ipmi_devintf sysimgblt fb_sys_fops\nk10temp i2c_piix4 ipmi_msghandler acpi_power_meter acpi_cpufreq vfat\nfat drm fuse xfs libcrc32c sd_mod t10_pi sg ahci crct10dif_pclmul\nlibahci crc32_pclmul crc32c_intel ghash_clmulni_intel igb megaraid_sas\ni40e libata i2c_algo_bit ccp sp5100_tco dca dm_mirror dm_region_hash\ndm_log dm_mod [last unloaded: async_tx]\n[ 130.117361] CPU: 3 PID: 19364 Comm: modprobe Kdump: loaded Not\ntainted 5.14.0-185.el9.x86_64 #1\n[ 130.126091] Hardware name: Dell Inc. PowerEdge R7425/02MJ3T, BIOS\n1.18.0 01/17/2022\n[ 130.133806] RIP: 0010:refcount_warn_saturate+0xba/0x110\n[ 130.139041] Code: 01 01 e8 6d bd 55 00 0f 0b e9 72 9d 8a 00 80 3d\n26 18 9c 01 00 75 85 48 c7 c7 f8 a3 03 9d c6 05 16 18 9c 01 01 e8 4a\nbd 55 00 <0f> 0b e9 4f 9d 8a 00 80 3d 01 18 9c 01 00 0f 85 5e ff ff ff\n48 c7\n[ 130.157807] RSP: 0018:ffffbf98898afe68 EFLAGS: 00010286\n[ 130.163036] RAX: 0000000000000000 RBX: ffff9da06028e598 RCX: 0000000000000000\n[ 130.170172] RDX: ffff9daf9de26480 RSI: ffff9daf9de198a0 RDI: ffff9daf9de198a0\n[ 130.177316] RBP: ffff9da7cddf3970 R08: 0000000000000000 R09: 00000000ffff7fff\n[ 130.184459] R10: ffffbf98898afd00 R11: ffffffff9d9e8c28 R12: ffff9da7cddf1970\n[ 130.191596] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n[ 130.198739] FS: 00007f646435c740(0000) GS:ffff9daf9de00000(0000)\nknlGS:0000000000000000\n[ 130.206832] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 130.212586] CR2: 00007f6463b214f0 CR3: 00000008ab98c000 CR4: 00000000003506e0\n[ 130.219729] Call Trace:\n[ 130.222192] \n[ 130.224305] dma_chan_put+0x10d/0x110\n[ 130.227988] dmaengine_put+0x7a/0xa0\n[ 130.231575] __do_sys_delete_module.constprop.0+0x178/0x280\n[ 130.237157] ? syscall_trace_enter.constprop.0+0x145/0x1d0\n[ 130.242652] do_syscall_64+0x5c/0x90\n[ 130.246240] ? exc_page_fault+0x62/0x150\n[ 130.250178] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[ 130.255243] RIP: 0033:0x7f6463a3f5ab\n[ 130.258830] Code: 73 01 c3 48 8b 0d 75 a8 1b 00 f7 d8 64 89 01 48\n83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00\n00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 45 a8 1b 00 f7 d8 64 89\n01 48\n[ 130.277591] RSP: 002b:00007fff22f972c8 EFLAGS: 00000206 ORIG_RAX:\n00000000000000b0\n[ 130.285164] RAX: ffffffffffffffda RBX: 000055b6786edd40 RCX: 00007f6463a3f5ab\n[ 130.292303] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 000055b6786edda8\n[ 130.299443] RBP: 000055b6786edd40 R08: 0000000000000000 R09: 0000000000000000\n[ 130.306584] R10: 00007f6463b9eac0 R11: 0000000000000206 R12: 000055b6786edda8\n[ 130.313731] R13: 0000000000000000 R14: 000055b6786edda8 R15: 00007fff22f995f8\n[ 130.320875] \n[ 130.323081] ---[ end trace eff7156d56b5cf25 ]---\n\ncat /sys/class/dma/dma0chan*/in_use would get the wrong result.\n2\n2\n2\n\nTest-by: Jie Hai

In the Linux kernel, the following vulnerability has been resolved:\n\ncpufreq: CPPC: Add u64 casts to avoid overflowing\n\nThe fields of the _CPC object are unsigned 32-bits values.\nTo avoid overflows while using _CPC's values, add 'u64' casts.

In the Linux kernel, the following vulnerability has been resolved:\n\ni2c: designware: use casting of u64 in clock multiplication to avoid overflow\n\nIn functions i2c_dw_scl_lcnt() and i2c_dw_scl_hcnt() may have overflow\nby depending on the values of the given parameters including the ic_clk.\nFor example in our use case where ic_clk is larger than one million,\nmultiplication of ic_clk * 4700 will result in 32 bit overflow.\n\nAdd cast of u64 to the calculation to avoid multiplication overflow, and\nuse the corresponding define for divide.

In the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86/amd: fix potential integer overflow on shift of a int\n\nThe left shift of int 32 bit integer constant 1 is evaluated using 32 bit\narithmetic and then passed as a 64 bit function argument. In the case where\ni is 32 or more this can lead to an overflow. Avoid this by shifting\nusing the BIT_ULL macro instead.

In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: imx-sdma: Fix a possible memory leak in sdma_transfer_init\n\nIf the function sdma_load_context() fails, the sdma_desc will be\nfreed, but the allocated desc->bd is forgot to be freed.\n\nWe already met the sdma_load_context() failure case and the log as\nbelow:\n[ 450.699064] imx-sdma 30bd0000.dma-controller: Timeout waiting for CH0 ready\n...\n\nIn this case, the desc->bd will not be freed without this change.

In the Linux kernel, the following vulnerability has been resolved:\n\novl: Use "buf" flexible array for memcpy() destination\n\nThe "buf" flexible array needs to be the memcpy() destination to avoid\nfalse positive run-time warning from the recent FORTIFY_SOURCE\nhardening:\n\n memcpy: detected field-spanning write (size 93) of single field "&fh->fb"\n at fs/overlayfs/export.c:799 (size 21)

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix hang during unmount when block group reclaim task is running\n\nWhen we start an unmount, at close_ctree(), if we have the reclaim task\nrunning and in the middle of a data block group relocation, we can trigger\na deadlock when stopping an async reclaim task, producing a trace like the\nfollowing:\n\n[629724.498185] task:kworker/u16:7 state:D stack: 0 pid:681170 ppid: 2 flags:0x00004000\n[629724.499760] Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs]\n[629724.501267] Call Trace:\n[629724.501759] <TASK>\n[629724.502174] __schedule+0x3cb/0xed0\n[629724.502842] schedule+0x4e/0xb0\n[629724.503447] btrfs_wait_on_delayed_iputs+0x7c/0xc0 [btrfs]\n[629724.504534] ? prepare_to_wait_exclusive+0xc0/0xc0\n[629724.505442] flush_space+0x423/0x630 [btrfs]\n[629724.506296] ? rcu_read_unlock_trace_special+0x20/0x50\n[629724.507259] ? lock_release+0x220/0x4a0\n[629724.507932] ? btrfs_get_alloc_profile+0xb3/0x290 [btrfs]\n[629724.508940] ? do_raw_spin_unlock+0x4b/0xa0\n[629724.509688] btrfs_async_reclaim_metadata_space+0x139/0x320 [btrfs]\n[629724.510922] process_one_work+0x252/0x5a0\n[629724.511694] ? process_one_work+0x5a0/0x5a0\n[629724.512508] worker_thread+0x52/0x3b0\n[629724.513220] ? process_one_work+0x5a0/0x5a0\n[629724.514021] kthread+0xf2/0x120\n[629724.514627] ? kthread_complete_and_exit+0x20/0x20\n[629724.515526] ret_from_fork+0x22/0x30\n[629724.516236] </TASK>\n[629724.516694] task:umount state:D stack: 0 pid:719055 ppid:695412 flags:0x00004000\n[629724.518269] Call Trace:\n[629724.518746] <TASK>\n[629724.519160] __schedule+0x3cb/0xed0\n[629724.519835] schedule+0x4e/0xb0\n[629724.520467] schedule_timeout+0xed/0x130\n[629724.521221] ? lock_release+0x220/0x4a0\n[629724.521946] ? lock_acquired+0x19c/0x420\n[629724.522662] ? trace_hardirqs_on+0x1b/0xe0\n[629724.523411] __wait_for_common+0xaf/0x1f0\n[629724.524189] ? usleep_range_state+0xb0/0xb0\n[629724.524997] __flush_work+0x26d/0x530\n[629724.525698] ? flush_workqueue_prep_pwqs+0x140/0x140\n[629724.526580] ? lock_acquire+0x1a0/0x310\n[629724.527324] __cancel_work_timer+0x137/0x1c0\n[629724.528190] close_ctree+0xfd/0x531 [btrfs]\n[629724.529000] ? evict_inodes+0x166/0x1c0\n[629724.529510] generic_shutdown_super+0x74/0x120\n[629724.530103] kill_anon_super+0x14/0x30\n[629724.530611] btrfs_kill_super+0x12/0x20 [btrfs]\n[629724.531246] deactivate_locked_super+0x31/0xa0\n[629724.531817] cleanup_mnt+0x147/0x1c0\n[629724.532319] task_work_run+0x5c/0xa0\n[629724.532984] exit_to_user_mode_prepare+0x1a6/0x1b0\n[629724.533598] syscall_exit_to_user_mode+0x16/0x40\n[629724.534200] do_syscall_64+0x48/0x90\n[629724.534667] entry_SYSCALL_64_after_hwframe+0x44/0xae\n[629724.535318] RIP: 0033:0x7fa2b90437a7\n[629724.535804] RSP: 002b:00007ffe0b7e4458 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6\n[629724.536912] RAX: 0000000000000000 RBX: 00007fa2b9182264 RCX: 00007fa2b90437a7\n[629724.538156] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000555d6cf20dd0\n[629724.539053] RBP: 0000555d6cf20ba0 R08: 0000000000000000 R09: 00007ffe0b7e3200\n[629724.539956] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\n[629724.540883] R13: 0000555d6cf20dd0 R14: 0000555d6cf20cb0 R15: 0000000000000000\n[629724.541796] </TASK>\n\nThis happens because:\n\n1) Before entering close_ctree() we have the async block group reclaim\n task running and relocating a data block group;\n\n2) There's an async metadata (or data) space reclaim task running;\n\n3) We enter close_ctree() and park the cleaner kthread;\n\n4) The async space reclaim task is at flush_space() and runs all the\n existing delayed iputs;\n\n5) Before the async space reclaim task calls\n btrfs_wait_on_delayed_iputs(), the block group reclaim task which is\n doing the data block group relocation, creates a delayed iput at\n replace_file_extents() (called when COWing leaves that have file extent\n items pointing to relocated data extents, during the merging phase\n of relocation roots);\n\n6) The async reclaim space reclaim task blocks at\n btrfs_wait_on_delayed_iputs(), since we have a new delayed iput;\n\n7) The task at close_ctree() then calls cancel_work_sync() to stop the\n async space reclaim task, but it blocks since that task is waiting for\n the delayed iput to be run;\n\n8) The delayed iput is never run because the cleaner kthread is parked,\n and no one else runs delayed iputs, resulting in a hang.\n\nSo fix this by stopping the async block group reclaim task before we\npark the cleaner kthread.

In the Linux kernel, the following vulnerability has been resolved:\n\nafs: Fix dynamic root getattr\n\nThe recent patch to make afs_getattr consult the server didn't account\nfor the pseudo-inodes employed by the dynamic root-type afs superblock\nnot having a volume or a server to access, and thus an oops occurs if\nsuch a directory is stat'd.\n\nFix this by checking to see if the vnode->volume pointer actually points\nanywhere before following it in afs_getattr().\n\nThis can be tested by stat'ing a directory in /afs. It may be\nsufficient just to do "ls /afs" and the oops looks something like:\n\n BUG: kernel NULL pointer dereference, address: 0000000000000020\n ...\n RIP: 0010:afs_getattr+0x8b/0x14b\n ...\n Call Trace:\n <TASK>\n vfs_statx+0x79/0xf5\n vfs_fstatat+0x49/0x62

In the Linux kernel, the following vulnerability has been resolved:\n\nxen/netback: avoid entering xenvif_rx_next_skb() with an empty rx queue\n\nxenvif_rx_next_skb() is expecting the rx queue not being empty, but\nin case the loop in xenvif_rx_action() is doing multiple iterations,\nthe availability of another skb in the rx queue is not being checked.\n\nThis can lead to crashes:\n\n[40072.537261] BUG: unable to handle kernel NULL pointer dereference at 0000000000000080\n[40072.537407] IP: xenvif_rx_skb+0x23/0x590 [xen_netback]\n[40072.537534] PGD 0 P4D 0\n[40072.537644] Oops: 0000 [#1] SMP NOPTI\n[40072.537749] CPU: 0 PID: 12505 Comm: v1-c40247-q2-gu Not tainted 4.12.14-122.121-default #1 SLE12-SP5\n[40072.537867] Hardware name: HP ProLiant DL580 Gen9/ProLiant DL580 Gen9, BIOS U17 11/23/2021\n[40072.537999] task: ffff880433b38100 task.stack: ffffc90043d40000\n[40072.538112] RIP: e030:xenvif_rx_skb+0x23/0x590 [xen_netback]\n[40072.538217] RSP: e02b:ffffc90043d43de0 EFLAGS: 00010246\n[40072.538319] RAX: 0000000000000000 RBX: ffffc90043cd7cd0 RCX: 00000000000000f7\n[40072.538430] RDX: 0000000000000000 RSI: 0000000000000006 RDI: ffffc90043d43df8\n[40072.538531] RBP: 000000000000003f R08: 000077ff80000000 R09: 0000000000000008\n[40072.538644] R10: 0000000000007ff0 R11: 00000000000008f6 R12: ffffc90043ce2708\n[40072.538745] R13: 0000000000000000 R14: ffffc90043d43ed0 R15: ffff88043ea748c0\n[40072.538861] FS: 0000000000000000(0000) GS:ffff880484600000(0000) knlGS:0000000000000000\n[40072.538988] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033\n[40072.539088] CR2: 0000000000000080 CR3: 0000000407ac8000 CR4: 0000000000040660\n[40072.539211] Call Trace:\n[40072.539319] xenvif_rx_action+0x71/0x90 [xen_netback]\n[40072.539429] xenvif_kthread_guest_rx+0x14a/0x29c [xen_netback]\n\nFix that by stopping the loop in case the rx queue becomes empty.

In the Linux kernel, the following vulnerability has been resolved:\n\nsysctl: Fix data races in proc_douintvec().\n\nA sysctl variable is accessed concurrently, and there is always a chance\nof data-race. So, all readers and writers need some basic protection to\navoid load/store-tearing.\n\nThis patch changes proc_douintvec() to use READ_ONCE() and WRITE_ONCE()\ninternally to fix data-races on the sysctl side. For now, proc_douintvec()\nitself is tolerant to a data-race, but we still need to add annotations on\nthe other subsystem's side.

In the Linux kernel, the following vulnerability has been resolved:\n\nvlan: fix memory leak in vlan_newlink()\n\nBlamed commit added back a bug I fixed in commit 9bbd917e0bec\n("vlan: fix memory leak in vlan_dev_set_egress_priority")\n\nIf a memory allocation fails in vlan_changelink() after other allocations\nsucceeded, we need to call vlan_dev_free_egress_priority()\nto free all allocated memory because after a failed ->newlink()\nwe do not call any methods like ndo_uninit() or dev->priv_destructor().\n\nIn following example, if the allocation for last element 2000:2001 fails,\nwe need to free eight prior allocations:\n\nip link add link dummy0 dummy0.100 type vlan id 100 \\\n egress-qos-map 1:2 2:3 3:4 4:5 5:6 6:7 7:8 8:9 2000:2001\n\nsyzbot report was:\n\nBUG: memory leak\nunreferenced object 0xffff888117bd1060 (size 32):\ncomm "syz-executor408", pid 3759, jiffies 4294956555 (age 34.090s)\nhex dump (first 32 bytes):\n09 00 00 00 00 a0 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[<ffffffff83fc60ad>] kmalloc include/linux/slab.h:600 [inline]\n[<ffffffff83fc60ad>] vlan_dev_set_egress_priority+0xed/0x170 net/8021q/vlan_dev.c:193\n[<ffffffff83fc6628>] vlan_changelink+0x178/0x1d0 net/8021q/vlan_netlink.c:128\n[<ffffffff83fc67c8>] vlan_newlink+0x148/0x260 net/8021q/vlan_netlink.c:185\n[<ffffffff838b1278>] rtnl_newlink_create net/core/rtnetlink.c:3363 [inline]\n[<ffffffff838b1278>] \__rtnl_newlink+0xa58/0xdc0 net/core/rtnetlink.c:3580\n[<ffffffff838b1629>] rtnl_newlink+0x49/0x70 net/core/rtnetlink.c:3593\n[<ffffffff838ac66c>] rtnetlink_rcv_msg+0x21c/0x5c0 net/core/rtnetlink.c:6089\n[<ffffffff839f9c37>] netlink_rcv_skb+0x87/0x1d0 net/netlink/af_netlink.c:2501\n[<ffffffff839f8da7>] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]\n[<ffffffff839f8da7>] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345\n[<ffffffff839f9266>] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c:1921\n[<ffffffff8384dbf6>] sock_sendmsg_nosec net/socket.c:714 [inline]\n[<ffffffff8384dbf6>] sock_sendmsg+0x56/0x80 net/socket.c:734\n[<ffffffff8384e15c>] \____sys_sendmsg+0x36c/0x390 net/socket.c:2488\n[<ffffffff838523cb>] \___sys_sendmsg+0x8b/0xd0 net/socket.c:2542\n[<ffffffff838525b8>] \__sys_sendmsg net/socket.c:2571 [inline]\n[<ffffffff838525b8>] \__do_sys_sendmsg net/socket.c:2580 [inline]\n[<ffffffff838525b8>] \__se_sys_sendmsg net/socket.c:2578 [inline]\n[<ffffffff838525b8>] \__x64_sys_sendmsg+0x78/0xf0 net/socket.c:2578\n[<ffffffff845ad8d5>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n[<ffffffff845ad8d5>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n[<ffffffff8460006a>] entry_SYSCALL_64_after_hwframe+0x46/0xb0

In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: rt711-sdca: fix kernel NULL pointer dereference when IO error\n\nThe initial settings will be written before the codec probe function.\nBut, the rt711->component doesn't be assigned yet.\nIf IO error happened during initial settings operations, it will cause the kernel panic.\nThis patch changed component->dev to slave->dev to fix this issue.

In the Linux kernel, the following vulnerability has been resolved:\n\npower: supply: core: Fix boundary conditions in interpolation\n\nThe functions power_supply_temp2resist_simple and power_supply_ocv2cap_simple\nhandle boundary conditions incorrectly.\nThe change was introduced in a4585ba2050f460f749bbaf2b67bd56c41e30283\n("power: supply: core: Use library interpolation").\nThere are two issues: First, the lines "high = i - 1" and "high = i" in ocv2cap\nhave the wrong order compared to temp2resist. As a consequence, ocv2cap\nsets high=-1 if ocv>table[0].ocv, which causes an out-of-bounds read.\nSecond, the logic of temp2resist is also not correct.\nConsider the case table[] = \{\{20, 100\}, \{10, 80\}, \{0, 60\}\}.\nFor temp=5, we expect a resistance of 70% by interpolation.\nHowever, temp2resist sets high=low=2 and returns 60.

In the Linux kernel, the following vulnerability has been resolved:\n\nip: Fix data-races around sysctl_ip_fwd_use_pmtu.\n\nWhile reading sysctl_ip_fwd_use_pmtu, it can be changed concurrently.\nThus, we need to add READ_ONCE() to its readers.

In the Linux kernel, the following vulnerability has been resolved:\n\ntcp/dccp: Fix a data-race around sysctl_tcp_fwmark_accept.\n\nWhile reading sysctl_tcp_fwmark_accept, it can be changed concurrently.\nThus, we need to add READ_ONCE() to its reader.

In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: Fix data-races around sysctl_tcp_l3mdev_accept.\n\nWhile reading sysctl_tcp_l3mdev_accept, it can be changed concurrently.\nThus, we need to add READ_ONCE() to its readers.

In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: Fix data-races around sysctl_tcp_mtu_probing.\n\nWhile reading sysctl_tcp_mtu_probing, it can be changed concurrently.\nThus, we need to add READ_ONCE() to its readers.

In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: Fix data-races around sysctl_tcp_base_mss.\n\nWhile reading sysctl_tcp_base_mss, it can be changed concurrently.\nThus, we need to add READ_ONCE() to its readers.

In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: Fix data-races around sysctl_tcp_min_snd_mss.\n\nWhile reading sysctl_tcp_min_snd_mss, it can be changed concurrently.\nThus, we need to add READ_ONCE() to its readers.

In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: Fix a data-race around sysctl_tcp_mtu_probe_floor.\n\nWhile reading sysctl_tcp_mtu_probe_floor, it can be changed concurrently.\nThus, we need to add READ_ONCE() to its reader.

In the Linux kernel, the following vulnerability has been resolved:\n\nigmp: Fix data-races around sysctl_igmp_qrv.\n\nWhile reading sysctl_igmp_qrv, it can be changed concurrently.\nThus, we need to add READ_ONCE() to its readers.\n\nThis test can be packed into a helper, so such changes will be in the\nfollow-up series after net is merged into net-next.\n\n qrv ?: READ_ONCE(net->ipv4.sysctl_igmp_qrv);

In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: Fix data-races around sysctl_tcp_migrate_req.\n\nWhile reading sysctl_tcp_migrate_req, it can be changed concurrently.\nThus, we need to add READ_ONCE() to its readers.

In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: Fix data-races around sysctl_tcp_fastopen.\n\nWhile reading sysctl_tcp_fastopen, it can be changed concurrently.\nThus, we need to add READ_ONCE() to its readers.

In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: Fix data-races around sysctl_tcp_fastopen_blackhole_timeout.\n\nWhile reading sysctl_tcp_fastopen_blackhole_timeout, it can be changed\nconcurrently. Thus, we need to add READ_ONCE() to its readers.

In the Linux kernel, the following vulnerability has been resolved:\n\niavf: Fix handling of dummy receive descriptors\n\nFix memory leak caused by not handling dummy receive descriptor properly.\niavf_get_rx_buffer now sets the rx_buffer return value for dummy receive\ndescriptors. Without this patch, when the hardware writes a dummy\ndescriptor, iavf would not free the page allocated for the previous receive\nbuffer. This is an unlikely event but can still happen.\n\n[Jesse: massaged commit message]

In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: Cancel pending work at closing a MIDI substream\n\nAt closing a USB MIDI output substream, there might be still a pending\nwork, which would eventually access the rawmidi runtime object that is\nbeing released. For fixing the race, make sure to cancel the pending\nwork at closing.

In the Linux kernel, the following vulnerability has been resolved:\n\nath11k: fix the warning of dev_wake in mhi_pm_disable_transition()\n\nWhen test device recovery with below command, it has warning in message\nas below.\necho assert > /sys/kernel/debug/ath11k/wcn6855\\ hw2.0/simulate_fw_crash\necho assert > /sys/kernel/debug/ath11k/qca6390\\ hw2.0/simulate_fw_crash\n\nwarning message:\n[ 1965.642121] ath11k_pci 0000:06:00.0: simulating firmware assert crash\n[ 1968.471364] ieee80211 phy0: Hardware restart was requested\n[ 1968.511305] ------------[ cut here ]------------\n[ 1968.511368] WARNING: CPU: 3 PID: 1546 at drivers/bus/mhi/core/pm.c:505 mhi_pm_disable_transition+0xb37/0xda0 [mhi]\n[ 1968.511443] Modules linked in: ath11k_pci ath11k mac80211 libarc4 cfg80211 qmi_helpers qrtr_mhi mhi qrtr nvme nvme_core\n[ 1968.511563] CPU: 3 PID: 1546 Comm: kworker/u17:0 Kdump: loaded Tainted: G W 5.17.0-rc3-wt-ath+ #579\n[ 1968.511629] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021\n[ 1968.511704] Workqueue: mhi_hiprio_wq mhi_pm_st_worker [mhi]\n[ 1968.511787] RIP: 0010:mhi_pm_disable_transition+0xb37/0xda0 [mhi]\n[ 1968.511870] Code: a9 fe ff ff 4c 89 ff 44 89 04 24 e8 03 46 f6 e5 44 8b 04 24 41 83 f8 01 0f 84 21 fe ff ff e9 4c fd ff ff 0f 0b e9 af f8 ff ff <0f> 0b e9 5c f8 ff ff 48 89 df e8 da 9e ee e3 e9 12 fd ff ff 4c 89\n[ 1968.511923] RSP: 0018:ffffc900024efbf0 EFLAGS: 00010286\n[ 1968.511969] RAX: 00000000ffffffff RBX: ffff88811d241250 RCX: ffffffffc0176922\n[ 1968.512014] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff888118a90a24\n[ 1968.512059] RBP: ffff888118a90800 R08: 0000000000000000 R09: ffff888118a90a27\n[ 1968.512102] R10: ffffed1023152144 R11: 0000000000000001 R12: ffff888118a908ac\n[ 1968.512229] R13: ffff888118a90928 R14: dffffc0000000000 R15: ffff888118a90a24\n[ 1968.512310] FS: 0000000000000000(0000) GS:ffff888234200000(0000) knlGS:0000000000000000\n[ 1968.512405] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 1968.512493] CR2: 00007f5538f443a8 CR3: 000000016dc28001 CR4: 00000000003706e0\n[ 1968.512587] Call Trace:\n[ 1968.512672] <TASK>\n[ 1968.512751] ? _raw_spin_unlock_irq+0x1f/0x40\n[ 1968.512859] mhi_pm_st_worker+0x3ac/0x790 [mhi]\n[ 1968.512959] ? mhi_pm_mission_mode_transition.isra.0+0x7d0/0x7d0 [mhi]\n[ 1968.513063] process_one_work+0x86a/0x1400\n[ 1968.513184] ? pwq_dec_nr_in_flight+0x230/0x230\n[ 1968.513312] ? move_linked_works+0x125/0x290\n[ 1968.513416] worker_thread+0x6db/0xf60\n[ 1968.513536] ? process_one_work+0x1400/0x1400\n[ 1968.513627] kthread+0x241/0x2d0\n[ 1968.513733] ? kthread_complete_and_exit+0x20/0x20\n[ 1968.513821] ret_from_fork+0x22/0x30\n[ 1968.513924] </TASK>\n\nReason is mhi_deassert_dev_wake() from mhi_device_put() is called\nbut mhi_assert_dev_wake() from __mhi_device_get_sync() is not called\nin progress of recovery. Commit 8e0559921f9a ("bus: mhi: core:\nSkip device wake in error or shutdown state") add check for the\npm_state of mhi in __mhi_device_get_sync(), and the pm_state is not\nthe normal state untill recovery is completed, so it leads the\ndev_wake is not 0 and above warning print in mhi_pm_disable_transition()\nwhile checking mhi_cntrl->dev_wake.\n\nAdd check in ath11k_pci_write32()/ath11k_pci_read32() to skip call\nmhi_device_put() if mhi_device_get_sync() does not really do wake,\nthen the warning gone.\n\nTested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03003-QCAHSPSWPL_V1_V2_SILICONZ_LITE-2

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: lpfc: Fix null pointer dereference after failing to issue FLOGI and PLOGI\n\nIf lpfc_issue_els_flogi() fails and returns non-zero status, the node\nreference count is decremented to trigger the release of the nodelist\nstructure. However, if there is a prior registration or dev-loss-evt work\npending, the node may be released prematurely. When dev-loss-evt\ncompletes, the released node is referenced causing a use-after-free null\npointer dereference.\n\nSimilarly, when processing non-zero ELS PLOGI completion status in\nlpfc_cmpl_els_plogi(), the ndlp flags are checked for a transport\nregistration before triggering node removal. If dev-loss-evt work is\npending, the node may be released prematurely and a subsequent call to\nlpfc_dev_loss_tmo_handler() results in a use after free ndlp dereference.\n\nAdd test for pending dev-loss before decrementing the node reference count\nfor FLOGI, PLOGI, PRLI, and ADISC handling.

In the Linux kernel, the following vulnerability has been resolved:\n\nloop: implement ->free_disk\n\nEnsure that the lo_device which is stored in the gendisk private\ndata is valid until the gendisk is freed. Currently the loop driver\nuses a lot of effort to make sure a device is not freed when it is\nstill in use, but to to fix a potential deadlock this will be relaxed\na bit soon.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu/pm: fix the null pointer while the smu is disabled\n\nIt needs to check if the pp_funcs is initialized while release the\ncontext, otherwise it will trigger null pointer panic while the software\nsmu is not enabled.\n\n[ 1109.404555] BUG: kernel NULL pointer dereference, address: 0000000000000078\n[ 1109.404609] #PF: supervisor read access in kernel mode\n[ 1109.404638] #PF: error_code(0x0000) - not-present page\n[ 1109.404657] PGD 0 P4D 0\n[ 1109.404672] Oops: 0000 [#1] PREEMPT SMP NOPTI\n[ 1109.404701] CPU: 7 PID: 9150 Comm: amdgpu_test Tainted: G OEL 5.16.0-custom #1\n[ 1109.404732] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006\n[ 1109.404765] RIP: 0010:amdgpu_dpm_force_performance_level+0x1d/0x170 [amdgpu]\n[ 1109.405109] Code: 5d c3 44 8b a3 f0 80 00 00 eb e5 66 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 08 4c 8b b7 f0 7d 00 00 <49> 83 7e 78 00 0f 84 f2 00 00 00 80 bf 87 80 00 00 00 48 89 fb 0f\n[ 1109.405176] RSP: 0018:ffffaf3083ad7c20 EFLAGS: 00010282\n[ 1109.405203] RAX: 0000000000000000 RBX: ffff9796b1c14600 RCX: 0000000002862007\n[ 1109.405229] RDX: ffff97968591c8c0 RSI: 0000000000000001 RDI: ffff9796a3700000\n[ 1109.405260] RBP: ffffaf3083ad7c50 R08: ffffffff9897de00 R09: ffff979688d9db60\n[ 1109.405286] R10: 0000000000000000 R11: ffff979688d9db90 R12: 0000000000000001\n[ 1109.405316] R13: ffff9796a3700000 R14: 0000000000000000 R15: ffff9796a3708fc0\n[ 1109.405345] FS: 00007ff055cff180(0000) GS:ffff9796bfdc0000(0000) knlGS:0000000000000000\n[ 1109.405378] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 1109.405400] CR2: 0000000000000078 CR3: 000000000a394000 CR4: 00000000000506e0\n[ 1109.405434] Call Trace:\n[ 1109.405445] <TASK>\n[ 1109.405456] ? delete_object_full+0x1d/0x20\n[ 1109.405480] amdgpu_ctx_set_stable_pstate+0x7c/0xa0 [amdgpu]\n[ 1109.405698] amdgpu_ctx_fini.part.0+0xcb/0x100 [amdgpu]\n[ 1109.405911] amdgpu_ctx_do_release+0x71/0x80 [amdgpu]\n[ 1109.406121] amdgpu_ctx_ioctl+0x52d/0x550 [amdgpu]\n[ 1109.406327] ? _raw_spin_unlock+0x1a/0x30\n[ 1109.406354] ? drm_gem_handle_delete+0x81/0xb0 [drm]\n[ 1109.406400] ? amdgpu_ctx_get_entity+0x2c0/0x2c0 [amdgpu]\n[ 1109.406609] drm_ioctl_kernel+0xb6/0x140 [drm]

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: cx25821: Fix the warning when removing the module\n\nWhen removing the module, we will get the following warning:\n\n[ 14.746697] remove_proc_entry: removing non-empty directory 'irq/21', leaking at least 'cx25821[1]'\n[ 14.747449] WARNING: CPU: 4 PID: 368 at fs/proc/generic.c:717 remove_proc_entry+0x389/0x3f0\n[ 14.751611] RIP: 0010:remove_proc_entry+0x389/0x3f0\n[ 14.759589] Call Trace:\n[ 14.759792] <TASK>\n[ 14.759975] unregister_irq_proc+0x14c/0x170\n[ 14.760340] irq_free_descs+0x94/0xe0\n[ 14.760640] mp_unmap_irq+0xb6/0x100\n[ 14.760937] acpi_unregister_gsi_ioapic+0x27/0x40\n[ 14.761334] acpi_pci_irq_disable+0x1d3/0x320\n[ 14.761688] pci_disable_device+0x1ad/0x380\n[ 14.762027] ? _raw_spin_unlock_irqrestore+0x2d/0x60\n[ 14.762442] ? cx25821_shutdown+0x20/0x9f0 [cx25821]\n[ 14.762848] cx25821_finidev+0x48/0xc0 [cx25821]\n[ 14.763242] pci_device_remove+0x92/0x240\n\nFix this by freeing the irq before call pci_disable_device().

In the Linux kernel, the following vulnerability has been resolved:\n\nath11k: disable spectral scan during spectral deinit\n\nWhen ath11k modules are removed using rmmod with spectral scan enabled,\ncrash is observed. Different crash trace is observed for each crash.\n\nSend spectral scan disable WMI command to firmware before cleaning\nthe spectral dbring in the spectral_deinit API to avoid this crash.\n\ncall trace from one of the crash observed:\n[ 1252.880802] Unable to handle kernel NULL pointer dereference at virtual address 00000008\n[ 1252.882722] pgd = 0f42e886\n[ 1252.890955] [00000008] *pgd=00000000\n[ 1252.893478] Internal error: Oops: 5 [#1] PREEMPT SMP ARM\n[ 1253.093035] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.89 #0\n[ 1253.115261] Hardware name: Generic DT based system\n[ 1253.121149] PC is at ath11k_spectral_process_data+0x434/0x574 [ath11k]\n[ 1253.125940] LR is at 0x88e31017\n[ 1253.132448] pc : [<7f9387b8>] lr : [<88e31017>] psr: a0000193\n[ 1253.135488] sp : 80d01bc8 ip : 00000001 fp : 970e0000\n[ 1253.141737] r10: 88e31000 r9 : 970ec000 r8 : 00000080\n[ 1253.146946] r7 : 94734040 r6 : a0000113 r5 : 00000057 r4 : 00000000\n[ 1253.152159] r3 : e18cb694 r2 : 00000217 r1 : 1df1f000 r0 : 00000001\n[ 1253.158755] Flags: NzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user\n[ 1253.165266] Control: 10c0383d Table: 5e71006a DAC: 00000055\n[ 1253.172472] Process swapper/0 (pid: 0, stack limit = 0x60870141)\n[ 1253.458055] [<7f9387b8>] (ath11k_spectral_process_data [ath11k]) from [<7f917fdc>] (ath11k_dbring_buffer_release_event+0x214/0x2e4 [ath11k])\n[ 1253.466139] [<7f917fdc>] (ath11k_dbring_buffer_release_event [ath11k]) from [<7f8ea3c4>] (ath11k_wmi_tlv_op_rx+0x1840/0x29cc [ath11k])\n[ 1253.478807] [<7f8ea3c4>] (ath11k_wmi_tlv_op_rx [ath11k]) from [<7f8fe868>] (ath11k_htc_rx_completion_handler+0x180/0x4e0 [ath11k])\n[ 1253.490699] [<7f8fe868>] (ath11k_htc_rx_completion_handler [ath11k]) from [<7f91308c>] (ath11k_ce_per_engine_service+0x2c4/0x3b4 [ath11k])\n[ 1253.502386] [<7f91308c>] (ath11k_ce_per_engine_service [ath11k]) from [<7f9a4198>] (ath11k_pci_ce_tasklet+0x28/0x80 [ath11k_pci])\n[ 1253.514811] [<7f9a4198>] (ath11k_pci_ce_tasklet [ath11k_pci]) from [<8032227c>] (tasklet_action_common.constprop.2+0x64/0xe8)\n[ 1253.526476] [<8032227c>] (tasklet_action_common.constprop.2) from [<803021e8>] (__do_softirq+0x130/0x2d0)\n[ 1253.537756] [<803021e8>] (__do_softirq) from [<80322610>] (irq_exit+0xcc/0xe8)\n[ 1253.547304] [<80322610>] (irq_exit) from [<8036a4a4>] (__handle_domain_irq+0x60/0xb4)\n[ 1253.554428] [<8036a4a4>] (__handle_domain_irq) from [<805eb348>] (gic_handle_irq+0x4c/0x90)\n[ 1253.562321] [<805eb348>] (gic_handle_irq) from [<80301a78>] (__irq_svc+0x58/0x8c)\n\nTested-on: QCN6122 hw1.0 AHB WLAN.HK.2.6.0.1-00851-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: defio: fix the pagelist corruption\n\nEasily hit the below list corruption:\n==\nlist_add corruption. prev->next should be next (ffffffffc0ceb090), but\nwas ffffec604507edc8. (prev=ffffec604507edc8).\nWARNING: CPU: 65 PID: 3959 at lib/list_debug.c:26\n__list_add_valid+0x53/0x80\nCPU: 65 PID: 3959 Comm: fbdev Tainted: G U\nRIP: 0010:__list_add_valid+0x53/0x80\nCall Trace:\n <TASK>\n fb_deferred_io_mkwrite+0xea/0x150\n do_page_mkwrite+0x57/0xc0\n do_wp_page+0x278/0x2f0\n __handle_mm_fault+0xdc2/0x1590\n handle_mm_fault+0xdd/0x2c0\n do_user_addr_fault+0x1d3/0x650\n exc_page_fault+0x77/0x180\n ? asm_exc_page_fault+0x8/0x30\n asm_exc_page_fault+0x1e/0x30\nRIP: 0033:0x7fd98fc8fad1\n==\n\nFigure out the race happens when one process is adding &page->lru into\nthe pagelist tail in fb_deferred_io_mkwrite(), another process is\nre-initializing the same &page->lru in fb_deferred_io_fault(), which is\nnot protected by the lock.\n\nThis fix is to init all the page lists one time during initialization,\nit not only fixes the list corruption, but also avoids INIT_LIST_HEAD()\nredundantly.\n\nV2: change "int i" to "unsigned int i" (Geert Uytterhoeven)

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/omap: fix NULL but dereferenced coccicheck error\n\nFix the following coccicheck warning:\n./drivers/gpu/drm/omapdrm/omap_overlay.c:89:22-25: ERROR: r_ovl is NULL\nbut dereferenced.\n\nHere should be ovl->idx rather than r_ovl->idx.

In the Linux kernel, the following vulnerability has been resolved:\n\nspi: spi-fsl-qspi: check return value after calling platform_get_resource_byname()\n\nIt will cause null-ptr-deref if platform_get_resource_byname() returns NULL,\nwe need check the return value.

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: fix dangling sco_conn and use-after-free in sco_sock_timeout\n\nConnecting the same socket twice consecutively in sco_sock_connect()\ncould lead to a race condition where two sco_conn objects are created\nbut only one is associated with the socket. If the socket is closed\nbefore the SCO connection is established, the timer associated with the\ndangling sco_conn object won't be canceled. As the sock object is being\nfreed, the use-after-free problem happens when the timer callback\nfunction sco_sock_timeout() accesses the socket. Here's the call trace:\n\ndump_stack+0x107/0x163\n? refcount_inc+0x1c/\nprint_address_description.constprop.0+0x1c/0x47e\n? refcount_inc+0x1c/0x7b\nkasan_report+0x13a/0x173\n? refcount_inc+0x1c/0x7b\ncheck_memory_region+0x132/0x139\nrefcount_inc+0x1c/0x7b\nsco_sock_timeout+0xb2/0x1ba\nprocess_one_work+0x739/0xbd1\n? cancel_delayed_work+0x13f/0x13f\n? __raw_spin_lock_init+0xf0/0xf0\n? to_kthread+0x59/0x85\nworker_thread+0x593/0x70e\nkthread+0x346/0x35a\n? drain_workqueue+0x31a/0x31a\n? kthread_bind+0x4b/0x4b\nret_from_fork+0x1f/0x30

In the Linux kernel, the following vulnerability has been resolved:\n\nlib/string_helpers: fix not adding strarray to device's resource list\n\nAdd allocated strarray to device's resource list. This is a must to\nautomatically release strarray when the device disappears.\n\nWithout this fix we have a memory leak in the few drivers which use\ndevm_kasprintf_strarray().

In the Linux kernel, the following vulnerability has been resolved:\n\ntty: Fix a possible resource leak in icom_probe\n\nWhen pci_read_config_dword failed, call pci_release_regions() and\npci_disable_device() to recycle the resource previously allocated.

In the Linux kernel, the following vulnerability has been resolved:\n\nipv4: Handle attempt to delete multipath route when fib_info contains an nh reference\n\nGwangun Jung reported a slab-out-of-bounds access in fib_nh_match:\n fib_nh_match+0xf98/0x1130 linux-6.0-rc7/net/ipv4/fib_semantics.c:961\n fib_table_delete+0x5f3/0xa40 linux-6.0-rc7/net/ipv4/fib_trie.c:1753\n inet_rtm_delroute+0x2b3/0x380 linux-6.0-rc7/net/ipv4/fib_frontend.c:874\n\nSeparate nexthop objects are mutually exclusive with the legacy\nmultipath spec. Fix fib_nh_match to return if the config for the\nto be deleted route contains a multipath spec while the fib_info\nis using a nexthop object.

In the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: Handle failure to register sensor with thermal zone correctly\n\nIf an attempt is made to a sensor with a thermal zone and it fails,\nthe call to devm_thermal_zone_of_sensor_register() may return -ENODEV.\nThis may result in crashes similar to the following.\n\nUnable to handle kernel NULL pointer dereference at virtual address 00000000000003cd\n...\nInternal error: Oops: 96000021 [#1] PREEMPT SMP\n...\npstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : mutex_lock+0x18/0x60\nlr : thermal_zone_device_update+0x40/0x2e0\nsp : ffff800014c4fc60\nx29: ffff800014c4fc60 x28: ffff365ee3f6e000 x27: ffffdde218426790\nx26: ffff365ee3f6e000 x25: 0000000000000000 x24: ffff365ee3f6e000\nx23: ffffdde218426870 x22: ffff365ee3f6e000 x21: 00000000000003cd\nx20: ffff365ee8bf3308 x19: ffffffffffffffed x18: 0000000000000000\nx17: ffffdde21842689c x16: ffffdde1cb7a0b7c x15: 0000000000000040\nx14: ffffdde21a4889a0 x13: 0000000000000228 x12: 0000000000000000\nx11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000\nx8 : 0000000001120000 x7 : 0000000000000001 x6 : 0000000000000000\nx5 : 0068000878e20f07 x4 : 0000000000000000 x3 : 00000000000003cd\nx2 : ffff365ee3f6e000 x1 : 0000000000000000 x0 : 00000000000003cd\nCall trace:\n mutex_lock+0x18/0x60\n hwmon_notify_event+0xfc/0x110\n 0xffffdde1cb7a0a90\n 0xffffdde1cb7a0b7c\n irq_thread_fn+0x2c/0xa0\n irq_thread+0x134/0x240\n kthread+0x178/0x190\n ret_from_fork+0x10/0x20\nCode: d503201f d503201f d2800001 aa0103e4 (c8e47c02)\n\nJon Hunter reports that the exact call sequence is:\n\nhwmon_notify_event()\n --> hwmon_thermal_notify()\n --> thermal_zone_device_update()\n --> update_temperature()\n --> mutex_lock()\n\nThe hwmon core needs to handle all errors returned from calls\nto devm_thermal_zone_of_sensor_register(). If the call fails\nwith -ENODEV, report that the sensor was not attached to a\nthermal zone but continue to register the hwmon device.

In the Linux kernel, the following vulnerability has been resolved:\n\ntracing/osnoise: Do not unregister events twice\n\nNicolas reported that using:\n\n # trace-cmd record -e all -M 10 -p osnoise --poll\n\nResulted in the following kernel warning:\n\n ------------[ cut here ]------------\n WARNING: CPU: 0 PID: 1217 at kernel/tracepoint.c:404 tracepoint_probe_unregister+0x280/0x370\n [...]\n CPU: 0 PID: 1217 Comm: trace-cmd Not tainted 5.17.0-rc6-next-20220307-nico+ #19\n RIP: 0010:tracepoint_probe_unregister+0x280/0x370\n [...]\n CR2: 00007ff919b29497 CR3: 0000000109da4005 CR4: 0000000000170ef0\n Call Trace:\n <TASK>\n osnoise_workload_stop+0x36/0x90\n tracing_set_tracer+0x108/0x260\n tracing_set_trace_write+0x94/0xd0\n ? __check_object_size.part.0+0x10a/0x150\n ? selinux_file_permission+0x104/0x150\n vfs_write+0xb5/0x290\n ksys_write+0x5f/0xe0\n do_syscall_64+0x3b/0x90\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n RIP: 0033:0x7ff919a18127\n [...]\n ---[ end trace 0000000000000000 ]---\n\nThe warning complains about an attempt to unregister an\nunregistered tracepoint.\n\nThis happens on trace-cmd because it first stops tracing, and\nthen switches the tracer to nop. Which is equivalent to:\n\n # cd /sys/kernel/tracing/\n # echo osnoise > current_tracer\n # echo 0 > tracing_on\n # echo nop > current_tracer\n\nThe osnoise tracer stops the workload when no trace instance\nis actually collecting data. This can be caused both by\ndisabling tracing or disabling the tracer itself.\n\nTo avoid unregistering events twice, use the existing\ntrace_osnoise_callback_enabled variable to check if the events\n(and the workload) are actually active before trying to\ndeactivate them.

In the Linux kernel, the following vulnerability has been resolved:\n\nwatch_queue: Fix filter limit check\n\nIn watch_queue_set_filter(), there are a couple of places where we check\nthat the filter type value does not exceed what the type_filter bitmap\ncan hold. One place calculates the number of bits by:\n\n if (tf[i].type >= sizeof(wfilter->type_filter) * 8)\n\nwhich is fine, but the second does:\n\n if (tf[i].type >= sizeof(wfilter->type_filter) * BITS_PER_LONG)\n\nwhich is not. This can lead to a couple of out-of-bounds writes due to\na too-large type:\n\n (1) __set_bit() on wfilter->type_filter\n (2) Writing more elements in wfilter->filters[] than we allocated.\n\nFix this by just using the proper WATCH_TYPE__NR instead, which is the\nnumber of types we actually know about.\n\nThe bug may cause an oops looking something like:\n\n BUG: KASAN: slab-out-of-bounds in watch_queue_set_filter+0x659/0x740\n Write of size 4 at addr ffff88800d2c66bc by task watch_queue_oob/611\n ...\n Call Trace:\n <TASK>\n dump_stack_lvl+0x45/0x59\n print_address_description.constprop.0+0x1f/0x150\n ...\n kasan_report.cold+0x7f/0x11b\n ...\n watch_queue_set_filter+0x659/0x740\n ...\n __x64_sys_ioctl+0x127/0x190\n do_syscall_64+0x43/0x90\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\n Allocated by task 611:\n kasan_save_stack+0x1e/0x40\n __kasan_kmalloc+0x81/0xa0\n watch_queue_set_filter+0x23a/0x740\n __x64_sys_ioctl+0x127/0x190\n do_syscall_64+0x43/0x90\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\n The buggy address belongs to the object at ffff88800d2c66a0\n which belongs to the cache kmalloc-32 of size 32\n The buggy address is located 28 bytes inside of\n 32-byte region [ffff88800d2c66a0, ffff88800d2c66c0)

In the Linux kernel, the following vulnerability has been resolved:\n\nMIPS: smp: fill in sibling and core maps earlier\n\nAfter enabling CONFIG_SCHED_CORE (landed during 5.14 cycle),\n2-core 2-thread-per-core interAptiv (CPS-driven) started emitting\nthe following:\n\n[ 0.025698] CPU1 revision is: 0001a120 (MIPS interAptiv (multi))\n[ 0.048183] ------------[ cut here ]------------\n[ 0.048187] WARNING: CPU: 1 PID: 0 at kernel/sched/core.c:6025 sched_core_cpu_starting+0x198/0x240\n[ 0.048220] Modules linked in:\n[ 0.048233] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.17.0-rc3+ #35 b7b319f24073fd9a3c2aa7ad15fb7993eec0b26f\n[ 0.048247] Stack : 817f0000 00000004 327804c8 810eb050 00000000 00000004 00000000 c314fdd1\n[ 0.048278] 830cbd64 819c0000 81800000 817f0000 83070bf4 00000001 830cbd08 00000000\n[ 0.048307] 00000000 00000000 815fcbc4 00000000 00000000 00000000 00000000 00000000\n[ 0.048334] 00000000 00000000 00000000 00000000 817f0000 00000000 00000000 817f6f34\n[ 0.048361] 817f0000 818a3c00 817f0000 00000004 00000000 00000000 4dc33260 0018c933\n[ 0.048389] ...\n[ 0.048396] Call Trace:\n[ 0.048399] [<8105a7bc>] show_stack+0x3c/0x140\n[ 0.048424] [<8131c2a0>] dump_stack_lvl+0x60/0x80\n[ 0.048440] [<8108b5c0>] __warn+0xc0/0xf4\n[ 0.048454] [<8108b658>] warn_slowpath_fmt+0x64/0x10c\n[ 0.048467] [<810bd418>] sched_core_cpu_starting+0x198/0x240\n[ 0.048483] [<810c6514>] sched_cpu_starting+0x14/0x80\n[ 0.048497] [<8108c0f8>] cpuhp_invoke_callback_range+0x78/0x140\n[ 0.048510] [<8108d914>] notify_cpu_starting+0x94/0x140\n[ 0.048523] [<8106593c>] start_secondary+0xbc/0x280\n[ 0.048539]\n[ 0.048543] ---[ end trace 0000000000000000 ]---\n[ 0.048636] Synchronize counters for CPU 1: done.\n\n...for each but CPU 0/boot.\nBasic debug printks right before the mentioned line say:\n\n[ 0.048170] CPU: 1, smt_mask:\n\nSo smt_mask, which is sibling mask obviously, is empty when entering\nthe function.\nThis is critical, as sched_core_cpu_starting() calculates\ncore-scheduling parameters only once per CPU start, and it's crucial\nto have all the parameters filled in at that moment (at least it\nuses cpu_smt_mask() which in fact is `&cpu_sibling_map[cpu]` on\nMIPS).\n\nA bit of debugging led me to that set_cpu_sibling_map() performing\nthe actual map calculation, was being invocated after\nnotify_cpu_start(), and exactly the latter function starts CPU HP\ncallback round (sched_core_cpu_starting() is basically a CPU HP\ncallback).\nWhile the flow is same on ARM64 (maps after the notifier, although\nbefore calling set_cpu_online()), x86 started calculating sibling\nmaps earlier than starting the CPU HP callbacks in Linux 4.14 (see\n[0] for the reference). Neither me nor my brief tests couldn't find\nany potential caveats in calculating the maps right after performing\ndelay calibration, but the WARN splat is now gone.\nThe very same debug prints now yield exactly what I expected from\nthem:\n\n[ 0.048433] CPU: 1, smt_mask: 0-1\n\n[0] https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=76ce7cfe35ef

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vrr: Set VRR capable prop only if it is attached to connector\n\nVRR capable property is not attached by default to the connector\nIt is attached only if VRR is supported.\nSo if the driver tries to call drm core set prop function without\nit being attached that causes NULL dereference.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qedf: Add stag_work to all the vports\n\nCall trace seen when creating NPIV ports, only 32 out of 64 show online.\nstag work was not initialized for vport, hence initialize the stag work.\n\nWARNING: CPU: 8 PID: 645 at kernel/workqueue.c:1635 __queue_delayed_work+0x68/0x80\nCPU: 8 PID: 645 Comm: kworker/8:1 Kdump: loaded Tainted: G IOE --------- --\n 4.18.0-348.el8.x86_64 #1\nHardware name: Dell Inc. PowerEdge MX740c/0177V9, BIOS 2.12.2 07/09/2021\nWorkqueue: events fc_lport_timeout [libfc]\nRIP: 0010:__queue_delayed_work+0x68/0x80\nCode: 89 b2 88 00 00 00 44 89 82 90 00 00 00 48 01 c8 48 89 42 50 41 81\nf8 00 20 00 00 75 1d e9 60 24 07 00 44 89 c7 e9 98 f6 ff ff <0f> 0b eb\nc5 0f 0b eb a1 0f 0b eb a7 0f 0b eb ac 44 89 c6 e9 40 23\nRSP: 0018:ffffae514bc3be40 EFLAGS: 00010006\nRAX: ffff8d25d6143750 RBX: 0000000000000202 RCX: 0000000000000002\nRDX: ffff8d2e31383748 RSI: ffff8d25c000d600 RDI: ffff8d2e31383788\nRBP: ffff8d2e31380de0 R08: 0000000000002000 R09: ffff8d2e31383750\nR10: ffffffffc0c957e0 R11: ffff8d2624800000 R12: ffff8d2e31380a58\nR13: ffff8d2d915eb000 R14: ffff8d25c499b5c0 R15: ffff8d2e31380e18\nFS: 0000000000000000(0000) GS:ffff8d2d1fb00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000055fd0484b8b8 CR3: 00000008ffc10006 CR4: 00000000007706e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n queue_delayed_work_on+0x36/0x40\n qedf_elsct_send+0x57/0x60 [qedf]\n fc_lport_enter_flogi+0x90/0xc0 [libfc]\n fc_lport_timeout+0xb7/0x140 [libfc]\n process_one_work+0x1a7/0x360\n ? create_worker+0x1a0/0x1a0\n worker_thread+0x30/0x390\n ? create_worker+0x1a0/0x1a0\n kthread+0x116/0x130\n ? kthread_flush_work_fn+0x10/0x10\n ret_from_fork+0x35/0x40\n ---[ end trace 008f00f722f2c2ff ]--\n\nInitialize stag work for all the vports.

In the Linux kernel, the following vulnerability has been resolved:\n\nmisc: fastrpc: avoid double fput() on failed usercopy\n\nIf the copy back to userland fails for the FASTRPC_IOCTL_ALLOC_DMA_BUFF\nioctl(), we shouldn't assume that 'buf->dmabuf' is still valid. In fact,\ndma_buf_fd() called fd_install() before, i.e. "consumed" one reference,\nleaving us with none.\n\nCalling dma_buf_put() will therefore put a reference we no longer own,\nleading to a valid file descritor table entry for an already released\n'file' object which is a straight use-after-free.\n\nSimply avoid calling dma_buf_put() and rely on the process exit code to\ndo the necessary cleanup, if needed, i.e. if the file descriptor is\nstill valid.

In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: take care of mixed splice()/sendmsg(MSG_ZEROCOPY) case\n\nsyzbot found that mixing sendpage() and sendmsg(MSG_ZEROCOPY)\ncalls over the same TCP socket would again trigger the\ninfamous warning in inet_sock_destruct()\n\n WARN_ON(sk_forward_alloc_get(sk));\n\nWhile Talal took into account a mix of regular copied data\nand MSG_ZEROCOPY one in the same skb, the sendpage() path\nhas been forgotten.\n\nWe want the charging to happen for sendpage(), because\npages could be coming from a pipe. What is missing is the\ndowngrading of pure zerocopy status to make sure\nsk_forward_alloc will stay synced.\n\nAdd tcp_downgrade_zcopy_pure() helper so that we can\nuse it from the two callers.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: bcm_sf2: don't use devres for mdiobus\n\nAs explained in commits:\n74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres")\n5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres")\n\nmdiobus_free() will panic when called from devm_mdiobus_free() <-\ndevres_release_all() <- __device_release_driver(), and that mdiobus was\nnot previously unregistered.\n\nThe Starfighter 2 is a platform device, so the initial set of\nconstraints that I thought would cause this (I2C or SPI buses which call\n->remove on ->shutdown) do not apply. But there is one more which\napplies here.\n\nIf the DSA master itself is on a bus that calls ->remove from ->shutdown\n(like dpaa2-eth, which is on the fsl-mc bus), there is a device link\nbetween the switch and the DSA master, and device_links_unbind_consumers()\nwill unbind the bcm_sf2 switch driver on shutdown.\n\nSo the same treatment must be applied to all DSA switch drivers, which\nis: either use devres for both the mdiobus allocation and registration,\nor don't use devres at all.\n\nThe bcm_sf2 driver has the code structure in place for orderly mdiobus\nremoval, so just replace devm_mdiobus_alloc() with the non-devres\nvariant, and add manual free where necessary, to ensure that we don't\nlet devres free a still-registered bus.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: fix a memleak when uncloning an skb dst and its metadata\n\nWhen uncloning an skb dst and its associated metadata, a new\ndst+metadata is allocated and later replaces the old one in the skb.\nThis is helpful to have a non-shared dst+metadata attached to a specific\nskb.\n\nThe issue is the uncloned dst+metadata is initialized with a refcount of\n1, which is increased to 2 before attaching it to the skb. When\ntun_dst_unclone returns, the dst+metadata is only referenced from a\nsingle place (the skb) while its refcount is 2. Its refcount will never\ndrop to 0 (when the skb is consumed), leading to a memory leak.\n\nFix this by removing the call to dst_hold in tun_dst_unclone, as the\ndst+metadata refcount is already 1.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: fix panic when DSA master device unbinds on shutdown\n\nRafael reports that on a system with LX2160A and Marvell DSA switches,\nif a reboot occurs while the DSA master (dpaa2-eth) is up, the following\npanic can be seen:\n\nsystemd-shutdown[1]: Rebooting.\nUnable to handle kernel paging request at virtual address 00a0000800000041\n[00a0000800000041] address between user and kernel address ranges\nInternal error: Oops: 96000004 [#1] PREEMPT SMP\nCPU: 6 PID: 1 Comm: systemd-shutdow Not tainted 5.16.5-00042-g8f5585009b24 #32\npc : dsa_slave_netdevice_event+0x130/0x3e4\nlr : raw_notifier_call_chain+0x50/0x6c\nCall trace:\n dsa_slave_netdevice_event+0x130/0x3e4\n raw_notifier_call_chain+0x50/0x6c\n call_netdevice_notifiers_info+0x54/0xa0\n __dev_close_many+0x50/0x130\n dev_close_many+0x84/0x120\n unregister_netdevice_many+0x130/0x710\n unregister_netdevice_queue+0x8c/0xd0\n unregister_netdev+0x20/0x30\n dpaa2_eth_remove+0x68/0x190\n fsl_mc_driver_remove+0x20/0x5c\n __device_release_driver+0x21c/0x220\n device_release_driver_internal+0xac/0xb0\n device_links_unbind_consumers+0xd4/0x100\n __device_release_driver+0x94/0x220\n device_release_driver+0x28/0x40\n bus_remove_device+0x118/0x124\n device_del+0x174/0x420\n fsl_mc_device_remove+0x24/0x40\n __fsl_mc_device_remove+0xc/0x20\n device_for_each_child+0x58/0xa0\n dprc_remove+0x90/0xb0\n fsl_mc_driver_remove+0x20/0x5c\n __device_release_driver+0x21c/0x220\n device_release_driver+0x28/0x40\n bus_remove_device+0x118/0x124\n device_del+0x174/0x420\n fsl_mc_bus_remove+0x80/0x100\n fsl_mc_bus_shutdown+0xc/0x1c\n platform_shutdown+0x20/0x30\n device_shutdown+0x154/0x330\n __do_sys_reboot+0x1cc/0x250\n __arm64_sys_reboot+0x20/0x30\n invoke_syscall.constprop.0+0x4c/0xe0\n do_el0_svc+0x4c/0x150\n el0_svc+0x24/0xb0\n el0t_64_sync_handler+0xa8/0xb0\n el0t_64_sync+0x178/0x17c\n\nIt can be seen from the stack trace that the problem is that the\nderegistration of the master causes a dev_close(), which gets notified\nas NETDEV_GOING_DOWN to dsa_slave_netdevice_event().\nBut dsa_switch_shutdown() has already run, and this has unregistered the\nDSA slave interfaces, and yet, the NETDEV_GOING_DOWN handler attempts to\ncall dev_close_many() on those slave interfaces, leading to the problem.\n\nThe previous attempt to avoid the NETDEV_GOING_DOWN on the master after\ndsa_switch_shutdown() was called seems improper. Unregistering the slave\ninterfaces is unnecessary and unhelpful. Instead, after the slaves have\nstopped being uppers of the DSA master, we can now reset to NULL the\nmaster->dsa_ptr pointer, which will make DSA start ignoring all future\nnotifier events on the master.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: ax88179_178a: Fix out-of-bounds accesses in RX fixup\n\nax88179_rx_fixup() contains several out-of-bounds accesses that can be\ntriggered by a malicious (or defective) USB device, in particular:\n\n - The metadata array (hdr_off..hdr_off+2*pkt_cnt) can be out of bounds,\n causing OOB reads and (on big-endian systems) OOB endianness flips.\n - A packet can overlap the metadata array, causing a later OOB\n endianness flip to corrupt data used by a cloned SKB that has already\n been handed off into the network stack.\n - A packet SKB can be constructed whose tail is far beyond its end,\n causing out-of-bounds heap data to be considered part of the SKB's\n data.\n\nI have tested that this can be used by a malicious USB device to send a\nbogus ICMPv6 Echo Request and receive an ICMPv6 Echo Reply in response\nthat contains random kernel heap data.\nIt's probably also possible to get OOB writes from this on a\nlittle-endian system somehow - maybe by triggering skb_cow() via IP\noptions processing -, but I haven't tested that.

In the Linux kernel, the following vulnerability has been resolved:\n\nfs/proc: task_mmu.c: don't read mapcount for migration entry\n\nThe syzbot reported the below BUG:\n\n kernel BUG at include/linux/page-flags.h:785!\n invalid opcode: 0000 [#1] PREEMPT SMP KASAN\n CPU: 1 PID: 4392 Comm: syz-executor560 Not tainted 5.16.0-rc6-syzkaller #0\n Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\n RIP: 0010:PageDoubleMap include/linux/page-flags.h:785 [inline]\n RIP: 0010:__page_mapcount+0x2d2/0x350 mm/util.c:744\n Call Trace:\n page_mapcount include/linux/mm.h:837 [inline]\n smaps_account+0x470/0xb10 fs/proc/task_mmu.c:466\n smaps_pte_entry fs/proc/task_mmu.c:538 [inline]\n smaps_pte_range+0x611/0x1250 fs/proc/task_mmu.c:601\n walk_pmd_range mm/pagewalk.c:128 [inline]\n walk_pud_range mm/pagewalk.c:205 [inline]\n walk_p4d_range mm/pagewalk.c:240 [inline]\n walk_pgd_range mm/pagewalk.c:277 [inline]\n __walk_page_range+0xe23/0x1ea0 mm/pagewalk.c:379\n walk_page_vma+0x277/0x350 mm/pagewalk.c:530\n smap_gather_stats.part.0+0x148/0x260 fs/proc/task_mmu.c:768\n smap_gather_stats fs/proc/task_mmu.c:741 [inline]\n show_smap+0xc6/0x440 fs/proc/task_mmu.c:822\n seq_read_iter+0xbb0/0x1240 fs/seq_file.c:272\n seq_read+0x3e0/0x5b0 fs/seq_file.c:162\n vfs_read+0x1b5/0x600 fs/read_write.c:479\n ksys_read+0x12d/0x250 fs/read_write.c:619\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nThe reproducer was trying to read /proc/$PID/smaps when calling\nMADV_FREE at the mean time. MADV_FREE may split THPs if it is called\nfor partial THP. It may trigger the below race:\n\n CPU A CPU B\n ----- -----\n smaps walk: MADV_FREE:\n page_mapcount()\n PageCompound()\n split_huge_page()\n page = compound_head(page)\n PageDoubleMap(page)\n\nWhen calling PageDoubleMap() this page is not a tail page of THP anymore\nso the BUG is triggered.\n\nThis could be fixed by elevated refcount of the page before calling\nmapcount, but that would prevent it from counting migration entries, and\nit seems overkilling because the race just could happen when PMD is\nsplit so all PTE entries of tail pages are actually migration entries,\nand smaps_account() does treat migration entries as mapcount == 1 as\nKirill pointed out.\n\nAdd a new parameter for smaps_account() to tell this entry is migration\nentry then skip calling page_mapcount(). Don't skip getting mapcount\nfor device private entries since they do track references with mapcount.\n\nPagemap also has the similar issue although it was not reported. Fixed\nit as well.\n\n[shy828301@gmail.com: v4]\n Link: https://lkml.kernel.org/r/20220203182641.824731-1-shy828301@gmail.com\n[nathan@kernel.org: avoid unused variable warning in pagemap_pmd_range()]\n Link: https://lkml.kernel.org/r/20220207171049.1102239-1-nathan@kernel.org

In the Linux kernel, the following vulnerability has been resolved:\n\nperf: Fix list corruption in perf_cgroup_switch()\n\nThere's list corruption on cgrp_cpuctx_list. This happens on the\nfollowing path:\n\n perf_cgroup_switch: list_for_each_entry(cgrp_cpuctx_list)\n cpu_ctx_sched_in\n ctx_sched_in\n ctx_pinned_sched_in\n merge_sched_in\n perf_cgroup_event_disable: remove the event from the list\n\nUse list_for_each_entry_safe() to allow removing an entry during\niteration.

In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: mcast: use rcu-safe version of ipv6_get_lladdr()\n\nSome time ago 8965779d2c0e ("ipv6,mcast: always hold idev->lock before mca_lock")\nswitched ipv6_get_lladdr() to __ipv6_get_lladdr(), which is rcu-unsafe\nversion. That was OK, because idev->lock was held for these codepaths.\n\nIn 88e2ca308094 ("mld: convert ifmcaddr6 to RCU") these external locks were\nremoved, so we probably need to restore the original rcu-safe call.\n\nOtherwise, we occasionally get a machine crashed/stalled with the following\nin dmesg:\n\n[ 3405.966610][T230589] general protection fault, probably for non-canonical address 0xdead00000000008c: 0000 [#1] SMP NOPTI\n[ 3405.982083][T230589] CPU: 44 PID: 230589 Comm: kworker/44:3 Tainted: G O 5.15.19-cloudflare-2022.2.1 #1\n[ 3405.998061][T230589] Hardware name: SUPA-COOL-SERV\n[ 3406.009552][T230589] Workqueue: mld mld_ifc_work\n[ 3406.017224][T230589] RIP: 0010:__ipv6_get_lladdr+0x34/0x60\n[ 3406.025780][T230589] Code: 57 10 48 83 c7 08 48 89 e5 48 39 d7 74 3e 48 8d 82 38 ff ff ff eb 13 48 8b 90 d0 00 00 00 48 8d 82 38 ff ff ff 48 39 d7 74 22 <66> 83 78 32 20 77 1b 75 e4 89 ca 23 50 2c 75 dd 48 8b 50 08 48 8b\n[ 3406.055748][T230589] RSP: 0018:ffff94e4b3fc3d10 EFLAGS: 00010202\n[ 3406.065617][T230589] RAX: dead00000000005a RBX: ffff94e4b3fc3d30 RCX: 0000000000000040\n[ 3406.077477][T230589] RDX: dead000000000122 RSI: ffff94e4b3fc3d30 RDI: ffff8c3a31431008\n[ 3406.089389][T230589] RBP: ffff94e4b3fc3d10 R08: 0000000000000000 R09: 0000000000000000\n[ 3406.101445][T230589] R10: ffff8c3a31430000 R11: 000000000000000b R12: ffff8c2c37887100\n[ 3406.113553][T230589] R13: ffff8c3a39537000 R14: 00000000000005dc R15: ffff8c3a31431000\n[ 3406.125730][T230589] FS: 0000000000000000(0000) GS:ffff8c3b9fc80000(0000) knlGS:0000000000000000\n[ 3406.138992][T230589] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 3406.149895][T230589] CR2: 00007f0dfea1db60 CR3: 000000387b5f2000 CR4: 0000000000350ee0\n[ 3406.162421][T230589] Call Trace:\n[ 3406.170235][T230589] <TASK>\n[ 3406.177736][T230589] mld_newpack+0xfe/0x1a0\n[ 3406.186686][T230589] add_grhead+0x87/0xa0\n[ 3406.195498][T230589] add_grec+0x485/0x4e0\n[ 3406.204310][T230589] ? newidle_balance+0x126/0x3f0\n[ 3406.214024][T230589] mld_ifc_work+0x15d/0x450\n[ 3406.223279][T230589] process_one_work+0x1e6/0x380\n[ 3406.232982][T230589] worker_thread+0x50/0x3a0\n[ 3406.242371][T230589] ? rescuer_thread+0x360/0x360\n[ 3406.252175][T230589] kthread+0x127/0x150\n[ 3406.261197][T230589] ? set_kthread_struct+0x40/0x40\n[ 3406.271287][T230589] ret_from_fork+0x22/0x30\n[ 3406.280812][T230589] </TASK>\n[ 3406.288937][T230589] Modules linked in: ... [last unloaded: kheaders]\n[ 3406.476714][T230589] ---[ end trace 3525a7655f2f3b9e ]---

In the Linux kernel, the following vulnerability has been resolved:\n\ncfg80211: fix race in netlink owner interface destruction\n\nMy previous fix here to fix the deadlock left a race where\nthe exact same deadlock (see the original commit referenced\nbelow) can still happen if cfg80211_destroy_ifaces() already\nruns while nl80211_netlink_notify() is still marking some\ninterfaces as nl_owner_dead.\n\nThe race happens because we have two loops here - first we\ndev_close() all the netdevs, and then we destroy them. If we\nalso have two netdevs (first one need only be a wdev though)\nthen we can find one during the first iteration, close it,\nand go to the second iteration -- but then find two, and try\nto destroy also the one we didn't close yet.\n\nFix this by only iterating once.

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Guard against accessing NULL pt_regs in bpf_get_task_stack()\n\ntask_pt_regs() can return NULL on powerpc for kernel threads. This is\nthen used in __bpf_get_stack() to check for user mode, resulting in a\nkernel oops. Guard against this by checking return value of\ntask_pt_regs() before trying to obtain the call chain.

In the Linux kernel, the following vulnerability has been resolved:\n\nefi: runtime: avoid EFIv2 runtime services on Apple x86 machines\n\nAditya reports [0] that his recent MacbookPro crashes in the firmware\nwhen using the variable services at runtime. The culprit appears to be a\ncall to QueryVariableInfo(), which we did not use to call on Apple x86\nmachines in the past as they only upgraded from EFI v1.10 to EFI v2.40\nfirmware fairly recently, and QueryVariableInfo() (along with\nUpdateCapsule() et al) was added in EFI v2.00.\n\nThe only runtime service introduced in EFI v2.00 that we actually use in\nLinux is QueryVariableInfo(), as the capsule based ones are optional,\ngenerally not used at runtime (all the LVFS/fwupd firmware update\ninfrastructure uses helper EFI programs that invoke capsule update at\nboot time, not runtime), and not implemented by Apple machines in the\nfirst place. QueryVariableInfo() is used to 'safely' set variables,\ni.e., only when there is enough space. This prevents machines with buggy\nfirmwares from corrupting their NVRAMs when they run out of space.\n\nGiven that Apple machines have been using EFI v1.10 services only for\nthe longest time (the EFI v2.0 spec was released in 2006, and Linux\nsupport for the newly introduced runtime services was added in 2011, but\nthe MacbookPro12,1 released in 2015 still claims to be EFI v1.10 only),\nlet's avoid the EFI v2.0 ones on all Apple x86 machines.\n\n[0] https://lore.kernel.org/all/6D757C75-65B1-468B-842D-10410081A8E4@live.com/

In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Free kvm_cpuid_entry2 array on post-KVM_RUN KVM_SET_CPUID{,2}\n\nFree the "struct kvm_cpuid_entry2" array on successful post-KVM_RUN\nKVM_SET_CPUID{,2} to fix a memory leak, the callers of kvm_set_cpuid()\nfree the array only on failure.\n\n BUG: memory leak\n unreferenced object 0xffff88810963a800 (size 2048):\n comm "syz-executor025", pid 3610, jiffies 4294944928 (age 8.080s)\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 0d 00 00 00 ................\n 47 65 6e 75 6e 74 65 6c 69 6e 65 49 00 00 00 00 GenuntelineI....\n backtrace:\n [<ffffffff814948ee>] kmalloc_node include/linux/slab.h:604 [inline]\n [<ffffffff814948ee>] kvmalloc_node+0x3e/0x100 mm/util.c:580\n [<ffffffff814950f2>] kvmalloc include/linux/slab.h:732 [inline]\n [<ffffffff814950f2>] vmemdup_user+0x22/0x100 mm/util.c:199\n [<ffffffff8109f5ff>] kvm_vcpu_ioctl_set_cpuid2+0x8f/0xf0 arch/x86/kvm/cpuid.c:423\n [<ffffffff810711b9>] kvm_arch_vcpu_ioctl+0xb99/0x1e60 arch/x86/kvm/x86.c:5251\n [<ffffffff8103e92d>] kvm_vcpu_ioctl+0x4ad/0x950 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4066\n [<ffffffff815afacc>] vfs_ioctl fs/ioctl.c:51 [inline]\n [<ffffffff815afacc>] __do_sys_ioctl fs/ioctl.c:874 [inline]\n [<ffffffff815afacc>] __se_sys_ioctl fs/ioctl.c:860 [inline]\n [<ffffffff815afacc>] __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:860\n [<ffffffff844a3335>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n [<ffffffff844a3335>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n [<ffffffff84600068>] entry_SYSCALL_64_after_hwframe+0x44/0xae

In the Linux kernel, the following vulnerability has been resolved:\n\nrpmsg: char: Fix race between the release of rpmsg_ctrldev and cdev\n\nstruct rpmsg_ctrldev contains a struct cdev. The current code frees\nthe rpmsg_ctrldev struct in rpmsg_ctrldev_release_device(), but the\ncdev is a managed object, therefore its release is not predictable\nand the rpmsg_ctrldev could be freed before the cdev is entirely\nreleased, as in the backtrace below.\n\n[ 93.625603] ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x7c\n[ 93.636115] WARNING: CPU: 0 PID: 12 at lib/debugobjects.c:488 debug_print_object+0x13c/0x1b0\n[ 93.644799] Modules linked in: veth xt_cgroup xt_MASQUERADE rfcomm algif_hash algif_skcipher af_alg uinput ip6table_nat fuse uvcvideo videobuf2_vmalloc venus_enc venus_dec videobuf2_dma_contig hci_uart btandroid btqca snd_soc_rt5682_i2c bluetooth qcom_spmi_temp_alarm snd_soc_rt5682v\n[ 93.715175] CPU: 0 PID: 12 Comm: kworker/0:1 Tainted: G B 5.4.163-lockdep #26\n[ 93.723855] Hardware name: Google Lazor (rev3 - 8) with LTE (DT)\n[ 93.730055] Workqueue: events kobject_delayed_cleanup\n[ 93.735271] pstate: 60c00009 (nZCv daif +PAN +UAO)\n[ 93.740216] pc : debug_print_object+0x13c/0x1b0\n[ 93.744890] lr : debug_print_object+0x13c/0x1b0\n[ 93.749555] sp : ffffffacf5bc7940\n[ 93.752978] x29: ffffffacf5bc7940 x28: dfffffd000000000\n[ 93.758448] x27: ffffffacdb11a800 x26: dfffffd000000000\n[ 93.763916] x25: ffffffd0734f856c x24: dfffffd000000000\n[ 93.769389] x23: 0000000000000000 x22: ffffffd0733c35b0\n[ 93.774860] x21: ffffffd0751994a0 x20: ffffffd075ec27c0\n[ 93.780338] x19: ffffffd075199100 x18: 00000000000276e0\n[ 93.785814] x17: 0000000000000000 x16: dfffffd000000000\n[ 93.791291] x15: ffffffffffffffff x14: 6e6968207473696c\n[ 93.796768] x13: 0000000000000000 x12: ffffffd075e2b000\n[ 93.802244] x11: 0000000000000001 x10: 0000000000000000\n[ 93.807723] x9 : d13400dff1921900 x8 : d13400dff1921900\n[ 93.813200] x7 : 0000000000000000 x6 : 0000000000000000\n[ 93.818676] x5 : 0000000000000080 x4 : 0000000000000000\n[ 93.824152] x3 : ffffffd0732a0fa4 x2 : 0000000000000001\n[ 93.829628] x1 : ffffffacf5bc7580 x0 : 0000000000000061\n[ 93.835104] Call trace:\n[ 93.837644] debug_print_object+0x13c/0x1b0\n[ 93.841963] __debug_check_no_obj_freed+0x25c/0x3c0\n[ 93.846987] debug_check_no_obj_freed+0x18/0x20\n[ 93.851669] slab_free_freelist_hook+0xbc/0x1e4\n[ 93.856346] kfree+0xfc/0x2f4\n[ 93.859416] rpmsg_ctrldev_release_device+0x78/0xb8\n[ 93.864445] device_release+0x84/0x168\n[ 93.868310] kobject_cleanup+0x12c/0x298\n[ 93.872356] kobject_delayed_cleanup+0x10/0x18\n[ 93.876948] process_one_work+0x578/0x92c\n[ 93.881086] worker_thread+0x804/0xcf8\n[ 93.884963] kthread+0x2a8/0x314\n[ 93.888303] ret_from_fork+0x10/0x18\n\nThe cdev_device_add/del() API was created to address this issue (see\ncommit '233ed09d7fda ("chardev: add helper function to register char\ndevs with a struct device")'), use it instead of cdev add/del().

In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/perf: Fix power_pmu_disable to call clear_pmi_irq_pending only if PMI is pending\n\nRunning selftest with CONFIG_PPC_IRQ_SOFT_MASK_DEBUG enabled in kernel\ntriggered below warning:\n\n[ 172.851380] ------------[ cut here ]------------\n[ 172.851391] WARNING: CPU: 8 PID: 2901 at arch/powerpc/include/asm/hw_irq.h:246 power_pmu_disable+0x270/0x280\n[ 172.851402] Modules linked in: dm_mod bonding nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables rfkill nfnetlink sunrpc xfs libcrc32c pseries_rng xts vmx_crypto uio_pdrv_genirq uio sch_fq_codel ip_tables ext4 mbcache jbd2 sd_mod t10_pi sg ibmvscsi ibmveth scsi_transport_srp fuse\n[ 172.851442] CPU: 8 PID: 2901 Comm: lost_exception_ Not tainted 5.16.0-rc5-03218-g798527287598 #2\n[ 172.851451] NIP: c00000000013d600 LR: c00000000013d5a4 CTR: c00000000013b180\n[ 172.851458] REGS: c000000017687860 TRAP: 0700 Not tainted (5.16.0-rc5-03218-g798527287598)\n[ 172.851465] MSR: 8000000000029033 <SF,EE,ME,IR,DR,RI,LE> CR: 48004884 XER: 20040000\n[ 172.851482] CFAR: c00000000013d5b4 IRQMASK: 1\n[ 172.851482] GPR00: c00000000013d5a4 c000000017687b00 c000000002a10600 0000000000000004\n[ 172.851482] GPR04: 0000000082004000 c0000008ba08f0a8 0000000000000000 00000008b7ed0000\n[ 172.851482] GPR08: 00000000446194f6 0000000000008000 c00000000013b118 c000000000d58e68\n[ 172.851482] GPR12: c00000000013d390 c00000001ec54a80 0000000000000000 0000000000000000\n[ 172.851482] GPR16: 0000000000000000 0000000000000000 c000000015d5c708 c0000000025396d0\n[ 172.851482] GPR20: 0000000000000000 0000000000000000 c00000000a3bbf40 0000000000000003\n[ 172.851482] GPR24: 0000000000000000 c0000008ba097400 c0000000161e0d00 c00000000a3bb600\n[ 172.851482] GPR28: c000000015d5c700 0000000000000001 0000000082384090 c0000008ba0020d8\n[ 172.851549] NIP [c00000000013d600] power_pmu_disable+0x270/0x280\n[ 172.851557] LR [c00000000013d5a4] power_pmu_disable+0x214/0x280\n[ 172.851565] Call Trace:\n[ 172.851568] [c000000017687b00] [c00000000013d5a4] power_pmu_disable+0x214/0x280 (unreliable)\n[ 172.851579] [c000000017687b40] [c0000000003403ac] perf_pmu_disable+0x4c/0x60\n[ 172.851588] [c000000017687b60] [c0000000003445e4] __perf_event_task_sched_out+0x1d4/0x660\n[ 172.851596] [c000000017687c50] [c000000000d1175c] __schedule+0xbcc/0x12a0\n[ 172.851602] [c000000017687d60] [c000000000d11ea8] schedule+0x78/0x140\n[ 172.851608] [c000000017687d90] [c0000000001a8080] sys_sched_yield+0x20/0x40\n[ 172.851615] [c000000017687db0] [c0000000000334dc] system_call_exception+0x18c/0x380\n[ 172.851622] [c000000017687e10] [c00000000000c74c] system_call_common+0xec/0x268\n\nThe warning indicates that MSR_EE being set(interrupt enabled) when\nthere was an overflown PMC detected. This could happen in\npower_pmu_disable since it runs under interrupt soft disable\ncondition ( local_irq_save ) and not with interrupts hard disabled.\ncommit 2c9ac51b850d ("powerpc/perf: Fix PMU callbacks to clear\npending PMI before resetting an overflown PMC") intended to clear\nPMI pending bit in Paca when disabling the PMU. It could happen\nthat PMC gets overflown while code is in power_pmu_disable\ncallback function. Hence add a check to see if PMI pending bit\nis set in Paca before clearing it via clear_pmi_pending.

In the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86/intel/pt: Fix crash with stop filters in single-range mode\n\nAdd a check for !buf->single before calling pt_buffer_region_size in a\nplace where a missing check can cause a kernel crash.\n\nFixes a bug introduced by commit 670638477aed ("perf/x86/intel/pt:\nOpportunistically use single range output mode"), which added a\nsupport for PT single-range output mode. Since that commit if a PT\nstop filter range is hit while tracing, the kernel will crash because\nof a null pointer dereference in pt_handle_status due to calling\npt_buffer_region_size without a ToPA configured.\n\nThe commit which introduced single-range mode guarded almost all uses of\nthe ToPA buffer variables with checks of the buf->single variable, but\nmissed the case where tracing was stopped by the PT hardware, which\nhappens when execution hits a configured stop filter.\n\nTested that hitting a stop filter while PT recording successfully\nrecords a trace with this patch but crashes without this patch.

In the Linux kernel, the following vulnerability has been resolved:\n\ntipc: improve size validations for received domain records\n\nThe function tipc_mon_rcv() allows a node to receive and process\ndomain_record structs from peer nodes to track their views of the\nnetwork topology.\n\nThis patch verifies that the number of members in a received domain\nrecord does not exceed the limit defined by MAX_MON_DOMAIN, something\nthat may otherwise lead to a stack overflow.\n\ntipc_mon_rcv() is called from the function tipc_link_proto_rcv(), where\nwe are reading a 32 bit message data length field into a uint16. To\navert any risk of bit overflow, we add an extra sanity check for this in\nthat function. We cannot see that happen with the current code, but\nfuture designers being unaware of this risk, may introduce it by\nallowing delivery of very large (> 64k) sk buffers from the bearer\nlayer. This potential problem was identified by Eric Dumazet.\n\nThis fixes CVE-2022-0435

If the user added a security exception for an invalid TLS certificate, opened an ongoing TLS connection with a server that used that certificate, and then deleted the exception, Firefox would have kept the connection alive, making it seem like the certificate was still trusted. This vulnerability affects Firefox < 107.

Service Workers did not detect Private Browsing Mode correctly in all cases, which could have led to Service Workers being written to disk for websites visited in Private Browsing Mode. This would not have persisted them in a state where they would run again, but it would have leaked Private Browsing Mode details to disk. This vulnerability affects Firefox < 107.

Using the S.browser_fallback_url parameter parameter, an attacker could redirect a user to a URL and cause SameSite=Strict cookies to be sent.
*This issue only affects Firefox for Android. Other operating systems are not affected.*. This vulnerability affects Firefox < 107.

During startup, a graphics driver with an unexpected name could lead to a stack-buffer overflow causing a potentially exploitable crash.
*This issue only affects Firefox for Android. Other operating systems are not affected.*. This vulnerability affects Firefox < 105.

A vulnerability was found in davidmoreno onion. It has been rated as problematic. Affected by this issue is the function onion_response_flush of the file src/onion/response.c of the component Log Handler. The manipulation leads to allocation of resources. The name of the patch is de8ea938342b36c28024fd8393ebc27b8442a161. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-214028.

An attacker could have written a value to the first element in a zero-length JavaScript array. Although the array was zero-length, the value was not written to an invalid memory address. This vulnerability affects Firefox < 104.

A website that had permission to access the microphone could record audio without the audio notification being shown. This bug does not allow the attacker to bypass the permission prompt - it only affects the notification shown once permission has been granted.
*This bug only affects Firefox for Android. Other operating systems are unaffected.*. This vulnerability affects Firefox < 104.

When visiting a website with an overly long URL, the user interface would start to hang. Due to session restore, this could lead to a permanent Denial of Service.
*This bug only affects Firefox for Android. Other operating systems are unaffected.*. This vulnerability affects Firefox < 103.

When using the Performance API, an attacker was able to notice subtle differences between PerformanceEntries and thus learn whether the target URL had been subject to a redirect. This vulnerability affects Firefox < 103.

SVG <use> tags that referenced a same-origin document could have resulted in script execution if attacker input was sanitized via the HTML Sanitizer API. This would have required the attacker to reference a same-origin JavaScript file containing the script to be executed. This vulnerability affects Firefox < 102.

Even when an iframe was sandboxed with allow-top-navigation-by-user-activation, if it received a redirect header to an external protocol the browser would process the redirect and prompt the user as appropriate. This vulnerability affects Firefox < 102.

The HTML Sanitizer should have sanitized the href attribute of SVG <use> tags; however it incorrectly did not sanitize xlink:href attributes. This vulnerability affects Firefox < 102.

When downloading an update for an addon, the downloaded addon update's version was not verified to match the version selected from the manifest. If the manifest had been tampered with on the server, an attacker could trick the browser into downgrading the addon to a prior version. This vulnerability affects Firefox < 102.

Internal URLs are protected by a secret UUID key, which could have been leaked to web page through the Referrer header. This vulnerability affects Firefox for iOS < 102.

If array shift operations are not used, the Garbage Collector may have become confused about valid objects. This vulnerability affects Firefox < 101.

Firefox's HTML parser did not correctly interpret HTML comment tags, resulting in an incongruity with other browsers. This could have been used to escape HTML comments on pages that put user-controlled data in them. This vulnerability affects Firefox < 101.

The Performance API did not properly hide the fact whether a request cross-origin resource has observed redirects. This vulnerability affects Firefox < 100.

When closed or sent to the background, Firefox for Android would not properly record and persist HSTS settings.
*Note: This issue only affected Firefox for Android. Other operating systems are unaffected.*. This vulnerability affects Firefox < 100.

In unusual circumstances, selecting text could cause text selection caching to behave incorrectly, leading to a crash. This vulnerability affects Firefox < 99.

The sourceMapURL feature in devtools was missing security checks that would have allowed a webpage to attempt to include local files or other files that should have been inaccessible. This vulnerability affects Firefox < 99.