In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915: Grab intel_display from the encoder to avoid potential oopsies\n\nGrab the intel_display from 'encoder' rather than 'state'\nin the encoder hooks to avoid the massive footgun that is\nintel_sanitize_encoder(), which passes NULL as the 'state'\nargument to encoder .disable() and .post_disable().\n\nTODO: figure out how to actually fix intel_sanitize_encoder()...

In the Linux kernel, the following vulnerability has been resolved:\n\nclk: mmp: pxa1908-mpmu: Fix a NULL vs IS_ERR() check\n\nThe devm_kzalloc() function returns NULL on error, not error pointers.\nUpdate the check to match.

In the Linux kernel, the following vulnerability has been resolved:\n\nclk: mmp: pxa1908-apbcp: Fix a NULL vs IS_ERR() check\n\nThe devm_kzalloc() function doesn't return error pointers, it returns\nNULL on error. Update the check to match.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: tests: Fix potential NULL dereference in test_cfg80211_parse_colocated_ap()\n\nkunit_kzalloc() may return NULL, dereferencing it without NULL check may\nlead to NULL dereference.\nAdd a NULL check for ies.

In the Linux kernel, the following vulnerability has been resolved:\n\naf_packet: fix vlan_get_protocol_dgram() vs MSG_PEEK\n\nBlamed commit forgot MSG_PEEK case, allowing a crash [1] as found\nby syzbot.\n\nRework vlan_get_protocol_dgram() to not touch skb at all,\nso that it can be used from many cpus on the same skb.\n\nAdd a const qualifier to skb argument.\n\n[1]\nskbuff: skb_under_panic: text:ffffffff8a8ccd05 len:29 put:14 head:ffff88807fc8e400 data:ffff88807fc8e3f4 tail:0x11 end:0x140 dev:<NULL>\n------------[ cut here ]------------\n kernel BUG at net/core/skbuff.c:206 !\nOops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 1 UID: 0 PID: 5892 Comm: syz-executor883 Not tainted 6.13.0-rc4-syzkaller-00054-gd6ef8b40d075 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\n RIP: 0010:skb_panic net/core/skbuff.c:206 [inline]\n RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216\nCode: 0b 8d 48 c7 c6 86 d5 25 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 5a 69 79 f7 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3\nRSP: 0018:ffffc900038d7638 EFLAGS: 00010282\nRAX: 0000000000000087 RBX: dffffc0000000000 RCX: 609ffd18ea660600\nRDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000\nRBP: ffff88802483c8d0 R08: ffffffff817f0a8c R09: 1ffff9200071ae60\nR10: dffffc0000000000 R11: fffff5200071ae61 R12: 0000000000000140\nR13: ffff88807fc8e400 R14: ffff88807fc8e3f4 R15: 0000000000000011\nFS: 00007fbac5e006c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fbac5e00d58 CR3: 000000001238e000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n skb_push+0xe5/0x100 net/core/skbuff.c:2636\n vlan_get_protocol_dgram+0x165/0x290 net/packet/af_packet.c:585\n packet_recvmsg+0x948/0x1ef0 net/packet/af_packet.c:3552\n sock_recvmsg_nosec net/socket.c:1033 [inline]\n sock_recvmsg+0x22f/0x280 net/socket.c:1055\n ____sys_recvmsg+0x1c6/0x480 net/socket.c:2803\n ___sys_recvmsg net/socket.c:2845 [inline]\n do_recvmmsg+0x426/0xab0 net/socket.c:2940\n __sys_recvmmsg net/socket.c:3014 [inline]\n __do_sys_recvmmsg net/socket.c:3037 [inline]\n __se_sys_recvmmsg net/socket.c:3030 [inline]\n __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3030\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:\n\nsched_ext: Fix invalid irq restore in scx_ops_bypass()\n\nWhile adding outer irqsave/restore locking, 0e7ffff1b811 ("scx: Fix raciness\nin scx_ops_bypass()") forgot to convert an inner rq_unlock_irqrestore() to\nrq_unlock() which could re-enable IRQ prematurely leading to the following\nwarning:\n\n raw_local_irq_restore() called with IRQs enabled\n WARNING: CPU: 1 PID: 96 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40\n ...\n Sched_ext: create_dsq (enabling)\n pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : warn_bogus_irq_restore+0x30/0x40\n lr : warn_bogus_irq_restore+0x30/0x40\n ...\n Call trace:\n warn_bogus_irq_restore+0x30/0x40 (P)\n warn_bogus_irq_restore+0x30/0x40 (L)\n scx_ops_bypass+0x224/0x3b8\n scx_ops_enable.isra.0+0x2c8/0xaa8\n bpf_scx_reg+0x18/0x30\n ...\n irq event stamp: 33739\n hardirqs last enabled at (33739): [<ffff8000800b699c>] scx_ops_bypass+0x174/0x3b8\n hardirqs last disabled at (33738): [<ffff800080d48ad4>] _raw_spin_lock_irqsave+0xb4/0xd8\n\nDrop the stray _irqrestore().

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: fix memory leak in tcp_conn_request()\n\nIf inet_csk_reqsk_queue_hash_add() return false, tcp_conn_request() will\nreturn without free the dst memory, which allocated in af_ops->route_req.\n\nHere is the kmemleak stack:\n\nunreferenced object 0xffff8881198631c0 (size 240):\n comm "softirq", pid 0, jiffies 4299266571 (age 1802.392s)\n hex dump (first 32 bytes):\n 00 10 9b 03 81 88 ff ff 80 98 da bc ff ff ff ff ................\n 81 55 18 bb ff ff ff ff 00 00 00 00 00 00 00 00 .U..............\n backtrace:\n [] kmem_cache_alloc+0x60c/0xa80\n [] dst_alloc+0x55/0x250\n [] rt_dst_alloc+0x46/0x1d0\n [] __mkroute_output+0x29a/0xa50\n [] ip_route_output_key_hash+0x10b/0x240\n [] ip_route_output_flow+0x1d/0x90\n [] inet_csk_route_req+0x2c5/0x500\n [] tcp_conn_request+0x691/0x12c0\n [] tcp_rcv_state_process+0x3c8/0x11b0\n [] tcp_v4_do_rcv+0x156/0x3b0\n [] tcp_v4_rcv+0x1cf8/0x1d80\n [] ip_protocol_deliver_rcu+0xf6/0x360\n [] ip_local_deliver_finish+0xe6/0x1e0\n [] ip_local_deliver+0xee/0x360\n [] ip_rcv+0xad/0x2f0\n [] __netif_receive_skb_one_core+0x123/0x140\n\nCall dst_release() to free the dst memory when\ninet_csk_reqsk_queue_hash_add() return false in tcp_conn_request()..

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix transaction atomicity bug when enabling simple quotas\n\nSet squota incompat bit before committing the transaction that enables\nthe feature.\n\nWith the config CONFIG_BTRFS_ASSERT enabled, an assertion\nfailure occurs regarding the simple quota feature.\n\n [5.596534] assertion failed: btrfs_fs_incompat(fs_info, SIMPLE_QUOTA), in fs/btrfs/qgroup.c:365\n [5.597098] ------------[ cut here ]------------\n [5.597371] kernel BUG at fs/btrfs/qgroup.c:365!\n [5.597946] CPU: 1 UID: 0 PID: 268 Comm: mount Not tainted 6.13.0-rc2-00031-gf92f4749861b #146\n [5.598450] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\n [5.599008] RIP: 0010:btrfs_read_qgroup_config+0x74d/0x7a0\n [5.604303] <TASK>\n [5.605230] ? btrfs_read_qgroup_config+0x74d/0x7a0\n [5.605538] ? exc_invalid_op+0x56/0x70\n [5.605775] ? btrfs_read_qgroup_config+0x74d/0x7a0\n [5.606066] ? asm_exc_invalid_op+0x1f/0x30\n [5.606441] ? btrfs_read_qgroup_config+0x74d/0x7a0\n [5.606741] ? btrfs_read_qgroup_config+0x74d/0x7a0\n [5.607038] ? try_to_wake_up+0x317/0x760\n [5.607286] open_ctree+0xd9c/0x1710\n [5.607509] btrfs_get_tree+0x58a/0x7e0\n [5.608002] vfs_get_tree+0x2e/0x100\n [5.608224] fc_mount+0x16/0x60\n [5.608420] btrfs_get_tree+0x2f8/0x7e0\n [5.608897] vfs_get_tree+0x2e/0x100\n [5.609121] path_mount+0x4c8/0xbc0\n [5.609538] __x64_sys_mount+0x10d/0x150\n\nThe issue can be easily reproduced using the following reproducer:\n\n root@q:linux# cat repro.sh\n set -e\n\n mkfs.btrfs -q -f /dev/sdb\n mount /dev/sdb /mnt/btrfs\n btrfs quota enable -s /mnt/btrfs\n umount /mnt/btrfs\n mount /dev/sdb /mnt/btrfs\n\nThe issue is that when enabling quotas, at btrfs_quota_enable(), we set\nBTRFS_QGROUP_STATUS_FLAG_SIMPLE_MODE at fs_info->qgroup_flags and persist\nit in the quota root in the item with the key BTRFS_QGROUP_STATUS_KEY, but\nwe only set the incompat bit BTRFS_FEATURE_INCOMPAT_SIMPLE_QUOTA after we\ncommit the transaction used to enable simple quotas.\n\nThis means that if after that transaction commit we unmount the filesystem\nwithout starting and committing any other transaction, or we have a power\nfailure, the next time we mount the filesystem we will find the flag\nBTRFS_QGROUP_STATUS_FLAG_SIMPLE_MODE set in the item with the key\nBTRFS_QGROUP_STATUS_KEY but we will not find the incompat bit\nBTRFS_FEATURE_INCOMPAT_SIMPLE_QUOTA set in the superblock, triggering an\nassertion failure at:\n\n btrfs_read_qgroup_config() -> qgroup_read_enable_gen()\n\nTo fix this issue, set the BTRFS_FEATURE_INCOMPAT_SIMPLE_QUOTA flag\nimmediately after setting the BTRFS_QGROUP_STATUS_FLAG_SIMPLE_MODE.\nThis ensures that both flags are flushed to disk within the same\ntransaction.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetrom: check buffer length before accessing it\n\nSyzkaller reports an uninit value read from ax25cmp when sending raw message\nthrough ieee802154 implementation.\n\n=====================================================\nBUG: KMSAN: uninit-value in ax25cmp+0x3a5/0x460 net/ax25/ax25_addr.c:119\n ax25cmp+0x3a5/0x460 net/ax25/ax25_addr.c:119\n nr_dev_get+0x20e/0x450 net/netrom/nr_route.c:601\n nr_route_frame+0x1a2/0xfc0 net/netrom/nr_route.c:774\n nr_xmit+0x5a/0x1c0 net/netrom/nr_dev.c:144\n __netdev_start_xmit include/linux/netdevice.h:4940 [inline]\n netdev_start_xmit include/linux/netdevice.h:4954 [inline]\n xmit_one net/core/dev.c:3548 [inline]\n dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564\n __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349\n dev_queue_xmit include/linux/netdevice.h:3134 [inline]\n raw_sendmsg+0x654/0xc10 net/ieee802154/socket.c:299\n ieee802154_sock_sendmsg+0x91/0xc0 net/ieee802154/socket.c:96\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638\n __sys_sendmsg net/socket.c:2667 [inline]\n __do_sys_sendmsg net/socket.c:2676 [inline]\n __se_sys_sendmsg net/socket.c:2674 [inline]\n __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\n\nUninit was created at:\n slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768\n slab_alloc_node mm/slub.c:3478 [inline]\n kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560\n __alloc_skb+0x318/0x740 net/core/skbuff.c:651\n alloc_skb include/linux/skbuff.h:1286 [inline]\n alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334\n sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2780\n sock_alloc_send_skb include/net/sock.h:1884 [inline]\n raw_sendmsg+0x36d/0xc10 net/ieee802154/socket.c:282\n ieee802154_sock_sendmsg+0x91/0xc0 net/ieee802154/socket.c:96\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638\n __sys_sendmsg net/socket.c:2667 [inline]\n __do_sys_sendmsg net/socket.c:2676 [inline]\n __se_sys_sendmsg net/socket.c:2674 [inline]\n __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\n\nCPU: 0 PID: 5037 Comm: syz-executor166 Not tainted 6.7.0-rc7-syzkaller-00003-gfbafc3e621c3 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023\n=====================================================\n\nThis issue occurs because the skb buffer is too small, and it's actual\nallocation is aligned. This hides an actual issue, which is that nr_route_frame\ndoes not validate the buffer size before using it.\n\nFix this issue by checking skb->len before accessing any fields in skb->data.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.

In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: memalloc: prefer dma_mapping_error() over explicit address checking\n\nWith CONFIG_DMA_API_DEBUG enabled, the following warning is observed:\n\nDMA-API: snd_hda_intel 0000:03:00.1: device driver failed to check map error[device address=0x00000000ffff0000] [size=20480 bytes] [mapped as single]\nWARNING: CPU: 28 PID: 2255 at kernel/dma/debug.c:1036 check_unmap+0x1408/0x2430\nCPU: 28 UID: 42 PID: 2255 Comm: wireplumber Tainted: G W L 6.12.0-10-133577cad6bf48e5a7848c4338124081393bfe8a+ #759\ndebug_dma_unmap_page+0xe9/0xf0\nsnd_dma_wc_free+0x85/0x130 [snd_pcm]\nsnd_pcm_lib_free_pages+0x1e3/0x440 [snd_pcm]\nsnd_pcm_common_ioctl+0x1c9a/0x2960 [snd_pcm]\nsnd_pcm_ioctl+0x6a/0xc0 [snd_pcm]\n...\n\nCheck for returned DMA addresses using specialized dma_mapping_error()\nhelper which is generally recommended for this purpose by\nDocumentation/core-api/dma-api.rst.

In the Linux kernel, the following vulnerability has been resolved:\n\nphy: rockchip: samsung-hdptx: Set drvdata before enabling runtime PM\n\nIn some cases, rk_hdptx_phy_runtime_resume() may be invoked before\nplatform_set_drvdata() is executed in ->probe(), leading to a NULL\npointer dereference when using the return of dev_get_drvdata().\n\nEnsure platform_set_drvdata() is called before devm_pm_runtime_enable().

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: check return value of sock_recvmsg when draining clc data\n\nWhen receiving clc msg, the field length in smc_clc_msg_hdr indicates the\nlength of msg should be received from network and the value should not be\nfully trusted as it is from the network. Once the value of length exceeds\nthe value of buflen in function smc_clc_wait_msg it may run into deadloop\nwhen trying to drain the remaining data exceeding buflen.\n\nThis patch checks the return value of sock_recvmsg when draining data in\ncase of deadloop in draining.

Memory safety bugs present in Firefox 126. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 127.

In violation of spec, cookie prefixes such as `__Secure` were being ignored if they were not correctly capitalized - by spec they should be checked with a case-insensitive comparison. This could have resulted in the browser not correctly honoring the behaviors specified by the prefix. This vulnerability affects Firefox < 127.

By manipulating the fullscreen feature while opening a data-list, an attacker could have overlaid a text box over the address bar. This could have led to user confusion and possible spoofing attacks. This vulnerability affects Firefox < 127.

A website was able to detect when a user took a screenshot of a page using the built-in Screenshot functionality in Firefox. This vulnerability affects Firefox < 127.

If an out-of-memory condition occurs at a specific point using allocations in the probabilistic heap checker, an assertion could have been triggered, and in rarer situations, memory corruption could have occurred. This vulnerability affects Firefox < 127.

In addition to detecting when a user was taking a screenshot (XXX), a website was able to overlay the 'My Shots' button that appeared, and direct the user to a replica Firefox Screenshots page that could be used for phishing. This vulnerability affects Firefox < 127.

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: put bpf_link's program when link is safe to be deallocated\n\nIn general, BPF link's underlying BPF program should be considered to be\nreachable through attach hook -> link -> prog chain, and, pessimistically,\nwe have to assume that as long as link's memory is not safe to free,\nattach hook's code might hold a pointer to BPF program and use it.\n\nAs such, it's not (generally) correct to put link's program early before\nwaiting for RCU GPs to go through. More eager bpf_prog_put() that we\ncurrently do is mostly correct due to BPF program's release code doing\nsimilar RCU GP waiting, but as will be shown in the following patches,\nBPF program can be non-sleepable (and, thus, reliant on only "classic"\nRCU GP), while BPF link's attach hook can have sleepable semantics and\nneeds to be protected by RCU Tasks Trace, and for such cases BPF link\nhas to go through RCU Tasks Trace + "classic" RCU GPs before being\ndeallocated. And so, if we put BPF program early, we might free BPF\nprogram before we free BPF link, leading to use-after-free situation.\n\nSo, this patch defers bpf_prog_put() until we are ready to perform\nbpf_link's deallocation. At worst, this delays BPF program freeing by\none extra RCU GP, but that seems completely acceptable. Alternatively,\nwe'd need more elaborate ways to determine BPF hook, BPF link, and BPF\nprogram lifetimes, and how they relate to each other, which seems like\nan unnecessary complication.\n\nNote, for most BPF links we still will perform eager bpf_prog_put() and\nlink dealloc, so for those BPF links there are no observable changes\nwhatsoever. Only BPF links that use deferred dealloc might notice\nslightly delayed freeing of BPF programs.\n\nAlso, to reduce code and logic duplication, extract program put + link\ndealloc logic into bpf_link_dealloc() helper.

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: add a sanity check for btrfs root in btrfs_search_slot()\n\nSyzbot reports a null-ptr-deref in btrfs_search_slot().\n\nThe reproducer is using rescue=ibadroots, and the extent tree root is\ncorrupted thus the extent tree is NULL.\n\nWhen scrub tries to search the extent tree to gather the needed extent\ninfo, btrfs_search_slot() doesn't check if the target root is NULL or\nnot, resulting the null-ptr-deref.\n\nAdd sanity check for btrfs root before using it in btrfs_search_slot().

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: dvb-frontends: dib3000mb: fix uninit-value in dib3000_write_reg\n\nSyzbot reports [1] an uninitialized value issue found by KMSAN in\ndib3000_read_reg().\n\nLocal u8 rb[2] is used in i2c_transfer() as a read buffer; in case\nthat call fails, the buffer may end up with some undefined values.\n\nSince no elaborate error handling is expected in dib3000_write_reg(),\nsimply zero out rb buffer to mitigate the problem.\n\n[1] Syzkaller report\ndvb-usb: bulk message failed: -22 (6/0)\n=====================================================\nBUG: KMSAN: uninit-value in dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758\n dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758\n dibusb_dib3000mb_frontend_attach+0x155/0x2f0 drivers/media/usb/dvb-usb/dibusb-mb.c:31\n dvb_usb_adapter_frontend_init+0xed/0x9a0 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:290\n dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:90 [inline]\n dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:186 [inline]\n dvb_usb_device_init+0x25a8/0x3760 drivers/media/usb/dvb-usb/dvb-usb-init.c:310\n dibusb_probe+0x46/0x250 drivers/media/usb/dvb-usb/dibusb-mb.c:110\n...\nLocal variable rb created at:\n dib3000_read_reg+0x86/0x4e0 drivers/media/dvb-frontends/dib3000mb.c:54\n dib3000mb_attach+0x123/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758\n...

In the Linux kernel, the following vulnerability has been resolved:\n\nPCI/MSI: Handle lack of irqdomain gracefully\n\nAlexandre observed a warning emitted from pci_msi_setup_msi_irqs() on a\nRISCV platform which does not provide PCI/MSI support:\n\n WARNING: CPU: 1 PID: 1 at drivers/pci/msi/msi.h:121 pci_msi_setup_msi_irqs+0x2c/0x32\n __pci_enable_msix_range+0x30c/0x596\n pci_msi_setup_msi_irqs+0x2c/0x32\n pci_alloc_irq_vectors_affinity+0xb8/0xe2\n\nRISCV uses hierarchical interrupt domains and correctly does not implement\nthe legacy fallback. The warning triggers from the legacy fallback stub.\n\nThat warning is bogus as the PCI/MSI layer knows whether a PCI/MSI parent\ndomain is associated with the device or not. There is a check for MSI-X,\nwhich has a legacy assumption. But that legacy fallback assumption is only\nvalid when legacy support is enabled, but otherwise the check should simply\nreturn -ENOTSUPP.\n\nLoongarch tripped over the same problem and blindly enabled legacy support\nwithout implementing the legacy fallbacks. There are weak implementations\nwhich return an error, so the problem was papered over.\n\nCorrect pci_msi_domain_supports() to evaluate the legacy mode and add\nthe missing supported check into the MSI enable path to complete it.

In the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem()\n\nWhen information such as info->screen_base is not ready, calling\nsh7760fb_free_mem() does not release memory correctly. Call\ndma_free_coherent() instead.

In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to avoid potential deadlock in f2fs_record_stop_reason()\n\nsyzbot reports deadlock issue of f2fs as below:\n\n======================================================\nWARNING: possible circular locking dependency detected\n6.12.0-rc3-syzkaller-00087-gc964ced77262 #0 Not tainted\n------------------------------------------------------\nkswapd0/79 is trying to acquire lock:\nffff888011824088 (&sbi->sb_lock){++++}-{3:3}, at: f2fs_down_write fs/f2fs/f2fs.h:2199 [inline]\nffff888011824088 (&sbi->sb_lock){++++}-{3:3}, at: f2fs_record_stop_reason+0x52/0x1d0 fs/f2fs/super.c:4068\n\nbut task is already holding lock:\nffff88804bd92610 (sb_internal#2){.+.+}-{0:0}, at: f2fs_evict_inode+0x662/0x15c0 fs/f2fs/inode.c:842\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-> #2 (sb_internal#2){.+.+}-{0:0}:\n lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825\n percpu_down_read include/linux/percpu-rwsem.h:51 [inline]\n __sb_start_write include/linux/fs.h:1716 [inline]\n sb_start_intwrite+0x4d/0x1c0 include/linux/fs.h:1899\n f2fs_evict_inode+0x662/0x15c0 fs/f2fs/inode.c:842\n evict+0x4e8/0x9b0 fs/inode.c:725\n f2fs_evict_inode+0x1a4/0x15c0 fs/f2fs/inode.c:807\n evict+0x4e8/0x9b0 fs/inode.c:725\n dispose_list fs/inode.c:774 [inline]\n prune_icache_sb+0x239/0x2f0 fs/inode.c:963\n super_cache_scan+0x38c/0x4b0 fs/super.c:223\n do_shrink_slab+0x701/0x1160 mm/shrinker.c:435\n shrink_slab+0x1093/0x14d0 mm/shrinker.c:662\n shrink_one+0x43b/0x850 mm/vmscan.c:4818\n shrink_many mm/vmscan.c:4879 [inline]\n lru_gen_shrink_node mm/vmscan.c:4957 [inline]\n shrink_node+0x3799/0x3de0 mm/vmscan.c:5937\n kswapd_shrink_node mm/vmscan.c:6765 [inline]\n balance_pgdat mm/vmscan.c:6957 [inline]\n kswapd+0x1ca3/0x3700 mm/vmscan.c:7226\n kthread+0x2f0/0x390 kernel/kthread.c:389\n ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n\n-> #1 (fs_reclaim){+.+.}-{0:0}:\n lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825\n __fs_reclaim_acquire mm/page_alloc.c:3834 [inline]\n fs_reclaim_acquire+0x88/0x130 mm/page_alloc.c:3848\n might_alloc include/linux/sched/mm.h:318 [inline]\n prepare_alloc_pages+0x147/0x5b0 mm/page_alloc.c:4493\n __alloc_pages_noprof+0x16f/0x710 mm/page_alloc.c:4722\n alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265\n alloc_pages_noprof mm/mempolicy.c:2345 [inline]\n folio_alloc_noprof+0x128/0x180 mm/mempolicy.c:2352\n filemap_alloc_folio_noprof+0xdf/0x500 mm/filemap.c:1010\n do_read_cache_folio+0x2eb/0x850 mm/filemap.c:3787\n read_mapping_folio include/linux/pagemap.h:1011 [inline]\n f2fs_commit_super+0x3c0/0x7d0 fs/f2fs/super.c:4032\n f2fs_record_stop_reason+0x13b/0x1d0 fs/f2fs/super.c:4079\n f2fs_handle_critical_error+0x2ac/0x5c0 fs/f2fs/super.c:4174\n f2fs_write_inode+0x35f/0x4d0 fs/f2fs/inode.c:785\n write_inode fs/fs-writeback.c:1503 [inline]\n __writeback_single_inode+0x711/0x10d0 fs/fs-writeback.c:1723\n writeback_single_inode+0x1f3/0x660 fs/fs-writeback.c:1779\n sync_inode_metadata+0xc4/0x120 fs/fs-writeback.c:2849\n f2fs_release_file+0xa8/0x100 fs/f2fs/file.c:1941\n __fput+0x23f/0x880 fs/file_table.c:431\n task_work_run+0x24f/0x310 kernel/task_work.c:228\n resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]\n exit_to_user_mode_loop kernel/entry/common.c:114 [inline]\n exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline]\n __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]\n syscall_exit_to_user_mode+0x168/0x370 kernel/entry/common.c:218\n do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-pf: handle otx2_mbox_get_rsp errors in otx2_flows.c\n\nAdding error pointer check after calling otx2_mbox_get_rsp().

In the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-pf: handle otx2_mbox_get_rsp errors in cn10k.c\n\nAdd error pointer check after calling otx2_mbox_get_rsp().

In the Linux kernel, the following vulnerability has been resolved:\n\nmfd: intel_soc_pmic_bxtwc: Use IRQ domain for PMIC devices\n\nWhile design wise the idea of converting the driver to use\nthe hierarchy of the IRQ chips is correct, the implementation\nhas (inherited) flaws. This was unveiled when platform_get_irq()\nhad started WARN() on IRQ 0 that is supposed to be a Linux\nIRQ number (also known as vIRQ).\n\nRework the driver to respect IRQ domain when creating each MFD\ndevice separately, as the domain is not the same for all of them.

In the Linux kernel, the following vulnerability has been resolved:\n\ns390/cpum_sf: Fix and protect memory allocation of SDBs with mutex\n\nReservation of the PMU hardware is done at first event creation\nand is protected by a pair of mutex_lock() and mutex_unlock().\nAfter reservation of the PMU hardware the memory\nrequired for the PMUs the event is to be installed on is\nallocated by allocate_buffers() and alloc_sampling_buffer().\nThis done outside of the mutex protection.\nWithout mutex protection two or more concurrent invocations of\nperf_event_init() may run in parallel.\nThis can lead to allocation of Sample Data Blocks (SDBs)\nmultiple times for the same PMU.\nPrevent this and protect memory allocation of SDBs by\nmutex.

In the Linux kernel, the following vulnerability has been resolved:\n\ns390/pci: Fix potential double remove of hotplug slot\n\nIn commit 6ee600bfbe0f ("s390/pci: remove hotplug slot when releasing the\ndevice") the zpci_exit_slot() was moved from zpci_device_reserved() to\nzpci_release_device() with the intention of keeping the hotplug slot\naround until the device is actually removed.\n\nNow zpci_release_device() is only called once all references are\ndropped. Since the zPCI subsystem only drops its reference once the\ndevice is in the reserved state it follows that zpci_release_device()\nmust only deal with devices in the reserved state. Despite that it\ncontains code to tear down from both configured and standby state. For\nthe standby case this already includes the removal of the hotplug slot\nso would cause a double removal if a device was ever removed in\neither configured or standby state.\n\nInstead of causing a potential double removal in a case that should\nnever happen explicitly WARN_ON() if a device in non-reserved state is\nreleased and get rid of the dead code cases.

In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: core: Fix possible NULL dereference caused by kunit_kzalloc()\n\nkunit_kzalloc() may return a NULL pointer, dereferencing it without\nNULL check may lead to NULL dereference.\nAdd NULL checks for all the kunit_kzalloc() in sound_kunit.c

In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: endpoint: epf-mhi: Avoid NULL dereference if DT lacks 'mmio'\n\nIf platform_get_resource_byname() fails and returns NULL because DT lacks\nan 'mmio' property for the MHI endpoint, dereferencing res->start will\ncause a NULL pointer access. Add a check to prevent it.\n\n[kwilczynski: error message update per the review feedback]\n[bhelgaas: commit log]

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: Dereference null return value\n\nIn the function pqm_uninit there is a call-assignment of "pdd =\nkfd_get_process_device_data" which could be null, and this value was\nlater dereferenced without checking.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: do not defer rule destruction via call_rcu\n\nnf_tables_chain_destroy can sleep, it can't be used from call_rcu\ncallbacks.\n\nMoreover, nf_tables_rule_release() is only safe for error unwinding,\nwhile transaction mutex is held and the to-be-desroyed rule was not\nexposed to either dataplane or dumps, as it deactives+frees without\nthe required synchronize_rcu() in-between.\n\nnft_rule_expr_deactivate() callbacks will change ->use counters\nof other chains/sets, see e.g. nft_lookup .deactivate callback, these\nmust be serialized via transaction mutex.\n\nAlso add a few lockdep asserts to make this more explicit.\n\nCalling synchronize_rcu() isn't ideal, but fixing this without is hard\nand way more intrusive. As-is, we can get:\n\nWARNING: .. net/netfilter/nf_tables_api.c:5515 nft_set_destroy+0x..\nWorkqueue: events nf_tables_trans_destroy_work\nRIP: 0010:nft_set_destroy+0x3fe/0x5c0\nCall Trace:\n \n nf_tables_trans_destroy_work+0x6b7/0xad0\n process_one_work+0x64a/0xce0\n worker_thread+0x613/0x10d0\n\nIn case the synchronize_rcu becomes an issue, we can explore alternatives.\n\nOne way would be to allocate nft_trans_rule objects + one nft_trans_chain\nobject, deactivate the rules + the chain and then defer the freeing to the\nnft destroy workqueue. We'd still need to keep the synchronize_rcu path as\na fallback to handle -ENOMEM corner cases though.

In the Linux kernel, the following vulnerability has been resolved:\nnet/ipv6: release expired exception dst cached in socket\nDst objects get leaked in ip6_negative_advice() when this function is\nexecuted for an expired IPv6 route located in the exception table. There\nare several conditions that must be fulfilled for the leak to occur:\n* an ICMPv6 packet indicating a change of the MTU for the path is received,\nresulting in an exception dst being created\n* a TCP connection that uses the exception dst for routing packets must\nstart timing out so that TCP begins retransmissions\n* after the exception dst expires, the FIB6 garbage collector must not run\nbefore TCP executes ip6_negative_advice() for the expired exception dst\nWhen TCP executes ip6_negative_advice() for an exception dst that has\nexpired and if no other socket holds a reference to the exception dst, the\nrefcount of the exception dst is 2, which corresponds to the increment\nmade by dst_init() and the increment made by the TCP socket for which the\nconnection is timing out. The refcount made by the socket is never\nreleased. The refcount of the dst is decremented in sk_dst_reset() but\nthat decrement is counteracted by a dst_hold() intentionally placed just\nbefore the sk_dst_reset() in ip6_negative_advice(). After\nip6_negative_advice() has finished, there is no other object tied to the\ndst. The socket lost its reference stored in sk_dst_cache and the dst is\nno longer in the exception table. The exception dst becomes a leaked\nobject.\nAs a result of this dst leak, an unbalanced refcount is reported for the\nloopback device of a net namespace being destroyed under kernels that do\nnot contain e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev"):\nunregister_netdevice: waiting for lo to become free. Usage count = 2\nFix the dst leak by removing the dst_hold() in ip6_negative_advice(). The\npatch that introduced the dst_hold() in ip6_negative_advice() was\n92f1655aa2b22 ("net: fix __dst_negative_advice() race"). But 92f1655aa2b22\nmerely refactored the code with regards to the dst refcount so the issue\nwas present even before 92f1655aa2b22. The bug was introduced in\n54c1a859efd9f ("ipv6: Don't drop cache route entry unless timer actually\nexpired.") where the expired cached route is deleted and the sk_dst_cache\nmember of the socket is set to NULL by calling dst_negative_advice() but\nthe refcount belonging to the socket is left unbalanced.\nThe IPv4 version - ipv4_negative_advice() - is not affected by this bug.\nWhen the TCP connection times out ipv4_negative_advice() merely resets the\nsk_dst_cache of the socket while decrementing the refcount of the\nexception dst.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_inner: incorrect percpu area handling under softirq\n\nSoftirq can interrupt ongoing packet from process context that is\nwalking over the percpu area that contains inner header offsets.\n\nDisable bh and perform three checks before restoring the percpu inner\nheader offsets to validate that the percpu area is valid for this\nskbuff:\n\n1) If the NFT_PKTINFO_INNER_FULL flag is set on, then this skbuff\n has already been parsed before for inner header fetching to\n register.\n\n2) Validate that the percpu area refers to this skbuff using the\n skbuff pointer as a cookie. If there is a cookie mismatch, then\n this skbuff needs to be parsed again.\n\n3) Finally, validate if the percpu area refers to this tunnel type.\n\nOnly after these three checks the percpu area is restored to a on-stack\ncopy and bh is enabled again.\n\nAfter inner header fetching, the on-stack copy is stored back to the\npercpu area.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: sg: Fix slab-use-after-free read in sg_release()\n\nFix a use-after-free bug in sg_release(), detected by syzbot with KASAN:\n\nBUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30\nkernel/locking/lockdep.c:5838\n__mutex_unlock_slowpath+0xe2/0x750 kernel/locking/mutex.c:912\nsg_release+0x1f4/0x2e0 drivers/scsi/sg.c:407\n\nIn sg_release(), the function kref_put(&sfp->f_ref, sg_remove_sfp) is\ncalled before releasing the open_rel_lock mutex. The kref_put() call may\ndecrement the reference count of sfp to zero, triggering its cleanup\nthrough sg_remove_sfp(). This cleanup includes scheduling deferred work\nvia sg_remove_sfp_usercontext(), which ultimately frees sfp.\n\nAfter kref_put(), sg_release() continues to unlock open_rel_lock and may\nreference sfp or sdp. If sfp has already been freed, this results in a\nslab-use-after-free error.\n\nMove the kref_put(&sfp->f_ref, sg_remove_sfp) call after unlocking the\nopen_rel_lock mutex. This ensures:\n\n - No references to sfp or sdp occur after the reference count is\n decremented.\n\n - Cleanup functions such as sg_remove_sfp() and\n sg_remove_sfp_usercontext() can safely execute without impacting the\n mutex handling in sg_release().\n\nThe fix has been tested and validated by syzbot. This patch closes the\nbug reported at the following syzkaller link and ensures proper\nsequencing of resource cleanup and mutex operations, eliminating the\nrisk of use-after-free errors in sg_release().

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ufs: qcom: Only free platform MSIs when ESI is enabled\n\nOtherwise, it will result in a NULL pointer dereference as below:\n\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000008\nCall trace:\n mutex_lock+0xc/0x54\n platform_device_msi_free_irqs_all+0x14/0x20\n ufs_qcom_remove+0x34/0x48 [ufs_qcom]\n platform_remove+0x28/0x44\n device_remove+0x4c/0x80\n device_release_driver_internal+0xd8/0x178\n driver_detach+0x50/0x9c\n bus_remove_driver+0x6c/0xbc\n driver_unregister+0x30/0x60\n platform_driver_unregister+0x14/0x20\n ufs_qcom_pltform_exit+0x18/0xb94 [ufs_qcom]\n __arm64_sys_delete_module+0x180/0x260\n invoke_syscall+0x44/0x100\n el0_svc_common.constprop.0+0xc0/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x34/0xdc\n el0t_64_sync_handler+0xc0/0xc4\n el0t_64_sync+0x190/0x194

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: RFCOMM: avoid leaving dangling sk pointer in rfcomm_sock_alloc()\n\nbt_sock_alloc() attaches allocated sk object to the provided sock object.\nIf rfcomm_dlc_alloc() fails, we release the sk object, but leave the\ndangling pointer in the sock object, which may cause use-after-free.\n\nFix this by swapping calls to bt_sock_alloc() and rfcomm_dlc_alloc().

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath10k: avoid NULL pointer error during sdio remove\n\nWhen running 'rmmod ath10k', ath10k_sdio_remove() will free sdio\nworkqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON\nis set to yes, kernel panic will happen:\nCall trace:\n destroy_workqueue+0x1c/0x258\n ath10k_sdio_remove+0x84/0x94\n sdio_bus_remove+0x50/0x16c\n device_release_driver_internal+0x188/0x25c\n device_driver_detach+0x20/0x2c\n\nThis is because during 'rmmod ath10k', ath10k_sdio_remove() will call\nath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release()\nwill finally be called in ath10k_core_destroy(). This function will free\nstruct cfg80211_registered_device *rdev and all its members, including\nwiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio\nworkqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.\n\nAfter device release, destroy_workqueue() will use NULL pointer then the\nkernel panic happen.\n\nCall trace:\nath10k_sdio_remove\n ->ath10k_core_unregister\n ……\n ->ath10k_core_stop\n ->ath10k_hif_stop\n ->ath10k_sdio_irq_disable\n ->ath10k_hif_power_down\n ->del_timer_sync(&ar_sdio->sleep_timer)\n ->ath10k_core_destroy\n ->ath10k_mac_destroy\n ->ieee80211_free_hw\n ->wiphy_free\n ……\n ->wiphy_dev_release\n ->destroy_workqueue\n\nNeed to call destroy_workqueue() before ath10k_core_destroy(), free\nthe work queue buffer first and then free pointer of work queue by\nath10k_core_destroy(). This order matches the error path order in\nath10k_sdio_probe().\n\nNo work will be queued on sdio workqueue between it is destroyed and\nath10k_core_destroy() is called. Based on the call_stack above, the\nreason is:\nOnly ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and\nath10k_sdio_irq_disable() will queue work on sdio workqueue.\nSleep timer will be deleted before ath10k_core_destroy() in\nath10k_hif_power_down().\nath10k_sdio_irq_disable() only be called in ath10k_hif_stop().\nath10k_core_unregister() will call ath10k_hif_power_down() to stop hif\nbus, so ath10k_sdio_hif_tx_sg() won't be called anymore.\n\nTested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_conn: Use disable_delayed_work_sync\n\nThis makes use of disable_delayed_work_sync instead\ncancel_delayed_work_sync as it not only cancel the ongoing work but also\ndisables new submit which is disarable since the object holding the work\nis about to be freed.

In the Linux kernel, the following vulnerability has been resolved:\n\nad7780: fix division by zero in ad7780_write_raw()\n\nIn the ad7780_write_raw() , val2 can be zero, which might lead to a\ndivision by zero error in DIV_ROUND_CLOSEST(). The ad7780_write_raw()\nis based on iio_info's write_raw. While val is explicitly declared that\ncan be zero (in read mode), val2 is not specified to be non-zero.

In the Linux kernel, the following vulnerability has been resolved:\n\nceph: pass cred pointer to ceph_mds_auth_match()\n\nThis eliminates a redundant get_current_cred() call, because\nceph_mds_check_access() has already obtained this pointer.\n\nAs a side effect, this also fixes a reference leak in\nceph_mds_auth_match(): by omitting the get_current_cred() call, no\nadditional cred reference is taken.

In the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix cred leak in ceph_mds_check_access()\n\nget_current_cred() increments the reference counter, but the\nput_cred() call was missing.

In the Linux kernel, the following vulnerability has been resolved:\n\ni3c: master: Fix miss free init_dyn_addr at i3c_master_put_i3c_addrs()\n\nif (dev->boardinfo && dev->boardinfo->init_dyn_addr)\n ^^^ here check "init_dyn_addr"\n i3c_bus_set_addr_slot_status(&master->bus, dev->info.dyn_addr, ...)\n ^^^^\n free "dyn_addr"\nFix copy/paste error "dyn_addr" by replacing it with "init_dyn_addr".

In the Linux kernel, the following vulnerability has been resolved:\n\nudmabuf: change folios array from kmalloc to kvmalloc\n\nWhen PAGE_SIZE 4096, MAX_PAGE_ORDER 10, 64bit machine,\npage_alloc only support 4MB.\nIf above this, trigger this warn and return NULL.\n\nudmabuf can change size limit, if change it to 3072(3GB), and then alloc\n3GB udmabuf, will fail create.\n\n[ 4080.876581] ------------[ cut here ]------------\n[ 4080.876843] WARNING: CPU: 3 PID: 2015 at mm/page_alloc.c:4556 __alloc_pages+0x2c8/0x350\n[ 4080.878839] RIP: 0010:__alloc_pages+0x2c8/0x350\n[ 4080.879470] Call Trace:\n[ 4080.879473] \n[ 4080.879473] ? __alloc_pages+0x2c8/0x350\n[ 4080.879475] ? __warn.cold+0x8e/0xe8\n[ 4080.880647] ? __alloc_pages+0x2c8/0x350\n[ 4080.880909] ? report_bug+0xff/0x140\n[ 4080.881175] ? handle_bug+0x3c/0x80\n[ 4080.881556] ? exc_invalid_op+0x17/0x70\n[ 4080.881559] ? asm_exc_invalid_op+0x1a/0x20\n[ 4080.882077] ? udmabuf_create+0x131/0x400\n\nBecause MAX_PAGE_ORDER, kmalloc can max alloc 4096 * (1 << 10), 4MB\nmemory, each array entry is pointer(8byte), so can save 524288 pages(2GB).\n\nFurther more, costly order(order 3) may not be guaranteed that it can be\napplied for, due to fragmentation.\n\nThis patch change udmabuf array use kvmalloc_array, this can fallback\nalloc into vmalloc, which can guarantee allocation for any size and does\nnot affect the performance of kmalloc allocations.

In the Linux kernel, the following vulnerability has been resolved:\n\nDrivers: hv: util: Avoid accessing a ringbuffer not initialized yet\n\nIf the KVP (or VSS) daemon starts before the VMBus channel's ringbuffer is\nfully initialized, we can hit the panic below:\n\nhv_utils: Registering HyperV Utility Driver\nhv_vmbus: registering driver hv_utils\n...\nBUG: kernel NULL pointer dereference, address: 0000000000000000\nCPU: 44 UID: 0 PID: 2552 Comm: hv_kvp_daemon Tainted: G E 6.11.0-rc3+ #1\nRIP: 0010:hv_pkt_iter_first+0x12/0xd0\nCall Trace:\n...\n vmbus_recvpacket\n hv_kvp_onchannelcallback\n vmbus_on_event\n tasklet_action_common\n tasklet_action\n handle_softirqs\n irq_exit_rcu\n sysvec_hyperv_stimer0\n </IRQ>\n <TASK>\n asm_sysvec_hyperv_stimer0\n...\n kvp_register_done\n hvt_op_read\n vfs_read\n ksys_read\n __x64_sys_read\n\nThis can happen because the KVP/VSS channel callback can be invoked\neven before the channel is fully opened:\n1) as soon as hv_kvp_init() -> hvutil_transport_init() creates\n/dev/vmbus/hv_kvp, the kvp daemon can open the device file immediately and\nregister itself to the driver by writing a message KVP_OP_REGISTER1 to the\nfile (which is handled by kvp_on_msg() ->kvp_handle_handshake()) and\nreading the file for the driver's response, which is handled by\nhvt_op_read(), which calls hvt->on_read(), i.e. kvp_register_done().\n\n2) the problem with kvp_register_done() is that it can cause the\nchannel callback to be called even before the channel is fully opened,\nand when the channel callback is starting to run, util_probe()->\nvmbus_open() may have not initialized the ringbuffer yet, so the\ncallback can hit the panic of NULL pointer dereference.\n\nTo reproduce the panic consistently, we can add a "ssleep(10)" for KVP in\n__vmbus_open(), just before the first hv_ringbuffer_init(), and then we\nunload and reload the driver hv_utils, and run the daemon manually within\nthe 10 seconds.\n\nFix the panic by reordering the steps in util_probe() so the char dev\nentry used by the KVP or VSS daemon is not created until after\nvmbus_open() has completed. This reordering prevents the race condition\nfrom happening.

In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Play nice with protected guests in complete_hypercall_exit()\n\nUse is_64_bit_hypercall() instead of is_64_bit_mode() to detect a 64-bit\nhypercall when completing said hypercall. For guests with protected state,\ne.g. SEV-ES and SEV-SNP, KVM must assume the hypercall was made in 64-bit\nmode as the vCPU state needed to detect 64-bit mode is unavailable.\n\nHacking the sev_smoke_test selftest to generate a KVM_HC_MAP_GPA_RANGE\nhypercall via VMGEXIT trips the WARN:\n\n ------------[ cut here ]------------\n WARNING: CPU: 273 PID: 326626 at arch/x86/kvm/x86.h:180 complete_hypercall_exit+0x44/0xe0 [kvm]\n Modules linked in: kvm_amd kvm ... [last unloaded: kvm]\n CPU: 273 UID: 0 PID: 326626 Comm: sev_smoke_test Not tainted 6.12.0-smp--392e932fa0f3-feat #470\n Hardware name: Google Astoria/astoria, BIOS 0.20240617.0-0 06/17/2024\n RIP: 0010:complete_hypercall_exit+0x44/0xe0 [kvm]\n Call Trace:\n <TASK>\n kvm_arch_vcpu_ioctl_run+0x2400/0x2720 [kvm]\n kvm_vcpu_ioctl+0x54f/0x630 [kvm]\n __se_sys_ioctl+0x6b/0xc0\n do_syscall_64+0x83/0x160\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n </TASK>\n ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: renesas: rswitch: avoid use-after-put for a device tree node\n\nThe device tree node saved in the rswitch_device structure is used at\nseveral driver locations. So passing this node to of_node_put() after\nthe first use is wrong.\n\nMove of_node_put() for this node to exit paths.

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: iso: Fix circular lock in iso_listen_bis\n\nThis fixes the circular locking dependency warning below, by\nreleasing the socket lock before enterning iso_listen_bis, to\navoid any potential deadlock with hdev lock.\n\n[ 75.307983] ======================================================\n[ 75.307984] WARNING: possible circular locking dependency detected\n[ 75.307985] 6.12.0-rc6+ #22 Not tainted\n[ 75.307987] ------------------------------------------------------\n[ 75.307987] kworker/u81:2/2623 is trying to acquire lock:\n[ 75.307988] ffff8fde1769da58 (sk_lock-AF_BLUETOOTH-BTPROTO_ISO)\n at: iso_connect_cfm+0x253/0x840 [bluetooth]\n[ 75.308021]\n but task is already holding lock:\n[ 75.308022] ffff8fdd61a10078 (&hdev->lock)\n at: hci_le_per_adv_report_evt+0x47/0x2f0 [bluetooth]\n[ 75.308053]\n which lock already depends on the new lock.\n\n[ 75.308054]\n the existing dependency chain (in reverse order) is:\n[ 75.308055]\n -> #1 (&hdev->lock){+.+.}-{3:3}:\n[ 75.308057] __mutex_lock+0xad/0xc50\n[ 75.308061] mutex_lock_nested+0x1b/0x30\n[ 75.308063] iso_sock_listen+0x143/0x5c0 [bluetooth]\n[ 75.308085] __sys_listen_socket+0x49/0x60\n[ 75.308088] __x64_sys_listen+0x4c/0x90\n[ 75.308090] x64_sys_call+0x2517/0x25f0\n[ 75.308092] do_syscall_64+0x87/0x150\n[ 75.308095] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[ 75.308098]\n -> #0 (sk_lock-AF_BLUETOOTH-BTPROTO_ISO){+.+.}-{0:0}:\n[ 75.308100] __lock_acquire+0x155e/0x25f0\n[ 75.308103] lock_acquire+0xc9/0x300\n[ 75.308105] lock_sock_nested+0x32/0x90\n[ 75.308107] iso_connect_cfm+0x253/0x840 [bluetooth]\n[ 75.308128] hci_connect_cfm+0x6c/0x190 [bluetooth]\n[ 75.308155] hci_le_per_adv_report_evt+0x27b/0x2f0 [bluetooth]\n[ 75.308180] hci_le_meta_evt+0xe7/0x200 [bluetooth]\n[ 75.308206] hci_event_packet+0x21f/0x5c0 [bluetooth]\n[ 75.308230] hci_rx_work+0x3ae/0xb10 [bluetooth]\n[ 75.308254] process_one_work+0x212/0x740\n[ 75.308256] worker_thread+0x1bd/0x3a0\n[ 75.308258] kthread+0xe4/0x120\n[ 75.308259] ret_from_fork+0x44/0x70\n[ 75.308261] ret_from_fork_asm+0x1a/0x30\n[ 75.308263]\n other info that might help us debug this:\n\n[ 75.308264] Possible unsafe locking scenario:\n\n[ 75.308264] CPU0 CPU1\n[ 75.308265] ---- ----\n[ 75.308265] lock(&hdev->lock);\n[ 75.308267] lock(sk_lock-\n AF_BLUETOOTH-BTPROTO_ISO);\n[ 75.308268] lock(&hdev->lock);\n[ 75.308269] lock(sk_lock-AF_BLUETOOTH-BTPROTO_ISO);\n[ 75.308270]\n *** DEADLOCK ***\n\n[ 75.308271] 4 locks held by kworker/u81:2/2623:\n[ 75.308272] #0: ffff8fdd66e52148 ((wq_completion)hci0#2){+.+.}-{0:0},\n at: process_one_work+0x443/0x740\n[ 75.308276] #1: ffffafb488b7fe48 ((work_completion)(&hdev->rx_work)),\n at: process_one_work+0x1ce/0x740\n[ 75.308280] #2: ffff8fdd61a10078 (&hdev->lock){+.+.}-{3:3}\n at: hci_le_per_adv_report_evt+0x47/0x2f0 [bluetooth]\n[ 75.308304] #3: ffffffffb6ba4900 (rcu_read_lock){....}-{1:2},\n at: hci_connect_cfm+0x29/0x190 [bluetooth]

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: iso: Fix circular lock in iso_conn_big_sync\n\nThis fixes the circular locking dependency warning below, by reworking\niso_sock_recvmsg, to ensure that the socket lock is always released\nbefore calling a function that locks hdev.\n\n[ 561.670344] ======================================================\n[ 561.670346] WARNING: possible circular locking dependency detected\n[ 561.670349] 6.12.0-rc6+ #26 Not tainted\n[ 561.670351] ------------------------------------------------------\n[ 561.670353] iso-tester/3289 is trying to acquire lock:\n[ 561.670355] ffff88811f600078 (&hdev->lock){+.+.}-{3:3},\n at: iso_conn_big_sync+0x73/0x260 [bluetooth]\n[ 561.670405]\n but task is already holding lock:\n[ 561.670407] ffff88815af58258 (sk_lock-AF_BLUETOOTH){+.+.}-{0:0},\n at: iso_sock_recvmsg+0xbf/0x500 [bluetooth]\n[ 561.670450]\n which lock already depends on the new lock.\n\n[ 561.670452]\n the existing dependency chain (in reverse order) is:\n[ 561.670453]\n -> #2 (sk_lock-AF_BLUETOOTH){+.+.}-{0:0}:\n[ 561.670458] lock_acquire+0x7c/0xc0\n[ 561.670463] lock_sock_nested+0x3b/0xf0\n[ 561.670467] bt_accept_dequeue+0x1a5/0x4d0 [bluetooth]\n[ 561.670510] iso_sock_accept+0x271/0x830 [bluetooth]\n[ 561.670547] do_accept+0x3dd/0x610\n[ 561.670550] __sys_accept4+0xd8/0x170\n[ 561.670553] __x64_sys_accept+0x74/0xc0\n[ 561.670556] x64_sys_call+0x17d6/0x25f0\n[ 561.670559] do_syscall_64+0x87/0x150\n[ 561.670563] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[ 561.670567]\n -> #1 (sk_lock-AF_BLUETOOTH-BTPROTO_ISO){+.+.}-{0:0}:\n[ 561.670571] lock_acquire+0x7c/0xc0\n[ 561.670574] lock_sock_nested+0x3b/0xf0\n[ 561.670577] iso_sock_listen+0x2de/0xf30 [bluetooth]\n[ 561.670617] __sys_listen_socket+0xef/0x130\n[ 561.670620] __x64_sys_listen+0xe1/0x190\n[ 561.670623] x64_sys_call+0x2517/0x25f0\n[ 561.670626] do_syscall_64+0x87/0x150\n[ 561.670629] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[ 561.670632]\n -> #0 (&hdev->lock){+.+.}-{3:3}:\n[ 561.670636] __lock_acquire+0x32ad/0x6ab0\n[ 561.670639] lock_acquire.part.0+0x118/0x360\n[ 561.670642] lock_acquire+0x7c/0xc0\n[ 561.670644] __mutex_lock+0x18d/0x12f0\n[ 561.670647] mutex_lock_nested+0x1b/0x30\n[ 561.670651] iso_conn_big_sync+0x73/0x260 [bluetooth]\n[ 561.670687] iso_sock_recvmsg+0x3e9/0x500 [bluetooth]\n[ 561.670722] sock_recvmsg+0x1d5/0x240\n[ 561.670725] sock_read_iter+0x27d/0x470\n[ 561.670727] vfs_read+0x9a0/0xd30\n[ 561.670731] ksys_read+0x1a8/0x250\n[ 561.670733] __x64_sys_read+0x72/0xc0\n[ 561.670736] x64_sys_call+0x1b12/0x25f0\n[ 561.670738] do_syscall_64+0x87/0x150\n[ 561.670741] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[ 561.670744]\n other info that might help us debug this:\n\n[ 561.670745] Chain exists of:\n&hdev->lock --> sk_lock-AF_BLUETOOTH-BTPROTO_ISO --> sk_lock-AF_BLUETOOTH\n\n[ 561.670751] Possible unsafe locking scenario:\n\n[ 561.670753] CPU0 CPU1\n[ 561.670754] ---- ----\n[ 561.670756] lock(sk_lock-AF_BLUETOOTH);\n[ 561.670758] lock(sk_lock\n AF_BLUETOOTH-BTPROTO_ISO);\n[ 561.670761] lock(sk_lock-AF_BLUETOOTH);\n[ 561.670764] lock(&hdev->lock);\n[ 561.670767]\n *** DEADLOCK ***

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: fix use-after-free in device_for_each_child()\n\nSyzbot has reported the following KASAN splat:\n\nBUG: KASAN: slab-use-after-free in device_for_each_child+0x18f/0x1a0\nRead of size 8 at addr ffff88801f605308 by task kbnepd bnep0/4980\n\nCPU: 0 UID: 0 PID: 4980 Comm: kbnepd bnep0 Not tainted 6.12.0-rc4-00161-gae90f6a6170d #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014\nCall Trace:\n \n dump_stack_lvl+0x100/0x190\n ? device_for_each_child+0x18f/0x1a0\n print_report+0x13a/0x4cb\n ? __virt_addr_valid+0x5e/0x590\n ? __phys_addr+0xc6/0x150\n ? device_for_each_child+0x18f/0x1a0\n kasan_report+0xda/0x110\n ? device_for_each_child+0x18f/0x1a0\n ? __pfx_dev_memalloc_noio+0x10/0x10\n device_for_each_child+0x18f/0x1a0\n ? __pfx_device_for_each_child+0x10/0x10\n pm_runtime_set_memalloc_noio+0xf2/0x180\n netdev_unregister_kobject+0x1ed/0x270\n unregister_netdevice_many_notify+0x123c/0x1d80\n ? __mutex_trylock_common+0xde/0x250\n ? __pfx_unregister_netdevice_many_notify+0x10/0x10\n ? trace_contention_end+0xe6/0x140\n ? __mutex_lock+0x4e7/0x8f0\n ? __pfx_lock_acquire.part.0+0x10/0x10\n ? rcu_is_watching+0x12/0xc0\n ? unregister_netdev+0x12/0x30\n unregister_netdevice_queue+0x30d/0x3f0\n ? __pfx_unregister_netdevice_queue+0x10/0x10\n ? __pfx_down_write+0x10/0x10\n unregister_netdev+0x1c/0x30\n bnep_session+0x1fb3/0x2ab0\n ? __pfx_bnep_session+0x10/0x10\n ? __pfx_lock_release+0x10/0x10\n ? __pfx_woken_wake_function+0x10/0x10\n ? __kthread_parkme+0x132/0x200\n ? __pfx_bnep_session+0x10/0x10\n ? kthread+0x13a/0x370\n ? __pfx_bnep_session+0x10/0x10\n kthread+0x2b7/0x370\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x48/0x80\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \n\nAllocated by task 4974:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0xaa/0xb0\n __kmalloc_noprof+0x1d1/0x440\n hci_alloc_dev_priv+0x1d/0x2820\n __vhci_create_device+0xef/0x7d0\n vhci_write+0x2c7/0x480\n vfs_write+0x6a0/0xfc0\n ksys_write+0x12f/0x260\n do_syscall_64+0xc7/0x250\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nFreed by task 4979:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n kasan_save_free_info+0x3b/0x60\n __kasan_slab_free+0x4f/0x70\n kfree+0x141/0x490\n hci_release_dev+0x4d9/0x600\n bt_host_release+0x6a/0xb0\n device_release+0xa4/0x240\n kobject_put+0x1ec/0x5a0\n put_device+0x1f/0x30\n vhci_release+0x81/0xf0\n __fput+0x3f6/0xb30\n task_work_run+0x151/0x250\n do_exit+0xa79/0x2c30\n do_group_exit+0xd5/0x2a0\n get_signal+0x1fcd/0x2210\n arch_do_signal_or_restart+0x93/0x780\n syscall_exit_to_user_mode+0x140/0x290\n do_syscall_64+0xd4/0x250\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nIn 'hci_conn_del_sysfs()', 'device_unregister()' may be called when\nan underlying (kobject) reference counter is greater than 1. This\nmeans that reparenting (happened when the device is actually freed)\nis delayed and, during that delay, parent controller device (hciX)\nmay be deleted. Since the latter may create a dangling pointer to\nfreed parent, avoid that scenario by reparenting to NULL explicitly.

In the Linux kernel, the following vulnerability has been resolved:\n\nxsk: Free skb when TX metadata options are invalid\n\nWhen a new skb is allocated for transmitting an xsk descriptor, i.e., for\nevery non-multibuf descriptor or the first frag of a multibuf descriptor,\nbut the descriptor is later found to have invalid options set for the TX\nmetadata, the new skb is never freed. This can leak skbs until the send\nbuffer is full which makes sending more packets impossible.\n\nFix this by freeing the skb in the error path if we are currently dealing\nwith the first frag, i.e., an skb allocated in this iteration of\nxsk_build_skb.

In the Linux kernel, the following vulnerability has been resolved:\n\niommu/s390: Implement blocking domain\n\nThis fixes a crash when surprise hot-unplugging a PCI device. This crash\nhappens because during hot-unplug __iommu_group_set_domain_nofail()\nattaching the default domain fails when the platform no longer\nrecognizes the device as it has already been removed and we end up with\na NULL domain pointer and UAF. This is exactly the case referred to in\nthe second comment in __iommu_device_set_domain() and just as stated\nthere if we can instead attach the blocking domain the UAF is prevented\nas this can handle the already removed device. Implement the blocking\ndomain to use this handling. With this change, the crash is fixed but\nwe still hit a warning attempting to change DMA ownership on a blocked\ndevice.

In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: kvm: Fix out-of-bounds array access\n\nIn kvm_riscv_vcpu_sbi_init() the entry->ext_idx can contain an\nout-of-bound index. This is used as a special marker for the base\nextensions, that cannot be disabled. However, when traversing the\nextensions, that special marker is not checked prior indexing the\narray.\n\nAdd an out-of-bounds check to the function.

In the Linux kernel, the following vulnerability has been resolved:\n\niommu/tegra241-cmdqv: Fix alignment failure at max_n_shift\n\nWhen configuring a kernel with PAGE_SIZE=4KB, depending on its setting of\nCONFIG_CMA_ALIGNMENT, VCMDQ_LOG2SIZE_MAX=19 could fail the alignment test\nand trigger a WARN_ON:\n WARNING: at drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:3646\n Call trace:\n arm_smmu_init_one_queue+0x15c/0x210\n tegra241_cmdqv_init_structures+0x114/0x338\n arm_smmu_device_probe+0xb48/0x1d90\n\nFix it by capping max_n_shift to CMDQ_MAX_SZ_SHIFT as SMMUv3 CMDQ does.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/l2tp: fix warning in l2tp_exit_net found by syzbot\n\nIn l2tp's net exit handler, we check that an IDR is empty before\ndestroying it:\n\n WARN_ON_ONCE(!idr_is_empty(&pn->l2tp_tunnel_idr));\n idr_destroy(&pn->l2tp_tunnel_idr);\n\nBy forcing memory allocation failures in idr_alloc_32, syzbot is able\nto provoke a condition where idr_is_empty returns false despite there\nbeing no items in the IDR. This turns out to be because the radix tree\nof the IDR contains only internal radix-tree nodes and it is this that\ncauses idr_is_empty to return false. The internal nodes are cleaned by\nidr_destroy.\n\nUse idr_for_each to check that the IDR is empty instead of\nidr_is_empty to avoid the problem.

In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: Fix use-after-free of nreq in reqsk_timer_handler().\n\nThe cited commit replaced inet_csk_reqsk_queue_drop_and_put() with\n__inet_csk_reqsk_queue_drop() and reqsk_put() in reqsk_timer_handler().\n\nThen, oreq should be passed to reqsk_put() instead of req; otherwise\nuse-after-free of nreq could happen when reqsk is migrated but the\nretry attempt failed (e.g. due to timeout).\n\nLet's pass oreq to reqsk_put().

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: fix potential array underflow in ucsi_ccg_sync_control()\n\nThe "command" variable can be controlled by the user via debugfs. The\nworry is that if con_index is zero then "&uc->ucsi->connector[con_index\n- 1]" would be an array underflow.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Fix null check for pipe_ctx->plane_state in hwss_setup_dpp\n\nThis commit addresses a null pointer dereference issue in\nhwss_setup_dpp(). The issue could occur when pipe_ctx->plane_state is\nnull. The fix adds a check to ensure `pipe_ctx->plane_state` is not null\nbefore accessing. This prevents a null pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: Don't retire aborted MMIO instruction\n\nReturning an abort to the guest for an unsupported MMIO access is a\ndocumented feature of the KVM UAPI. Nevertheless, it's clear that this\nplumbing has seen limited testing, since userspace can trivially cause a\nWARN in the MMIO return:\n\n WARNING: CPU: 0 PID: 30558 at arch/arm64/include/asm/kvm_emulate.h:536 kvm_handle_mmio_return+0x46c/0x5c4 arch/arm64/include/asm/kvm_emulate.h:536\n Call trace:\n kvm_handle_mmio_return+0x46c/0x5c4 arch/arm64/include/asm/kvm_emulate.h:536\n kvm_arch_vcpu_ioctl_run+0x98/0x15b4 arch/arm64/kvm/arm.c:1133\n kvm_vcpu_ioctl+0x75c/0xa78 virt/kvm/kvm_main.c:4487\n __do_sys_ioctl fs/ioctl.c:51 [inline]\n __se_sys_ioctl fs/ioctl.c:893 [inline]\n __arm64_sys_ioctl+0x14c/0x1c8 fs/ioctl.c:893\n __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]\n invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49\n el0_svc_common+0x1e0/0x23c arch/arm64/kernel/syscall.c:132\n do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151\n el0_svc+0x38/0x68 arch/arm64/kernel/entry-common.c:712\n el0t_64_sync_handler+0x90/0xfc arch/arm64/kernel/entry-common.c:730\n el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598\n\nThe splat is complaining that KVM is advancing PC while an exception is\npending, i.e. that KVM is retiring the MMIO instruction despite a\npending synchronous external abort. Womp womp.\n\nFix the glaring UAPI bug by skipping over all the MMIO emulation in\ncase there is a pending synchronous exception. Note that while userspace\nis capable of pending an asynchronous exception (SError, IRQ, or FIQ),\nit is still safe to retire the MMIO instruction in this case as (1) they\nare by definition asynchronous, and (2) KVM relies on hardware support\nfor pending/delivering these exceptions instead of the software state\nmachine for advancing PC.

In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: Get rid of userspace_irqchip_in_use\n\nImproper use of userspace_irqchip_in_use led to syzbot hitting the\nfollowing WARN_ON() in kvm_timer_update_irq():\n\nWARNING: CPU: 0 PID: 3281 at arch/arm64/kvm/arch_timer.c:459\nkvm_timer_update_irq+0x21c/0x394\nCall trace:\n kvm_timer_update_irq+0x21c/0x394 arch/arm64/kvm/arch_timer.c:459\n kvm_timer_vcpu_reset+0x158/0x684 arch/arm64/kvm/arch_timer.c:968\n kvm_reset_vcpu+0x3b4/0x560 arch/arm64/kvm/reset.c:264\n kvm_vcpu_set_target arch/arm64/kvm/arm.c:1553 [inline]\n kvm_arch_vcpu_ioctl_vcpu_init arch/arm64/kvm/arm.c:1573 [inline]\n kvm_arch_vcpu_ioctl+0x112c/0x1b3c arch/arm64/kvm/arm.c:1695\n kvm_vcpu_ioctl+0x4ec/0xf74 virt/kvm/kvm_main.c:4658\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:907 [inline]\n __se_sys_ioctl fs/ioctl.c:893 [inline]\n __arm64_sys_ioctl+0x108/0x184 fs/ioctl.c:893\n __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]\n invoke_syscall+0x78/0x1b8 arch/arm64/kernel/syscall.c:49\n el0_svc_common+0xe8/0x1b0 arch/arm64/kernel/syscall.c:132\n do_el0_svc+0x40/0x50 arch/arm64/kernel/syscall.c:151\n el0_svc+0x54/0x14c arch/arm64/kernel/entry-common.c:712\n el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730\n el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598\n\nThe following sequence led to the scenario:\n - Userspace creates a VM and a vCPU.\n - The vCPU is initialized with KVM_ARM_VCPU_PMU_V3 during\n KVM_ARM_VCPU_INIT.\n - Without any other setup, such as vGIC or vPMU, userspace issues\n KVM_RUN on the vCPU. Since the vPMU is requested, but not setup,\n kvm_arm_pmu_v3_enable() fails in kvm_arch_vcpu_run_pid_change().\n As a result, KVM_RUN returns after enabling the timer, but before\n incrementing 'userspace_irqchip_in_use':\n kvm_arch_vcpu_run_pid_change()\n ret = kvm_arm_pmu_v3_enable()\n if (!vcpu->arch.pmu.created)\n return -EINVAL;\n if (ret)\n return ret;\n [...]\n if (!irqchip_in_kernel(kvm))\n static_branch_inc(&userspace_irqchip_in_use);\n - Userspace ignores the error and issues KVM_ARM_VCPU_INIT again.\n Since the timer is already enabled, control moves through the\n following flow, ultimately hitting the WARN_ON():\n kvm_timer_vcpu_reset()\n if (timer->enabled)\n kvm_timer_update_irq()\n if (!userspace_irqchip())\n ret = kvm_vgic_inject_irq()\n ret = vgic_lazy_init()\n if (unlikely(!vgic_initialized(kvm)))\n if (kvm->arch.vgic.vgic_model !=\n KVM_DEV_TYPE_ARM_VGIC_V2)\n return -EBUSY;\n WARN_ON(ret);\n\nTheoretically, since userspace_irqchip_in_use's functionality can be\nsimply replaced by '!irqchip_in_kernel()', get rid of the static key\nto avoid the mismanagement, which also helps with the syzbot issue.

In the Linux kernel, the following vulnerability has been resolved:\n\nclk: clk-loongson2: Fix potential buffer overflow in flexible-array member access\n\nFlexible-array member `hws` in `struct clk_hw_onecell_data` is annotated\nwith the `counted_by()` attribute. This means that when memory is\nallocated for this array, the _counter_, which in this case is member\n`num` in the flexible structure, should be set to the maximum number of\nelements the flexible array can contain, or fewer.\n\nIn this case, the total number of elements for the flexible array is\ndetermined by variable `clks_num` when allocating heap space via\n`devm_kzalloc()`, as shown below:\n\n289 struct loongson2_clk_provider *clp;\n ...\n296 for (p = data; p->name; p++)\n297 clks_num++;\n298\n299 clp = devm_kzalloc(dev, struct_size(clp, clk_data.hws, clks_num),\n300 GFP_KERNEL);\n\nSo, `clp->clk_data.num` should be set to `clks_num` or less, and not\nexceed `clks_num`, as is currently the case. Otherwise, if data is\nwritten into `clp->clk_data.hws[clks_num]`, the instrumentation\nprovided by the compiler won't detect the overflow, leading to a\nmemory corruption bug at runtime.\n\nFix this issue by setting `clp->clk_data.num` to `clks_num`.

In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: During unmount, ensure all cached dir instances drop their dentry\n\nThe unmount process (cifs_kill_sb() calling close_all_cached_dirs()) can\nrace with various cached directory operations, which ultimately results\nin dentries not being dropped and these kernel BUGs:\n\nBUG: Dentry ffff88814f37e358{i=1000000000080,n=/} still in use (2) [unmount of cifs cifs]\nVFS: Busy inodes after unmount of cifs (cifs)\n------------[ cut here ]------------\nkernel BUG at fs/super.c:661!\n\nThis happens when a cfid is in the process of being cleaned up when, and\nhas been removed from the cfids->entries list, including:\n\n- Receiving a lease break from the server\n- Server reconnection triggers invalidate_all_cached_dirs(), which\n removes all the cfids from the list\n- The laundromat thread decides to expire an old cfid.\n\nTo solve these problems, dropping the dentry is done in queued work done\nin a newly-added cfid_put_wq workqueue, and close_all_cached_dirs()\nflushes that workqueue after it drops all the dentries of which it's\naware. This is a global workqueue (rather than scoped to a mount), but\nthe queued work is minimal.\n\nThe final cleanup work for cleaning up a cfid is performed via work\nqueued in the serverclose_wq workqueue; this is done separate from\ndropping the dentries so that close_all_cached_dirs() doesn't block on\nany server operations.\n\nBoth of these queued works expect to invoked with a cfid reference and\na tcon reference to avoid those objects from being freed while the work\nis ongoing.\n\nWhile we're here, add proper locking to close_all_cached_dirs(), and\nlocking around the freeing of cfid->dentry.

In the Linux kernel, the following vulnerability has been resolved:\n\nrcu/kvfree: Fix data-race in __mod_timer / kvfree_call_rcu\n\nKCSAN reports a data race when access the krcp->monitor_work.timer.expires\nvariable in the schedule_delayed_monitor_work() function:\n\n\nBUG: KCSAN: data-race in __mod_timer / kvfree_call_rcu\n\nread to 0xffff888237d1cce8 of 8 bytes by task 10149 on cpu 1:\n schedule_delayed_monitor_work kernel/rcu/tree.c:3520 [inline]\n kvfree_call_rcu+0x3b8/0x510 kernel/rcu/tree.c:3839\n trie_update_elem+0x47c/0x620 kernel/bpf/lpm_trie.c:441\n bpf_map_update_value+0x324/0x350 kernel/bpf/syscall.c:203\n generic_map_update_batch+0x401/0x520 kernel/bpf/syscall.c:1849\n bpf_map_do_batch+0x28c/0x3f0 kernel/bpf/syscall.c:5143\n __sys_bpf+0x2e5/0x7a0\n __do_sys_bpf kernel/bpf/syscall.c:5741 [inline]\n __se_sys_bpf kernel/bpf/syscall.c:5739 [inline]\n __x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5739\n x64_sys_call+0x2625/0x2d60 arch/x86/include/generated/asm/syscalls_64.h:322\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xc9/0x1c0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nwrite to 0xffff888237d1cce8 of 8 bytes by task 56 on cpu 0:\n __mod_timer+0x578/0x7f0 kernel/time/timer.c:1173\n add_timer_global+0x51/0x70 kernel/time/timer.c:1330\n __queue_delayed_work+0x127/0x1a0 kernel/workqueue.c:2523\n queue_delayed_work_on+0xdf/0x190 kernel/workqueue.c:2552\n queue_delayed_work include/linux/workqueue.h:677 [inline]\n schedule_delayed_monitor_work kernel/rcu/tree.c:3525 [inline]\n kfree_rcu_monitor+0x5e8/0x660 kernel/rcu/tree.c:3643\n process_one_work kernel/workqueue.c:3229 [inline]\n process_scheduled_works+0x483/0x9a0 kernel/workqueue.c:3310\n worker_thread+0x51d/0x6f0 kernel/workqueue.c:3391\n kthread+0x1d1/0x210 kernel/kthread.c:389\n ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n\nReported by Kernel Concurrency Sanitizer on:\nCPU: 0 UID: 0 PID: 56 Comm: kworker/u8:4 Not tainted 6.12.0-rc2-syzkaller-00050-g5b7c893ed5ed #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nWorkqueue: events_unbound kfree_rcu_monitor\n\n\nkfree_rcu_monitor() rearms the work if a "krcp" has to be still\noffloaded and this is done without holding krcp->lock, whereas\nthe kvfree_call_rcu() holds it.\n\nFix it by acquiring the "krcp->lock" for kfree_rcu_monitor() so\nboth functions do not race anymore.

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: ucsi: glink: fix off-by-one in connector_status\n\nUCSI connector's indices start from 1 up to 3, PMIC_GLINK_MAX_PORTS.\nCorrect the condition in the pmic_glink_ucsi_connector_status()\ncallback, fixing Type-C orientation reporting for the third USB-C\nconnector.

In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: error out earlier on disconnect\n\nEric reported a division by zero splat in the MPTCP protocol:\n\nOops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 1 UID: 0 PID: 6094 Comm: syz-executor317 Not tainted\n6.12.0-rc5-syzkaller-00291-g05b92660cdfe #0\nHardware name: Google Google Compute Engine/Google Compute Engine,\nBIOS Google 09/13/2024\nRIP: 0010:__tcp_select_window+0x5b4/0x1310 net/ipv4/tcp_output.c:3163\nCode: f6 44 01 e3 89 df e8 9b 75 09 f8 44 39 f3 0f 8d 11 ff ff ff e8\n0d 74 09 f8 45 89 f4 e9 04 ff ff ff e8 00 74 09 f8 44 89 f0 99 7c\n24 14 41 29 d6 45 89 f4 e9 ec fe ff ff e8 e8 73 09 f8 48 89\nRSP: 0018:ffffc900041f7930 EFLAGS: 00010293\nRAX: 0000000000017e67 RBX: 0000000000017e67 RCX: ffffffff8983314b\nRDX: 0000000000000000 RSI: ffffffff898331b0 RDI: 0000000000000004\nRBP: 00000000005d6000 R08: 0000000000000004 R09: 0000000000017e67\nR10: 0000000000003e80 R11: 0000000000000000 R12: 0000000000003e80\nR13: ffff888031d9b440 R14: 0000000000017e67 R15: 00000000002eb000\nFS: 00007feb5d7f16c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007feb5d8adbb8 CR3: 0000000074e4c000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n\n__tcp_cleanup_rbuf+0x3e7/0x4b0 net/ipv4/tcp.c:1493\nmptcp_rcv_space_adjust net/mptcp/protocol.c:2085 [inline]\nmptcp_recvmsg+0x2156/0x2600 net/mptcp/protocol.c:2289\ninet_recvmsg+0x469/0x6a0 net/ipv4/af_inet.c:885\nsock_recvmsg_nosec net/socket.c:1051 [inline]\nsock_recvmsg+0x1b2/0x250 net/socket.c:1073\n__sys_recvfrom+0x1a5/0x2e0 net/socket.c:2265\n__do_sys_recvfrom net/socket.c:2283 [inline]\n__se_sys_recvfrom net/socket.c:2279 [inline]\n__x64_sys_recvfrom+0xe0/0x1c0 net/socket.c:2279\ndo_syscall_x64 arch/x86/entry/common.c:52 [inline]\ndo_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\nentry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7feb5d857559\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48\n89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d\n01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007feb5d7f1208 EFLAGS: 00000246 ORIG_RAX: 000000000000002d\nRAX: ffffffffffffffda RBX: 00007feb5d8e1318 RCX: 00007feb5d857559\nRDX: 000000800000000e RSI: 0000000000000000 RDI: 0000000000000003\nRBP: 00007feb5d8e1310 R08: 0000000000000000 R09: ffffffff81000000\nR10: 0000000000000100 R11: 0000000000000246 R12: 00007feb5d8e131c\nR13: 00007feb5d8ae074 R14: 000000800000000e R15: 00000000fffffdef\n\nand provided a nice reproducer.\n\nThe root cause is the current bad handling of racing disconnect.\nAfter the blamed commit below, sk_wait_data() can return (with\nerror) with the underlying socket disconnected and a zero rcv_mss.\n\nCatch the error and return without performing any additional\noperations on the current socket.

In the Linux kernel, the following vulnerability has been resolved:\n\nnvme: tcp: avoid race between queue_lock lock and destroy\n\nCommit 76d54bf20cdc ("nvme-tcp: don't access released socket during\nerror recovery") added a mutex_lock() call for the queue->queue_lock\nin nvme_tcp_get_address(). However, the mutex_lock() races with\nmutex_destroy() in nvme_tcp_free_queue(), and causes the WARN below.\n\nDEBUG_LOCKS_WARN_ON(lock->magic != lock)\nWARNING: CPU: 3 PID: 34077 at kernel/locking/mutex.c:587 __mutex_lock+0xcf0/0x1220\nModules linked in: nvmet_tcp nvmet nvme_tcp nvme_fabrics iw_cm ib_cm ib_core pktcdvd nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables qrtr sunrpc ppdev 9pnet_virtio 9pnet pcspkr netfs parport_pc parport e1000 i2c_piix4 i2c_smbus loop fuse nfnetlink zram bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper xfs drm sym53c8xx floppy nvme scsi_transport_spi nvme_core nvme_auth serio_raw ata_generic pata_acpi dm_multipath qemu_fw_cfg [last unloaded: ib_uverbs]\nCPU: 3 UID: 0 PID: 34077 Comm: udisksd Not tainted 6.11.0-rc7 #319\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014\nRIP: 0010:__mutex_lock+0xcf0/0x1220\nCode: 08 84 d2 0f 85 c8 04 00 00 8b 15 ef b6 c8 01 85 d2 0f 85 78 f4 ff ff 48 c7 c6 20 93 ee af 48 c7 c7 60 91 ee af e8 f0 a7 6d fd <0f> 0b e9 5e f4 ff ff 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1\nRSP: 0018:ffff88811305f760 EFLAGS: 00010286\nRAX: 0000000000000000 RBX: ffff88812c652058 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001\nRBP: ffff88811305f8b0 R08: 0000000000000001 R09: ffffed1075c36341\nR10: ffff8883ae1b1a0b R11: 0000000000010498 R12: 0000000000000000\nR13: 0000000000000000 R14: dffffc0000000000 R15: ffff88812c652058\nFS: 00007f9713ae4980(0000) GS:ffff8883ae180000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fcd78483c7c CR3: 0000000122c38000 CR4: 00000000000006f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n ? __warn.cold+0x5b/0x1af\n ? __mutex_lock+0xcf0/0x1220\n ? report_bug+0x1ec/0x390\n ? handle_bug+0x3c/0x80\n ? exc_invalid_op+0x13/0x40\n ? asm_exc_invalid_op+0x16/0x20\n ? __mutex_lock+0xcf0/0x1220\n ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp]\n ? __pfx___mutex_lock+0x10/0x10\n ? __lock_acquire+0xd6a/0x59e0\n ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp]\n nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp]\n ? __pfx_nvme_tcp_get_address+0x10/0x10 [nvme_tcp]\n nvme_sysfs_show_address+0x81/0xc0 [nvme_core]\n dev_attr_show+0x42/0x80\n ? __asan_memset+0x1f/0x40\n sysfs_kf_seq_show+0x1f0/0x370\n seq_read_iter+0x2cb/0x1130\n ? rw_verify_area+0x3b1/0x590\n ? __mutex_lock+0x433/0x1220\n vfs_read+0x6a6/0xa20\n ? lockdep_hardirqs_on+0x78/0x100\n ? __pfx_vfs_read+0x10/0x10\n ksys_read+0xf7/0x1d0\n ? __pfx_ksys_read+0x10/0x10\n ? __x64_sys_openat+0x105/0x1d0\n do_syscall_64+0x93/0x180\n ? lockdep_hardirqs_on_prepare+0x16d/0x400\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on+0x78/0x100\n ? do_syscall_64+0x9f/0x180\n ? __pfx_ksys_read+0x10/0x10\n ? lockdep_hardirqs_on_prepare+0x16d/0x400\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on+0x78/0x100\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on_prepare+0x16d/0x400\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on+0x78/0x100\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on_prepare+0x16d/0x400\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on+0x78/0x100\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on_prepare+0x16d/0x400\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on+0x78/0x100\n ? do_syscall_64+0x9f/0x180\n ? do_syscall_64+0x9f/0x180\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7f9713f55cfa\nCode: 55 48 89 e5 48 83 ec 20 48 89 55 e8 48 89 75 f0 89 7d f8 e8 e8 74 f8 ff 48 8b 55 e8 48 8b 75 f0 41 89 c0 8b 7d f8 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 2e 44 89 c7 48 89 45 f8 e8 42 75 f8 ff 48 8b\nRSP: 002b:00007ffd7f512e70 EFLAGS: 00000246 ORIG_RAX: 0000000000000000\nRAX: ffffffffffffffda RBX: 000055c38f316859 RCX: 00007f9713f55cfa\nRDX: 0000000000000fff RSI: 00007ffd7f512eb0 RDI: 0000000000000011\nRBP: 00007ffd7f512e90 R08: 0000000000000000 R09: 00000000ffffffff\nR10: 0000000000000000 R11: 0000000000000246 R12: 000055c38f317148\nR13: 0000000000000000 R14: 00007f96f4004f30 R15: 000055c3b6b623c0\n </TASK>\n\nThe WARN is observed when the blktests test case nvme/014 is repeated\nwith tcp transport. It is rare, and 200 times repeat is required to\nrecreate in some test environments.\n\nTo avoid the WARN, check the NVME_TCP_Q_LIVE flag before locking\nqueue->queue_lock. The flag is cleared long time before the lock gets\ndestroyed.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/panthor: Lock XArray when getting entries for the VM\n\nSimilar to commit cac075706f29 ("drm/panthor: Fix race when converting\ngroup handle to group object") we need to use the XArray's internal\nlocking when retrieving a vm pointer from there.\n\nv2: Removed part of the patch that was trying to protect fetching\nthe heap pointer from XArray, as that operation is protected by\nthe @pool->lock.

In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: dapm: fix bounds checker error in dapm_widget_list_create\n\nThe widgets array in the snd_soc_dapm_widget_list has a __counted_by\nattribute attached to it, which points to the num_widgets variable. This\nattribute is used in bounds checking, and if it is not set before the\narray is filled, then the bounds sanitizer will issue a warning or a\nkernel panic if CONFIG_UBSAN_TRAP is set.\n\nThis patch sets the size of the widgets list calculated with\nlist_for_each as the initial value for num_widgets as it is used for\nallocating memory for the array. It is updated with the actual number of\nadded elements after the array is filled.

In the Linux kernel, the following vulnerability has been resolved:\n\nsctp: properly validate chunk size in sctp_sf_ootb()\n\nA size validation fix similar to that in Commit 50619dbf8db7 ("sctp: add\nsize validation when walking chunks") is also required in sctp_sf_ootb()\nto address a crash reported by syzbot:\n\n BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712\n sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712\n sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166\n sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407\n sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88\n sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243\n sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159\n ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205\n ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: enetc: allocate vf_state during PF probes\n\nIn the previous implementation, vf_state is allocated memory only when VF\nis enabled. However, net_device_ops::ndo_set_vf_mac() may be called before\nVF is enabled to configure the MAC address of VF. If this is the case,\nenetc_pf_set_vf_mac() will access vf_state, resulting in access to a null\npointer. The simplified error log is as follows.\n\nroot@ls1028ardb:~# ip link set eno0 vf 1 mac 00:0c:e7:66:77:89\n[ 173.543315] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004\n[ 173.637254] pc : enetc_pf_set_vf_mac+0x3c/0x80 Message from sy\n[ 173.641973] lr : do_setlink+0x4a8/0xec8\n[ 173.732292] Call trace:\n[ 173.734740] enetc_pf_set_vf_mac+0x3c/0x80\n[ 173.738847] __rtnl_newlink+0x530/0x89c\n[ 173.742692] rtnl_newlink+0x50/0x7c\n[ 173.746189] rtnetlink_rcv_msg+0x128/0x390\n[ 173.750298] netlink_rcv_skb+0x60/0x130\n[ 173.754145] rtnetlink_rcv+0x18/0x24\n[ 173.757731] netlink_unicast+0x318/0x380\n[ 173.761665] netlink_sendmsg+0x17c/0x3c8

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: Fix use-after-free in get_info()\n\nip6table_nat module unload has refcnt warning for UAF. call trace is:\n\nWARNING: CPU: 1 PID: 379 at kernel/module/main.c:853 module_put+0x6f/0x80\nModules linked in: ip6table_nat(-)\nCPU: 1 UID: 0 PID: 379 Comm: ip6tables Not tainted 6.12.0-rc4-00047-gc2ee9f594da8-dirty #205\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996),\nBIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nRIP: 0010:module_put+0x6f/0x80\nCall Trace:\n <TASK>\n get_info+0x128/0x180\n do_ip6t_get_ctl+0x6a/0x430\n nf_getsockopt+0x46/0x80\n ipv6_getsockopt+0xb9/0x100\n rawv6_getsockopt+0x42/0x190\n do_sock_getsockopt+0xaa/0x180\n __sys_getsockopt+0x70/0xc0\n __x64_sys_getsockopt+0x20/0x30\n do_syscall_64+0xa2/0x1a0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nConcurrent execution of module unload and get_info() trigered the warning.\nThe root cause is as follows:\n\ncpu0 cpu1\nmodule_exit\n//mod->state = MODULE_STATE_GOING\n ip6table_nat_exit\n xt_unregister_template\n kfree(t)\n //removed from templ_list\n getinfo()\n t = xt_find_table_lock\n list_for_each_entry(tmpl, &xt_templates[af]...)\n if (strcmp(tmpl->name, name))\n continue; //table not found\n try_module_get\n list_for_each_entry(t, &xt_net->tables[af]...)\n return t; //not get refcnt\n module_put(t->me) //uaf\n unregister_pernet_subsys\n //remove table from xt_net list\n\nWhile xt_table module was going away and has been removed from\nxt_templates list, we couldnt get refcnt of xt_table->me. Check\nmodule in xt_net->tables list re-traversal to fix it.

In the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Add rough attr alloc_size check

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: do not pass a stopped vif to the driver in .get_txpower\n\nAvoid potentially crashing in the driver because of uninitialized private data

In the Linux kernel, the following vulnerability has been resolved:\n\nmaple_tree: correct tree corruption on spanning store\n\nPatch series "maple_tree: correct tree corruption on spanning store", v3.\n\nThere has been a nasty yet subtle maple tree corruption bug that appears\nto have been in existence since the inception of the algorithm.\n\nThis bug seems far more likely to happen since commit f8d112a4e657\n("mm/mmap: avoid zeroing vma tree in mmap_region()"), which is the point\nat which reports started to be submitted concerning this bug.\n\nWe were made definitely aware of the bug thanks to the kind efforts of\nBert Karwatzki who helped enormously in my being able to track this down\nand identify the cause of it.\n\nThe bug arises when an attempt is made to perform a spanning store across\ntwo leaf nodes, where the right leaf node is the rightmost child of the\nshared parent, AND the store completely consumes the right-mode node.\n\nThis results in mas_wr_spanning_store() mitakenly duplicating the new and\nexisting entries at the maximum pivot within the range, and thus maple\ntree corruption.\n\nThe fix patch corrects this by detecting this scenario and disallowing the\nmistaken duplicate copy.\n\nThe fix patch commit message goes into great detail as to how this occurs.\n\nThis series also includes a test which reliably reproduces the issue, and\nasserts that the fix works correctly.\n\nBert has kindly tested the fix and confirmed it resolved his issues. Also\nMikhail Gavrilov kindly reported what appears to be precisely the same\nbug, which this fix should also resolve.\n\n\nThis patch (of 2):\n\nThere has been a subtle bug present in the maple tree implementation from\nits inception.\n\nThis arises from how stores are performed - when a store occurs, it will\noverwrite overlapping ranges and adjust the tree as necessary to\naccommodate this.\n\nA range may always ultimately span two leaf nodes. In this instance we\nwalk the two leaf nodes, determine which elements are not overwritten to\nthe left and to the right of the start and end of the ranges respectively\nand then rebalance the tree to contain these entries and the newly\ninserted one.\n\nThis kind of store is dubbed a 'spanning store' and is implemented by\nmas_wr_spanning_store().\n\nIn order to reach this stage, mas_store_gfp() invokes\nmas_wr_preallocate(), mas_wr_store_type() and mas_wr_walk() in turn to\nwalk the tree and update the object (mas) to traverse to the location\nwhere the write should be performed, determining its store type.\n\nWhen a spanning store is required, this function returns false stopping at\nthe parent node which contains the target range, and mas_wr_store_type()\nmarks the mas->store_type as wr_spanning_store to denote this fact.\n\nWhen we go to perform the store in mas_wr_spanning_store(), we first\ndetermine the elements AFTER the END of the range we wish to store (that\nis, to the right of the entry to be inserted) - we do this by walking to\nthe NEXT pivot in the tree (i.e. r_mas.last + 1), starting at the node we\nhave just determined contains the range over which we intend to write.\n\nWe then turn our attention to the entries to the left of the entry we are\ninserting, whose state is represented by l_mas, and copy these into a 'big\nnode', which is a special node which contains enough slots to contain two\nleaf node's worth of data.\n\nWe then copy the entry we wish to store immediately after this - the copy\nand the insertion of the new entry is performed by mas_store_b_node().\n\nAfter this we copy the elements to the right of the end of the range which\nwe are inserting, if we have not exceeded the length of the node (i.e. \nr_mas.offset <= r_mas.end).\n\nHerein lies the bug - under very specific circumstances, this logic can\nbreak and corrupt the maple tree.\n\nConsider the following tree:\n\nHeight\n 0 Root Node\n / \\\n pivot = 0xffff / \\ pivot = ULONG_MAX\n / \n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nmm/swapfile: skip HugeTLB pages for unuse_vma\n\nI got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The\nproblem can be reproduced by the following steps:\n\n 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory.\n 2. Swapout the above anonymous memory.\n 3. run swapoff and we will get a bad pud error in kernel message:\n\n mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7)\n\nWe can tell that pud_clear_bad is called by pud_none_or_clear_bad in\nunuse_pud_range() by ftrace. And therefore the HugeTLB pages will never\nbe freed because we lost it from page table. We can skip HugeTLB pages\nfor unuse_vma to fix it.

In the Linux kernel, the following vulnerability has been resolved:\n\npinctrl: intel: platform: fix error path in device_for_each_child_node()\n\nThe device_for_each_child_node() loop requires calls to\nfwnode_handle_put() upon early returns to decrement the refcount of\nthe child node and avoid leaking memory if that error path is triggered.\n\nThere is one early returns within that loop in\nintel_platform_pinctrl_prepare_community(), but fwnode_handle_put() is\nmissing.\n\nInstead of adding the missing call, the scoped version of the loop can\nbe used to simplify the code and avoid mistakes in the future if new\nearly returns are added, as the child node is only used for parsing, and\nit is never assigned.

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/bnxt_re: Fix a possible memory leak\n\nIn bnxt_re_setup_chip_ctx() when bnxt_qplib_map_db_bar() fails\ndriver is not freeing the memory allocated for "rdev->chip_ctx".

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: bcmasp: fix potential memory leak in bcmasp_xmit()\n\nThe bcmasp_xmit() returns NETDEV_TX_OK without freeing skb\nin case of mapping fails, add dev_kfree_skb() to fix it.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm: Avoid NULL dereference in msm_disp_state_print_regs()\n\nIf the allocation in msm_disp_state_dump_regs() failed then\n`block->state` can be NULL. The msm_disp_state_print_regs() function\n_does_ have code to try to handle it with:\n\n if (*reg)\n dump_addr = *reg;\n\n...but since "dump_addr" is initialized to NULL the above is actually\na noop. The code then goes on to dereference `dump_addr`.\n\nMake the function print "Registers not stored" when it sees a NULL to\nsolve this. Since we're touching the code, fix\nmsm_disp_state_print_regs() not to pointlessly take a double-pointer\nand properly mark the pointer as `const`.\n\nPatchwork: https://patchwork.freedesktop.org/patch/619657/

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: ISO: Fix UAF on iso_sock_timeout\n\nconn->sk maybe have been unlinked/freed while waiting for iso_conn_lock\nso this checks if the conn->sk is still valid by checking if it part of\niso_sk_list.

In the Linux kernel, the following vulnerability has been resolved:\n\nxhci: tegra: fix checked USB2 port number\n\nIf USB virtualizatoin is enabled, USB2 ports are shared between all\nVirtual Functions. The USB2 port number owned by an USB2 root hub in\na Virtual Function may be less than total USB2 phy number supported\nby the Tegra XUSB controller.\n\nUsing total USB2 phy number as port number to check all PORTSC values\nwould cause invalid memory access.\n\n[ 116.923438] Unable to handle kernel paging request at virtual address 006c622f7665642f\n...\n[ 117.213640] Call trace:\n[ 117.216783] tegra_xusb_enter_elpg+0x23c/0x658\n[ 117.222021] tegra_xusb_runtime_suspend+0x40/0x68\n[ 117.227260] pm_generic_runtime_suspend+0x30/0x50\n[ 117.232847] __rpm_callback+0x84/0x3c0\n[ 117.237038] rpm_suspend+0x2dc/0x740\n[ 117.241229] pm_runtime_work+0xa0/0xb8\n[ 117.245769] process_scheduled_works+0x24c/0x478\n[ 117.251007] worker_thread+0x23c/0x328\n[ 117.255547] kthread+0x104/0x1b0\n[ 117.259389] ret_from_fork+0x10/0x20\n[ 117.263582] Code: 54000222 f9461ae8 f8747908 b4ffff48 (f9400100)

In the Linux kernel, the following vulnerability has been resolved:\n\nparport: Proper fix for array out-of-bounds access\n\nThe recent fix for array out-of-bounds accesses replaced sprintf()\ncalls blindly with snprintf(). However, since snprintf() returns the\nwould-be-printed size, not the actually output size, the length\ncalculation can still go over the given limit.\n\nUse scnprintf() instead of snprintf(), which returns the actually\noutput letters, for addressing the potential out-of-bounds access\nproperly.

In the Linux kernel, the following vulnerability has been resolved:\n\nserial: protect uart_port_dtr_rts() in uart_shutdown() too\n\nCommit af224ca2df29 (serial: core: Prevent unsafe uart port access, part\n3) added few uport == NULL checks. It added one to uart_shutdown(), so\nthe commit assumes, uport can be NULL in there. But right after that\nprotection, there is an unprotected "uart_port_dtr_rts(uport, false);"\ncall. That is invoked only if HUPCL is set, so I assume that is the\nreason why we do not see lots of these reports.\n\nOr it cannot be NULL at this point at all for some reason :P.\n\nUntil the above is investigated, stay on the safe side and move this\ndereference to the if too.\n\nI got this inconsistency from Coverity under CID 1585130. Thanks.

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: tipd: Free IRQ only if it was requested before\n\nIn polling mode, if no IRQ was requested there is no need to free it.\nCall devm_free_irq() only if client->irq is set. This fixes the warning\ncaused by the tps6598x module removal:\n\nWARNING: CPU: 2 PID: 333 at kernel/irq/devres.c:144 devm_free_irq+0x80/0x8c\n...\n...\nCall trace:\n devm_free_irq+0x80/0x8c\n tps6598x_remove+0x28/0x88 [tps6598x]\n i2c_device_remove+0x2c/0x9c\n device_remove+0x4c/0x80\n device_release_driver_internal+0x1cc/0x228\n driver_detach+0x50/0x98\n bus_remove_driver+0x6c/0xbc\n driver_unregister+0x30/0x60\n i2c_del_driver+0x54/0x64\n tps6598x_i2c_driver_exit+0x18/0xc3c [tps6598x]\n __arm64_sys_delete_module+0x184/0x264\n invoke_syscall+0x48/0x110\n el0_svc_common.constprop.0+0xc8/0xe8\n do_el0_svc+0x20/0x2c\n el0_svc+0x28/0x98\n el0t_64_sync_handler+0x13c/0x158\n el0t_64_sync+0x190/0x194

In the Linux kernel, the following vulnerability has been resolved:\n\nspi: mpc52xx: Add cancel_work_sync before module remove\n\nIf we remove the module which will call mpc52xx_spi_remove\nit will free 'ms' through spi_unregister_controller.\nwhile the work ms->work will be used. The sequence of operations\nthat may lead to a UAF bug.\n\nFix it by ensuring that the work is canceled before proceeding with\nthe cleanup in mpc52xx_spi_remove.

In the Linux kernel, the following vulnerability has been resolved:\n\nx86/mm/ident_map: Use gbpages only where full GB page should be mapped.\n\nWhen ident_pud_init() uses only GB pages to create identity maps, large\nranges of addresses not actually requested can be included in the resulting\ntable; a 4K request will map a full GB. This can include a lot of extra\naddress space past that requested, including areas marked reserved by the\nBIOS. That allows processor speculation into reserved regions, that on UV\nsystems can cause system halts.\n\nOnly use GB pages when map creation requests include the full GB page of\nspace. Fall back to using smaller 2M pages when only portions of a GB page\nare included in the request.\n\nNo attempt is made to coalesce mapping requests. If a request requires a\nmap entry at the 2M (pmd) level, subsequent mapping requests within the\nsame 1G region will also be at the pmd level, even if adjacent or\noverlapping such requests could have been combined to map a full GB page.\nExisting usage starts with larger regions and then adds smaller regions, so\nthis should not have any great consequence.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtw89: avoid reading out of bounds when loading TX power FW elements\n\nBecause the loop-expression will do one more time before getting false from\ncond-expression, the original code copied one more entry size beyond valid\nregion.\n\nFix it by moving the entry copy to loop-body.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags\n\n[WHAT & HOW]\n"dcn20_validate_apply_pipe_split_flags" dereferences merge, and thus it\ncannot be a null pointer. Let's pass a valid pointer to avoid null\ndereference.\n\nThis fixes 2 FORWARD_NULL issues reported by Coverity.

In the Linux kernel, the following vulnerability has been resolved:\n\nsched/fair: Fix NEXT_BUDDY\n\nAdam reports that enabling NEXT_BUDDY insta triggers a WARN in\npick_next_entity().\n\nMoving clear_buddies() up before the delayed dequeue bits ensures\nno ->next buddy becomes delayed. Further ensure no new ->next buddy\never starts as delayed.

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: don't take dev_replace rwsem on task already holding it\n\nRunning fstests btrfs/011 with MKFS_OPTIONS="-O rst" to force the usage of\nthe RAID stripe-tree, we get the following splat from lockdep:\n\n BTRFS info (device sdd): dev_replace from /dev/sdd (devid 1) to /dev/sdb started\n\n ============================================\n WARNING: possible recursive locking detected\n 6.11.0-rc3-btrfs-for-next #599 Not tainted\n --------------------------------------------\n btrfs/2326 is trying to acquire lock:\n ffff88810f215c98 (&fs_info->dev_replace.rwsem){++++}-{3:3}, at: btrfs_map_block+0x39f/0x2250\n\n but task is already holding lock:\n ffff88810f215c98 (&fs_info->dev_replace.rwsem){++++}-{3:3}, at: btrfs_map_block+0x39f/0x2250\n\n other info that might help us debug this:\n Possible unsafe locking scenario:\n\n CPU0\n ----\n lock(&fs_info->dev_replace.rwsem);\n lock(&fs_info->dev_replace.rwsem);\n\n *** DEADLOCK ***\n\n May be due to missing lock nesting notation\n\n 1 lock held by btrfs/2326:\n #0: ffff88810f215c98 (&fs_info->dev_replace.rwsem){++++}-{3:3}, at: btrfs_map_block+0x39f/0x2250\n\n stack backtrace:\n CPU: 1 UID: 0 PID: 2326 Comm: btrfs Not tainted 6.11.0-rc3-btrfs-for-next #599\n Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011\n Call Trace:\n <TASK>\n dump_stack_lvl+0x5b/0x80\n __lock_acquire+0x2798/0x69d0\n ? __pfx___lock_acquire+0x10/0x10\n ? __pfx___lock_acquire+0x10/0x10\n lock_acquire+0x19d/0x4a0\n ? btrfs_map_block+0x39f/0x2250\n ? __pfx_lock_acquire+0x10/0x10\n ? find_held_lock+0x2d/0x110\n ? lock_is_held_type+0x8f/0x100\n down_read+0x8e/0x440\n ? btrfs_map_block+0x39f/0x2250\n ? __pfx_down_read+0x10/0x10\n ? do_raw_read_unlock+0x44/0x70\n ? _raw_read_unlock+0x23/0x40\n btrfs_map_block+0x39f/0x2250\n ? btrfs_dev_replace_by_ioctl+0xd69/0x1d00\n ? btrfs_bio_counter_inc_blocked+0xd9/0x2e0\n ? __kasan_slab_alloc+0x6e/0x70\n ? __pfx_btrfs_map_block+0x10/0x10\n ? __pfx_btrfs_bio_counter_inc_blocked+0x10/0x10\n ? kmem_cache_alloc_noprof+0x1f2/0x300\n ? mempool_alloc_noprof+0xed/0x2b0\n btrfs_submit_chunk+0x28d/0x17e0\n ? __pfx_btrfs_submit_chunk+0x10/0x10\n ? bvec_alloc+0xd7/0x1b0\n ? bio_add_folio+0x171/0x270\n ? __pfx_bio_add_folio+0x10/0x10\n ? __kasan_check_read+0x20/0x20\n btrfs_submit_bio+0x37/0x80\n read_extent_buffer_pages+0x3df/0x6c0\n btrfs_read_extent_buffer+0x13e/0x5f0\n read_tree_block+0x81/0xe0\n read_block_for_search+0x4bd/0x7a0\n ? __pfx_read_block_for_search+0x10/0x10\n btrfs_search_slot+0x78d/0x2720\n ? __pfx_btrfs_search_slot+0x10/0x10\n ? lock_is_held_type+0x8f/0x100\n ? kasan_save_track+0x14/0x30\n ? __kasan_slab_alloc+0x6e/0x70\n ? kmem_cache_alloc_noprof+0x1f2/0x300\n btrfs_get_raid_extent_offset+0x181/0x820\n ? __pfx_lock_acquire+0x10/0x10\n ? __pfx_btrfs_get_raid_extent_offset+0x10/0x10\n ? down_read+0x194/0x440\n ? __pfx_down_read+0x10/0x10\n ? do_raw_read_unlock+0x44/0x70\n ? _raw_read_unlock+0x23/0x40\n btrfs_map_block+0x5b5/0x2250\n ? __pfx_btrfs_map_block+0x10/0x10\n scrub_submit_initial_read+0x8fe/0x11b0\n ? __pfx_scrub_submit_initial_read+0x10/0x10\n submit_initial_group_read+0x161/0x3a0\n ? lock_release+0x20e/0x710\n ? __pfx_submit_initial_group_read+0x10/0x10\n ? __pfx_lock_release+0x10/0x10\n scrub_simple_mirror.isra.0+0x3eb/0x580\n scrub_stripe+0xe4d/0x1440\n ? lock_release+0x20e/0x710\n ? __pfx_scrub_stripe+0x10/0x10\n ? __pfx_lock_release+0x10/0x10\n ? do_raw_read_unlock+0x44/0x70\n ? _raw_read_unlock+0x23/0x40\n scrub_chunk+0x257/0x4a0\n scrub_enumerate_chunks+0x64c/0xf70\n ? __mutex_unlock_slowpath+0x147/0x5f0\n ? __pfx_scrub_enumerate_chunks+0x10/0x10\n ? bit_wait_timeout+0xb0/0x170\n ? __up_read+0x189/0x700\n ? scrub_workers_get+0x231/0x300\n ? up_write+0x490/0x4f0\n btrfs_scrub_dev+0x52e/0xcd0\n ? create_pending_snapshots+0x230/0x250\n ? __pfx_btrfs_scrub_dev+0x10/0x10\n btrfs_dev_replace_by_ioctl+0xd69/0x1d00\n ? lock_acquire+0x19d/0x4a0\n ? __pfx_btrfs_dev_replace_by_ioctl+0x10/0x10\n ? lock_release+0x20e/0x710\n ? btrfs_ioctl+0xa09/0x74f0\n ? __pfx_lock_release+0x10/0x10\n ? do_raw_spin_lock+0x11e/0x240\n ? __pfx_do_raw_spin_lock+0x10/0x10\n btrfs_ioctl+0xa14/0x74f0\n ? lock_acquire+0x19d/0x4a0\n ? find_held_lock+0x2d/0x110\n ? __pfx_btrfs_ioctl+0x10/0x10\n ? lock_release+0x20e/0x710\n ? do_sigaction+0x3f0/0x860\n ? __pfx_do_vfs_ioctl+0x10/0x10\n ? do_raw_spin_lock+0x11e/0x240\n ? lockdep_hardirqs_on_prepare+0x270/0x3e0\n ? _raw_spin_unlock_irq+0x28/0x50\n ? do_sigaction+0x3f0/0x860\n ? __pfx_do_sigaction+0x10/0x10\n ? __x64_sys_rt_sigaction+0x18e/0x1e0\n ? __pfx___x64_sys_rt_sigaction+0x10/0x10\n ? __x64_sys_close+0x7c/0xd0\n __x64_sys_ioctl+0x137/0x190\n do_syscall_64+0x71/0x140\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n RIP: 0033:0x7f0bd1114f9b\n Code: Unable to access opcode bytes at 0x7f0bd1114f71.\n RSP: 002b:00007ffc8a8c3130 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\n RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f0bd1114f9b\n RDX: 00007ffc8a8c35e0 RSI: 00000000ca289435 RDI: 0000000000000003\n RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000007\n R10: 0000000000000008 R11: 0000000000000246 R12: 00007ffc8a8c6c85\n R13: 00000000398e72a0 R14: 0000000000004361 R15: 0000000000000004\n </TASK>\n\nThis happens because on RAID stripe-tree filesystems we recurse back into\nbtrfs_map_block() on scrub to perform the logical to device physical\nmapping.\n\nBut as the device replace task is already holding the dev_replace::rwsem\nwe deadlock.\n\nSo don't take the dev_replace::rwsem in case our task is the task performing\nthe device replace.

In the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: add bounds checking to ocfs2_xattr_find_entry()\n\nAdd a paranoia check to make sure it doesn't stray beyond valid memory\nregion containing ocfs2 xattr entries when scanning for a match. It will\nprevent out-of-bound access in case of crafted images.

In the Linux kernel, the following vulnerability has been resolved:\n\nsmack: tcp: ipv4, fix incorrect labeling\n\nCurrently, Smack mirrors the label of incoming tcp/ipv4 connections:\nwhen a label 'foo' connects to a label 'bar' with tcp/ipv4,\n'foo' always gets 'foo' in returned ipv4 packets. So,\n1) returned packets are incorrectly labeled ('foo' instead of 'bar')\n2) 'bar' can write to 'foo' without being authorized to write.\n\nHere is a scenario how to see this:\n\n* Take two machines, let's call them C and S,\n with active Smack in the default state\n (no settings, no rules, no labeled hosts, only builtin labels)\n\n* At S, add Smack rule 'foo bar w'\n (labels 'foo' and 'bar' are instantiated at S at this moment)\n\n* At S, at label 'bar', launch a program\n that listens for incoming tcp/ipv4 connections\n\n* From C, at label 'foo', connect to the listener at S.\n (label 'foo' is instantiated at C at this moment)\n Connection succeedes and works.\n\n* Send some data in both directions.\n* Collect network traffic of this connection.\n\nAll packets in both directions are labeled with the CIPSO\nof the label 'foo'. Hence, label 'bar' writes to 'foo' without\nbeing authorized, and even without ever being known at C.\n\nIf anybody cares: exactly the same happens with DCCP.\n\nThis behavior 1st manifested in release 2.6.29.4 (see Fixes below)\nand it looks unintentional. At least, no explanation was provided.\n\nI changed returned packes label into the 'bar',\nto bring it into line with the Smack documentation claims.

Rollup is a module bundler for JavaScript. Versions prior to 2.79.2, 3.29.5, and 4.22.4 are susceptible to a DOM Clobbering vulnerability when bundling scripts with properties from `import.meta` (e.g., `import.meta.url`) in `cjs`/`umd`/`iife` format. The DOM Clobbering gadget can lead to cross-site scripting (XSS) in web pages where scriptless attacker-controlled HTML elements (e.g., an `img` tag with an unsanitized `name` attribute) are present. Versions 2.79.2, 3.29.5, and 4.22.4 contain a patch for the vulnerability.