In the Linux kernel, the following vulnerability has been resolved:\n\ntracing/synthetic: Fix races on freeing last_cmd\n\nCurrently, the "last_cmd" variable can be accessed by multiple processes\nasynchronously when multiple users manipulate synthetic_events node\nat the same time, it could lead to use-after-free or double-free.\n\nThis patch add "lastcmd_mutex" to prevent "last_cmd" from being accessed\nasynchronously.\n\n================================================================\n\nIt's easy to reproduce in the KASAN environment by running the two\nscripts below in different shells.\n\nscript 1:\n while :\n do\n echo -n -e '\\x88' > /sys/kernel/tracing/synthetic_events\n done\n\nscript 2:\n while :\n do\n echo -n -e '\\xb0' > /sys/kernel/tracing/synthetic_events\n done\n\n================================================================\ndouble-free scenario:\n\n process A process B\n------------------- ---------------\n1.kstrdup last_cmd\n 2.free last_cmd\n3.free last_cmd(double-free)\n\n================================================================\nuse-after-free scenario:\n\n process A process B\n------------------- ---------------\n1.kstrdup last_cmd\n 2.free last_cmd\n3.tracing_log_err(use-after-free)\n\n================================================================\n\nAppendix 1. KASAN report double-free:\n\nBUG: KASAN: double-free in kfree+0xdc/0x1d4\nFree of addr ***** by task sh/4879\nCall trace:\n ...\n kfree+0xdc/0x1d4\n create_or_delete_synth_event+0x60/0x1e8\n trace_parse_run_command+0x2bc/0x4b8\n synth_events_write+0x20/0x30\n vfs_write+0x200/0x830\n ...\n\nAllocated by task 4879:\n ...\n kstrdup+0x5c/0x98\n create_or_delete_synth_event+0x6c/0x1e8\n trace_parse_run_command+0x2bc/0x4b8\n synth_events_write+0x20/0x30\n vfs_write+0x200/0x830\n ...\n\nFreed by task 5464:\n ...\n kfree+0xdc/0x1d4\n create_or_delete_synth_event+0x60/0x1e8\n trace_parse_run_command+0x2bc/0x4b8\n synth_events_write+0x20/0x30\n vfs_write+0x200/0x830\n ...\n\n================================================================\nAppendix 2. KASAN report use-after-free:\n\nBUG: KASAN: use-after-free in strlen+0x5c/0x7c\nRead of size 1 at addr ***** by task sh/5483\nsh: CPU: 7 PID: 5483 Comm: sh\n ...\n __asan_report_load1_noabort+0x34/0x44\n strlen+0x5c/0x7c\n tracing_log_err+0x60/0x444\n create_or_delete_synth_event+0xc4/0x204\n trace_parse_run_command+0x2bc/0x4b8\n synth_events_write+0x20/0x30\n vfs_write+0x200/0x830\n ...\n\nAllocated by task 5483:\n ...\n kstrdup+0x5c/0x98\n create_or_delete_synth_event+0x80/0x204\n trace_parse_run_command+0x2bc/0x4b8\n synth_events_write+0x20/0x30\n vfs_write+0x200/0x830\n ...\n\nFreed by task 5480:\n ...\n kfree+0xdc/0x1d4\n create_or_delete_synth_event+0x74/0x204\n trace_parse_run_command+0x2bc/0x4b8\n synth_events_write+0x20/0x30\n vfs_write+0x200/0x830\n ...

In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: Add lwtunnel encap size of all siblings in nexthop calculation\n\nIn function rt6_nlmsg_size(), the length of nexthop is calculated\nby multipling the nexthop length of fib6_info and the number of\nsiblings. However if the fib6_info has no lwtunnel but the siblings\nhave lwtunnels, the nexthop length is less than it should be, and\nit will trigger a warning in inet6_rt_notify() as follows:\n\nWARNING: CPU: 0 PID: 6082 at net/ipv6/route.c:6180 inet6_rt_notify+0x120/0x130\n......\nCall Trace:\n \n fib6_add_rt2node+0x685/0xa30\n fib6_add+0x96/0x1b0\n ip6_route_add+0x50/0xd0\n inet6_rtm_newroute+0x97/0xa0\n rtnetlink_rcv_msg+0x156/0x3d0\n netlink_rcv_skb+0x5a/0x110\n netlink_unicast+0x246/0x350\n netlink_sendmsg+0x250/0x4c0\n sock_sendmsg+0x66/0x70\n ___sys_sendmsg+0x7c/0xd0\n __sys_sendmsg+0x5d/0xb0\n do_syscall_64+0x3f/0x90\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\n\nThis bug can be reproduced by script:\n\nip -6 addr add 2002::2/64 dev ens2\nip -6 route add 100::/64 via 2002::1 dev ens2 metric 100\n\nfor i in 10 20 30 40 50 60 70;\ndo\n ip link add link ens2 name ipv_$i type ipvlan\n ip -6 addr add 2002::$i/64 dev ipv_$i\n ifconfig ipv_$i up\ndone\n\nfor i in 10 20 30 40 50 60;\ndo\n ip -6 route append 100::/64 encap ip6 dst 2002::$i via 2002::1\ndev ipv_$i metric 100\ndone\n\nip -6 route append 100::/64 via 2002::1 dev ipv_70 metric 100\n\nThis patch fixes it by adding nexthop_len of every siblings using\nrt6_nh_nlmsg_size().

In the Linux kernel, the following vulnerability has been resolved:\n\niw_cxgb4: Fix potential NULL dereference in c4iw_fill_res_cm_id_entry()\n\nThis condition needs to match the previous "if (epcp->state == LISTEN) {"\nexactly to avoid a NULL dereference of either "listen_ep" or "ep". The\nproblem is that "epcp" has been re-assigned so just testing\n"if (epcp->state == LISTEN) {" a second time is not sufficient.

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: xhci: tegra: fix sleep in atomic call\n\nWhen we set the dual-role port to Host mode, we observed the following\nsplat:\n[ 167.057718] BUG: sleeping function called from invalid context at\ninclude/linux/sched/mm.h:229\n[ 167.057872] Workqueue: events tegra_xusb_usb_phy_work\n[ 167.057954] Call trace:\n[ 167.057962] dump_backtrace+0x0/0x210\n[ 167.057996] show_stack+0x30/0x50\n[ 167.058020] dump_stack_lvl+0x64/0x84\n[ 167.058065] dump_stack+0x14/0x34\n[ 167.058100] __might_resched+0x144/0x180\n[ 167.058140] __might_sleep+0x64/0xd0\n[ 167.058171] slab_pre_alloc_hook.constprop.0+0xa8/0x110\n[ 167.058202] __kmalloc_track_caller+0x74/0x2b0\n[ 167.058233] kvasprintf+0xa4/0x190\n[ 167.058261] kasprintf+0x58/0x90\n[ 167.058285] tegra_xusb_find_port_node.isra.0+0x58/0xd0\n[ 167.058334] tegra_xusb_find_port+0x38/0xa0\n[ 167.058380] tegra_xusb_padctl_get_usb3_companion+0x38/0xd0\n[ 167.058430] tegra_xhci_id_notify+0x8c/0x1e0\n[ 167.058473] notifier_call_chain+0x88/0x100\n[ 167.058506] atomic_notifier_call_chain+0x44/0x70\n[ 167.058537] tegra_xusb_usb_phy_work+0x60/0xd0\n[ 167.058581] process_one_work+0x1dc/0x4c0\n[ 167.058618] worker_thread+0x54/0x410\n[ 167.058650] kthread+0x188/0x1b0\n[ 167.058672] ret_from_fork+0x10/0x20\n\nThe function tegra_xusb_padctl_get_usb3_companion eventually calls\ntegra_xusb_find_port and this in turn calls kasprintf which might sleep\nand so cannot be called from an atomic context.\n\nFix this by moving the call to tegra_xusb_padctl_get_usb3_companion to\nthe tegra_xhci_id_work function where it is really needed.

In the Linux kernel, the following vulnerability has been resolved:\n\nx86/MCE/AMD: Use an u64 for bank_map\n\nThee maximum number of MCA banks is 64 (MAX_NR_BANKS), see\n\n a0bc32b3cacf ("x86/mce: Increase maximum number of banks to 64").\n\nHowever, the bank_map which contains a bitfield of which banks to\ninitialize is of type unsigned int and that overflows when those bit\nnumbers are >= 32, leading to UBSAN complaining correctly:\n\n UBSAN: shift-out-of-bounds in arch/x86/kernel/cpu/mce/amd.c:1365:38\n shift exponent 32 is too large for 32-bit type 'int'\n\nChange the bank_map to a u64 and use the proper BIT_ULL() macro when\nmodifying bits in there.\n\n [ bp: Rewrite commit message. ]

In the Linux kernel, the following vulnerability has been resolved:\n\next4: improve error handling from ext4_dirhash()\n\nThe ext4_dirhash() will *almost* never fail, especially when the hash\ntree feature was first introduced. However, with the addition of\nsupport of encrypted, casefolded file names, that function can most\ncertainly fail today.\n\nSo make sure the callers of ext4_dirhash() properly check for\nfailures, and reflect the errors back up to their callers.

In the Linux kernel, the following vulnerability has been resolved:\n\npwm: lpc32xx: Remove handling of PWM channels\n\nBecause LPC32xx PWM controllers have only a single output which is\nregistered as the only PWM device/channel per controller, it is known in\nadvance that pwm->hwpwm value is always 0. On basis of this fact\nsimplify the code by removing operations with pwm->hwpwm, there is no\ncontrols which require channel number as input.\n\nEven though I wasn't aware at the time when I forward ported that patch,\nthis fixes a null pointer dereference as lpc32xx->chip.pwms is NULL\nbefore devm_pwmchip_add() is called.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu/gfx: disable gfx9 cp_ecc_error_irq only when enabling legacy gfx ras\n\ngfx9 cp_ecc_error_irq is only enabled when legacy gfx ras is assert.\nSo in gfx_v9_0_hw_fini, interrupt disablement for cp_ecc_error_irq\nshould be executed under such condition, otherwise, an amdgpu_irq_put\ncalltrace will occur.\n\n[ 7283.170322] RIP: 0010:amdgpu_irq_put+0x45/0x70 [amdgpu]\n[ 7283.170964] RSP: 0018:ffff9a5fc3967d00 EFLAGS: 00010246\n[ 7283.170967] RAX: ffff98d88afd3040 RBX: ffff98d89da20000 RCX: 0000000000000000\n[ 7283.170969] RDX: 0000000000000000 RSI: ffff98d89da2bef8 RDI: ffff98d89da20000\n[ 7283.170971] RBP: ffff98d89da20000 R08: ffff98d89da2ca18 R09: 0000000000000006\n[ 7283.170973] R10: ffffd5764243c008 R11: 0000000000000000 R12: 0000000000001050\n[ 7283.170975] R13: ffff98d89da38978 R14: ffffffff999ae15a R15: ffff98d880130105\n[ 7283.170978] FS: 0000000000000000(0000) GS:ffff98d996f00000(0000) knlGS:0000000000000000\n[ 7283.170981] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 7283.170983] CR2: 00000000f7a9d178 CR3: 00000001c42ea000 CR4: 00000000003506e0\n[ 7283.170986] Call Trace:\n[ 7283.170988] \n[ 7283.170989] gfx_v9_0_hw_fini+0x1c/0x6d0 [amdgpu]\n[ 7283.171655] amdgpu_device_ip_suspend_phase2+0x101/0x1a0 [amdgpu]\n[ 7283.172245] amdgpu_device_suspend+0x103/0x180 [amdgpu]\n[ 7283.172823] amdgpu_pmops_freeze+0x21/0x60 [amdgpu]\n[ 7283.173412] pci_pm_freeze+0x54/0xc0\n[ 7283.173419] ? __pfx_pci_pm_freeze+0x10/0x10\n[ 7283.173425] dpm_run_callback+0x98/0x200\n[ 7283.173430] __device_suspend+0x164/0x5f0\n\nv2: drop gfx11 as it's fixed in a different solution by retiring cp_ecc_irq funcs(Hawking)

In the Linux kernel, the following vulnerability has been resolved:\n\nionic: catch failure from devlink_alloc\n\nAdd a check for NULL on the alloc return. If devlink_alloc() fails and\nwe try to use devlink_priv() on the NULL return, the kernel gets very\nunhappy and panics. With this fix, the driver load will still fail,\nbut at least it won't panic the kernel.

In the Linux kernel, the following vulnerability has been resolved:\n\naf_unix: Fix null-ptr-deref in unix_stream_sendpage().\n\nBing-Jhong Billy Jheng reported null-ptr-deref in unix_stream_sendpage()\nwith detailed analysis and a nice repro.\n\nunix_stream_sendpage() tries to add data to the last skb in the peer's\nrecv queue without locking the queue.\n\nIf the peer's FD is passed to another socket and the socket's FD is\npassed to the peer, there is a loop between them. If we close both\nsockets without receiving FD, the sockets will be cleaned up by garbage\ncollection.\n\nThe garbage collection iterates such sockets and unlinks skb with\nFD from the socket's receive queue under the queue's lock.\n\nSo, there is a race where unix_stream_sendpage() could access an skb\nlocklessly that is being released by garbage collection, resulting in\nuse-after-free.\n\nTo avoid the issue, unix_stream_sendpage() must lock the peer's recv\nqueue.\n\nNote the issue does not exist in 6.5+ thanks to the recent sendpage()\nrefactoring.\n\nThis patch is originally written by Linus Torvalds.\n\nBUG: unable to handle page fault for address: ffff988004dd6870\nPF: supervisor read access in kernel mode\nPF: error_code(0x0000) - not-present page\nPGD 0 P4D 0\nPREEMPT SMP PTI\nCPU: 4 PID: 297 Comm: garbage_uaf Not tainted 6.1.46 #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nRIP: 0010:kmem_cache_alloc_node+0xa2/0x1e0\nCode: c0 0f 84 32 01 00 00 41 83 fd ff 74 10 48 8b 00 48 c1 e8 3a 41 39 c5 0f 85 1c 01 00 00 41 8b 44 24 28 49 8b 3c 24 48 8d 4a 40 <49> 8b 1c 06 4c 89 f0 65 48 0f c7 0f 0f 94 c0 84 c0 74 a1 41 8b 44\nRSP: 0018:ffffc9000079fac0 EFLAGS: 00000246\nRAX: 0000000000000070 RBX: 0000000000000005 RCX: 000000000001a284\nRDX: 000000000001a244 RSI: 0000000000400cc0 RDI: 000000000002eee0\nRBP: 0000000000400cc0 R08: 0000000000400cc0 R09: 0000000000000003\nR10: 0000000000000001 R11: 0000000000000000 R12: ffff888003970f00\nR13: 00000000ffffffff R14: ffff988004dd6800 R15: 00000000000000e8\nFS: 00007f174d6f3600(0000) GS:ffff88807db00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffff988004dd6870 CR3: 00000000092be000 CR4: 00000000007506e0\nPKRU: 55555554\nCall Trace:\n \n ? __die_body.cold+0x1a/0x1f\n ? page_fault_oops+0xa9/0x1e0\n ? fixup_exception+0x1d/0x310\n ? exc_page_fault+0xa8/0x150\n ? asm_exc_page_fault+0x22/0x30\n ? kmem_cache_alloc_node+0xa2/0x1e0\n ? __alloc_skb+0x16c/0x1e0\n __alloc_skb+0x16c/0x1e0\n alloc_skb_with_frags+0x48/0x1e0\n sock_alloc_send_pskb+0x234/0x270\n unix_stream_sendmsg+0x1f5/0x690\n sock_sendmsg+0x5d/0x60\n ____sys_sendmsg+0x210/0x260\n ___sys_sendmsg+0x83/0xd0\n ? kmem_cache_alloc+0xc6/0x1c0\n ? avc_disable+0x20/0x20\n ? percpu_counter_add_batch+0x53/0xc0\n ? alloc_empty_file+0x5d/0xb0\n ? alloc_file+0x91/0x170\n ? alloc_file_pseudo+0x94/0x100\n ? __fget_light+0x9f/0x120\n __sys_sendmsg+0x54/0xa0\n do_syscall_64+0x3b/0x90\n entry_SYSCALL_64_after_hwframe+0x69/0xd3\nRIP: 0033:0x7f174d639a7d\nCode: 28 89 54 24 1c 48 89 74 24 10 89 7c 24 08 e8 8a c1 f4 ff 8b 54 24 1c 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 33 44 89 c7 48 89 44 24 08 e8 de c1 f4 ff 48\nRSP: 002b:00007ffcb563ea50 EFLAGS: 00000293 ORIG_RAX: 000000000000002e\nRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f174d639a7d\nRDX: 0000000000000000 RSI: 00007ffcb563eab0 RDI: 0000000000000007\nRBP: 00007ffcb563eb10 R08: 0000000000000000 R09: 00000000ffffffff\nR10: 00000000004040a0 R11: 0000000000000293 R12: 00007ffcb563ec28\nR13: 0000000000401398 R14: 0000000000403e00 R15: 00007f174d72c000\n

In the Linux kernel, the following vulnerability has been resolved:\nubifs: Fix memory leak in alloc_wbufs()\nkmemleak reported a sequence of memory leaks, and show them as following:\nunreferenced object 0xffff8881575f8400 (size 1024):\ncomm "mount", pid 19625, jiffies 4297119604 (age 20.383s)\nhex dump (first 32 bytes):\n00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\nbacktrace:\n[] __kmalloc+0x4d/0x150\n[] ubifs_mount+0x307b/0x7170 [ubifs]\n[] legacy_get_tree+0xed/0x1d0\n[] vfs_get_tree+0x7d/0x230\n[] path_mount+0xdd4/0x17b0\n[] __x64_sys_mount+0x1fa/0x270\n[] do_syscall_64+0x35/0x80\n[] entry_SYSCALL_64_after_hwframe+0x46/0xb0\nunreferenced object 0xffff8881798a6e00 (size 512):\ncomm "mount", pid 19677, jiffies 4297121912 (age 37.816s)\nhex dump (first 32 bytes):\n6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk\n6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk\nbacktrace:\n[] __kmalloc+0x4d/0x150\n[] ubifs_wbuf_init+0x52/0x480 [ubifs]\n[] ubifs_mount+0x31f5/0x7170 [ubifs]\n[] legacy_get_tree+0xed/0x1d0\n[] vfs_get_tree+0x7d/0x230\n[] path_mount+0xdd4/0x17b0\n[] __x64_sys_mount+0x1fa/0x270\n[] do_syscall_64+0x35/0x80\n[] entry_SYSCALL_64_after_hwframe+0x46/0xb0\nThe problem is that the ubifs_wbuf_init() returns an error in the\nloop which in the alloc_wbufs(), then the wbuf->buf and wbuf->inodes\nthat were successfully alloced before are not freed.\nFix it by adding error hanging path in alloc_wbufs() which frees\nthe memory alloced before when ubifs_wbuf_init() returns an error.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtw89: fix potential leak in rtw89_append_probe_req_ie()\n\nDo `kfree_skb(new)` before `goto out` to prevent potential leak.

In the Linux kernel, the following vulnerability has been resolved:\nwifi: mt76: mt7915: fix memory leak in mt7915_mcu_exit\nAlways purge mcu skb queues in mt7915_mcu_exit routine even if\nmt7915_firmware_state fails.

In the Linux kernel, the following vulnerability has been resolved:\n\nsoundwire: qcom: fix storing port config out-of-bounds\n\nThe 'qcom_swrm_ctrl->pconfig' has size of QCOM_SDW_MAX_PORTS (14),\nhowever we index it starting from 1, not 0, to match real port numbers.\nThis can lead to writing port config past 'pconfig' bounds and\noverwriting next member of 'qcom_swrm_ctrl' struct. Reported also by\nsmatch:\n\n drivers/soundwire/qcom.c:1269 qcom_swrm_get_port_config() error: buffer overflow 'ctrl->pconfig' 14 <= 14

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: iscsi_tcp: Check that sock is valid before iscsi_set_param()\n\nThe validity of sock should be checked before assignment to avoid incorrect\nvalues. Commit 57569c37f0ad ("scsi: iscsi: iscsi_tcp: Fix null-ptr-deref\nwhile calling getpeername()") introduced this change which may lead to\ninconsistent values of tcp_sw_conn->sendpage and conn->datadgst_en.\n\nFix the issue by moving the position of the assignment.

In the Linux kernel, the following vulnerability has been resolved:\n\nibmvnic: Do not reset dql stats on NON_FATAL err\n\nAll ibmvnic resets, make a call to netdev_tx_reset_queue() when\nre-opening the device. netdev_tx_reset_queue() resets the num_queued\nand num_completed byte counters. These stats are used in Byte Queue\nLimit (BQL) algorithms. The difference between these two stats tracks\nthe number of bytes currently sitting on the physical NIC. ibmvnic\nincreases the number of queued bytes though calls to\nnetdev_tx_sent_queue() in the drivers xmit function. When, VIOS reports\nthat it is done transmitting bytes, the ibmvnic device increases the\nnumber of completed bytes through calls to netdev_tx_completed_queue().\nIt is important to note that the driver batches its transmit calls and\nnum_queued is increased every time that an skb is added to the next\nbatch, not necessarily when the batch is sent to VIOS for transmission.\n\nUnlike other reset types, a NON FATAL reset will not flush the sub crq\ntx buffers. Therefore, it is possible for the batched skb array to be\npartially full. So if there is call to netdev_tx_reset_queue() when\nre-opening the device, the value of num_queued (0) would not account\nfor the skb's that are currently batched. Eventually, when the batch\nis sent to VIOS, the call to netdev_tx_completed_queue() would increase\nnum_completed to a value greater than the num_queued. This causes a\nBUG_ON crash:\n\nibmvnic 30000002: Firmware reports error, cause: adapter problem.\nStarting recovery...\nibmvnic 30000002: tx error 600\nibmvnic 30000002: tx error 600\nibmvnic 30000002: tx error 600\nibmvnic 30000002: tx error 600\n------------[ cut here ]------------\nkernel BUG at lib/dynamic_queue_limits.c:27!\nOops: Exception in kernel mode, sig: 5\n[....]\nNIP dql_completed+0x28/0x1c0\nLR ibmvnic_complete_tx.isra.0+0x23c/0x420 [ibmvnic]\nCall Trace:\nibmvnic_complete_tx.isra.0+0x3f8/0x420 [ibmvnic] (unreliable)\nibmvnic_interrupt_tx+0x40/0x70 [ibmvnic]\n__handle_irq_event_percpu+0x98/0x270\n---[ end trace ]---\n\nTherefore, do not reset the dql stats when performing a NON_FATAL reset.

In the Linux kernel, the following vulnerability has been resolved:\n\nhsr: Fix uninit-value access in fill_frame_info()\n\nSyzbot reports the following uninit-value access problem.\n\n=====================================================\nBUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:601 [inline]\nBUG: KMSAN: uninit-value in hsr_forward_skb+0x9bd/0x30f0 net/hsr/hsr_forward.c:616\n fill_frame_info net/hsr/hsr_forward.c:601 [inline]\n hsr_forward_skb+0x9bd/0x30f0 net/hsr/hsr_forward.c:616\n hsr_dev_xmit+0x192/0x330 net/hsr/hsr_device.c:223\n __netdev_start_xmit include/linux/netdevice.h:4889 [inline]\n netdev_start_xmit include/linux/netdevice.h:4903 [inline]\n xmit_one net/core/dev.c:3544 [inline]\n dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3560\n __dev_queue_xmit+0x34d0/0x52a0 net/core/dev.c:4340\n dev_queue_xmit include/linux/netdevice.h:3082 [inline]\n packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276\n packet_snd net/packet/af_packet.c:3087 [inline]\n packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119\n sock_sendmsg_nosec net/socket.c:730 [inline]\n sock_sendmsg net/socket.c:753 [inline]\n __sys_sendto+0x781/0xa30 net/socket.c:2176\n __do_sys_sendto net/socket.c:2188 [inline]\n __se_sys_sendto net/socket.c:2184 [inline]\n __ia32_sys_sendto+0x11f/0x1c0 net/socket.c:2184\n do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]\n __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178\n do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203\n do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246\n entry_SYSENTER_compat_after_hwframe+0x70/0x82\n\nUninit was created at:\n slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767\n slab_alloc_node mm/slub.c:3478 [inline]\n kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523\n kmalloc_reserve+0x148/0x470 net/core/skbuff.c:559\n __alloc_skb+0x318/0x740 net/core/skbuff.c:644\n alloc_skb include/linux/skbuff.h:1286 [inline]\n alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6299\n sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2794\n packet_alloc_skb net/packet/af_packet.c:2936 [inline]\n packet_snd net/packet/af_packet.c:3030 [inline]\n packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119\n sock_sendmsg_nosec net/socket.c:730 [inline]\n sock_sendmsg net/socket.c:753 [inline]\n __sys_sendto+0x781/0xa30 net/socket.c:2176\n __do_sys_sendto net/socket.c:2188 [inline]\n __se_sys_sendto net/socket.c:2184 [inline]\n __ia32_sys_sendto+0x11f/0x1c0 net/socket.c:2184\n do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]\n __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178\n do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203\n do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246\n entry_SYSENTER_compat_after_hwframe+0x70/0x82\n\nIt is because VLAN not yet supported in hsr driver. Return error\nwhen protocol is ETH_P_8021Q in fill_frame_info() now to fix it.

In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: wait interruptibly for request completions on exit\n\nWHen the ring exits, cleanup is done and the final cancelation and\nwaiting on completions is done by io_ring_exit_work. That function is\ninvoked by kworker, which doesn't take any signals. Because of that, it\ndoesn't really matter if we wait for completions in TASK_INTERRUPTIBLE\nor TASK_UNINTERRUPTIBLE state. However, it does matter to the hung task\ndetection checker!\n\nNormally we expect cancelations and completions to happen rather\nquickly. Some test cases, however, will exit the ring and park the\nowning task stopped (eg via SIGSTOP). If the owning task needs to run\ntask_work to complete requests, then io_ring_exit_work won't make any\nprogress until the task is runnable again. Hence io_ring_exit_work can\ntrigger the hung task detection, which is particularly problematic if\npanic-on-hung-task is enabled.\n\nAs the ring exit doesn't take signals to begin with, have it wait\ninterruptibly rather than uninterruptibly. io_uring has a separate\nstuck-exit warning that triggers independently anyway, so we're not\nreally missing anything by making this switch.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtw88: fix memory leak in rtw_usb_probe()\n\ndrivers/net/wireless/realtek/rtw88/usb.c:876 rtw_usb_probe()\nwarn: 'hw' from ieee80211_alloc_hw() not released on lines: 811\n\nFix this by modifying return to a goto statement.

In the Linux kernel, the following vulnerability has been resolved:\n\nHID: mcp-2221: prevent UAF in delayed work\n\nIf the device is plugged/unplugged without giving time for mcp_init_work()\nto complete, we might kick in the devm free code path and thus have\nunavailable struct mcp_2221 while in delayed work.\n\nCanceling the delayed_work item is enough to solve the issue, because\ncancel_delayed_work_sync will prevent the work item to requeue itself.

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: cx23885: Fix a null-ptr-deref bug in buffer_prepare() and buffer_finish()\n\nWhen the driver calls cx23885_risc_buffer() to prepare the buffer, the\nfunction call dma_alloc_coherent may fail, resulting in a empty buffer\nrisc->cpu. Later when we free the buffer or access the buffer, null ptr\nderef is triggered.\n\nThis bug is similar to the following one:\nhttps://git.linuxtv.org/media_stage.git/commit/?id=2b064d91440b33fba5b452f2d1b31f13ae911d71.\n\nWe believe the bug can be also dynamically triggered from user side.\nSimilarly, we fix this by checking the return value of cx23885_risc_buffer()\nand the value of risc->cpu before buffer free.

In the Linux kernel, the following vulnerability has been resolved:\n\nFS: JFS: Fix null-ptr-deref Read in txBegin\n\n Syzkaller reported an issue where txBegin may be called\n on a superblock in a read-only mounted filesystem which leads\n to NULL pointer deref. This could be solved by checking if\n the filesystem is read-only before calling txBegin, and returning\n with appropiate error code.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla4xxx: Add length check when parsing nlattrs\n\nThere are three places that qla4xxx parses nlattrs:\n\n - qla4xxx_set_chap_entry()\n\n - qla4xxx_iface_set_param()\n\n - qla4xxx_sysfs_ddb_set_param()\n\nand each of them directly converts the nlattr to specific pointer of\nstructure without length checking. This could be dangerous as those\nattributes are not validated and a malformed nlattr (e.g., length 0) could\nresult in an OOB read that leaks heap dirty data.\n\nAdd the nla_len check before accessing the nlattr data and return EINVAL if\nthe length check fails.

In the Linux kernel, the following vulnerability has been resolved:\nHID: multitouch: Correct devm device reference for hidinput input_dev name\nReference the HID device rather than the input device for the devm\nallocation of the input_dev name. Referencing the input_dev would lead to a\nuse-after-free when the input_dev was unregistered and subsequently fires a\nuevent that depends on the name. At the point of firing the uevent, the\nname would be freed by devres management.\nUse devm_kasprintf to simplify the logic for allocating memory and\nformatting the input_dev name string.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtw89: fix potential race condition between napi_init and napi_enable\n\nA race condition can happen if netdev is registered, but NAPI isn't\ninitialized yet, and meanwhile user space starts the netdev that will\nenable NAPI. Then, it hits BUG_ON():\n\n kernel BUG at net/core/dev.c:6423!\n invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\n CPU: 0 PID: 417 Comm: iwd Not tainted 6.2.7-slab-dirty #3 eb0f5a8a9d91\n Hardware name: LENOVO 21DL/LNVNB161216, BIOS JPCN20WW(V1.06) 09/20/2022\n RIP: 0010:napi_enable+0x3f/0x50\n Code: 48 89 c2 48 83 e2 f6 f6 81 89 08 00 00 02 74 0d 48 83 ...\n RSP: 0018:ffffada1414f3548 EFLAGS: 00010246\n RAX: 0000000000000000 RBX: ffffa01425802080 RCX: 0000000000000000\n RDX: 00000000000002ff RSI: ffffada14e50c614 RDI: ffffa01425808dc0\n RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000\n R10: 0000000000000001 R11: 0000000000000100 R12: ffffa01425808f58\n R13: 0000000000000000 R14: ffffa01423498940 R15: 0000000000000001\n FS: 00007f5577c0a740(0000) GS:ffffa0169fc00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f5577a19972 CR3: 0000000125a7a000 CR4: 0000000000750ef0\n PKRU: 55555554\n Call Trace:\n \n rtw89_pci_ops_start+0x1c/0x70 [rtw89_pci 6cbc75429515c181cbc386478d5cfb32ffc5a0f8]\n rtw89_core_start+0xbe/0x160 [rtw89_core fe07ecb874820b6d778370d4acb6ef8a37847f22]\n rtw89_ops_start+0x26/0x40 [rtw89_core fe07ecb874820b6d778370d4acb6ef8a37847f22]\n drv_start+0x42/0x100 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2]\n ieee80211_do_open+0x311/0x7d0 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2]\n ieee80211_open+0x6a/0x90 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2]\n __dev_open+0xe0/0x180\n __dev_change_flags+0x1da/0x250\n dev_change_flags+0x26/0x70\n do_setlink+0x37c/0x12c0\n ? ep_poll_callback+0x246/0x290\n ? __nla_validate_parse+0x61/0xd00\n ? __wake_up_common_lock+0x8f/0xd0\n\nTo fix this, follow Jonas' suggestion to switch the order of these\nfunctions and move register netdev to be the last step of PCI probe.\nAlso, correct the error handling of rtw89_core_register_hw().

In the Linux kernel, the following vulnerability has been resolved:\nscsi: qla2xxx: Fix potential NULL pointer dereference\nKlocwork tool reported 'cur_dsd' may be dereferenced. Add fix to validate\npointer before dereferencing the pointer.

In the Linux kernel, the following vulnerability has been resolved:\n\ns390/dasd: Fix potential memleak in dasd_eckd_init()\n\n`dasd_reserve_req` is allocated before `dasd_vol_info_req`, and it\nalso needs to be freed before the error returns, just like the other\ncases in this function.

In the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: imxfb: Removed unneeded release_mem_region\n\nRemove unnecessary release_mem_region from the error path to prevent\nmem region from being released twice, which could avoid resource leak\nor other unexpected issues.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\nwifi: mt76: mt76x0: fix oob access in mt76x0_phy_get_target_power\nAfter 'commit ba45841ca5eb ("wifi: mt76: mt76x02: simplify struct\nmt76x02_rate_power")', mt76x02 relies on ht[0-7] rate_power data for\nvht mcs{0,7}, while it uses vth[0-1] rate_power for vht mcs {8,9}.\nFix a possible out-of-bound access in mt76x0_phy_get_target_power routine.

In the Linux kernel, the following vulnerability has been resolved:\nfs/ntfs3: Validate data run offset\nThis adds sanity checks for data run offset. We should make sure data\nrun offset is legit before trying to unpack them, otherwise we may\nencounter use-after-free or some unexpected memory access behaviors.\n[ 82.940342] BUG: KASAN: use-after-free in run_unpack+0x2e3/0x570\n[ 82.941180] Read of size 1 at addr ffff888008a8487f by task mount/240\n[ 82.941670]\n[ 82.942069] CPU: 0 PID: 240 Comm: mount Not tainted 5.19.0+ #15\n[ 82.942482] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014\n[ 82.943720] Call Trace:\n[ 82.944204] \n[ 82.944471] dump_stack_lvl+0x49/0x63\n[ 82.944908] print_report.cold+0xf5/0x67b\n[ 82.945141] ? __wait_on_bit+0x106/0x120\n[ 82.945750] ? run_unpack+0x2e3/0x570\n[ 82.946626] kasan_report+0xa7/0x120\n[ 82.947046] ? run_unpack+0x2e3/0x570\n[ 82.947280] __asan_load1+0x51/0x60\n[ 82.947483] run_unpack+0x2e3/0x570\n[ 82.947709] ? memcpy+0x4e/0x70\n[ 82.947927] ? run_pack+0x7a0/0x7a0\n[ 82.948158] run_unpack_ex+0xad/0x3f0\n[ 82.948399] ? mi_enum_attr+0x14a/0x200\n[ 82.948717] ? run_unpack+0x570/0x570\n[ 82.949072] ? ni_enum_attr_ex+0x1b2/0x1c0\n[ 82.949332] ? ni_fname_type.part.0+0xd0/0xd0\n[ 82.949611] ? mi_read+0x262/0x2c0\n[ 82.949970] ? ntfs_cmp_names_cpu+0x125/0x180\n[ 82.950249] ntfs_iget5+0x632/0x1870\n[ 82.950621] ? ntfs_get_block_bmap+0x70/0x70\n[ 82.951192] ? evict+0x223/0x280\n[ 82.951525] ? iput.part.0+0x286/0x320\n[ 82.951969] ntfs_fill_super+0x1321/0x1e20\n[ 82.952436] ? put_ntfs+0x1d0/0x1d0\n[ 82.952822] ? vsprintf+0x20/0x20\n[ 82.953188] ? mutex_unlock+0x81/0xd0\n[ 82.953379] ? set_blocksize+0x95/0x150\n[ 82.954001] get_tree_bdev+0x232/0x370\n[ 82.954438] ? put_ntfs+0x1d0/0x1d0\n[ 82.954700] ntfs_fs_get_tree+0x15/0x20\n[ 82.955049] vfs_get_tree+0x4c/0x130\n[ 82.955292] path_mount+0x645/0xfd0\n[ 82.955615] ? putname+0x80/0xa0\n[ 82.955955] ? finish_automount+0x2e0/0x2e0\n[ 82.956310] ? kmem_cache_free+0x110/0x390\n[ 82.956723] ? putname+0x80/0xa0\n[ 82.957023] do_mount+0xd6/0xf0\n[ 82.957411] ? path_mount+0xfd0/0xfd0\n[ 82.957638] ? __kasan_check_write+0x14/0x20\n[ 82.957948] __x64_sys_mount+0xca/0x110\n[ 82.958310] do_syscall_64+0x3b/0x90\n[ 82.958719] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[ 82.959341] RIP: 0033:0x7fd0d1ce948a\n[ 82.960193] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008\n[ 82.961532] RSP: 002b:00007ffe59ff69a8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5\n[ 82.962527] RAX: ffffffffffffffda RBX: 0000564dcc107060 RCX: 00007fd0d1ce948a\n[ 82.963266] RDX: 0000564dcc107260 RSI: 0000564dcc1072e0 RDI: 0000564dcc10fce0\n[ 82.963686] RBP: 0000000000000000 R08: 0000564dcc107280 R09: 0000000000000020\n[ 82.964272] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 0000564dcc10fce0\n[ 82.964785] R13: 0000564dcc107260 R14: 0000000000000000 R15: 00000000ffffffff

In the Linux kernel, the following vulnerability has been resolved:\ndrbd: only clone bio if we have a backing device\nCommit c347a787e34cb (drbd: set ->bi_bdev in drbd_req_new) moved a\nbio_set_dev call (which has since been removed) to "earlier", from\ndrbd_request_prepare to drbd_req_new.\nThe problem is that this accesses device->ldev->backing_bdev, which is\nnot NULL-checked at this point. When we don't have an ldev (i.e. when\nthe DRBD device is diskless), this leads to a null pointer deref.\nSo, only allocate the private_bio if we actually have a disk. This is\nalso a small optimization, since we don't clone the bio to only to\nimmediately free it again in the diskless case.

In the Linux kernel, the following vulnerability has been resolved:\niommu/amd: Fix pci device refcount leak in ppr_notifier()\nAs comment of pci_get_domain_bus_and_slot() says, it returns\na pci device with refcount increment, when finish using it,\nthe caller must decrement the reference count by calling\npci_dev_put(). So call it before returning from ppr_notifier()\nto avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:\npowerpc/rtas: avoid scheduling in rtas_os_term()\nIt's unsafe to use rtas_busy_delay() to handle a busy status from\nthe ibm,os-term RTAS function in rtas_os_term():\nKernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b\nBUG: sleeping function called from invalid context at arch/powerpc/kernel/rtas.c:618\nin_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0\npreempt_count: 2, expected: 0\nCPU: 7 PID: 1 Comm: swapper/0 Tainted: G D 6.0.0-rc5-02182-gf8553a572277-dirty #9\nCall Trace:\n[c000000007b8f000] [c000000001337110] dump_stack_lvl+0xb4/0x110 (unreliable)\n[c000000007b8f040] [c0000000002440e4] __might_resched+0x394/0x3c0\n[c000000007b8f0e0] [c00000000004f680] rtas_busy_delay+0x120/0x1b0\n[c000000007b8f100] [c000000000052d04] rtas_os_term+0xb8/0xf4\n[c000000007b8f180] [c0000000001150fc] pseries_panic+0x50/0x68\n[c000000007b8f1f0] [c000000000036354] ppc_panic_platform_handler+0x34/0x50\n[c000000007b8f210] [c0000000002303c4] notifier_call_chain+0xd4/0x1c0\n[c000000007b8f2b0] [c0000000002306cc] atomic_notifier_call_chain+0xac/0x1c0\n[c000000007b8f2f0] [c0000000001d62b8] panic+0x228/0x4d0\n[c000000007b8f390] [c0000000001e573c] do_exit+0x140c/0x1420\n[c000000007b8f480] [c0000000001e586c] make_task_dead+0xdc/0x200\nUse rtas_busy_delay_time() instead, which signals without side effects\nwhether to attempt the ibm,os-term RTAS call again.

In the Linux kernel, the following vulnerability has been resolved:\nmtd: lpddr2_nvm: Fix possible null-ptr-deref\nIt will cause null-ptr-deref when resource_size(add_range) invoked,\nif platform_get_resource() returns NULL.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\nnetdevsim: fix memory leak in nsim_drv_probe() when nsim_dev_resources_register() failed\nIf some items in nsim_dev_resources_register() fail, memory leak will\noccur. The following is the memory leak information.\nunreferenced object 0xffff888074c02600 (size 128):\ncomm "echo", pid 8159, jiffies 4294945184 (age 493.530s)\nhex dump (first 32 bytes):\n40 47 ea 89 ff ff ff ff 01 00 00 00 00 00 00 00 @G..............\nff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................\nbacktrace:\n[<0000000011a31c98>] kmalloc_trace+0x22/0x60\n[<0000000027384c69>] devl_resource_register+0x144/0x4e0\n[<00000000a16db248>] nsim_drv_probe+0x37a/0x1260\n[<000000007d1f448c>] really_probe+0x20b/0xb10\n[<00000000c416848a>] __driver_probe_device+0x1b3/0x4a0\n[<00000000077e0351>] driver_probe_device+0x49/0x140\n[<0000000054f2465a>] __device_attach_driver+0x18c/0x2a0\n[<000000008538f359>] bus_for_each_drv+0x151/0x1d0\n[<0000000038e09747>] __device_attach+0x1c9/0x4e0\n[<00000000dd86e533>] bus_probe_device+0x1d5/0x280\n[<00000000839bea35>] device_add+0xae0/0x1cb0\n[<000000009c2abf46>] new_device_store+0x3b6/0x5f0\n[<00000000fb823d7f>] bus_attr_store+0x72/0xa0\n[<000000007acc4295>] sysfs_kf_write+0x106/0x160\n[<000000005f50cb4d>] kernfs_fop_write_iter+0x3a8/0x5a0\n[<0000000075eb41bf>] vfs_write+0x8f0/0xc80

In the Linux kernel, the following vulnerability has been resolved:\nmedia: dvb-core: Fix double free in dvb_register_device()\nIn function dvb_register_device() -> dvb_register_media_device() ->\ndvb_create_media_entity(), dvb->entity is allocated and initialized. If\nthe initialization fails, it frees the dvb->entity, and return an error\ncode. The caller takes the error code and handles the error by calling\ndvb_media_device_free(), which unregisters the entity and frees the\nfield again if it is not NULL. As dvb->entity may not NULLed in\ndvb_create_media_entity() when the allocation of dvbdev->pad fails, a\ndouble free may occur. This may also cause an Use After free in\nmedia_device_unregister_entity().\nFix this by storing NULL to dvb->entity when it is freed.

In the Linux kernel, the following vulnerability has been resolved:\neth: alx: take rtnl_lock on resume\nZbynek reports that alx trips an rtnl assertion on resume:\nRTNL: assertion failed at net/core/dev.c (2891)\nRIP: 0010:netif_set_real_num_tx_queues+0x1ac/0x1c0\nCall Trace:\n\n__alx_open+0x230/0x570 [alx]\nalx_resume+0x54/0x80 [alx]\n? pci_legacy_resume+0x80/0x80\ndpm_run_callback+0x4a/0x150\ndevice_resume+0x8b/0x190\nasync_resume+0x19/0x30\nasync_run_entry_fn+0x30/0x130\nprocess_one_work+0x1e5/0x3b0\nindeed the driver does not hold rtnl_lock during its internal close\nand re-open functions during suspend/resume. Note that this is not\na huge bug as the driver implements its own locking, and does not\nimplement changing the number of queues, but we need to silence\nthe splat.

In the Linux kernel, the following vulnerability has been resolved:\nbinfmt_misc: fix shift-out-of-bounds in check_special_flags\nUBSAN reported a shift-out-of-bounds warning:\nleft shift of 1 by 31 places cannot be represented in type 'int'\nCall Trace:\n\n__dump_stack lib/dump_stack.c:88 [inline]\ndump_stack_lvl+0x8d/0xcf lib/dump_stack.c:106\nubsan_epilogue+0xa/0x44 lib/ubsan.c:151\n__ubsan_handle_shift_out_of_bounds+0x1e7/0x208 lib/ubsan.c:322\ncheck_special_flags fs/binfmt_misc.c:241 [inline]\ncreate_entry fs/binfmt_misc.c:456 [inline]\nbm_register_write+0x9d3/0xa20 fs/binfmt_misc.c:654\nvfs_write+0x11e/0x580 fs/read_write.c:582\nksys_write+0xcf/0x120 fs/read_write.c:637\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x34/0x80 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\nRIP: 0033:0x4194e1\nSince the type of Node's flags is unsigned long, we should define these\nmacros with same type too.

In the Linux kernel, the following vulnerability has been resolved:\ndm cache: Fix UAF in destroy()\nDm_cache also has the same UAF problem when dm_resume()\nand dm_destroy() are concurrent.\nTherefore, cancelling timer again in destroy().

In the Linux kernel, the following vulnerability has been resolved:\nthermal: intel_powerclamp: Use get_cpu() instead of smp_processor_id() to avoid crash\nWhen CPU 0 is offline and intel_powerclamp is used to inject\nidle, it generates kernel BUG:\nBUG: using smp_processor_id() in preemptible [00000000] code: bash/15687\ncaller is debug_smp_processor_id+0x17/0x20\nCPU: 4 PID: 15687 Comm: bash Not tainted 5.19.0-rc7+ #57\nCall Trace:\n\ndump_stack_lvl+0x49/0x63\ndump_stack+0x10/0x16\ncheck_preemption_disabled+0xdd/0xe0\ndebug_smp_processor_id+0x17/0x20\npowerclamp_set_cur_state+0x7f/0xf9 [intel_powerclamp]\n...\n...\nHere CPU 0 is the control CPU by default and changed to the current CPU,\nif CPU 0 offlined. This check has to be performed under cpus_read_lock(),\nhence the above warning.\nUse get_cpu() instead of smp_processor_id() to avoid this BUG.\n[ rjw: Subject edits ]

In the Linux kernel, the following vulnerability has been resolved:\nscsi: qla2xxx: Fix crash when I/O abort times out\nWhile performing CPU hotplug, a crash with the following stack was seen:\nCall Trace:\nqla24xx_process_response_queue+0x42a/0x970 [qla2xxx]\nqla2x00_start_nvme_mq+0x3a2/0x4b0 [qla2xxx]\nqla_nvme_post_cmd+0x166/0x240 [qla2xxx]\nnvme_fc_start_fcp_op.part.0+0x119/0x2e0 [nvme_fc]\nblk_mq_dispatch_rq_list+0x17b/0x610\n__blk_mq_sched_dispatch_requests+0xb0/0x140\nblk_mq_sched_dispatch_requests+0x30/0x60\n__blk_mq_run_hw_queue+0x35/0x90\n__blk_mq_delay_run_hw_queue+0x161/0x180\nblk_execute_rq+0xbe/0x160\n__nvme_submit_sync_cmd+0x16f/0x220 [nvme_core]\nnvmf_connect_admin_queue+0x11a/0x170 [nvme_fabrics]\nnvme_fc_create_association.cold+0x50/0x3dc [nvme_fc]\nnvme_fc_connect_ctrl_work+0x19/0x30 [nvme_fc]\nprocess_one_work+0x1e8/0x3c0\nOn abort timeout, completion was called without checking if the I/O was\nalready completed.\nVerify that I/O and abort request are indeed outstanding before attempting\ncompletion.

In the Linux kernel, the following vulnerability has been resolved:\ndrm/msm: fix use-after-free on probe deferral\nThe bridge counter was never reset when tearing down the DRM device so\nthat stale pointers to deallocated structures would be accessed on the\nnext tear down (e.g. after a second late bind deferral).\nGiven enough bridges and a few probe deferrals this could currently also\nlead to data beyond the bridge array being corrupted.\nPatchwork: https://patchwork.freedesktop.org/patch/502665/

In the Linux kernel, the following vulnerability has been resolved:\ncoresight: cti: Fix hang in cti_disable_hw()\ncti_enable_hw() and cti_disable_hw() are called from an atomic context\nso shouldn't use runtime PM because it can result in a sleep when\ncommunicating with firmware.\nSince commit 3c6656337852 ("Revert "firmware: arm_scmi: Add clock\nmanagement to the SCMI power domain""), this causes a hang on Juno when\nrunning the Perf Coresight tests or running this command:\nperf record -e cs_etm//u -- ls\nThis was also missed until the revert commit because pm_runtime_put()\nwas called with the wrong device until commit 692c9a499b28 ("coresight:\ncti: Correct the parameter for pm_runtime_put")\nWith lock and scheduler debugging enabled the following is output:\ncoresight cti_sys0: cti_enable_hw -- dev:cti_sys0 parent: 20020000.cti\nBUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1151\nin_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 330, name: perf-exec\npreempt_count: 2, expected: 0\nRCU nest depth: 0, expected: 0\nINFO: lockdep is turned off.\nirq event stamp: 0\nhardirqs last enabled at (0): [<0000000000000000>] 0x0\nhardirqs last disabled at (0): [] copy_process+0xa0c/0x1948\nsoftirqs last enabled at (0): [] copy_process+0xa0c/0x1948\nsoftirqs last disabled at (0): [<0000000000000000>] 0x0\nCPU: 3 PID: 330 Comm: perf-exec Not tainted 6.0.0-00053-g042116d99298 #7\nHardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Sep 13 2022\nCall trace:\ndump_backtrace+0x134/0x140\nshow_stack+0x20/0x58\ndump_stack_lvl+0x8c/0xb8\ndump_stack+0x18/0x34\n__might_resched+0x180/0x228\n__might_sleep+0x50/0x88\n__pm_runtime_resume+0xac/0xb0\ncti_enable+0x44/0x120\ncoresight_control_assoc_ectdev+0xc0/0x150\ncoresight_enable_path+0xb4/0x288\netm_event_start+0x138/0x170\netm_event_add+0x48/0x70\nevent_sched_in.isra.122+0xb4/0x280\nmerge_sched_in+0x1fc/0x3d0\nvisit_groups_merge.constprop.137+0x16c/0x4b0\nctx_sched_in+0x114/0x1f0\nperf_event_sched_in+0x60/0x90\nctx_resched+0x68/0xb0\nperf_event_exec+0x138/0x508\nbegin_new_exec+0x52c/0xd40\nload_elf_binary+0x6b8/0x17d0\nbprm_execve+0x360/0x7f8\ndo_execveat_common.isra.47+0x218/0x238\n__arm64_sys_execve+0x48/0x60\ninvoke_syscall+0x4c/0x110\nel0_svc_common.constprop.4+0xfc/0x120\ndo_el0_svc+0x34/0xc0\nel0_svc+0x40/0x98\nel0t_64_sync_handler+0x98/0xc0\nel0t_64_sync+0x170/0x174\nFix the issue by removing the runtime PM calls completely. They are not\nneeded here because it must have already been done when building the\npath for a trace.\n[ Fix build warnings ]

In the Linux kernel, the following vulnerability has been resolved:\nbpf: Propagate error from htab_lock_bucket() to userspace\nIn __htab_map_lookup_and_delete_batch() if htab_lock_bucket() returns\n-EBUSY, it will go to next bucket. Going to next bucket may not only\nskip the elements in current bucket silently, but also incur\nout-of-bound memory access or expose kernel memory to userspace if\ncurrent bucket_cnt is greater than bucket_size or zero.\nFixing it by stopping batch operation and returning -EBUSY when\nhtab_lock_bucket() fails, and the application can retry or skip the busy\nbatch as needed.

In the Linux kernel, the following vulnerability has been resolved:\ndrm/mipi-dsi: Detach devices when removing the host\nWhenever the MIPI-DSI host is unregistered, the code of\nmipi_dsi_host_unregister() loops over every device currently found on that\nbus and will unregister it.\nHowever, it doesn't detach it from the bus first, which leads to all kind\nof resource leaks if the host wants to perform some clean up whenever a\ndevice is detached.

In the Linux kernel, the following vulnerability has been resolved:\nNFSD: Protect against send buffer overflow in NFSv3 READDIR\nSince before the git era, NFSD has conserved the number of pages\nheld by each nfsd thread by combining the RPC receive and send\nbuffers into a single array of pages. This works because there are\nno cases where an operation needs a large RPC Call message and a\nlarge RPC Reply message at the same time.\nOnce an RPC Call has been received, svc_process() updates\nsvc_rqst::rq_res to describe the part of rq_pages that can be\nused for constructing the Reply. This means that the send buffer\n(rq_res) shrinks when the received RPC record containing the RPC\nCall is large.\nA client can force this shrinkage on TCP by sending a correctly-\nformed RPC Call header contained in an RPC record that is\nexcessively large. The full maximum payload size cannot be\nconstructed in that case.\nThanks to Aleksi Illikainen and Kari Hulkko for uncovering this\nissue.

In the Linux kernel, the following vulnerability has been resolved:\nnet: ethernet: ti: Fix return type of netcp_ndo_start_xmit()\nWith clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),\nindirect call targets are validated against the expected function\npointer prototype to make sure the call target is valid to help mitigate\nROP attacks. If they are not identical, there is a failure at run time,\nwhich manifests as either a kernel panic or thread getting killed. A\nproposed warning in clang aims to catch these at compile time, which\nreveals:\ndrivers/net/ethernet/ti/netcp_core.c:1944:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict]\n.ndo_start_xmit = netcp_ndo_start_xmit,\n^~~~~~~~~~~~~~~~~~~~\n1 error generated.\n->ndo_start_xmit() in 'struct net_device_ops' expects a return type of\n'netdev_tx_t', not 'int'. Adjust the return type of\nnetcp_ndo_start_xmit() to match the prototype's to resolve the warning\nand CFI failure.

In the Linux kernel, the following vulnerability has been resolved:\next4: add EXT4_IGET_BAD flag to prevent unexpected bad inode\nThere are many places that will get unhappy (and crash) when ext4_iget()\nreturns a bad inode. However, if iget the boot loader inode, allows a bad\ninode to be returned, because the inode may not be initialized. This\nmechanism can be used to bypass some checks and cause panic. To solve this\nproblem, we add a special iget flag EXT4_IGET_BAD. Only with this flag\nwe'd be returning bad inode from ext4_iget(), otherwise we always return\nthe error code if the inode is bad inode.(suggested by Jan Kara)

In the Linux kernel, the following vulnerability has been resolved:\nALSA: usb-audio: Fix potential memory leaks\nWhen the driver hits -ENOMEM at allocating a URB or a buffer, it\naborts and goes to the error path that releases the all previously\nallocated resources. However, when -ENOMEM hits at the middle of the\nsync EP URB allocation loop, the partially allocated URBs might be\nleft without released, because ep->nurbs is still zero at that point.\nFix it by setting ep->nurbs at first, so that the error handler loops\nover the full URB list.

In the Linux kernel, the following vulnerability has been resolved:\nnet: enetc: avoid buffer leaks on xdp_do_redirect() failure\nBefore enetc_clean_rx_ring_xdp() calls xdp_do_redirect(), each software\nBD in the RX ring between index orig_i and i can have one of 2 refcount\nvalues on its page.\nWe are the owner of the current buffer that is being processed, so the\nrefcount will be at least 1.\nIf the current owner of the buffer at the diametrically opposed index\nin the RX ring (i.o.w, the other half of this page) has not yet called\nkfree(), this page's refcount could even be 2.\nenetc_page_reusable() in enetc_flip_rx_buff() tests for the page\nrefcount against 1, and [ if it's 2 ] does not attempt to reuse it.\nBut if enetc_flip_rx_buff() is put after the xdp_do_redirect() call,\nthe page refcount can have one of 3 values. It can also be 0, if there\nis no owner of the other page half, and xdp_do_redirect() for this\nbuffer ran so far that it triggered a flush of the devmap/cpumap bulk\nqueue, and the consumers of those bulk queues also freed the buffer,\nall by the time xdp_do_redirect() returns the execution back to enetc.\nThis is the reason why enetc_flip_rx_buff() is called before\nxdp_do_redirect(), but there is a big flaw with that reasoning:\nenetc_flip_rx_buff() will set rx_swbd->page = NULL on both sides of the\nenetc_page_reusable() branch, and if xdp_do_redirect() returns an error,\nwe call enetc_xdp_free(), which does not deal gracefully with that.\nIn fact, what happens is quite special. The page refcounts start as 1.\nenetc_flip_rx_buff() figures they're reusable, transfers these\nrx_swbd->page pointers to a different rx_swbd in enetc_reuse_page(), and\nbumps the refcount to 2. When xdp_do_redirect() later returns an error,\nwe call the no-op enetc_xdp_free(), but we still haven't lost the\nreference to that page. A copy of it is still at rx_ring->next_to_alloc,\nbut that has refcount 2 (and there are no concurrent owners of it in\nflight, to drop the refcount). What really kills the system is when\nwe'll flip the rx_swbd->page the second time around. With an updated\nrefcount of 2, the page will not be reusable and we'll really leak it.\nThen enetc_new_page() will have to allocate more pages, which will then\neventually leak again on further errors from xdp_do_redirect().\nThe problem, summarized, is that we zeroize rx_swbd->page before we're\ncompletely done with it, and this makes it impossible for the error path\nto do something with it.\nSince the packet is potentially multi-buffer and therefore the\nrx_swbd->page is potentially an array, manual passing of the old\npointers between enetc_flip_rx_buff() and enetc_xdp_free() is a bit\ndifficult.\nFor the sake of going with a simple solution, we accept the possibility\nof racing with xdp_do_redirect(), and we move the flip procedure to\nexecute only on the redirect success path. By racing, I mean that the\npage may be deemed as not reusable by enetc (having a refcount of 0),\nbut there will be no leak in that case, either.\nOnce we accept that, we have something better to do with buffers on\nXDP_REDIRECT failure. Since we haven't performed half-page flipping yet,\nwe won't, either (and this way, we can avoid enetc_xdp_free()\ncompletely, which gives the entire page to the slab allocator).\nInstead, we'll call enetc_xdp_drop(), which will recycle this half of\nthe buffer back to the RX ring.

In the Linux kernel, the following vulnerability has been resolved:\niommu/vt-d: Clean up si_domain in the init_dmars() error path\nA splat from kmem_cache_destroy() was seen with a kernel prior to\ncommit ee2653bbe89d ("iommu/vt-d: Remove domain and devinfo mempool")\nwhen there was a failure in init_dmars(), because the iommu_domain\ncache still had objects. While the mempool code is now gone, there\nstill is a leak of the si_domain memory if init_dmars() fails. So\nclean up si_domain in the init_dmars() error path.

In the Linux kernel, the following vulnerability has been resolved:\ncxl: fix possible null-ptr-deref in cxl_guest_init_afu