In the Linux kernel, the following vulnerability has been resolved:\nUSB: Gadget: core: Help prevent panic during UVC unconfigure\nAvichal Rakesh reported a kernel panic that occurred when the UVC\ngadget driver was removed from a gadget's configuration. The panic\ninvolves a somewhat complicated interaction between the kernel driver\nand a userspace component (as described in the Link tag below), but\nthe analysis did make one thing clear: The Gadget core should\naccomodate gadget drivers calling usb_gadget_deactivate() as part of\ntheir unbind procedure.\nCurrently this doesn't work. gadget_unbind_driver() calls\ndriver->unbind() while holding the udc->connect_lock mutex, and\nusb_gadget_deactivate() attempts to acquire that mutex, which will\nresult in a deadlock.\nThe simple fix is for gadget_unbind_driver() to release the mutex when\ninvoking the ->unbind() callback. There is no particular reason for\nit to be holding the mutex at that time, and the mutex isn't held\nwhile the ->bind() callback is invoked. So we'll drop the mutex\nbefore performing the unbind callback and reacquire it afterward.\nWe'll also add a couple of comments to usb_gadget_activate() and\nusb_gadget_deactivate(). Because they run in process context they\nmust not be called from a gadget driver's ->disconnect() callback,\nwhich (according to the kerneldoc for struct usb_gadget_driver in\ninclude/linux/usb/gadget.h) may run in interrupt context. This may\nhelp prevent similar bugs from arising in the future.

In the Linux kernel, the following vulnerability has been resolved:\ngpio: mvebu: fix irq domain leak\nUwe Kleine-König pointed out we still have one resource leak in the mvebu\ndriver triggered on driver detach. Let's address it with a custom devm\naction.

In the Linux kernel, the following vulnerability has been resolved:\nnet: qrtr: Fix an uninit variable access bug in qrtr_tx_resume()\nSyzbot reported a bug as following:\n=====================================================\nBUG: KMSAN: uninit-value in qrtr_tx_resume+0x185/0x1f0 net/qrtr/af_qrtr.c:230\nqrtr_tx_resume+0x185/0x1f0 net/qrtr/af_qrtr.c:230\nqrtr_endpoint_post+0xf85/0x11b0 net/qrtr/af_qrtr.c:519\nqrtr_tun_write_iter+0x270/0x400 net/qrtr/tun.c:108\ncall_write_iter include/linux/fs.h:2189 [inline]\naio_write+0x63a/0x950 fs/aio.c:1600\nio_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019\n__do_sys_io_submit fs/aio.c:2078 [inline]\n__se_sys_io_submit+0x293/0x770 fs/aio.c:2048\n__x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\nUninit was created at:\nslab_post_alloc_hook mm/slab.h:766 [inline]\nslab_alloc_node mm/slub.c:3452 [inline]\n__kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491\n__do_kmalloc_node mm/slab_common.c:967 [inline]\n__kmalloc_node_track_caller+0x114/0x3b0 mm/slab_common.c:988\nkmalloc_reserve net/core/skbuff.c:492 [inline]\n__alloc_skb+0x3af/0x8f0 net/core/skbuff.c:565\n__netdev_alloc_skb+0x120/0x7d0 net/core/skbuff.c:630\nqrtr_endpoint_post+0xbd/0x11b0 net/qrtr/af_qrtr.c:446\nqrtr_tun_write_iter+0x270/0x400 net/qrtr/tun.c:108\ncall_write_iter include/linux/fs.h:2189 [inline]\naio_write+0x63a/0x950 fs/aio.c:1600\nio_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019\n__do_sys_io_submit fs/aio.c:2078 [inline]\n__se_sys_io_submit+0x293/0x770 fs/aio.c:2048\n__x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\nIt is because that skb->len requires at least sizeof(struct qrtr_ctrl_pkt)\nin qrtr_tx_resume(). And skb->len equals to size in qrtr_endpoint_post().\nBut size is less than sizeof(struct qrtr_ctrl_pkt) when qrtr_cb->type\nequals to QRTR_TYPE_RESUME_TX in qrtr_endpoint_post() under the syzbot\nscenario. This triggers the uninit variable access bug.\nAdd size check when qrtr_cb->type equals to QRTR_TYPE_RESUME_TX in\nqrtr_endpoint_post() to fix the bug.

In the Linux kernel, the following vulnerability has been resolved:\nbpf, cpumap: Make sure kthread is running before map update returns\nThe following warning was reported when running stress-mode enabled\nxdp_redirect_cpu with some RT threads:\n------------[ cut here ]------------\nWARNING: CPU: 4 PID: 65 at kernel/bpf/cpumap.c:135\nCPU: 4 PID: 65 Comm: kworker/4:1 Not tainted 6.5.0-rc2+ #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996)\nWorkqueue: events cpu_map_kthread_stop\nRIP: 0010:put_cpu_map_entry+0xda/0x220\n......\nCall Trace:\n\n? show_regs+0x65/0x70\n? __warn+0xa5/0x240\n......\n? put_cpu_map_entry+0xda/0x220\ncpu_map_kthread_stop+0x41/0x60\nprocess_one_work+0x6b0/0xb80\nworker_thread+0x96/0x720\nkthread+0x1a5/0x1f0\nret_from_fork+0x3a/0x70\nret_from_fork_asm+0x1b/0x30\n\nThe root cause is the same as commit 436901649731 ("bpf: cpumap: Fix memory\nleak in cpu_map_update_elem"). The kthread is stopped prematurely by\nkthread_stop() in cpu_map_kthread_stop(), and kthread() doesn't call\ncpu_map_kthread_run() at all but XDP program has already queued some\nframes or skbs into ptr_ring. So when __cpu_map_ring_cleanup() checks\nthe ptr_ring, it will find it was not emptied and report a warning.\nAn alternative fix is to use __cpu_map_ring_cleanup() to drop these\npending frames or skbs when kthread_stop() returns -EINTR, but it may\nconfuse the user, because these frames or skbs have been handled\ncorrectly by XDP program. So instead of dropping these frames or skbs,\njust make sure the per-cpu kthread is running before\n__cpu_map_entry_alloc() returns.\nAfter apply the fix, the error handle for kthread_stop() will be\nunnecessary because it will always return 0, so just remove it.

In the Linux kernel, the following vulnerability has been resolved:\nnull_blk: Always check queue mode setting from configfs\nMake sure to check device queue mode in the null_validate_conf() and\nreturn error for NULL_Q_RQ as we don't allow legacy I/O path, without\nthis patch we get OOPs when queue mode is set to 1 from configfs,\nfollowing are repro steps :-\nmodprobe null_blk nr_devices=0\nmkdir config/nullb/nullb0\necho 1 > config/nullb/nullb0/memory_backed\necho 4096 > config/nullb/nullb0/blocksize\necho 20480 > config/nullb/nullb0/size\necho 1 > config/nullb/nullb0/queue_mode\necho 1 > config/nullb/nullb0/power\nEntering kdb (current=0xffff88810acdd080, pid 2372) on processor 42 Oops: (null)\ndue to oops @ 0xffffffffc041c329\nCPU: 42 PID: 2372 Comm: sh Tainted: G O N 6.3.0-rc5lblk+ #5\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014\nRIP: 0010:null_add_dev.part.0+0xd9/0x720 [null_blk]\nCode: 01 00 00 85 d2 0f 85 a1 03 00 00 48 83 bb 08 01 00 00 00 0f 85 f7 03 00 00 80 bb 62 01 00 00 00 48 8b 75 20 0f 85 6d 02 00 00 <48> 89 6e 60 48 8b 75 20 bf 06 00 00 00 e8 f5 37 2c c1 48 8b 75 20\nRSP: 0018:ffffc900052cbde0 EFLAGS: 00010246\nRAX: 0000000000000001 RBX: ffff88811084d800 RCX: 0000000000000001\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888100042e00\nRBP: ffff8881053d8200 R08: ffffc900052cbd68 R09: ffff888105db2000\nR10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000002\nR13: ffff888104765200 R14: ffff88810eec1748 R15: ffff88810eec1740\nFS: 00007fd445fd1740(0000) GS:ffff8897dfc80000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000060 CR3: 0000000166a00000 CR4: 0000000000350ee0\nDR0: ffffffff8437a488 DR1: ffffffff8437a489 DR2: ffffffff8437a48a\nDR3: ffffffff8437a48b DR6: 00000000ffff0ff0 DR7: 0000000000000400\nCall Trace:\n\nnullb_device_power_store+0xd1/0x120 [null_blk]\nconfigfs_write_iter+0xb4/0x120\nvfs_write+0x2ba/0x3c0\nksys_write+0x5f/0xe0\ndo_syscall_64+0x3b/0x90\nentry_SYSCALL_64_after_hwframe+0x72/0xdc\nRIP: 0033:0x7fd4460c57a7\nCode: 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24\nRSP: 002b:00007ffd3792a4a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fd4460c57a7\nRDX: 0000000000000002 RSI: 000055b43c02e4c0 RDI: 0000000000000001\nRBP: 000055b43c02e4c0 R08: 000000000000000a R09: 00007fd44615b4e0\nR10: 00007fd44615b3e0 R11: 0000000000000246 R12: 0000000000000002\nR13: 00007fd446198520 R14: 0000000000000002 R15: 00007fd446198700\n

In the Linux kernel, the following vulnerability has been resolved:\nwifi: iwlwifi: mvm: fix potential array out of bounds access\nAccount for IWL_SEC_WEP_KEY_OFFSET when needed while verifying\nkey_len size in iwl_mvm_sec_key_add().

In the Linux kernel, the following vulnerability has been resolved:\nwifi: rtw88: delete timer and free skb queue when unloading\nFix possible crash and memory leak on driver unload by deleting\nTX purge timer and freeing C2H queue in 'rtw_core_deinit()',\nshrink critical section in the latter by freeing COEX queue\nout of TX report lock scope.

In the Linux kernel, the following vulnerability has been resolved:\nclk: rs9: Fix suspend/resume\nDisabling the cache in commit 2ff4ba9e3702 ("clk: rs9: Fix I2C accessors")\nwithout removing cache synchronization in resume path results in a\nkernel panic as map->cache_ops is unset, due to REGCACHE_NONE.\nEnable flat cache again to support resume again. num_reg_defaults_raw\nis necessary to read the cache defaults from hardware. Some registers\nare strapped in hardware and cannot be provided in software.

In the Linux kernel, the following vulnerability has been resolved:\nclk: imx: scu: use _safe list iterator to avoid a use after free\nThis loop is freeing "clk" so it needs to use list_for_each_entry_safe().\nOtherwise it dereferences a freed variable to get the next item on the\nloop.

In the Linux kernel, the following vulnerability has been resolved:\ndrm/i915: Make intel_get_crtc_new_encoder() less oopsy\nThe point of the WARN was to print something, not oops\nstraight up. Currently that is precisely what happens\nif we can't find the connector for the crtc in the atomic\nstate. Get the dev pointer from the atomic state instead\nof the potentially NULL encoder to avoid that.\n(cherry picked from commit 3b6692357f70498f617ea1b31a0378070a0acf1c)

In the Linux kernel, the following vulnerability has been resolved:\nwifi: nl80211: fix integer overflow in nl80211_parse_mbssid_elems()\nnl80211_parse_mbssid_elems() uses a u8 variable num_elems to count the\nnumber of MBSSID elements in the nested netlink attribute attrs, which can\nlead to an integer overflow if a user of the nl80211 interface specifies\n256 or more elements in the corresponding attribute in userspace. The\ninteger overflow can lead to a heap buffer overflow as num_elems determines\nthe size of the trailing array in elems, and this array is thereafter\nwritten to for each element in attrs.\nNote that this vulnerability only affects devices with the\nwiphy->mbssid_max_interfaces member set for the wireless physical device\nstruct in the device driver, and can only be triggered by a process with\nCAP_NET_ADMIN capabilities.\nFix this by checking for a maximum of 255 elements in attrs.

In the Linux kernel, the following vulnerability has been resolved:\next2: Check block size validity during mount\nCheck that log of block size stored in the superblock has sensible\nvalue. Otherwise the shift computing the block size can overflow leading\nto undefined behavior.

In the Linux kernel, the following vulnerability has been resolved:\ns390/zcrypt: don't leak memory if dev_set_name() fails\nWhen dev_set_name() fails, zcdn_create() doesn't free the newly\nallocated resources. Do it.

In the Linux kernel, the following vulnerability has been resolved:\nspi: qup: Don't skip cleanup in remove's error path\nReturning early in a platform driver's remove callback is wrong. In this\ncase the dma resources are not released in the error path. this is never\nretried later and so this is a permanent leak. To fix this, only skip\nhardware disabling if waking the device fails.

In the Linux kernel, the following vulnerability has been resolved:\nnetfilter: nft_set_rbtree: fix null deref on element insertion\nThere is no guarantee that rb_prev() will not return NULL in nft_rbtree_gc_elem():\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN\nKASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]\nnft_add_set_elem+0x14b0/0x2990\nnf_tables_newsetelem+0x528/0xb30\nFurthermore, there is a possible use-after-free while iterating,\n'node' can be free'd so we need to cache the next value to use.

In the Linux kernel, the following vulnerability has been resolved:\nwifi: brcmfmac: Check for probe() id argument being NULL\nThe probe() id argument may be NULL in 2 scenarios:\n1. brcmf_pcie_pm_leave_D3() calling brcmf_pcie_probe() to reprobe\nthe device.\n2. If a user tries to manually bind the driver from sysfs then the sdio /\npcie / usb probe() function gets called with NULL as id argument.\n1. Is being hit by users causing the following oops on resume and causing\nwifi to stop working:\nBUG: kernel NULL pointer dereference, address: 0000000000000018\n\nHardware name: Dell Inc. XPS 13 9350/0PWNCR, BIDS 1.13.0 02/10/2020\nWorkgueue: events_unbound async_run_entry_fn\nRIP: 0010:brcmf_pcie_probe+Ox16b/0x7a0 [brcmfmac]\n\nCall Trace:\n\nbrcmf_pcie_pm_leave_D3+0xc5/8x1a0 [brcmfmac be3b4cefca451e190fa35be8f00db1bbec293887]\n? pci_pm_resume+0x5b/0xf0\n? pci_legacy_resume+0x80/0x80\ndpm_run_callback+0x47/0x150\ndevice_resume+0xa2/0x1f0\nasync_resume+0x1d/0x30\n\nFix this by checking for id being NULL.\nIn the PCI and USB cases try a manual lookup of the id so that manually\nbinding the driver through sysfs and more importantly brcmf_pcie_probe()\non resume will work.\nFor the SDIO case there is no helper to do a manual sdio_device_id lookup,\nso just directly error out on a NULL id there.

In the Linux kernel, the following vulnerability has been resolved:\nocfs2: fix defrag path triggering jbd2 ASSERT\ncode path:\nocfs2_ioctl_move_extents\nocfs2_move_extents\nocfs2_defrag_extent\n__ocfs2_move_extent\n+ ocfs2_journal_access_di\n+ ocfs2_split_extent //sub-paths call jbd2_journal_restart\n+ ocfs2_journal_dirty //crash by jbs2 ASSERT\ncrash stacks:\nPID: 11297 TASK: ffff974a676dcd00 CPU: 67 COMMAND: "defragfs.ocfs2"\n#0 [ffffb25d8dad3900] machine_kexec at ffffffff8386fe01\n#1 [ffffb25d8dad3958] __crash_kexec at ffffffff8395959d\n#2 [ffffb25d8dad3a20] crash_kexec at ffffffff8395a45d\n#3 [ffffb25d8dad3a38] oops_end at ffffffff83836d3f\n#4 [ffffb25d8dad3a58] do_trap at ffffffff83833205\n#5 [ffffb25d8dad3aa0] do_invalid_op at ffffffff83833aa6\n#6 [ffffb25d8dad3ac0] invalid_op at ffffffff84200d18\n[exception RIP: jbd2_journal_dirty_metadata+0x2ba]\nRIP: ffffffffc09ca54a RSP: ffffb25d8dad3b70 RFLAGS: 00010207\nRAX: 0000000000000000 RBX: ffff9706eedc5248 RCX: 0000000000000000\nRDX: 0000000000000001 RSI: ffff97337029ea28 RDI: ffff9706eedc5250\nRBP: ffff9703c3520200 R8: 000000000f46b0b2 R9: 0000000000000000\nR10: 0000000000000001 R11: 00000001000000fe R12: ffff97337029ea28\nR13: 0000000000000000 R14: ffff9703de59bf60 R15: ffff9706eedc5250\nORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018\n#7 [ffffb25d8dad3ba8] ocfs2_journal_dirty at ffffffffc137fb95 [ocfs2]\n#8 [ffffb25d8dad3be8] __ocfs2_move_extent at ffffffffc139a950 [ocfs2]\n#9 [ffffb25d8dad3c80] ocfs2_defrag_extent at ffffffffc139b2d2 [ocfs2]\nAnalysis\nThis bug has the same root cause of 'commit 7f27ec978b0e ("ocfs2: call\nocfs2_journal_access_di() before ocfs2_journal_dirty() in\nocfs2_write_end_nolock()")'. For this bug, jbd2_journal_restart() is\ncalled by ocfs2_split_extent() during defragmenting.\nHow to fix\nFor ocfs2_split_extent() can handle journal operations totally by itself. \nCaller doesn't need to call journal access/dirty pair, and caller only\nneeds to call journal start/stop pair. The fix method is to remove\njournal access/dirty from __ocfs2_move_extent().\nThe discussion for this patch:\nhttps://oss.oracle.com/pipermail/ocfs2-devel/2023-February/000647.html

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\ndrm/msm: fix vram leak on bind errors\nMake sure to release the VRAM buffer also in a case a subcomponent fails\nto bind.\nPatchwork: https://patchwork.freedesktop.org/patch/525094/

In the Linux kernel, the following vulnerability has been resolved:\nnet: wwan: iosm: fix NULL pointer dereference when removing device\nIn suspend and resume cycle, the removal and rescan of device ends\nup in NULL pointer dereference.\nDuring driver initialization, if the ipc_imem_wwan_channel_init()\nfails to get the valid device capabilities it returns an error and\nfurther no resource (wwan struct) will be allocated. Now in this\nsituation if driver removal procedure is initiated it would result\nin NULL pointer exception since unallocated wwan struct is dereferenced\ninside ipc_wwan_deinit().\nipc_imem_run_state_worker() to handle the called functions return value\nand to release the resource in failure case. It also reports the link\ndown event in failure cases. The user space application can handle this\nevent to do a device reset for restoring the device communication.

In the Linux kernel, the following vulnerability has been resolved:\ntracing/histograms: Add histograms to hist_vars if they have referenced variables\nHist triggers can have referenced variables without having direct\nvariables fields. This can be the case if referenced variables are added\nfor trigger actions. In this case the newly added references will not\nhave field variables. Not taking such referenced variables into\nconsideration can result in a bug where it would be possible to remove\nhist trigger with variables being refenced. This will result in a bug\nthat is easily reproducable like so\n$ cd /sys/kernel/tracing\n$ echo 'synthetic_sys_enter char[] comm; long id' >> synthetic_events\n$ echo 'hist:keys=common_pid.execname,id.syscall:vals=hitcount:comm=common_pid.execname' >> events/raw_syscalls/sys_enter/trigger\n$ echo 'hist:keys=common_pid.execname,id.syscall:onmatch(raw_syscalls.sys_enter).synthetic_sys_enter($comm, id)' >> events/raw_syscalls/sys_enter/trigger\n$ echo '!hist:keys=common_pid.execname,id.syscall:vals=hitcount:comm=common_pid.execname' >> events/raw_syscalls/sys_enter/trigger\n[ 100.263533] ==================================================================\n[ 100.264634] BUG: KASAN: slab-use-after-free in resolve_var_refs+0xc7/0x180\n[ 100.265520] Read of size 8 at addr ffff88810375d0f0 by task bash/439\n[ 100.266320]\n[ 100.266533] CPU: 2 PID: 439 Comm: bash Not tainted 6.5.0-rc1 #4\n[ 100.267277] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-20220807_005459-localhost 04/01/2014\n[ 100.268561] Call Trace:\n[ 100.268902] \n[ 100.269189] dump_stack_lvl+0x4c/0x70\n[ 100.269680] print_report+0xc5/0x600\n[ 100.270165] ? resolve_var_refs+0xc7/0x180\n[ 100.270697] ? kasan_complete_mode_report_info+0x80/0x1f0\n[ 100.271389] ? resolve_var_refs+0xc7/0x180\n[ 100.271913] kasan_report+0xbd/0x100\n[ 100.272380] ? resolve_var_refs+0xc7/0x180\n[ 100.272920] __asan_load8+0x71/0xa0\n[ 100.273377] resolve_var_refs+0xc7/0x180\n[ 100.273888] event_hist_trigger+0x749/0x860\n[ 100.274505] ? kasan_save_stack+0x2a/0x50\n[ 100.275024] ? kasan_set_track+0x29/0x40\n[ 100.275536] ? __pfx_event_hist_trigger+0x10/0x10\n[ 100.276138] ? ksys_write+0xd1/0x170\n[ 100.276607] ? do_syscall_64+0x3c/0x90\n[ 100.277099] ? entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n[ 100.277771] ? destroy_hist_data+0x446/0x470\n[ 100.278324] ? event_hist_trigger_parse+0xa6c/0x3860\n[ 100.278962] ? __pfx_event_hist_trigger_parse+0x10/0x10\n[ 100.279627] ? __kasan_check_write+0x18/0x20\n[ 100.280177] ? mutex_unlock+0x85/0xd0\n[ 100.280660] ? __pfx_mutex_unlock+0x10/0x10\n[ 100.281200] ? kfree+0x7b/0x120\n[ 100.281619] ? ____kasan_slab_free+0x15d/0x1d0\n[ 100.282197] ? event_trigger_write+0xac/0x100\n[ 100.282764] ? __kasan_slab_free+0x16/0x20\n[ 100.283293] ? __kmem_cache_free+0x153/0x2f0\n[ 100.283844] ? sched_mm_cid_remote_clear+0xb1/0x250\n[ 100.284550] ? __pfx_sched_mm_cid_remote_clear+0x10/0x10\n[ 100.285221] ? event_trigger_write+0xbc/0x100\n[ 100.285781] ? __kasan_check_read+0x15/0x20\n[ 100.286321] ? __bitmap_weight+0x66/0xa0\n[ 100.286833] ? _find_next_bit+0x46/0xe0\n[ 100.287334] ? task_mm_cid_work+0x37f/0x450\n[ 100.287872] event_triggers_call+0x84/0x150\n[ 100.288408] trace_event_buffer_commit+0x339/0x430\n[ 100.289073] ? ring_buffer_event_data+0x3f/0x60\n[ 100.292189] trace_event_raw_event_sys_enter+0x8b/0xe0\n[ 100.295434] syscall_trace_enter.constprop.0+0x18f/0x1b0\n[ 100.298653] syscall_enter_from_user_mode+0x32/0x40\n[ 100.301808] do_syscall_64+0x1a/0x90\n[ 100.304748] entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n[ 100.307775] RIP: 0033:0x7f686c75c1cb\n[ 100.310617] Code: 73 01 c3 48 8b 0d 65 3c 10 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 21 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 35 3c 10 00 f7 d8 64 89 01 48\n[ 100.317847] RSP: 002b:00007ffc60137a38 EFLAGS: 00000246 ORIG_RAX: 0000000000000021\n[ 100.321200] RA\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\nip_vti: fix potential slab-use-after-free in decode_session6\nWhen ip_vti device is set to the qdisc of the sfb type, the cb field\nof the sent skb may be modified during enqueuing. Then,\nslab-use-after-free may occur when ip_vti device sends IPv6 packets.\nAs commit f855691975bb ("xfrm6: Fix the nexthdr offset in\n_decode_session6.") showed, xfrm_decode_session was originally intended\nonly for the receive path. IP6CB(skb)->nhoff is not set during\ntransmission. Therefore, set the cb field in the skb to 0 before\nsending packets.

In the Linux kernel, the following vulnerability has been resolved:\nrcu-tasks: Avoid pr_info() with spin lock in cblist_init_generic()\npr_info() is called with rtp->cbs_gbl_lock spin lock locked. Because\npr_info() calls printk() that might sleep, this will result in BUG\nlike below:\n[ 0.206455] cblist_init_generic: Setting adjustable number of callback queues.\n[ 0.206463]\n[ 0.206464] =============================\n[ 0.206464] [ BUG: Invalid wait context ]\n[ 0.206465] 5.19.0-00428-g9de1f9c8ca51 #5 Not tainted\n[ 0.206466] -----------------------------\n[ 0.206466] swapper/0/1 is trying to lock:\n[ 0.206467] ffffffffa0167a58 (&port_lock_key){....}-{3:3}, at: serial8250_console_write+0x327/0x4a0\n[ 0.206473] other info that might help us debug this:\n[ 0.206473] context-{5:5}\n[ 0.206474] 3 locks held by swapper/0/1:\n[ 0.206474] #0: ffffffff9eb597e0 (rcu_tasks.cbs_gbl_lock){....}-{2:2}, at: cblist_init_generic.constprop.0+0x14/0x1f0\n[ 0.206478] #1: ffffffff9eb579c0 (console_lock){+.+.}-{0:0}, at: _printk+0x63/0x7e\n[ 0.206482] #2: ffffffff9ea77780 (console_owner){....}-{0:0}, at: console_emit_next_record.constprop.0+0x111/0x330\n[ 0.206485] stack backtrace:\n[ 0.206486] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-00428-g9de1f9c8ca51 #5\n[ 0.206488] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014\n[ 0.206489] Call Trace:\n[ 0.206490] \n[ 0.206491] dump_stack_lvl+0x6a/0x9f\n[ 0.206493] __lock_acquire.cold+0x2d7/0x2fe\n[ 0.206496] ? stack_trace_save+0x46/0x70\n[ 0.206497] lock_acquire+0xd1/0x2f0\n[ 0.206499] ? serial8250_console_write+0x327/0x4a0\n[ 0.206500] ? __lock_acquire+0x5c7/0x2720\n[ 0.206502] _raw_spin_lock_irqsave+0x3d/0x90\n[ 0.206504] ? serial8250_console_write+0x327/0x4a0\n[ 0.206506] serial8250_console_write+0x327/0x4a0\n[ 0.206508] console_emit_next_record.constprop.0+0x180/0x330\n[ 0.206511] console_unlock+0xf7/0x1f0\n[ 0.206512] vprintk_emit+0xf7/0x330\n[ 0.206514] _printk+0x63/0x7e\n[ 0.206516] cblist_init_generic.constprop.0.cold+0x24/0x32\n[ 0.206518] rcu_init_tasks_generic+0x5/0xd9\n[ 0.206522] kernel_init_freeable+0x15b/0x2a2\n[ 0.206523] ? rest_init+0x160/0x160\n[ 0.206526] kernel_init+0x11/0x120\n[ 0.206527] ret_from_fork+0x1f/0x30\n[ 0.206530] \n[ 0.207018] cblist_init_generic: Setting shift to 1 and lim to 1.\nThis patch moves pr_info() so that it is called without\nrtp->cbs_gbl_lock locked.

In the Linux kernel, the following vulnerability has been resolved:\nfprobe: Release rethook after the ftrace_ops is unregistered\nWhile running bpf selftests it's possible to get following fault:\ngeneral protection fault, probably for non-canonical address \\\n0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC NOPTI\n...\nCall Trace:\n\nfprobe_handler+0xc1/0x270\n? __pfx_bpf_testmod_init+0x10/0x10\n? __pfx_bpf_testmod_init+0x10/0x10\n? bpf_fentry_test1+0x5/0x10\n? bpf_fentry_test1+0x5/0x10\n? bpf_testmod_init+0x22/0x80\n? do_one_initcall+0x63/0x2e0\n? rcu_is_watching+0xd/0x40\n? kmalloc_trace+0xaf/0xc0\n? do_init_module+0x60/0x250\n? __do_sys_finit_module+0xac/0x120\n? do_syscall_64+0x37/0x90\n? entry_SYSCALL_64_after_hwframe+0x72/0xdc\n\nIn unregister_fprobe function we can't release fp->rethook while it's\npossible there are some of its users still running on another cpu.\nMoving rethook_free call after fp->ops is unregistered with\nunregister_ftrace_function call.

In the Linux kernel, the following vulnerability has been resolved:\n\niavf: Fix use-after-free in free_netdev\n\nWe do netif_napi_add() for all allocated q_vectors[], but potentially\ndo netif_napi_del() for part of them, then kfree q_vectors and leave\ninvalid pointers at dev->napi_list.\n\nReproducer:\n\n [root@host ~]# cat repro.sh\n #!/bin/bash\n\n pf_dbsf="0000:41:00.0"\n vf0_dbsf="0000:41:02.0"\n g_pids=()\n\n function do_set_numvf()\n {\n echo 2 >/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs\n sleep $((RANDOM%3+1))\n echo 0 >/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs\n sleep $((RANDOM%3+1))\n }\n\n function do_set_channel()\n {\n local nic=$(ls -1 --indicator-style=none /sys/bus/pci/devices/${vf0_dbsf}/net/)\n [ -z "$nic" ] && { sleep $((RANDOM%3)) ; return 1; }\n ifconfig $nic 192.168.18.5 netmask 255.255.255.0\n ifconfig $nic up\n ethtool -L $nic combined 1\n ethtool -L $nic combined 4\n sleep $((RANDOM%3))\n }\n\n function on_exit()\n {\n local pid\n for pid in "${g_pids[@]}"; do\n kill -0 "$pid" &>/dev/null && kill "$pid" &>/dev/null\n done\n g_pids=()\n }\n\n trap "on_exit; exit" EXIT\n\n while :; do do_set_numvf ; done &\n g_pids+=($!)\n while :; do do_set_channel ; done &\n g_pids+=($!)\n\n wait\n\nResult:\n\n[ 4093.900222] ==================================================================\n[ 4093.900230] BUG: KASAN: use-after-free in free_netdev+0x308/0x390\n[ 4093.900232] Read of size 8 at addr ffff88b4dc145640 by task repro.sh/6699\n[ 4093.900233]\n[ 4093.900236] CPU: 10 PID: 6699 Comm: repro.sh Kdump: loaded Tainted: G O --------- -t - 4.18.0 #1\n[ 4093.900238] Hardware name: Powerleader PR2008AL/H12DSi-N6, BIOS 2.0 04/09/2021\n[ 4093.900239] Call Trace:\n[ 4093.900244] dump_stack+0x71/0xab\n[ 4093.900249] print_address_description+0x6b/0x290\n[ 4093.900251] ? free_netdev+0x308/0x390\n[ 4093.900252] kasan_report+0x14a/0x2b0\n[ 4093.900254] free_netdev+0x308/0x390\n[ 4093.900261] iavf_remove+0x825/0xd20 [iavf]\n[ 4093.900265] pci_device_remove+0xa8/0x1f0\n[ 4093.900268] device_release_driver_internal+0x1c6/0x460\n[ 4093.900271] pci_stop_bus_device+0x101/0x150\n[ 4093.900273] pci_stop_and_remove_bus_device+0xe/0x20\n[ 4093.900275] pci_iov_remove_virtfn+0x187/0x420\n[ 4093.900277] ? pci_iov_add_virtfn+0xe10/0xe10\n[ 4093.900278] ? pci_get_subsys+0x90/0x90\n[ 4093.900280] sriov_disable+0xed/0x3e0\n[ 4093.900282] ? bus_find_device+0x12d/0x1a0\n[ 4093.900290] i40e_free_vfs+0x754/0x1210 [i40e]\n[ 4093.900298] ? i40e_reset_all_vfs+0x880/0x880 [i40e]\n[ 4093.900299] ? pci_get_device+0x7c/0x90\n[ 4093.900300] ? pci_get_subsys+0x90/0x90\n[ 4093.900306] ? pci_vfs_assigned.part.7+0x144/0x210\n[ 4093.900309] ? __mutex_lock_slowpath+0x10/0x10\n[ 4093.900315] i40e_pci_sriov_configure+0x1fa/0x2e0 [i40e]\n[ 4093.900318] sriov_numvfs_store+0x214/0x290\n[ 4093.900320] ? sriov_totalvfs_show+0x30/0x30\n[ 4093.900321] ? __mutex_lock_slowpath+0x10/0x10\n[ 4093.900323] ? __check_object_size+0x15a/0x350\n[ 4093.900326] kernfs_fop_write+0x280/0x3f0\n[ 4093.900329] vfs_write+0x145/0x440\n[ 4093.900330] ksys_write+0xab/0x160\n[ 4093.900332] ? __ia32_sys_read+0xb0/0xb0\n[ 4093.900334] ? fput_many+0x1a/0x120\n[ 4093.900335] ? filp_close+0xf0/0x130\n[ 4093.900338] do_syscall_64+0xa0/0x370\n[ 4093.900339] ? page_fault+0x8/0x30\n[ 4093.900341] entry_SYSCALL_64_after_hwframe+0x65/0xca\n[ 4093.900357] RIP: 0033:0x7f16ad4d22c0\n[ 4093.900359] Code: 73 01 c3 48 8b 0d d8 cb 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 89 24 2d 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 fe dd 01 00 48 89 04 24\n[ 4093.900360] RSP: 002b:00007ffd6491b7f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\n[ 4093.900362] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f16ad4d22c0\n[ 4093.900363] RDX: 0000000000000002 RSI: 0000000001a41408 RDI: 0000000000000001\n[ 4093.900364] RBP: 0000000001a41408 R08: 00007f16ad7a1780 R09: 00007f16ae1f2700\n[ 4093.9003\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\nmm/damon/core: initialize damo_filter->list from damos_new_filter()\ndamos_new_filter() is not initializing the list field of newly allocated\nfilter object. However, DAMON sysfs interface and DAMON_RECLAIM are not\ninitializing it after calling damos_new_filter(). As a result, accessing\nuninitialized memory is possible. Actually, adding multiple DAMOS filters\nvia DAMON sysfs interface caused NULL pointer dereferencing. Initialize\nthe field just after the allocation from damos_new_filter().

In the Linux kernel, the following vulnerability has been resolved:\nstaging: ks7010: potential buffer overflow in ks_wlan_set_encode_ext()\nThe "exc->key_len" is a u16 that comes from the user. If it's over\nIW_ENCODING_TOKEN_MAX (64) that could lead to memory corruption.

In the Linux kernel, the following vulnerability has been resolved:\ndrm/i915: mark requests for GuC virtual engines to avoid use-after-free\nReferences to i915_requests may be trapped by userspace inside a\nsync_file or dmabuf (dma-resv) and held indefinitely across different\nproceses. To counter-act the memory leaks, we try to not to keep\nreferences from the request past their completion.\nOn the other side on fence release we need to know if rq->engine\nis valid and points to hw engine (true for non-virtual requests).\nTo make it possible extra bit has been added to rq->execution_mask,\nfor marking virtual engines.\n(cherry picked from commit 280410677af763f3871b93e794a199cfcf6fb580)

In the Linux kernel, the following vulnerability has been resolved:\nusb: gadget: u_serial: Add null pointer check in gserial_resume\nConsider a case where gserial_disconnect has already cleared\ngser->ioport. And if a wakeup interrupt triggers afterwards,\ngserial_resume gets called, which will lead to accessing of\ngser->ioport and thus causing null pointer dereference.Add\na null pointer check to prevent this.\nAdded a static spinlock to prevent gser->ioport from becoming\nnull after the newly added check.

In the Linux kernel, the following vulnerability has been resolved:\ncpufreq: amd-pstate: fix global sysfs attribute type\nIn commit 3666062b87ec ("cpufreq: amd-pstate: move to use bus_get_dev_root()")\nthe "amd_pstate" attributes where moved from a dedicated kobject to the\ncpu root kobject.\nWhile the dedicated kobject expects to contain kobj_attributes the root\nkobject needs device_attributes.\nAs the changed arguments are not used by the callbacks it works most of\nthe time.\nHowever CFI will detect this issue:\n[ 4947.849350] CFI failure at dev_attr_show+0x24/0x60 (target: show_status+0x0/0x70; expected type: 0x8651b1de)\n...\n[ 4947.849409] Call Trace:\n[ 4947.849410] \n[ 4947.849411] ? __warn+0xcf/0x1c0\n[ 4947.849414] ? dev_attr_show+0x24/0x60\n[ 4947.849415] ? report_cfi_failure+0x4e/0x60\n[ 4947.849417] ? handle_cfi_failure+0x14c/0x1d0\n[ 4947.849419] ? __cfi_show_status+0x10/0x10\n[ 4947.849420] ? handle_bug+0x4f/0x90\n[ 4947.849421] ? exc_invalid_op+0x1a/0x60\n[ 4947.849422] ? asm_exc_invalid_op+0x1a/0x20\n[ 4947.849424] ? __cfi_show_status+0x10/0x10\n[ 4947.849425] ? dev_attr_show+0x24/0x60\n[ 4947.849426] sysfs_kf_seq_show+0xa6/0x110\n[ 4947.849433] seq_read_iter+0x16c/0x4b0\n[ 4947.849436] vfs_read+0x272/0x2d0\n[ 4947.849438] ksys_read+0x72/0xe0\n[ 4947.849439] do_syscall_64+0x76/0xb0\n[ 4947.849440] ? do_user_addr_fault+0x252/0x650\n[ 4947.849442] ? exc_page_fault+0x7a/0x1b0\n[ 4947.849443] entry_SYSCALL_64_after_hwframe+0x72/0xdc

In the Linux kernel, the following vulnerability has been resolved:\nnetfilter: ipset: Rework long task execution when adding/deleting entries\nWhen adding/deleting large number of elements in one step in ipset, it can\ntake a reasonable amount of time and can result in soft lockup errors. The\npatch 5f7b51bf09ba ("netfilter: ipset: Limit the maximal range of\nconsecutive elements to add/delete") tried to fix it by limiting the max\nelements to process at all. However it was not enough, it is still possible\nthat we get hung tasks. Lowering the limit is not reasonable, so the\napproach in this patch is as follows: rely on the method used at resizing\nsets and save the state when we reach a smaller internal batch limit,\nunlock/lock and proceed from the saved state. Thus we can avoid long\ncontinuous tasks and at the same time removed the limit to add/delete large\nnumber of elements in one step.\nThe nfnl mutex is held during the whole operation which prevents one to\nissue other ipset commands in parallel.

In the Linux kernel, the following vulnerability has been resolved:\nnet: usbnet: Fix WARNING in usbnet_start_xmit/usb_submit_urb\nThe syzbot fuzzer identified a problem in the usbnet driver:\nusb 1-1: BOGUS urb xfer, pipe 3 != type 1\nWARNING: CPU: 0 PID: 754 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504\nModules linked in:\nCPU: 0 PID: 754 Comm: kworker/0:2 Not tainted 6.4.0-rc7-syzkaller-00014-g692b7dc87ca6 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023\nWorkqueue: mld mld_ifc_work\nRIP: 0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504\nCode: 7c 24 18 e8 2c b4 5b fb 48 8b 7c 24 18 e8 42 07 f0 fe 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 a0 c9 fc 8a e8 5a 6f 23 fb <0f> 0b e9 58 f8 ff ff e8 fe b3 5b fb 48 81 c5 c0 05 00 00 e9 84 f7\nRSP: 0018:ffffc9000463f568 EFLAGS: 00010086\nRAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000\nRDX: ffff88801eb28000 RSI: ffffffff814c03b7 RDI: 0000000000000001\nRBP: ffff8881443b7190 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000003\nR13: ffff88802a77cb18 R14: 0000000000000003 R15: ffff888018262500\nFS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000556a99c15a18 CR3: 0000000028c71000 CR4: 0000000000350ef0\nCall Trace:\n\nusbnet_start_xmit+0xfe5/0x2190 drivers/net/usb/usbnet.c:1453\n__netdev_start_xmit include/linux/netdevice.h:4918 [inline]\nnetdev_start_xmit include/linux/netdevice.h:4932 [inline]\nxmit_one net/core/dev.c:3578 [inline]\ndev_hard_start_xmit+0x187/0x700 net/core/dev.c:3594\n...\nThis bug is caused by the fact that usbnet trusts the bulk endpoint\naddresses its probe routine receives in the driver_info structure, and\nit does not check to see that these endpoints actually exist and have\nthe expected type and directions.\nThe fix is simply to add such a check.

In the Linux kernel, the following vulnerability has been resolved:\ndrm/amdgpu: Fix sdma v4 sw fini error\nFix sdma v4 sw fini error for sdma 4.2.2 to\nsolve the following general protection fault\n[ +0.108196] general protection fault, probably for non-canonical\naddress 0xd5e5a4ae79d24a32: 0000 [#1] PREEMPT SMP PTI\n[ +0.000018] RIP: 0010:free_fw_priv+0xd/0x70\n[ +0.000022] Call Trace:\n[ +0.000012] \n[ +0.000011] release_firmware+0x55/0x80\n[ +0.000021] amdgpu_ucode_release+0x11/0x20 [amdgpu]\n[ +0.000415] amdgpu_sdma_destroy_inst_ctx+0x4f/0x90 [amdgpu]\n[ +0.000360] sdma_v4_0_sw_fini+0xce/0x110 [amdgpu]

In the Linux kernel, the following vulnerability has been resolved:\nnet/mlx5: DR, fix memory leak in mlx5dr_cmd_create_reformat_ctx\nwhen mlx5_cmd_exec failed in mlx5dr_cmd_create_reformat_ctx, the memory\npointed by 'in' is not released, which will cause memory leak. Move memory\nrelease after mlx5_cmd_exec.

In the Linux kernel, the following vulnerability has been resolved:\ndrm/amdgpu: unmap and remove csa_va properly\nRoot PD BO should be reserved before unmap and remove\na bo_va from VM otherwise lockdep will complain.\nv2: check fpriv->csa_va is not NULL instead of amdgpu_mcbp (christian)\n[14616.936827] WARNING: CPU: 6 PID: 1711 at drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1762 amdgpu_vm_bo_del+0x399/0x3f0 [amdgpu]\n[14616.937096] Call Trace:\n[14616.937097] \n[14616.937102] amdgpu_driver_postclose_kms+0x249/0x2f0 [amdgpu]\n[14616.937187] drm_file_free+0x1d6/0x300 [drm]\n[14616.937207] drm_close_helper.isra.0+0x62/0x70 [drm]\n[14616.937220] drm_release+0x5e/0x100 [drm]\n[14616.937234] __fput+0x9f/0x280\n[14616.937239] ____fput+0xe/0x20\n[14616.937241] task_work_run+0x61/0x90\n[14616.937246] exit_to_user_mode_prepare+0x215/0x220\n[14616.937251] syscall_exit_to_user_mode+0x2a/0x60\n[14616.937254] do_syscall_64+0x48/0x90\n[14616.937257] entry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:\ncpufreq: davinci: Fix clk use after free\nThe remove function first frees the clks and only then calls\ncpufreq_unregister_driver(). If one of the cpufreq callbacks is called\njust before cpufreq_unregister_driver() is run, the freed clks might be\nused.

In the Linux kernel, the following vulnerability has been resolved:\nARM: dts: exynos: Use Exynos5420 compatible for the MIPI video phy\nFor some reason, the driver adding support for Exynos5420 MIPI phy\nback in 2016 wasn't used on Exynos5420, which caused a kernel panic.\nAdd the proper compatible for it.

In the Linux kernel, the following vulnerability has been resolved:\nmtd: rawnand: brcmnand: Fix potential out-of-bounds access in oob write\nWhen the oob buffer length is not in multiple of words, the oob write\nfunction does out-of-bounds read on the oob source buffer at the last\niteration. Fix that by always checking length limit on the oob buffer\nread and fill with 0xff when reaching the end of the buffer to the oob\nregisters.

In the Linux kernel, the following vulnerability has been resolved:\nwifi: cfg80211: reject auth/assoc to AP with our address\nIf the AP uses our own address as its MLD address or BSSID, then\nclearly something's wrong. Reject such connections so we don't\ntry and fail later.

In the Linux kernel, the following vulnerability has been resolved:\nRDMA/rxe: Fix incomplete state save in rxe_requester\nIf a send packet is dropped by the IP layer in rxe_requester()\nthe call to rxe_xmit_packet() can fail with err == -EAGAIN.\nTo recover, the state of the wqe is restored to the state before\nthe packet was sent so it can be resent. However, the routines\nthat save and restore the state miss a significnt part of the\nvariable state in the wqe, the dma struct which is used to process\nthrough the sge table. And, the state is not saved before the packet\nis built which modifies the dma struct.\nUnder heavy stress testing with many QPs on a fast node sending\nlarge messages to a slow node dropped packets are observed and\nthe resent packets are corrupted because the dma struct was not\nrestored. This patch fixes this behavior and allows the test cases\nto succeed.

In the Linux kernel, the following vulnerability has been resolved:\nbtrfs: insert tree mod log move in push_node_left\nThere is a fairly unlikely race condition in tree mod log rewind that\ncan result in a kernel panic which has the following trace:\n[530.569] BTRFS critical (device sda3): unable to find logical 0 length 4096\n[530.585] BTRFS critical (device sda3): unable to find logical 0 length 4096\n[530.602] BUG: kernel NULL pointer dereference, address: 0000000000000002\n[530.618] #PF: supervisor read access in kernel mode\n[530.629] #PF: error_code(0x0000) - not-present page\n[530.641] PGD 0 P4D 0\n[530.647] Oops: 0000 [#1] SMP\n[530.654] CPU: 30 PID: 398973 Comm: below Kdump: loaded Tainted: G S O K 5.12.0-0_fbk13_clang_7455_gb24de3bdb045 #1\n[530.680] Hardware name: Quanta Mono Lake-M.2 SATA 1HY9U9Z001G/Mono Lake-M.2 SATA, BIOS F20_3A15 08/16/2017\n[530.703] RIP: 0010:__btrfs_map_block+0xaa/0xd00\n[530.755] RSP: 0018:ffffc9002c2f7600 EFLAGS: 00010246\n[530.767] RAX: ffffffffffffffea RBX: ffff888292e41000 RCX: f2702d8b8be15100\n[530.784] RDX: ffff88885fda6fb8 RSI: ffff88885fd973c8 RDI: ffff88885fd973c8\n[530.800] RBP: ffff888292e410d0 R08: ffffffff82fd7fd0 R09: 00000000fffeffff\n[530.816] R10: ffffffff82e57fd0 R11: ffffffff82e57d70 R12: 0000000000000000\n[530.832] R13: 0000000000001000 R14: 0000000000001000 R15: ffffc9002c2f76f0\n[530.848] FS: 00007f38d64af000(0000) GS:ffff88885fd80000(0000) knlGS:0000000000000000\n[530.866] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[530.880] CR2: 0000000000000002 CR3: 00000002b6770004 CR4: 00000000003706e0\n[530.896] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[530.912] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[530.928] Call Trace:\n[530.934] ? btrfs_printk+0x13b/0x18c\n[530.943] ? btrfs_bio_counter_inc_blocked+0x3d/0x130\n[530.955] btrfs_map_bio+0x75/0x330\n[530.963] ? kmem_cache_alloc+0x12a/0x2d0\n[530.973] ? btrfs_submit_metadata_bio+0x63/0x100\n[530.984] btrfs_submit_metadata_bio+0xa4/0x100\n[530.995] submit_extent_page+0x30f/0x360\n[531.004] read_extent_buffer_pages+0x49e/0x6d0\n[531.015] ? submit_extent_page+0x360/0x360\n[531.025] btree_read_extent_buffer_pages+0x5f/0x150\n[531.037] read_tree_block+0x37/0x60\n[531.046] read_block_for_search+0x18b/0x410\n[531.056] btrfs_search_old_slot+0x198/0x2f0\n[531.066] resolve_indirect_ref+0xfe/0x6f0\n[531.076] ? ulist_alloc+0x31/0x60\n[531.084] ? kmem_cache_alloc_trace+0x12e/0x2b0\n[531.095] find_parent_nodes+0x720/0x1830\n[531.105] ? ulist_alloc+0x10/0x60\n[531.113] iterate_extent_inodes+0xea/0x370\n[531.123] ? btrfs_previous_extent_item+0x8f/0x110\n[531.134] ? btrfs_search_path_in_tree+0x240/0x240\n[531.146] iterate_inodes_from_logical+0x98/0xd0\n[531.157] ? btrfs_search_path_in_tree+0x240/0x240\n[531.168] btrfs_ioctl_logical_to_ino+0xd9/0x180\n[531.179] btrfs_ioctl+0xe2/0x2eb0\nThis occurs when logical inode resolution takes a tree mod log sequence\nnumber, and then while backref walking hits a rewind on a busy node\nwhich has the following sequence of tree mod log operations (numbers\nfilled in from a specific example, but they are somewhat arbitrary)\nREMOVE_WHILE_FREEING slot 532\nREMOVE_WHILE_FREEING slot 531\nREMOVE_WHILE_FREEING slot 530\n...\nREMOVE_WHILE_FREEING slot 0\nREMOVE slot 455\nREMOVE slot 454\nREMOVE slot 453\n...\nREMOVE slot 0\nADD slot 455\nADD slot 454\nADD slot 453\n...\nADD slot 0\nMOVE src slot 0 -> dst slot 456 nritems 533\nREMOVE slot 455\nREMOVE slot 454\nREMOVE slot 453\n...\nREMOVE slot 0\nWhen this sequence gets applied via btrfs_tree_mod_log_rewind, it\nallocates a fresh rewind eb, and first inserts the correct key info for\nthe 533 elements, then overwrites the first 456 of them, then decrements\nthe count by 456 via the add ops, then rewinds the move by doing a\nmemmove from 456:988->0:532. We have never written anything past 532,\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\nf2fs: fix to avoid use-after-free for cached IPU bio\nxfstest generic/019 reports a bug:\nkernel BUG at mm/filemap.c:1619!\nRIP: 0010:folio_end_writeback+0x8a/0x90\nCall Trace:\nend_page_writeback+0x1c/0x60\nf2fs_write_end_io+0x199/0x420\nbio_endio+0x104/0x180\nsubmit_bio_noacct+0xa5/0x510\nsubmit_bio+0x48/0x80\nf2fs_submit_write_bio+0x35/0x300\nf2fs_submit_merged_ipu_write+0x2a0/0x2b0\nf2fs_write_single_data_page+0x838/0x8b0\nf2fs_write_cache_pages+0x379/0xa30\nf2fs_write_data_pages+0x30c/0x340\ndo_writepages+0xd8/0x1b0\n__writeback_single_inode+0x44/0x370\nwriteback_sb_inodes+0x233/0x4d0\n__writeback_inodes_wb+0x56/0xf0\nwb_writeback+0x1dd/0x2d0\nwb_workfn+0x367/0x4a0\nprocess_one_work+0x21d/0x430\nworker_thread+0x4e/0x3c0\nkthread+0x103/0x130\nret_from_fork+0x2c/0x50\nThe root cause is: after cp_error is set, f2fs_submit_merged_ipu_write()\nin f2fs_write_single_data_page() tries to flush IPU bio in cache, however\nf2fs_submit_merged_ipu_write() missed to check validity of @bio parameter,\nresult in submitting random cached bio which belong to other IO context,\nthen it will cause use-after-free issue, fix it by adding additional\nvalidity check.

In the Linux kernel, the following vulnerability has been resolved:\nblk-crypto: make blk_crypto_evict_key() more robust\nIf blk_crypto_evict_key() sees that the key is still in-use (due to a\nbug) or that ->keyslot_evict failed, it currently just returns while\nleaving the key linked into the keyslot management structures.\nHowever, blk_crypto_evict_key() is only called in contexts such as inode\neviction where failure is not an option. So actually the caller\nproceeds with freeing the blk_crypto_key regardless of the return value\nof blk_crypto_evict_key().\nThese two assumptions don't match, and the result is that there can be a\nuse-after-free in blk_crypto_reprogram_all_keys() after one of these\nerrors occurs. (Note, these errors *shouldn't* happen; we're just\ntalking about what happens if they do anyway.)\nFix this by making blk_crypto_evict_key() unlink the key from the\nkeyslot management structures even on failure.\nAlso improve some comments.

In the Linux kernel, the following vulnerability has been resolved:\nnet: bcmgenet: Add a check for oversized packets\nOccasionnaly we may get oversized packets from the hardware which\nexceed the nomimal 2KiB buffer size we allocate SKBs with. Add an early\ncheck which drops the packet to avoid invoking skb_over_panic() and move\non to processing the next packet.

In the Linux kernel, the following vulnerability has been resolved:\ndrm/mediatek: mtk_drm_crtc: Add checks for devm_kcalloc\nAs the devm_kcalloc may return NULL, the return value needs to be checked\nto avoid NULL poineter dereference.

In the Linux kernel, the following vulnerability has been resolved:\nInput: raspberrypi-ts - fix refcount leak in rpi_ts_probe\nrpi_firmware_get() take reference, we need to release it in error paths\nas well. Use devm_rpi_firmware_get() helper to handling the resources.\nAlso remove the existing rpi_firmware_put().

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath11k: fix deinitialization of firmware resources\n\nCurrently, in ath11k_ahb_fw_resources_init(), iommu domain\nmapping is done only for the chipsets having fixed firmware\nmemory. Also, for such chipsets, mapping is done only if it\ndoes not have TrustZone support.\n\nDuring deinitialization, only if TrustZone support is not there,\niommu is unmapped back. However, for non fixed firmware memory\nchipsets, TrustZone support is not there and this makes the\ncondition check to true and it tries to unmap the memory which\nwas not mapped during initialization.\n\nThis leads to the following trace -\n\n[ 83.198790] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008\n[ 83.259537] Modules linked in: ath11k_ahb ath11k qmi_helpers\n.. snip ..\n[ 83.280286] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 83.287228] pc : __iommu_unmap+0x30/0x140\n[ 83.293907] lr : iommu_unmap+0x5c/0xa4\n[ 83.298072] sp : ffff80000b3abad0\n.. snip ..\n[ 83.369175] Call trace:\n[ 83.376282] __iommu_unmap+0x30/0x140\n[ 83.378541] iommu_unmap+0x5c/0xa4\n[ 83.382360] ath11k_ahb_fw_resource_deinit.part.12+0x2c/0xac [ath11k_ahb]\n[ 83.385666] ath11k_ahb_free_resources+0x140/0x17c [ath11k_ahb]\n[ 83.392521] ath11k_ahb_shutdown+0x34/0x40 [ath11k_ahb]\n[ 83.398248] platform_shutdown+0x20/0x2c\n[ 83.403455] device_shutdown+0x16c/0x1c4\n[ 83.407621] kernel_restart_prepare+0x34/0x3c\n[ 83.411529] kernel_restart+0x14/0x74\n[ 83.415781] __do_sys_reboot+0x1c4/0x22c\n[ 83.419427] __arm64_sys_reboot+0x1c/0x24\n[ 83.423420] invoke_syscall+0x44/0xfc\n[ 83.427326] el0_svc_common.constprop.3+0xac/0xe8\n[ 83.430974] do_el0_svc+0xa0/0xa8\n[ 83.435659] el0_svc+0x1c/0x44\n[ 83.438957] el0t_64_sync_handler+0x60/0x144\n[ 83.441910] el0t_64_sync+0x15c/0x160\n[ 83.446343] Code: aa0103f4 f9400001 f90027a1 d2800001 (f94006a0)\n[ 83.449903] ---[ end trace 0000000000000000 ]---\n\nThis can be reproduced by probing an AHB chipset which is not\nhaving a fixed memory region. During reboot (or rmmod) trace\ncan be seen.\n\nFix this issue by adding a condition check on firmware fixed memory\nhw_param as done in the counter initialization function.\n\nTested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:\n\nnull_blk: fix poll request timeout handling\n\nWhen doing io_uring benchmark on /dev/nullb0, it's easy to crash the\nkernel if poll requests timeout triggered, as reported by David. [1]\n\nBUG: kernel NULL pointer dereference, address: 0000000000000008\nWorkqueue: kblockd blk_mq_timeout_work\nRIP: 0010:null_timeout_rq+0x4e/0x91\nCall Trace:\n ? null_timeout_rq+0x4e/0x91\n blk_mq_handle_expired+0x31/0x4b\n bt_iter+0x68/0x84\n ? bt_tags_iter+0x81/0x81\n __sbitmap_for_each_set.constprop.0+0xb0/0xf2\n ? __blk_mq_complete_request_remote+0xf/0xf\n bt_for_each+0x46/0x64\n ? __blk_mq_complete_request_remote+0xf/0xf\n ? percpu_ref_get_many+0xc/0x2a\n blk_mq_queue_tag_busy_iter+0x14d/0x18e\n blk_mq_timeout_work+0x95/0x127\n process_one_work+0x185/0x263\n worker_thread+0x1b5/0x227\n\nThis is indeed a race problem between null_timeout_rq() and null_poll().\n\nnull_poll() null_timeout_rq()\n spin_lock(&nq->poll_lock)\n list_splice_init(&nq->poll_list, &list)\n spin_unlock(&nq->poll_lock)\n\n while (!list_empty(&list))\n req = list_first_entry()\n list_del_init()\n ...\n blk_mq_add_to_batch()\n // req->rq_next = NULL\n spin_lock(&nq->poll_lock)\n\n // rq->queuelist->next == NULL\n list_del_init(&rq->queuelist)\n\n spin_unlock(&nq->poll_lock)\n\nFix these problems by setting requests state to MQ_RQ_COMPLETE under\nnq->poll_lock protection, in which null_timeout_rq() can safely detect\nthis race and early return.\n\nNote this patch just fix the kernel panic when request timeout happen.\n\n[1] https://lore.kernel.org/all/3893581.1691785261@warthog.procyon.org.uk/

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Use raw_smp_processor_id() instead of smp_processor_id()\n\nThe following call trace was observed:\n\nlocalhost kernel: nvme nvme0: NVME-FC{0}: controller connect complete\nlocalhost kernel: BUG: using smp_processor_id() in preemptible [00000000] code: kworker/u129:4/75092\nlocalhost kernel: nvme nvme0: NVME-FC{0}: new ctrl: NQN "nqn.1992-08.com.netapp:sn.b42d198afb4d11ecad6d00a098d6abfa:subsystem.PR_Channel2022_RH84_subsystem_291"\nlocalhost kernel: caller is qla_nvme_post_cmd+0x216/0x1380 [qla2xxx]\nlocalhost kernel: CPU: 6 PID: 75092 Comm: kworker/u129:4 Kdump: loaded Tainted: G B W OE --------- --- 5.14.0-70.22.1.el9_0.x86_64+debug #1\nlocalhost kernel: Hardware name: HPE ProLiant XL420 Gen10/ProLiant XL420 Gen10, BIOS U39 01/13/2022\nlocalhost kernel: Workqueue: nvme-wq nvme_async_event_work [nvme_core]\nlocalhost kernel: Call Trace:\nlocalhost kernel: dump_stack_lvl+0x57/0x7d\nlocalhost kernel: check_preemption_disabled+0xc8/0xd0\nlocalhost kernel: qla_nvme_post_cmd+0x216/0x1380 [qla2xxx]\n\nUse raw_smp_processor_id() instead of smp_processor_id().\n\nAlso use queue_work() across the driver instead of queue_work_on() thus\navoiding usage of smp_processor_id() when CONFIG_DEBUG_PREEMPT is enabled.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtw88: Fix memory leak in rtw88_usb\n\nKmemleak shows the following leak arising from routine in the usb\nprobe routine:\n\nunreferenced object 0xffff895cb29bba00 (size 512):\n comm "(udev-worker)", pid 534, jiffies 4294903932 (age 102751.088s)\n hex dump (first 32 bytes):\n 77 30 30 30 00 00 00 00 02 2f 2d 2b 30 00 00 00 w000...../-+0...\n 02 00 2a 28 00 00 00 00 ff 55 ff ff ff 00 00 00 ..*(.....U......\n backtrace:\n [] kmalloc_trace+0x26/0x90\n [] rtw_usb_probe+0x2f1/0x680 [rtw_usb]\n [] usb_probe_interface+0xdd/0x2e0 [usbcore]\n [] really_probe+0x18e/0x3d0\n [] __driver_probe_device+0x78/0x160\n [] driver_probe_device+0x1f/0x90\n [] __driver_attach+0xbf/0x1b0\n [] bus_for_each_dev+0x70/0xc0\n [] bus_add_driver+0x10e/0x210\n [] driver_register+0x55/0xf0\n [] usb_register_driver+0x88/0x140 [usbcore]\n [] do_one_initcall+0x43/0x210\n [] do_init_module+0x4a/0x200\n [] __do_sys_finit_module+0xac/0x120\n [] do_syscall_64+0x56/0x80\n [] entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nThe leak was verified to be real by unloading the driver, which resulted\nin a dangling pointer to the allocation.\n\nThe allocated memory is freed in rtw_usb_intf_deinit().

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix unsafe drain work queue code\n\nIf create_qp does not fully succeed it is possible for qp cleanup\ncode to attempt to drain the send or recv work queues before the\nqueues have been created causing a seg fault. This patch checks\nto see if the queues exist before attempting to drain them.

In the Linux kernel, the following vulnerability has been resolved:\n\nthunderbolt: Fix memory leak in tb_handle_dp_bandwidth_request()\n\nThe memory allocated in tb_queue_dp_bandwidth_request() needs to be\nreleased once the request is handled to avoid leaking it.

In the Linux kernel, the following vulnerability has been resolved:\n\njbd2: check 'jh->b_transaction' before removing it from checkpoint\n\nFollowing process will corrupt ext4 image:\nStep 1:\njbd2_journal_commit_transaction\n __jbd2_journal_insert_checkpoint(jh, commit_transaction)\n // Put jh into trans1->t_checkpoint_list\n journal->j_checkpoint_transactions = commit_transaction\n // Put trans1 into journal->j_checkpoint_transactions\n\nStep 2:\ndo_get_write_access\n test_clear_buffer_dirty(bh) // clear buffer dirty，set jbd dirty\n __jbd2_journal_file_buffer(jh, transaction) // jh belongs to trans2\n\nStep 3:\ndrop_cache\n journal_shrink_one_cp_list\n jbd2_journal_try_remove_checkpoint\n if (!trylock_buffer(bh)) // lock bh, true\n if (buffer_dirty(bh)) // buffer is not dirty\n __jbd2_journal_remove_checkpoint(jh)\n // remove jh from trans1->t_checkpoint_list\n\nStep 4:\njbd2_log_do_checkpoint\n trans1 = journal->j_checkpoint_transactions\n // jh is not in trans1->t_checkpoint_list\n jbd2_cleanup_journal_tail(journal) // trans1 is done\n\nStep 5: Power cut, trans2 is not committed, jh is lost in next mounting.\n\nFix it by checking 'jh->b_transaction' before remove it from checkpoint.

In the Linux kernel, the following vulnerability has been resolved:\nRDMA/cma: Allow UD qp_type to join multicast only\nAs for multicast:\n- The SIDR is the only mode that makes sense;\n- Besides PS_UDP, other port spaces like PS_IB is also allowed, as it is\nUD compatible. In this case qkey also needs to be set [1].\nThis patch allows only UD qp_type to join multicast, and set qkey to\ndefault if it's not set, to fix an uninit-value error: the ib->rec.qkey\nfield is accessed without being initialized.\n=====================================================\nBUG: KMSAN: uninit-value in cma_set_qkey drivers/infiniband/core/cma.c:510 [inline]\nBUG: KMSAN: uninit-value in cma_make_mc_event+0xb73/0xe00 drivers/infiniband/core/cma.c:4570\ncma_set_qkey drivers/infiniband/core/cma.c:510 [inline]\ncma_make_mc_event+0xb73/0xe00 drivers/infiniband/core/cma.c:4570\ncma_iboe_join_multicast drivers/infiniband/core/cma.c:4782 [inline]\nrdma_join_multicast+0x2b83/0x30a0 drivers/infiniband/core/cma.c:4814\nucma_process_join+0xa76/0xf60 drivers/infiniband/core/ucma.c:1479\nucma_join_multicast+0x1e3/0x250 drivers/infiniband/core/ucma.c:1546\nucma_write+0x639/0x6d0 drivers/infiniband/core/ucma.c:1732\nvfs_write+0x8ce/0x2030 fs/read_write.c:588\nksys_write+0x28c/0x520 fs/read_write.c:643\n__do_sys_write fs/read_write.c:655 [inline]\n__se_sys_write fs/read_write.c:652 [inline]\n__ia32_sys_write+0xdb/0x120 fs/read_write.c:652\ndo_syscall_32_irqs_on arch/x86/entry/common.c:114 [inline]\n__do_fast_syscall_32+0x96/0xf0 arch/x86/entry/common.c:180\ndo_fast_syscall_32+0x34/0x70 arch/x86/entry/common.c:205\ndo_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:248\nentry_SYSENTER_compat_after_hwframe+0x4d/0x5c\nLocal variable ib.i created at:\ncma_iboe_join_multicast drivers/infiniband/core/cma.c:4737 [inline]\nrdma_join_multicast+0x586/0x30a0 drivers/infiniband/core/cma.c:4814\nucma_process_join+0xa76/0xf60 drivers/infiniband/core/ucma.c:1479\nCPU: 0 PID: 29874 Comm: syz-executor.3 Not tainted 5.16.0-rc3-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\n=====================================================\n[1] https://lore.kernel.org/linux-rdma/20220117183832.GD84788@nvidia.com/

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: pcie: Fix integer overflow in iwl_write_to_user_buf\n\nAn integer overflow occurs in the iwl_write_to_user_buf() function,\nwhich is called by the iwl_dbgfs_monitor_data_read() function.\n\nstatic bool iwl_write_to_user_buf(char __user *user_buf, ssize_t count,\n void *buf, ssize_t *size,\n ssize_t *bytes_copied)\n{\n int buf_size_left = count - *bytes_copied;\n\n buf_size_left = buf_size_left - (buf_size_left % sizeof(u32));\n if (*size > buf_size_left)\n *size = buf_size_left;\n\nIf the user passes a SIZE_MAX value to the "ssize_t count" parameter,\nthe ssize_t count parameter is assigned to "int buf_size_left".\nThen compare "*size" with "buf_size_left" . Here, "buf_size_left" is a\nnegative number, so "*size" is assigned "buf_size_left" and goes into\nthe third argument of the copy_to_user function, causing a heap overflow.\n\nThis is not a security vulnerability because iwl_dbgfs_monitor_data_read()\nis a debugfs operation with 0400 privileges.

In the Linux kernel, the following vulnerability has been resolved:\n\ncan: gs_usb: fix time stamp counter initialization\n\nIf the gs_usb device driver is unloaded (or unbound) before the\ninterface is shut down, the USB stack first calls the struct\nusb_driver::disconnect and then the struct net_device_ops::ndo_stop\ncallback.\n\nIn gs_usb_disconnect() all pending bulk URBs are killed, i.e. no more\nRX'ed CAN frames are send from the USB device to the host. Later in\ngs_can_close() a reset control message is send to each CAN channel to\nremove the controller from the CAN bus. In this race window the USB\ndevice can still receive CAN frames from the bus and internally queue\nthem to be send to the host.\n\nAt least in the current version of the candlelight firmware, the queue\nof received CAN frames is not emptied during the reset command. After\nloading (or binding) the gs_usb driver, new URBs are submitted during\nthe struct net_device_ops::ndo_open callback and the candlelight\nfirmware starts sending its already queued CAN frames to the host.\n\nHowever, this scenario was not considered when implementing the\nhardware timestamp function. The cycle counter/time counter\ninfrastructure is set up (gs_usb_timestamp_init()) after the USBs are\nsubmitted, resulting in a NULL pointer dereference if\ntimecounter_cyc2time() (via the call chain:\ngs_usb_receive_bulk_callback() -> gs_usb_set_timestamp() ->\ngs_usb_skb_set_timestamp()) is called too early.\n\nMove the gs_usb_timestamp_init() function before the URBs are\nsubmitted to fix this problem.\n\nFor a comprehensive solution, we need to consider gs_usb devices with\nmore than 1 channel. The cycle counter/time counter infrastructure is\nsetup per channel, but the RX URBs are per device. Once gs_can_open()\nof _a_ channel has been called, and URBs have been submitted, the\ngs_usb_receive_bulk_callback() can be called for _all_ available\nchannels, even for channels that are not running, yet. As cycle\ncounter/time counter has not set up, this will again lead to a NULL\npointer dereference.\n\nConvert the cycle counter/time counter from a "per channel" to a "per\ndevice" functionality. Also set it up, before submitting any URBs to\nthe device.\n\nFurther in gs_usb_receive_bulk_callback(), don't process any URBs for\nnot started CAN channels, only resubmit the URB.

In the Linux kernel, the following vulnerability has been resolved:\n\ncgroup,freezer: hold cpu_hotplug_lock before freezer_mutex\n\nsyzbot is reporting circular locking dependency between cpu_hotplug_lock\nand freezer_mutex, for commit f5d39b020809 ("freezer,sched: Rewrite core\nfreezer logic") replaced atomic_inc() in freezer_apply_state() with\nstatic_branch_inc() which holds cpu_hotplug_lock.\n\ncpu_hotplug_lock => cgroup_threadgroup_rwsem => freezer_mutex\n\n cgroup_file_write() {\n cgroup_procs_write() {\n __cgroup_procs_write() {\n cgroup_procs_write_start() {\n cgroup_attach_lock() {\n cpus_read_lock() {\n percpu_down_read(&cpu_hotplug_lock);\n }\n percpu_down_write(&cgroup_threadgroup_rwsem);\n }\n }\n cgroup_attach_task() {\n cgroup_migrate() {\n cgroup_migrate_execute() {\n freezer_attach() {\n mutex_lock(&freezer_mutex);\n (...snipped...)\n }\n }\n }\n }\n (...snipped...)\n }\n }\n }\n\nfreezer_mutex => cpu_hotplug_lock\n\n cgroup_file_write() {\n freezer_write() {\n freezer_change_state() {\n mutex_lock(&freezer_mutex);\n freezer_apply_state() {\n static_branch_inc(&freezer_active) {\n static_key_slow_inc() {\n cpus_read_lock();\n static_key_slow_inc_cpuslocked();\n cpus_read_unlock();\n }\n }\n }\n mutex_unlock(&freezer_mutex);\n }\n }\n }\n\nSwap locking order by moving cpus_read_lock() in freezer_apply_state()\nto before mutex_lock(&freezer_mutex) in freezer_change_state().

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ses: Fix slab-out-of-bounds in ses_intf_remove()\n\nA fix for:\n\nBUG: KASAN: slab-out-of-bounds in ses_intf_remove+0x23f/0x270 [ses]\nRead of size 8 at addr ffff88a10d32e5d8 by task rmmod/12013\n\nWhen edev->components is zero, accessing edev->component[0] members is\nwrong.

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Fix hci_suspend_sync crash\n\nIf hci_unregister_dev() frees the hci_dev object but hci_suspend_notifier\nmay still be accessing it, it can cause the program to crash.\nHere's the call trace:\n <4>[102152.653246] Call Trace:\n <4>[102152.653254] hci_suspend_sync+0x109/0x301 [bluetooth]\n <4>[102152.653259] hci_suspend_dev+0x78/0xcd [bluetooth]\n <4>[102152.653263] hci_suspend_notifier+0x42/0x7a [bluetooth]\n <4>[102152.653268] notifier_call_chain+0x43/0x6b\n <4>[102152.653271] __blocking_notifier_call_chain+0x48/0x69\n <4>[102152.653273] __pm_notifier_call_chain+0x22/0x39\n <4>[102152.653276] pm_suspend+0x287/0x57c\n <4>[102152.653278] state_store+0xae/0xe5\n <4>[102152.653281] kernfs_fop_write+0x109/0x173\n <4>[102152.653284] __vfs_write+0x16f/0x1a2\n <4>[102152.653287] ? selinux_file_permission+0xca/0x16f\n <4>[102152.653289] ? security_file_permission+0x36/0x109\n <4>[102152.653291] vfs_write+0x114/0x21d\n <4>[102152.653293] __x64_sys_write+0x7b/0xdb\n <4>[102152.653296] do_syscall_64+0x59/0x194\n <4>[102152.653299] entry_SYSCALL_64_after_hwframe+0x5c/0xc1\n\nThis patch holds the reference count of the hci_dev object while\nprocessing it in hci_suspend_notifier to avoid potential crash\ncaused by the race condition.

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: v4l2-mem2mem: add lock to protect parameter num_rdy\n\nGetting below error when using KCSAN to check the driver. Adding lock to\nprotect parameter num_rdy when getting the value with function:\nv4l2_m2m_num_src_bufs_ready/v4l2_m2m_num_dst_bufs_ready.\n\nkworker/u16:3: [name:report&]BUG: KCSAN: data-race in v4l2_m2m_buf_queue\nkworker/u16:3: [name:report&]\n\nkworker/u16:3: [name:report&]read-write to 0xffffff8105f35b94 of 1 bytes by task 20865 on cpu 7:\nkworker/u16:3: v4l2_m2m_buf_queue+0xd8/0x10c

In the Linux kernel, the following vulnerability has been resolved:\nPM / devfreq: Fix leak in devfreq_dev_release()\nsrcu_init_notifier_head() allocates resources that need to be released\nwith a srcu_cleanup_notifier_head() call.\nReported by kmemleak.

In the Linux kernel, the following vulnerability has been resolved:\n\ntipc: do not update mtu if msg_max is too small in mtu negotiation\n\nWhen doing link mtu negotiation, a malicious peer may send Activate msg\nwith a very small mtu, e.g. 4 in Shuang's testing, without checking for\nthe minimum mtu, l->mtu will be set to 4 in tipc_link_proto_rcv(), then\nn->links[bearer_id].mtu is set to 4294967228, which is a overflow of\n'4 - INT_H_SIZE - EMSG_OVERHEAD' in tipc_link_mss().\n\nWith tipc_link.mtu = 4, tipc_link_xmit() kept printing the warning:\n\n tipc: Too large msg, purging xmit list 1 5 0 40 4!\n tipc: Too large msg, purging xmit list 1 15 0 60 4!\n\nAnd with tipc_link_entry.mtu 4294967228, a huge skb was allocated in\nnamed_distribute(), and when purging it in tipc_link_xmit(), a crash\nwas even caused:\n\n general protection fault, probably for non-canonical address 0x2100001011000dd: 0000 [#1] PREEMPT SMP PTI\n CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Not tainted 6.3.0.neta #19\n RIP: 0010:kfree_skb_list_reason+0x7e/0x1f0\n Call Trace:\n \n skb_release_data+0xf9/0x1d0\n kfree_skb_reason+0x40/0x100\n tipc_link_xmit+0x57a/0x740 [tipc]\n tipc_node_xmit+0x16c/0x5c0 [tipc]\n tipc_named_node_up+0x27f/0x2c0 [tipc]\n tipc_node_write_unlock+0x149/0x170 [tipc]\n tipc_rcv+0x608/0x740 [tipc]\n tipc_udp_recv+0xdc/0x1f0 [tipc]\n udp_queue_rcv_one_skb+0x33e/0x620\n udp_unicast_rcv_skb.isra.72+0x75/0x90\n __udp4_lib_rcv+0x56d/0xc20\n ip_protocol_deliver_rcu+0x100/0x2d0\n\nThis patch fixes it by checking the new mtu against tipc_bearer_min_mtu(),\nand not updating mtu if it is too small.

In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio-mmio: don't break lifecycle of vm_dev\n\nvm_dev has a separate lifecycle because it has a 'struct device'\nembedded. Thus, having a release callback for it is correct.\n\nAllocating the vm_dev struct with devres totally breaks this protection,\nthough. Instead of waiting for the vm_dev release callback, the memory\nis freed when the platform_device is removed. Resulting in a\nuse-after-free when finally the callback is to be called.\n\nTo easily see the problem, compile the kernel with\nCONFIG_DEBUG_KOBJECT_RELEASE and unbind with sysfs.\n\nThe fix is easy, don't use devres in this case.\n\nFound during my research about object lifetime problems.

In the Linux kernel, the following vulnerability has been resolved:\n\ngpu: host1x: Fix memory leak of device names\n\nThe device names allocated by dev_set_name() need be freed\nbefore module unloading, but they can not be freed because\nthe kobject's refcount which was set in device_initialize()\nhas not be decreased to 0.\n\nAs comment of device_add() says, if it fails, use only\nput_device() drop the refcount, then the name will be\nfreed in kobejct_cleanup().\n\ndevice_del() and put_device() can be replaced with\ndevice_unregister(), so call it to unregister the added\nsuccessfully devices, and just call put_device() to the\nnot added device.\n\nAdd a release() function to device to avoid null release()\nfunction WARNING in device_release(), it's empty, because\nthe context devices are freed together in\nhost1x_memory_context_list_free().

In the Linux kernel, the following vulnerability has been resolved:\n\nnbd: fix incomplete validation of ioctl arg\n\nWe tested and found an alarm caused by nbd_ioctl arg without verification.\nThe UBSAN warning calltrace like below:\n\nUBSAN: Undefined behaviour in fs/buffer.c:1709:35\nsigned integer overflow:\n-9223372036854775808 - 1 cannot be represented in type 'long long int'\nCPU: 3 PID: 2523 Comm: syz-executor.0 Not tainted 4.19.90 #1\nHardware name: linux,dummy-virt (DT)\nCall trace:\n dump_backtrace+0x0/0x3f0 arch/arm64/kernel/time.c:78\n show_stack+0x28/0x38 arch/arm64/kernel/traps.c:158\n __dump_stack lib/dump_stack.c:77 [inline]\n dump_stack+0x170/0x1dc lib/dump_stack.c:118\n ubsan_epilogue+0x18/0xb4 lib/ubsan.c:161\n handle_overflow+0x188/0x1dc lib/ubsan.c:192\n __ubsan_handle_sub_overflow+0x34/0x44 lib/ubsan.c:206\n __block_write_full_page+0x94c/0xa20 fs/buffer.c:1709\n block_write_full_page+0x1f0/0x280 fs/buffer.c:2934\n blkdev_writepage+0x34/0x40 fs/block_dev.c:607\n __writepage+0x68/0xe8 mm/page-writeback.c:2305\n write_cache_pages+0x44c/0xc70 mm/page-writeback.c:2240\n generic_writepages+0xdc/0x148 mm/page-writeback.c:2329\n blkdev_writepages+0x2c/0x38 fs/block_dev.c:2114\n do_writepages+0xd4/0x250 mm/page-writeback.c:2344\n\nThe reason for triggering this warning is __block_write_full_page()\n-> i_size_read(inode) - 1 overflow.\ninode->i_size is assigned in __nbd_ioctl() -> nbd_set_size() -> bytesize.\nWe think it is necessary to limit the size of arg to prevent errors.\n\nMoreover, __nbd_ioctl() -> nbd_add_socket(), arg will be cast to int.\nAssuming the value of arg is 0x80000000000000001) (on a 64-bit machine),\nit will become 1 after the coercion, which will return unexpected results.\n\nFix it by adding checks to prevent passing in too large numbers.

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

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ufs: core: Fix handling of lrbp->cmd\n\nufshcd_queuecommand() may be called two times in a row for a SCSI command\nbefore it is completed. Hence make the following changes:\n\n - In the functions that submit a command, do not check the old value of\n lrbp->cmd nor clear lrbp->cmd in error paths.\n\n - In ufshcd_release_scsi_cmd(), do not clear lrbp->cmd.\n\nSee also scsi_send_eh_cmnd().\n\nThis commit prevents that the following appears if a command times out:\n\nWARNING: at drivers/ufs/core/ufshcd.c:2965 ufshcd_queuecommand+0x6f8/0x9a8\nCall trace:\n ufshcd_queuecommand+0x6f8/0x9a8\n scsi_send_eh_cmnd+0x2c0/0x960\n scsi_eh_test_devices+0x100/0x314\n scsi_eh_ready_devs+0xd90/0x114c\n scsi_error_handler+0x2b4/0xb70\n kthread+0x16c/0x1e0

In the Linux kernel, the following vulnerability has been resolved:\n\nqed: allow sleep in qed_mcp_trace_dump()\n\nBy default, qed_mcp_cmd_and_union() delays 10us at a time in a loop\nthat can run 500K times, so calls to qed_mcp_nvm_rd_cmd()\nmay block the current thread for over 5s.\nWe observed thread scheduling delays over 700ms in production,\nwith stacktraces pointing to this code as the culprit.\n\nqed_mcp_trace_dump() is called from ethtool, so sleeping is permitted.\nIt already can sleep in qed_mcp_halt(), which calls qed_mcp_cmd().\nAdd a "can sleep" parameter to qed_find_nvram_image() and\nqed_nvram_read() so they can sleep during qed_mcp_trace_dump().\nqed_mcp_trace_get_meta_info() and qed_mcp_trace_read_meta(),\ncalled only by qed_mcp_trace_dump(), allow these functions to sleep.\nI can't tell if the other caller (qed_grc_dump_mcp_hw_dump()) can sleep,\nso keep b_can_sleep set to false when it calls these functions.\n\nAn example stacktrace from a custom warning we added to the kernel\nshowing a thread that has not scheduled despite long needing resched:\n[ 2745.362925,17] ------------[ cut here ]------------\n[ 2745.362941,17] WARNING: CPU: 23 PID: 5640 at arch/x86/kernel/irq.c:233 do_IRQ+0x15e/0x1a0()\n[ 2745.362946,17] Thread not rescheduled for 744 ms after irq 99\n[ 2745.362956,17] Modules linked in: ...\n[ 2745.363339,17] CPU: 23 PID: 5640 Comm: lldpd Tainted: P O 4.4.182+ #202104120910+6d1da174272d.61x\n[ 2745.363343,17] Hardware name: FOXCONN MercuryB/Quicksilver Controller, BIOS H11P1N09 07/08/2020\n[ 2745.363346,17] 0000000000000000 ffff885ec07c3ed8 ffffffff8131eb2f ffff885ec07c3f20\n[ 2745.363358,17] ffffffff81d14f64 ffff885ec07c3f10 ffffffff81072ac2 ffff88be98ed0000\n[ 2745.363369,17] 0000000000000063 0000000000000174 0000000000000074 0000000000000000\n[ 2745.363379,17] Call Trace:\n[ 2745.363382,17] [] dump_stack+0x8e/0xcf\n[ 2745.363393,17] [] warn_slowpath_common+0x82/0xc0\n[ 2745.363398,17] [] warn_slowpath_fmt+0x4c/0x50\n[ 2745.363404,17] [] ? rcu_irq_exit+0xae/0xc0\n[ 2745.363408,17] [] do_IRQ+0x15e/0x1a0\n[ 2745.363413,17] [] common_interrupt+0x89/0x89\n[ 2745.363416,17] [] ? delay_tsc+0x24/0x50\n[ 2745.363425,17] [] __udelay+0x34/0x40\n[ 2745.363457,17] [] qed_mcp_cmd_and_union+0x36f/0x7d0 [qed]\n[ 2745.363473,17] [] qed_mcp_nvm_rd_cmd+0x4d/0x90 [qed]\n[ 2745.363490,17] [] qed_mcp_trace_dump+0x4a7/0x630 [qed]\n[ 2745.363504,17] [] ? qed_fw_asserts_dump+0x1d6/0x1f0 [qed]\n[ 2745.363520,17] [] qed_dbg_mcp_trace_get_dump_buf_size+0x37/0x80 [qed]\n[ 2745.363536,17] [] qed_dbg_feature_size+0x61/0xa0 [qed]\n[ 2745.363551,17] [] qed_dbg_all_data_size+0x247/0x260 [qed]\n[ 2745.363560,17] [] qede_get_regs_len+0x30/0x40 [qede]\n[ 2745.363566,17] [] ethtool_get_drvinfo+0xe3/0x190\n[ 2745.363570,17] [] dev_ethtool+0x1362/0x2140\n[ 2745.363575,17] [] ? finish_task_switch+0x76/0x260\n[ 2745.363580,17] [] ? __schedule+0x3c6/0x9d0\n[ 2745.363585,17] [] ? hrtimer_start_range_ns+0x1d0/0x370\n[ 2745.363589,17] [] ? dev_get_by_name_rcu+0x6b/0x90\n[ 2745.363594,17] [] dev_ioctl+0xe8/0x710\n[ 2745.363599,17] [] sock_do_ioctl+0x48/0x60\n[ 2745.363603,17] [] sock_ioctl+0x1c7/0x280\n[ 2745.363608,17] [] ? seccomp_phase1+0x83/0x220\n[ 2745.363612,17] [] do_vfs_ioctl+0x2b3/0x4e0\n[ 2745.363616,17] [] SyS_ioctl+0x41/0x70\n[ 2745.363619,17] [] entry_SYSCALL_64_fastpath+0x1e/0x79\n[ 2745.363622,17] ---[ end trace f6954aa440266421 ]---

In the Linux kernel, the following vulnerability has been resolved:\nublk: fail to start device if queue setup is interrupted\nIn ublk_ctrl_start_dev(), if wait_for_completion_interruptible() is\ninterrupted by signal, queues aren't setup successfully yet, so we\nhave to fail UBLK_CMD_START_DEV, otherwise kernel oops can be triggered.\nReported by German when working on qemu-storage-deamon which requires\nsingle thread ublk daemon.

In the Linux kernel, the following vulnerability has been resolved:\nnet/mlx5: Unregister devlink params in case interface is down\nCurrently, in case an interface is down, mlx5 driver doesn't\nunregister its devlink params, which leads to this WARN[1].\nFix it by unregistering devlink params in that case as well.\n[1]\n[ 295.244769 ] WARNING: CPU: 15 PID: 1 at net/core/devlink.c:9042 devlink_free+0x174/0x1fc\n[ 295.488379 ] CPU: 15 PID: 1 Comm: shutdown Tainted: G S OE 5.15.0-1017.19.3.g0677e61-bluefield #g0677e61\n[ 295.509330 ] Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS 4.2.0.12761 Jun 6 2023\n[ 295.543096 ] pc : devlink_free+0x174/0x1fc\n[ 295.551104 ] lr : mlx5_devlink_free+0x18/0x2c [mlx5_core]\n[ 295.561816 ] sp : ffff80000809b850\n[ 295.711155 ] Call trace:\n[ 295.716030 ] devlink_free+0x174/0x1fc\n[ 295.723346 ] mlx5_devlink_free+0x18/0x2c [mlx5_core]\n[ 295.733351 ] mlx5_sf_dev_remove+0x98/0xb0 [mlx5_core]\n[ 295.743534 ] auxiliary_bus_remove+0x2c/0x50\n[ 295.751893 ] __device_release_driver+0x19c/0x280\n[ 295.761120 ] device_release_driver+0x34/0x50\n[ 295.769649 ] bus_remove_device+0xdc/0x170\n[ 295.777656 ] device_del+0x17c/0x3a4\n[ 295.784620 ] mlx5_sf_dev_remove+0x28/0xf0 [mlx5_core]\n[ 295.794800 ] mlx5_sf_dev_table_destroy+0x98/0x110 [mlx5_core]\n[ 295.806375 ] mlx5_unload+0x34/0xd0 [mlx5_core]\n[ 295.815339 ] mlx5_unload_one+0x70/0xe4 [mlx5_core]\n[ 295.824998 ] shutdown+0xb0/0xd8 [mlx5_core]\n[ 295.833439 ] pci_device_shutdown+0x3c/0xa0\n[ 295.841651 ] device_shutdown+0x170/0x340\n[ 295.849486 ] __do_sys_reboot+0x1f4/0x2a0\n[ 295.857322 ] __arm64_sys_reboot+0x2c/0x40\n[ 295.865329 ] invoke_syscall+0x78/0x100\n[ 295.872817 ] el0_svc_common.constprop.0+0x54/0x184\n[ 295.882392 ] do_el0_svc+0x30/0xac\n[ 295.889008 ] el0_svc+0x48/0x160\n[ 295.895278 ] el0t_64_sync_handler+0xa4/0x130\n[ 295.903807 ] el0t_64_sync+0x1a4/0x1a8\n[ 295.911120 ] ---[ end trace 4f1d2381d00d9dce ]---

In the Linux kernel, the following vulnerability has been resolved:\n\nudf: Do not bother merging very long extents\n\nWhen merging very long extents we try to push as much length as possible\nto the first extent. However this is unnecessarily complicated and not\nreally worth the trouble. Furthermore there was a bug in the logic\nresulting in corrupting extents in the file as syzbot reproducer shows.\nSo just don't bother with the merging of extents that are too long\ntogether.

In the Linux kernel, the following vulnerability has been resolved:\n\nclk: tegra: tegra124-emc: Fix potential memory leak\n\nThe tegra and tegra needs to be freed in the error handling path, otherwise\nit will be leaked.

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/bnxt_re: Properly order ib_device_unalloc() to avoid UAF\n\nib_dealloc_device() should be called only after device cleanup. Fix the\ndealloc sequence.

In the Linux kernel, the following vulnerability has been resolved:\n\next4: allow ext4_get_group_info() to fail\n\nPreviously, ext4_get_group_info() would treat an invalid group number\nas BUG(), since in theory it should never happen. However, if a\nmalicious attaker (or fuzzer) modifies the superblock via the block\ndevice while it is the file system is mounted, it is possible for\ns_first_data_block to get set to a very large number. In that case,\nwhen calculating the block group of some block number (such as the\nstarting block of a preallocation region), could result in an\nunderflow and very large block group number. Then the BUG_ON check in\next4_get_group_info() would fire, resutling in a denial of service\nattack that can be triggered by root or someone with write access to\nthe block device.\n\nFor a quality of implementation perspective, it's best that even if\nthe system administrator does something that they shouldn't, that it\nwill not trigger a BUG. So instead of BUG'ing, ext4_get_group_info()\nwill call ext4_error and return NULL. We also add fallback code in\nall of the callers of ext4_get_group_info() that it might NULL.\n\nAlso, since ext4_get_group_info() was already borderline to be an\ninline function, un-inline it. The results in a next reduction of the\ncompiled text size of ext4 by roughly 2k.

In the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd/iommu_v2: Fix pasid_state refcount dec hit 0 warning on pasid unbind\n\nWhen unbinding pasid - a race condition exists vs outstanding page faults.\n\nTo prevent this, the pasid_state object contains a refcount.\n * set to 1 on pasid bind\n * incremented on each ppr notification start\n * decremented on each ppr notification done\n * decremented on pasid unbind\n\nSince refcount_dec assumes that refcount will never reach 0:\n the current implementation causes the following to be invoked on\n pasid unbind:\n REFCOUNT_WARN("decrement hit 0; leaking memory")\n\nFix this issue by changing refcount_dec to refcount_dec_and_test\nto explicitly handle refcount=1.

In the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: fix slab-use-after-free in decode_session6\n\nWhen the xfrm device is set to the qdisc of the sfb type, the cb field\nof the sent skb may be modified during enqueuing. Then,\nslab-use-after-free may occur when the xfrm device sends IPv6 packets.\n\nThe stack information is as follows:\nBUG: KASAN: slab-use-after-free in decode_session6+0x103f/0x1890\nRead of size 1 at addr ffff8881111458ef by task swapper/3/0\nCPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.4.0-next-20230707 #409\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014\nCall Trace:\n\ndump_stack_lvl+0xd9/0x150\nprint_address_description.constprop.0+0x2c/0x3c0\nkasan_report+0x11d/0x130\ndecode_session6+0x103f/0x1890\n__xfrm_decode_session+0x54/0xb0\nxfrmi_xmit+0x173/0x1ca0\ndev_hard_start_xmit+0x187/0x700\nsch_direct_xmit+0x1a3/0xc30\n__qdisc_run+0x510/0x17a0\n__dev_queue_xmit+0x2215/0x3b10\nneigh_connected_output+0x3c2/0x550\nip6_finish_output2+0x55a/0x1550\nip6_finish_output+0x6b9/0x1270\nip6_output+0x1f1/0x540\nndisc_send_skb+0xa63/0x1890\nndisc_send_rs+0x132/0x6f0\naddrconf_rs_timer+0x3f1/0x870\ncall_timer_fn+0x1a0/0x580\nexpire_timers+0x29b/0x4b0\nrun_timer_softirq+0x326/0x910\n__do_softirq+0x1d4/0x905\nirq_exit_rcu+0xb7/0x120\nsysvec_apic_timer_interrupt+0x97/0xc0\n\n\nasm_sysvec_apic_timer_interrupt+0x1a/0x20\nRIP: 0010:intel_idle_hlt+0x23/0x30\nCode: 1f 84 00 00 00 00 00 f3 0f 1e fa 41 54 41 89 d4 0f 1f 44 00 00 66 90 0f 1f 44 00 00 0f 00 2d c4 9f ab 00 0f 1f 44 00 00 fb f4 44 89 e0 41 5c c3 66 0f 1f 44 00 00 f3 0f 1e fa 41 54 41 89 d4\nRSP: 0018:ffffc90000197d78 EFLAGS: 00000246\nRAX: 00000000000a83c3 RBX: ffffe8ffffd09c50 RCX: ffffffff8a22d8e5\nRDX: 0000000000000001 RSI: ffffffff8d3f8080 RDI: ffffe8ffffd09c50\nRBP: ffffffff8d3f8080 R08: 0000000000000001 R09: ffffed1026ba6d9d\nR10: ffff888135d36ceb R11: 0000000000000001 R12: 0000000000000001\nR13: ffffffff8d3f8100 R14: 0000000000000001 R15: 0000000000000000\ncpuidle_enter_state+0xd3/0x6f0\ncpuidle_enter+0x4e/0xa0\ndo_idle+0x2fe/0x3c0\ncpu_startup_entry+0x18/0x20\nstart_secondary+0x200/0x290\nsecondary_startup_64_no_verify+0x167/0x16b\n\nAllocated by task 939:\nkasan_save_stack+0x22/0x40\nkasan_set_track+0x25/0x30\n__kasan_slab_alloc+0x7f/0x90\nkmem_cache_alloc_node+0x1cd/0x410\nkmalloc_reserve+0x165/0x270\n__alloc_skb+0x129/0x330\ninet6_ifa_notify+0x118/0x230\n__ipv6_ifa_notify+0x177/0xbe0\naddrconf_dad_completed+0x133/0xe00\naddrconf_dad_work+0x764/0x1390\nprocess_one_work+0xa32/0x16f0\nworker_thread+0x67d/0x10c0\nkthread+0x344/0x440\nret_from_fork+0x1f/0x30\nThe buggy address belongs to the object at ffff888111145800\nwhich belongs to the cache skbuff_small_head of size 640\nThe buggy address is located 239 bytes inside of\nfreed 640-byte region [ffff888111145800, ffff888111145a80)\n\nAs commit f855691975bb ("xfrm6: Fix the nexthdr offset in\n_decode_session6.") showed, xfrm_decode_session was originally intended\nonly for the receive path. IP6CB(skb)->nhoff is not set during\ntransmission. Therefore, set the cb field in the skb to 0 before\nsending packets.

In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio_net: Fix error unwinding of XDP initialization\n\nWhen initializing XDP in virtnet_open(), some rq xdp initialization\nmay hit an error causing net device open failed. However, previous\nrqs have already initialized XDP and enabled NAPI, which is not the\nexpected behavior. Need to roll back the previous rq initialization\nto avoid leaks in error unwinding of init code.\n\nAlso extract helper functions of disable and enable queue pairs.\nUse newly introduced disable helper function in error unwinding and\nvirtnet_close. Use enable helper function in virtnet_open.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Fix potential null dereference\n\nThe adev->dm.dc pointer can be NULL and dereferenced in amdgpu_dm_fini()\nwithout checking.\n\nAdd a NULL pointer check before calling dc_dmub_srv_destroy().\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: vsp1: Replace vb2_is_streaming() with vb2_start_streaming_called()\n\nThe vsp1 driver uses the vb2_is_streaming() function in its .buf_queue()\nhandler to check if the .start_streaming() operation has been called,\nand decide whether to just add the buffer to an internal queue, or also\ntrigger a hardware run. vb2_is_streaming() relies on the vb2_queue\nstructure's streaming field, which used to be set only after calling the\n.start_streaming() operation.\n\nCommit a10b21532574 ("media: vb2: add (un)prepare_streaming queue ops")\nchanged this, setting the .streaming field in vb2_core_streamon() before\nenqueuing buffers to the driver and calling .start_streaming(). This\nbroke the vsp1 driver which now believes that .start_streaming() has\nbeen called when it hasn't, leading to a crash:\n\n[ 881.058705] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020\n[ 881.067495] Mem abort info:\n[ 881.070290] ESR = 0x0000000096000006\n[ 881.074042] EC = 0x25: DABT (current EL), IL = 32 bits\n[ 881.079358] SET = 0, FnV = 0\n[ 881.082414] EA = 0, S1PTW = 0\n[ 881.085558] FSC = 0x06: level 2 translation fault\n[ 881.090439] Data abort info:\n[ 881.093320] ISV = 0, ISS = 0x00000006\n[ 881.097157] CM = 0, WnR = 0\n[ 881.100126] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004fa51000\n[ 881.106573] [0000000000000020] pgd=080000004f36e003, p4d=080000004f36e003, pud=080000004f7ec003, pmd=0000000000000000\n[ 881.117217] Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP\n[ 881.123494] Modules linked in: rcar_fdp1 v4l2_mem2mem\n[ 881.128572] CPU: 0 PID: 1271 Comm: yavta Tainted: G B 6.2.0-rc1-00023-g6c94e2e99343 #556\n[ 881.138061] Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT)\n[ 881.145981] pstate: 400000c5 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 881.152951] pc : vsp1_dl_list_add_body+0xa8/0xe0\n[ 881.157580] lr : vsp1_dl_list_add_body+0x34/0xe0\n[ 881.162206] sp : ffff80000c267710\n[ 881.165522] x29: ffff80000c267710 x28: ffff000010938ae8 x27: ffff000013a8dd98\n[ 881.172683] x26: ffff000010938098 x25: ffff000013a8dc00 x24: ffff000010ed6ba8\n[ 881.179841] x23: ffff00000faa4000 x22: 0000000000000000 x21: 0000000000000020\n[ 881.186998] x20: ffff00000faa4000 x19: 0000000000000000 x18: 0000000000000000\n[ 881.194154] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\n[ 881.201309] x14: 0000000000000000 x13: 746e696174206c65 x12: ffff70000157043d\n[ 881.208465] x11: 1ffff0000157043c x10: ffff70000157043c x9 : dfff800000000000\n[ 881.215622] x8 : ffff80000ab821e7 x7 : 00008ffffea8fbc4 x6 : 0000000000000001\n[ 881.222779] x5 : ffff80000ab821e0 x4 : ffff70000157043d x3 : 0000000000000020\n[ 881.229936] x2 : 0000000000000020 x1 : ffff00000e4f6400 x0 : 0000000000000000\n[ 881.237092] Call trace:\n[ 881.239542] vsp1_dl_list_add_body+0xa8/0xe0\n[ 881.243822] vsp1_video_pipeline_run+0x270/0x2a0\n[ 881.248449] vsp1_video_buffer_queue+0x1c0/0x1d0\n[ 881.253076] __enqueue_in_driver+0xbc/0x260\n[ 881.257269] vb2_start_streaming+0x48/0x200\n[ 881.261461] vb2_core_streamon+0x13c/0x280\n[ 881.265565] vb2_streamon+0x3c/0x90\n[ 881.269064] vsp1_video_streamon+0x2fc/0x3e0\n[ 881.273344] v4l_streamon+0x50/0x70\n[ 881.276844] __video_do_ioctl+0x2bc/0x5d0\n[ 881.280861] video_usercopy+0x2a8/0xc80\n[ 881.284704] video_ioctl2+0x20/0x40\n[ 881.288201] v4l2_ioctl+0xa4/0xc0\n[ 881.291525] __arm64_sys_ioctl+0xe8/0x110\n[ 881.295543] invoke_syscall+0x68/0x190\n[ 881.299303] el0_svc_common.constprop.0+0x88/0x170\n[ 881.304105] do_el0_svc+0x4c/0xf0\n[ 881.307430] el0_svc+0x4c/0xa0\n[ 881.310494] el0t_64_sync_handler+0xbc/0x140\n[ 881.314773] el0t_64_sync+0x190/0x194\n[ 881.318450] Code: d50323bf d65f03c0 91008263 f9800071 (885f7c60)\n[ 881.324551] ---[ end trace 0000000000000000 ]---\n[ 881.329173] note: yavta[1271] exited with preempt_count 1\n\nA different r\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nx86/platform/uv: Use alternate source for socket to node data\n\nThe UV code attempts to build a set of tables to allow it to do\nbidirectional socket<=>node lookups.\n\nBut when nr_cpus is set to a smaller number than actually present, the\ncpu_to_node() mapping information for unused CPUs is not available to\nbuild_socket_tables(). This results in skipping some nodes or sockets\nwhen creating the tables and leaving some -1's for later code to trip.\nover, causing oopses.\n\nThe problem is that the socket<=>node lookups are created by doing a\nloop over all CPUs, then looking up the CPU's APICID and socket. But\nif a CPU is not present, there is no way to start this lookup.\n\nInstead of looping over all CPUs, take CPUs out of the equation\nentirely. Loop over all APICIDs which are mapped to a valid NUMA node.\nThen just extract the socket-id from the APICID.\n\nThis avoid tripping over disabled CPUs.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ethernet: mvpp2_main: fix possible OOB write in mvpp2_ethtool_get_rxnfc()\n\nrules is allocated in ethtool_get_rxnfc and the size is determined by\nrule_cnt from user space. So rule_cnt needs to be check before using\nrules to avoid OOB writing or NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: xts - Handle EBUSY correctly\n\nAs it is xts only handles the special return value of EINPROGRESS,\nwhich means that in all other cases it will free data related to the\nrequest.\n\nHowever, as the caller of xts may specify MAY_BACKLOG, we also need\nto expect EBUSY and treat it in the same way. Otherwise backlogged\nrequests will trigger a use-after-free.

In the Linux kernel, the following vulnerability has been resolved:\n\naccel/qaic: tighten bounds checking in decode_message()\n\nCopy the bounds checking from encode_message() to decode_message().\n\nThis patch addresses the following concerns. Ensure that there is\nenough space for at least one header so that we don't have a negative\nsize later.\n\n if (msg_hdr_len < sizeof(*trans_hdr))\n\nEnsure that we have enough space to read the next header from the\nmsg->data.\n\n if (msg_len > msg_hdr_len - sizeof(*trans_hdr))\n return -EINVAL;\n\nCheck that the trans_hdr->len is not below the minimum size:\n\n if (hdr_len < sizeof(*trans_hdr))\n\nThis minimum check ensures that we don't corrupt memory in\ndecode_passthrough() when we do.\n\n memcpy(out_trans->data, in_trans->data, len - sizeof(in_trans->hdr));\n\nAnd finally, use size_add() to prevent an integer overflow:\n\n if (size_add(msg_len, hdr_len) > msg_hdr_len)

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: do not ignore genmask when looking up chain by id\n\nWhen adding a rule to a chain referring to its ID, if that chain had been\ndeleted on the same batch, the rule might end up referring to a deleted\nchain.\n\nThis will lead to a WARNING like following:\n\n[ 33.098431] ------------[ cut here ]------------\n[ 33.098678] WARNING: CPU: 5 PID: 69 at net/netfilter/nf_tables_api.c:2037 nf_tables_chain_destroy+0x23d/0x260\n[ 33.099217] Modules linked in:\n[ 33.099388] CPU: 5 PID: 69 Comm: kworker/5:1 Not tainted 6.4.0+ #409\n[ 33.099726] Workqueue: events nf_tables_trans_destroy_work\n[ 33.100018] RIP: 0010:nf_tables_chain_destroy+0x23d/0x260\n[ 33.100306] Code: 8b 7c 24 68 e8 64 9c ed fe 4c 89 e7 e8 5c 9c ed fe 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 89 c6 89 c7 c3 cc cc cc cc <0f> 0b 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 89 c6 89 c7\n[ 33.101271] RSP: 0018:ffffc900004ffc48 EFLAGS: 00010202\n[ 33.101546] RAX: 0000000000000001 RBX: ffff888006fc0a28 RCX: 0000000000000000\n[ 33.101920] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\n[ 33.102649] RBP: ffffc900004ffc78 R08: 0000000000000000 R09: 0000000000000000\n[ 33.103018] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8880135ef500\n[ 33.103385] R13: 0000000000000000 R14: dead000000000122 R15: ffff888006fc0a10\n[ 33.103762] FS: 0000000000000000(0000) GS:ffff888024c80000(0000) knlGS:0000000000000000\n[ 33.104184] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 33.104493] CR2: 00007fe863b56a50 CR3: 00000000124b0001 CR4: 0000000000770ee0\n[ 33.104872] PKRU: 55555554\n[ 33.104999] Call Trace:\n[ 33.105113] \n[ 33.105214] ? show_regs+0x72/0x90\n[ 33.105371] ? __warn+0xa5/0x210\n[ 33.105520] ? nf_tables_chain_destroy+0x23d/0x260\n[ 33.105732] ? report_bug+0x1f2/0x200\n[ 33.105902] ? handle_bug+0x46/0x90\n[ 33.106546] ? exc_invalid_op+0x19/0x50\n[ 33.106762] ? asm_exc_invalid_op+0x1b/0x20\n[ 33.106995] ? nf_tables_chain_destroy+0x23d/0x260\n[ 33.107249] ? nf_tables_chain_destroy+0x30/0x260\n[ 33.107506] nf_tables_trans_destroy_work+0x669/0x680\n[ 33.107782] ? mark_held_locks+0x28/0xa0\n[ 33.107996] ? __pfx_nf_tables_trans_destroy_work+0x10/0x10\n[ 33.108294] ? _raw_spin_unlock_irq+0x28/0x70\n[ 33.108538] process_one_work+0x68c/0xb70\n[ 33.108755] ? lock_acquire+0x17f/0x420\n[ 33.108977] ? __pfx_process_one_work+0x10/0x10\n[ 33.109218] ? do_raw_spin_lock+0x128/0x1d0\n[ 33.109435] ? _raw_spin_lock_irq+0x71/0x80\n[ 33.109634] worker_thread+0x2bd/0x700\n[ 33.109817] ? __pfx_worker_thread+0x10/0x10\n[ 33.110254] kthread+0x18b/0x1d0\n[ 33.110410] ? __pfx_kthread+0x10/0x10\n[ 33.110581] ret_from_fork+0x29/0x50\n[ 33.110757] \n[ 33.110866] irq event stamp: 1651\n[ 33.111017] hardirqs last enabled at (1659): [] __up_console_sem+0x79/0xa0\n[ 33.111379] hardirqs last disabled at (1666): [] __up_console_sem+0x5e/0xa0\n[ 33.111740] softirqs last enabled at (1616): [] __irq_exit_rcu+0x9e/0xe0\n[ 33.112094] softirqs last disabled at (1367): [] __irq_exit_rcu+0x9e/0xe0\n[ 33.112453] ---[ end trace 0000000000000000 ]---\n\nThis is due to the nft_chain_lookup_byid ignoring the genmask. After this\nchange, adding the new rule will fail as it will not find the chain.

In the Linux kernel, the following vulnerability has been resolved:\n\nstart_kernel: Add __no_stack_protector function attribute\n\nBack during the discussion of\ncommit a9a3ed1eff36 ("x86: Fix early boot crash on gcc-10, third try")\nwe discussed the need for a function attribute to control the omission\nof stack protectors on a per-function basis; at the time Clang had\nsupport for no_stack_protector but GCC did not. This was fixed in\ngcc-11. Now that the function attribute is available, let's start using\nit.\n\nCallers of boot_init_stack_canary need to use this function attribute\nunless they're compiled with -fno-stack-protector, otherwise the canary\nstored in the stack slot of the caller will differ upon the call to\nboot_init_stack_canary. This will lead to a call to __stack_chk_fail()\nthen panic.

In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix disconnect vs accept race\n\nDespite commit 0ad529d9fd2b ("mptcp: fix possible divide by zero in\nrecvmsg()"), the mptcp protocol is still prone to a race between\ndisconnect() (or shutdown) and accept.\n\nThe root cause is that the mentioned commit checks the msk-level\nflag, but mptcp_stream_accept() does acquire the msk-level lock,\nas it can rely directly on the first subflow lock.\n\nAs reported by Christoph than can lead to a race where an msk\nsocket is accepted after that mptcp_subflow_queue_clean() releases\nthe listener socket lock and just before it takes destructive\nactions leading to the following splat:\n\nBUG: kernel NULL pointer dereference, address: 0000000000000012\nPGD 5a4ca067 P4D 5a4ca067 PUD 37d4c067 PMD 0\nOops: 0000 [#1] PREEMPT SMP\nCPU: 2 PID: 10955 Comm: syz-executor.5 Not tainted 6.5.0-rc1-gdc7b257ee5dd #37\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014\nRIP: 0010:mptcp_stream_accept+0x1ee/0x2f0 include/net/inet_sock.h:330\nCode: 0a 09 00 48 8b 1b 4c 39 e3 74 07 e8 bc 7c 7f fe eb a1 e8 b5 7c 7f fe 4c 8b 6c 24 08 eb 05 e8 a9 7c 7f fe 49 8b 85 d8 09 00 00 <0f> b6 40 12 88 44 24 07 0f b6 6c 24 07 bf 07 00 00 00 89 ee e8 89\nRSP: 0018:ffffc90000d07dc0 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: ffff888037e8d020 RCX: ffff88803b093300\nRDX: 0000000000000000 RSI: ffffffff833822c5 RDI: ffffffff8333896a\nRBP: 0000607f82031520 R08: ffff88803b093300 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000003e83 R12: ffff888037e8d020\nR13: ffff888037e8c680 R14: ffff888009af7900 R15: ffff888009af6880\nFS: 00007fc26d708640(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000012 CR3: 0000000066bc5001 CR4: 0000000000370ee0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \n do_accept+0x1ae/0x260 net/socket.c:1872\n __sys_accept4+0x9b/0x110 net/socket.c:1913\n __do_sys_accept4 net/socket.c:1954 [inline]\n __se_sys_accept4 net/socket.c:1951 [inline]\n __x64_sys_accept4+0x20/0x30 net/socket.c:1951\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x47/0xa0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n\nAddress the issue by temporary removing the pending request socket\nfrom the accept queue, so that racing accept() can't touch them.\n\nAfter depleting the msk - the ssk still exists, as plain TCP sockets,\nre-insert them into the accept queue, so that later inet_csk_listen_stop()\nwill complete the tcp socket disposal.

In the Linux kernel, the following vulnerability has been resolved:\n\ntcp/udp: Fix memleaks of sk and zerocopy skbs with TX timestamp.\n\nsyzkaller reported [0] memory leaks of an UDP socket and ZEROCOPY\nskbs. We can reproduce the problem with these sequences:\n\n sk = socket(AF_INET, SOCK_DGRAM, 0)\n sk.setsockopt(SOL_SOCKET, SO_TIMESTAMPING, SOF_TIMESTAMPING_TX_SOFTWARE)\n sk.setsockopt(SOL_SOCKET, SO_ZEROCOPY, 1)\n sk.sendto(b'', MSG_ZEROCOPY, ('127.0.0.1', 53))\n sk.close()\n\nsendmsg() calls msg_zerocopy_alloc(), which allocates a skb, sets\nskb->cb->ubuf.refcnt to 1, and calls sock_hold(). Here, struct\nubuf_info_msgzc indirectly holds a refcnt of the socket. When the\nskb is sent, __skb_tstamp_tx() clones it and puts the clone into\nthe socket's error queue with the TX timestamp.\n\nWhen the original skb is received locally, skb_copy_ubufs() calls\nskb_unclone(), and pskb_expand_head() increments skb->cb->ubuf.refcnt.\nThis additional count is decremented while freeing the skb, but struct\nubuf_info_msgzc still has a refcnt, so __msg_zerocopy_callback() is\nnot called.\n\nThe last refcnt is not released unless we retrieve the TX timestamped\nskb by recvmsg(). Since we clear the error queue in inet_sock_destruct()\nafter the socket's refcnt reaches 0, there is a circular dependency.\nIf we close() the socket holding such skbs, we never call sock_put()\nand leak the count, sk, and skb.\n\nTCP has the same problem, and commit e0c8bccd40fc ("net: stream:\npurge sk_error_queue in sk_stream_kill_queues()") tried to fix it\nby calling skb_queue_purge() during close(). However, there is a\nsmall chance that skb queued in a qdisc or device could be put\ninto the error queue after the skb_queue_purge() call.\n\nIn __skb_tstamp_tx(), the cloned skb should not have a reference\nto the ubuf to remove the circular dependency, but skb_clone() does\nnot call skb_copy_ubufs() for zerocopy skb. So, we need to call\nskb_orphan_frags_rx() for the cloned skb to call skb_copy_ubufs().\n\n[0]:\nBUG: memory leak\nunreferenced object 0xffff88800c6d2d00 (size 1152):\n comm "syz-executor392", pid 264, jiffies 4294785440 (age 13.044s)\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 cd af e8 81 00 00 00 00 ................\n 02 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............\n backtrace:\n [<0000000055636812>] sk_prot_alloc+0x64/0x2a0 net/core/sock.c:2024\n [<0000000054d77b7a>] sk_alloc+0x3b/0x800 net/core/sock.c:2083\n [<0000000066f3c7e0>] inet_create net/ipv4/af_inet.c:319 [inline]\n [<0000000066f3c7e0>] inet_create+0x31e/0xe40 net/ipv4/af_inet.c:245\n [<000000009b83af97>] __sock_create+0x2ab/0x550 net/socket.c:1515\n [<00000000b9b11231>] sock_create net/socket.c:1566 [inline]\n [<00000000b9b11231>] __sys_socket_create net/socket.c:1603 [inline]\n [<00000000b9b11231>] __sys_socket_create net/socket.c:1588 [inline]\n [<00000000b9b11231>] __sys_socket+0x138/0x250 net/socket.c:1636\n [<000000004fb45142>] __do_sys_socket net/socket.c:1649 [inline]\n [<000000004fb45142>] __se_sys_socket net/socket.c:1647 [inline]\n [<000000004fb45142>] __x64_sys_socket+0x73/0xb0 net/socket.c:1647\n [<0000000066999e0e>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n [<0000000066999e0e>] do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80\n [<0000000017f238c1>] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nBUG: memory leak\nunreferenced object 0xffff888017633a00 (size 240):\n comm "syz-executor392", pid 264, jiffies 4294785440 (age 13.044s)\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 00 00 00 00 00 00 00 00 00 2d 6d 0c 80 88 ff ff .........-m.....\n backtrace:\n [<000000002b1c4368>] __alloc_skb+0x229/0x320 net/core/skbuff.c:497\n [<00000000143579a6>] alloc_skb include/linux/skbuff.h:1265 [inline]\n [<00000000143579a6>] sock_omalloc+0xaa/0x190 net/core/sock.c:2596\n [<00000000be626478>] msg_zerocopy_alloc net/core/skbuff.c:1294 [inline]\n [<00000000be626478>]\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nIB/hfi1: Fix possible panic during hotplug remove\n\nDuring hotplug remove it is possible that the update counters work\nmight be pending, and may run after memory has been freed.\nCancel the update counters work before freeing memory.

In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/rtas_flash: allow user copy to flash block cache objects\n\nWith hardened usercopy enabled (CONFIG_HARDENED_USERCOPY=y), using the\n/proc/powerpc/rtas/firmware_update interface to prepare a system\nfirmware update yields a BUG():\n\n kernel BUG at mm/usercopy.c:102!\n Oops: Exception in kernel mode, sig: 5 [#1]\n LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries\n Modules linked in:\n CPU: 0 PID: 2232 Comm: dd Not tainted 6.5.0-rc3+ #2\n Hardware name: IBM,8408-E8E POWER8E (raw) 0x4b0201 0xf000004 of:IBM,FW860.50 (SV860_146) hv:phyp pSeries\n NIP: c0000000005991d0 LR: c0000000005991cc CTR: 0000000000000000\n REGS: c0000000148c76a0 TRAP: 0700 Not tainted (6.5.0-rc3+)\n MSR: 8000000000029033 CR: 24002242 XER: 0000000c\n CFAR: c0000000001fbd34 IRQMASK: 0\n [ ... GPRs omitted ... ]\n NIP usercopy_abort+0xa0/0xb0\n LR usercopy_abort+0x9c/0xb0\n Call Trace:\n usercopy_abort+0x9c/0xb0 (unreliable)\n __check_heap_object+0x1b4/0x1d0\n __check_object_size+0x2d0/0x380\n rtas_flash_write+0xe4/0x250\n proc_reg_write+0xfc/0x160\n vfs_write+0xfc/0x4e0\n ksys_write+0x90/0x160\n system_call_exception+0x178/0x320\n system_call_common+0x160/0x2c4\n\nThe blocks of the firmware image are copied directly from user memory\nto objects allocated from flash_block_cache, so flash_block_cache must\nbe created using kmem_cache_create_usercopy() to mark it safe for user\naccess.\n\n[mpe: Trim and indent oops]

In the Linux kernel, the following vulnerability has been resolved:\n\nfs: jfs: Fix UBSAN: array-index-out-of-bounds in dbAllocDmapLev\n\nSyzkaller reported the following issue:\n\nUBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:1965:6\nindex -84 is out of range for type 's8[341]' (aka 'signed char[341]')\nCPU: 1 PID: 4995 Comm: syz-executor146 Not tainted 6.4.0-rc6-syzkaller-00037-gb6dad5178cea #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023\nCall Trace:\n \n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106\n ubsan_epilogue lib/ubsan.c:217 [inline]\n __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348\n dbAllocDmapLev+0x3e5/0x430 fs/jfs/jfs_dmap.c:1965\n dbAllocCtl+0x113/0x920 fs/jfs/jfs_dmap.c:1809\n dbAllocAG+0x28f/0x10b0 fs/jfs/jfs_dmap.c:1350\n dbAlloc+0x658/0xca0 fs/jfs/jfs_dmap.c:874\n dtSplitUp fs/jfs/jfs_dtree.c:974 [inline]\n dtInsert+0xda7/0x6b00 fs/jfs/jfs_dtree.c:863\n jfs_create+0x7b6/0xbb0 fs/jfs/namei.c:137\n lookup_open fs/namei.c:3492 [inline]\n open_last_lookups fs/namei.c:3560 [inline]\n path_openat+0x13df/0x3170 fs/namei.c:3788\n do_filp_open+0x234/0x490 fs/namei.c:3818\n do_sys_openat2+0x13f/0x500 fs/open.c:1356\n do_sys_open fs/open.c:1372 [inline]\n __do_sys_openat fs/open.c:1388 [inline]\n __se_sys_openat fs/open.c:1383 [inline]\n __x64_sys_openat+0x247/0x290 fs/open.c:1383\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\nRIP: 0033:0x7f1f4e33f7e9\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 14 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007ffc21129578 EFLAGS: 00000246 ORIG_RAX: 0000000000000101\nRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1f4e33f7e9\nRDX: 000000000000275a RSI: 0000000020000040 RDI: 00000000ffffff9c\nRBP: 00007f1f4e2ff080 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 00007f1f4e2ff110\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n \n\nThe bug occurs when the dbAllocDmapLev()function attempts to access\ndp->tree.stree[leafidx + LEAFIND] while the leafidx value is negative.\n\nTo rectify this, the patch introduces a safeguard within the\ndbAllocDmapLev() function. A check has been added to verify if leafidx is\nnegative. If it is, the function immediately returns an I/O error, preventing\nany further execution that could potentially cause harm.\n\nTested via syzbot.

In the Linux kernel, the following vulnerability has been resolved:\n\nlib: cpu_rmap: Avoid use after free on rmap->obj array entries\n\nWhen calling irq_set_affinity_notifier() with NULL at the notify\nargument, it will cause freeing of the glue pointer in the\ncorresponding array entry but will leave the pointer in the array. A\nsubsequent call to free_irq_cpu_rmap() will try to free this entry again\nleading to possible use after free.\n\nFix that by setting NULL to the array entry and checking that we have\nnon-zero at the array entry when iterating over the array in\nfree_irq_cpu_rmap().\n\nThe current code does not suffer from this since there are no cases\nwhere irq_set_affinity_notifier(irq, NULL) (note the NULL passed for the\nnotify arg) is called, followed by a call to free_irq_cpu_rmap() so we\ndon't hit and issue. Subsequent patches in this series excersize this\nflow, hence the required fix.

In the Linux kernel, the following vulnerability has been resolved:\n\niommu: Fix error unwind in iommu_group_alloc()\n\nIf either iommu_group_grate_file() fails then the\niommu_group is leaked.\n\nDestroy it on these error paths.\n\nFound by kselftest/iommu/iommufd_fail_nth

In the Linux kernel, the following vulnerability has been resolved:\n\nubi: ubi_wl_put_peb: Fix infinite loop when wear-leveling work failed\n\nFollowing process will trigger an infinite loop in ubi_wl_put_peb():\n\n ubifs_bgt ubi_bgt\nubifs_leb_unmap\n ubi_leb_unmap\n ubi_eba_unmap_leb\n ubi_wl_put_peb wear_leveling_worker\n e1 = rb_entry(rb_first(&ubi->used)\n e2 = get_peb_for_wl(ubi)\n ubi_io_read_vid_hdr // return err (flash fault)\n out_error:\n ubi->move_from = ubi->move_to = NULL\n wl_entry_destroy(ubi, e1)\n ubi->lookuptbl[e->pnum] = NULL\n retry:\n e = ubi->lookuptbl[pnum]; // return NULL\n if (e == ubi->move_from) { // NULL == NULL gets true\n goto retry; // infinite loop !!!\n\n$ top\n PID USER PR NI VIRT RES SHR S %CPU %MEM COMMAND\n 7676 root 20 0 0 0 0 R 100.0 0.0 ubifs_bgt0_0\n\nFix it by:\n 1) Letting ubi_wl_put_peb() returns directly if wearl leveling entry has\n been removed from 'ubi->lookuptbl'.\n 2) Using 'ubi->wl_lock' protecting wl entry deletion to preventing an\n use-after-free problem for wl entry in ubi_wl_put_peb().\n\nFetch a reproducer in [Link].

In the Linux kernel, the following vulnerability has been resolved:\n\nkobject: Add sanity check for kset->kobj.ktype in kset_register()\n\nWhen I register a kset in the following way:\n static struct kset my_kset;\n kobject_set_name(&my_kset.kobj, "my_kset");\n ret = kset_register(&my_kset);\n\nA null pointer dereference exception is occurred:\n[ 4453.568337] Unable to handle kernel NULL pointer dereference at \\\nvirtual address 0000000000000028\n... ...\n[ 4453.810361] Call trace:\n[ 4453.813062] kobject_get_ownership+0xc/0x34\n[ 4453.817493] kobject_add_internal+0x98/0x274\n[ 4453.822005] kset_register+0x5c/0xb4\n[ 4453.825820] my_kobj_init+0x44/0x1000 [my_kset]\n... ...\n\nBecause I didn't initialize my_kset.kobj.ktype.\n\nAccording to the description in Documentation/core-api/kobject.rst:\n - A ktype is the type of object that embeds a kobject. Every structure\n that embeds a kobject needs a corresponding ktype.\n\nSo add sanity check to make sure kset->kobj.ktype is not NULL.

In the Linux kernel, the following vulnerability has been resolved:\n\ncxl/acpi: Fix a use-after-free in cxl_parse_cfmws()\n\nKASAN and KFENCE detected an user-after-free in the CXL driver. This\nhappens in the cxl_decoder_add() fail path. KASAN prints the following\nerror:\n\n BUG: KASAN: slab-use-after-free in cxl_parse_cfmws (drivers/cxl/acpi.c:299)\n\nThis happens in cxl_parse_cfmws(), where put_device() is called,\nreleasing cxld, which is accessed later.\n\nUse the local variables in the dev_err() instead of pointing to the\nreleased memory. Since the dev_err() is printing a resource, change the open\ncoded print format to use the %pr format specifier.