Detections
Analytics
Debian dsa-5658 : affs-modules-6.1.0-11-4kc-malta-di - security update
high Nessus Plugin ID 193309
Synopsis
The remote Debian host is missing one or more security-related updates.Description
The remote Debian 12 host has packages installed that are affected by multiple vulnerabilities as referenced in the dsa-5658 advisory.- A vulnerability was found in compare_netdev_and_ip in drivers/infiniband/core/cma.c in RDMA in the Linux Kernel. The improper cleanup results in out-of-boundary read, where a local user can utilize this problem to crash the system or escalation of privilege. (CVE-2023-2176)
- Information exposure through microarchitectural state after transient execution from some register files for some Intel(R) Atom(R) Processors may allow an authenticated user to potentially enable information disclosure via local access. (CVE-2023-28746)
- The brcm80211 component in the Linux kernel through 6.5.10 has a brcmf_cfg80211_detach use-after-free in the device unplugging (disconnect the USB by hotplug) code. For physically proximate attackers with local access, this could be exploited in a real world scenario. This is related to brcmf_cfg80211_escan_timeout_worker in drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c.
(CVE-2023-47233)
- dm_table_create in drivers/md/dm-table.c in the Linux kernel through 6.7.4 can attempt to (in alloc_targets) allocate more than INT_MAX bytes, and crash, because of a missing check for struct dm_ioctl.target_count. (CVE-2023-52429)
- In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential OOBs in smb2_parse_contexts() Validate offsets and lengths before dereferencing create contexts in smb2_parse_contexts(). This fixes following oops when accessing invalid create contexts from server: BUG:
unable to handle page fault for address: ffff8881178d8cc3 #PF: supervisor read access in kernel mode #PF:
error_code(0x0000) - not-present page PGD 4a01067 P4D 4a01067 PUD 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU:
3 PID: 1736 Comm: mount.cifs Not tainted 6.7.0-rc4 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 RIP: 0010:smb2_parse_contexts+0xa0/0x3a0 [cifs] Code: f8 10 75 13 48 b8 93 ad 25 50 9c b4 11 e7 49 39 06 0f 84 d2 00 00 00 8b 45 00 85 c0 74 61 41 29 c5 48 01 c5 41 83 fd 0f 76 55 <0f> b7 7d 04 0f b7 45 06 4c 8d 74 3d 00 66 83 f8 04 75 bc ba 04 00 RSP:
0018:ffffc900007939e0 EFLAGS: 00010216 RAX: ffffc90000793c78 RBX: ffff8880180cc000 RCX: ffffc90000793c90 RDX: ffffc90000793cc0 RSI: ffff8880178d8cc0 RDI: ffff8880180cc000 RBP: ffff8881178d8cbf R08:
ffffc90000793c22 R09: 0000000000000000 R10: ffff8880180cc000 R11: 0000000000000024 R12: 0000000000000000 R13: 0000000000000020 R14: 0000000000000000 R15: ffffc90000793c22 FS: 00007f873753cbc0(0000) GS:ffff88806bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
ffff8881178d8cc3 CR3: 00000000181ca000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ?
__die+0x23/0x70 ? page_fault_oops+0x181/0x480 ? search_module_extables+0x19/0x60 ? srso_alias_return_thunk+0x5/0xfbef5 ? exc_page_fault+0x1b6/0x1c0 ? asm_exc_page_fault+0x26/0x30 ? smb2_parse_contexts+0xa0/0x3a0 [cifs] SMB2_open+0x38d/0x5f0 [cifs] ? smb2_is_path_accessible+0x138/0x260 [cifs] smb2_is_path_accessible+0x138/0x260 [cifs] cifs_is_path_remote+0x8d/0x230 [cifs] cifs_mount+0x7e/0x350 [cifs] cifs_smb3_do_mount+0x128/0x780 [cifs] smb3_get_tree+0xd9/0x290 [cifs] vfs_get_tree+0x2c/0x100 ? capable+0x37/0x70 path_mount+0x2d7/0xb80 ? srso_alias_return_thunk+0x5/0xfbef5 ?
_raw_spin_unlock_irqrestore+0x44/0x60 __x64_sys_mount+0x11a/0x150 do_syscall_64+0x47/0xf0 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7f8737657b1e (CVE-2023-52434)
- In the Linux kernel, the following vulnerability has been resolved: net: prevent mss overflow in skb_segment() Once again syzbot is able to crash the kernel in skb_segment() [1] GSO_BY_FRAGS is a forbidden value, but unfortunately the following computation in skb_segment() can reach it quite easily :
mss = mss * partial_segs; 65535 = 3 * 5 * 17 * 257, so many initial values of mss can lead to a bad final result. Make sure to limit segmentation so that the new mss value is smaller than GSO_BY_FRAGS. [1] general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 1 PID: 5079 Comm: syz- executor993 Not tainted 6.7.0-rc4-syzkaller-00141-g1ae4cd3cbdd0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023 RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551 Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00 RSP: 0018:ffffc900043473d0 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000010046 RCX:
ffffffff886b1597 RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070 RBP: ffffc90004347578 R08: 0000000000000005 R09: 000000000000ffff R10: 000000000000ffff R11: 0000000000000002 R12:
ffff888063202ac0 R13: 0000000000010000 R14: 000000000000ffff R15: 0000000000000046 FS:
0000555556e7e380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033 CR2: 0000000020010000 CR3: 0000000027ee2000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400 Call Trace: <TASK> udp6_ufo_fragment+0xa0e/0xd00 net/ipv6/udp_offload.c:109 ipv6_gso_segment+0x534/0x17e0 net/ipv6/ip6_offload.c:120 skb_mac_gso_segment+0x290/0x610 net/core/gso.c:53
__skb_gso_segment+0x339/0x710 net/core/gso.c:124 skb_gso_segment include/net/gso.h:83 [inline] validate_xmit_skb+0x36c/0xeb0 net/core/dev.c:3626 __dev_queue_xmit+0x6f3/0x3d60 net/core/dev.c:4338 dev_queue_xmit include/linux/netdevice.h:3134 [inline] packet_xmit+0x257/0x380 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x24c6/0x5220 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745
__sys_sendto+0x255/0x340 net/socket.c:2190 __do_sys_sendto net/socket.c:2202 [inline] __se_sys_sendto net/socket.c:2198 [inline] __x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b RIP: 0033:0x7f8692032aa9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 d1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff8d685418 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f8692032aa9 RDX:
0000000000010048 RSI: 00000000200000c0 RDI: 0000000000000003 RBP: 00000000000f4240 R08: 0000000020000540 R09: 0000000000000014 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff8d685480 R13:
0000000000000001 R14: 00007fff8d685480 R15: 0000000000000003 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551 Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00 RSP: 0018:ffffc900043473d0 EFLAGS:
00010202 RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597 RDX: 000000000000000e RSI:
ffffffff886b2520 RDI: 0000000000000070 RBP: ffffc90004347578 R0 ---truncated--- (CVE-2023-52435)
- In the Linux kernel, the following vulnerability has been resolved: ceph: fix deadlock or deadcode of misusing dget() The lock order is incorrect between denty and its parent, we should always make sure that the parent get the lock first. But since this deadcode is never used and the parent dir will always be set from the callers, let's just remove it. (CVE-2023-52583)
- In the Linux kernel, the following vulnerability has been resolved: spmi: mediatek: Fix UAF on device remove The pmif driver data that contains the clocks is allocated along with spmi_controller. On device remove, spmi_controller will be freed first, and then devres , including the clocks, will be cleanup. This leads to UAF because putting the clocks will access the clocks in the pmif driver data, which is already freed along with spmi_controller. This can be reproduced by enabling DEBUG_TEST_DRIVER_REMOVE and building the kernel with KASAN. Fix the UAF issue by using unmanaged clk_bulk_get() and putting the clocks before freeing spmi_controller. (CVE-2023-52584)
- In the Linux kernel, the following vulnerability has been resolved: IB/ipoib: Fix mcast list locking Releasing the `priv->lock` while iterating the `priv->multicast_list` in `ipoib_mcast_join_task()` opens a window for `ipoib_mcast_dev_flush()` to remove the items while in the middle of iteration. If the mcast is removed while the lock was dropped, the for loop spins forever resulting in a hard lockup (as was reported on RHEL 4.18.0-372.75.1.el8_6 kernel): Task A (kworker/u72:2 below) | Task B (kworker/u72:0 below)
-----------------------------------+----------------------------------- ipoib_mcast_join_task(work) | ipoib_ib_dev_flush_light(work) spin_lock_irq(&priv->lock) | __ipoib_ib_dev_flush(priv, ...) list_for_each_entry(mcast, | ipoib_mcast_dev_flush(dev = priv->dev) &priv->multicast_list, list) | ipoib_mcast_join(dev, mcast) | spin_unlock_irq(&priv->lock) | | spin_lock_irqsave(&priv->lock, flags) | list_for_each_entry_safe(mcast, tmcast, | &priv->multicast_list, list) | list_del(&mcast->list); | list_add_tail(&mcast->list, &remove_list) | spin_unlock_irqrestore(&priv->lock, flags) spin_lock_irq(&priv->lock) | | ipoib_mcast_remove_list(&remove_list) (Here, `mcast` is no longer on the | list_for_each_entry_safe(mcast, tmcast, `priv->multicast_list` and we keep | remove_list, list) spinning on the `remove_list` of | >>> wait_for_completion(&mcast->done) the other thread which is blocked | and the list is still valid on | it's stack.) Fix this by keeping the lock held and changing to GFP_ATOMIC to prevent eventual sleeps. Unfortunately we could not reproduce the lockup and confirm this fix but based on the code review I think this fix should address such lockups. crash> bc 31 PID: 747 TASK: ff1c6a1a007e8000 CPU: 31 COMMAND: kworker/u72:2 -- [exception RIP: ipoib_mcast_join_task+0x1b1] RIP: ffffffffc0944ac1 RSP: ff646f199a8c7e00 RFLAGS: 00000002 RAX: 0000000000000000 RBX: ff1c6a1a04dc82f8 RCX: 0000000000000000 work (&priv->mcast_task{,.work}) RDX: ff1c6a192d60ac68 RSI: 0000000000000286 RDI: ff1c6a1a04dc8000 &mcast->list RBP: ff646f199a8c7e90 R8: ff1c699980019420 R9: ff1c6a1920c9a000 R10: ff646f199a8c7e00 R11:
ff1c6a191a7d9800 R12: ff1c6a192d60ac00 mcast R13: ff1c6a1d82200000 R14: ff1c6a1a04dc8000 R15:
ff1c6a1a04dc82d8 dev priv (&priv->lock) &priv->multicast_list (aka head) ORIG_RAX: ffffffffffffffff CS:
0010 SS: 0018 --- <NMI exception stack> --- #5 [ff646f199a8c7e00] ipoib_mcast_join_task+0x1b1 at ffffffffc0944ac1 [ib_ipoib] #6 [ff646f199a8c7e98] process_one_work+0x1a7 at ffffffff9bf10967 crash> rx ff646f199a8c7e68 ff646f199a8c7e68: ff1c6a1a04dc82f8 <<< work = &priv->mcast_task.work crash> list -hO ipoib_dev_priv.multicast_list ff1c6a1a04dc8000 (empty) crash> ipoib_dev_priv.mcast_task.work.func,mcast_mutex.owner.counter ff1c6a1a04dc8000 mcast_task.work.func = 0xffffffffc0944910 <ipoib_mcast_join_task>, mcast_mutex.owner.counter = 0xff1c69998efec000 crash> b 8 PID:
8 TASK: ff1c69998efec000 CPU: 33 COMMAND: kworker/u72:0 -- #3 [ff646f1980153d50] wait_for_completion+0x96 at ffffffff9c7d7646 #4 [ff646f1980153d90] ipoib_mcast_remove_list+0x56 at ffffffffc0944dc6 [ib_ipoib] #5 [ff646f1980153de8] ipoib_mcast_dev_flush+0x1a7 at ffffffffc09455a7 [ib_ipoib] #6 [ff646f1980153e58] __ipoib_ib_dev_flush+0x1a4 at ffffffffc09431a4 [ib_ipoib] #7 [ff
---truncated--- (CVE-2023-52587)
- In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to tag gcing flag on page during block migration It needs to add missing gcing flag on page during block migration, in order to garantee migrated data be persisted during checkpoint, otherwise out-of-order persistency between data and node may cause data corruption after SPOR. Similar issue was fixed by commit 2d1fe8a86bf5 (f2fs: fix to tag gcing flag on page during file defragment). (CVE-2023-52588)
- In the Linux kernel, the following vulnerability has been resolved: media: rkisp1: Fix IRQ disable race issue In rkisp1_isp_stop() and rkisp1_csi_disable() the driver masks the interrupts and then apparently assumes that the interrupt handler won't be running, and proceeds in the stop procedure. This is not the case, as the interrupt handler can already be running, which would lead to the ISP being disabled while the interrupt handler handling a captured frame. This brings up two issues: 1) the ISP could be powered off while the interrupt handler is still running and accessing registers, leading to board lockup, and 2) the interrupt handler code and the code that disables the streaming might do things that conflict. It is not clear to me if 2) causes a real issue, but 1) can be seen with a suitable delay (or printk in my case) in the interrupt handler, leading to board lockup. (CVE-2023-52589)
- In the Linux kernel, the following vulnerability has been resolved: wifi: wfx: fix possible NULL pointer dereference in wfx_set_mfp_ap() Since 'ieee80211_beacon_get()' can return NULL, 'wfx_set_mfp_ap()' should check the return value before examining skb data. So convert the latter to return an appropriate error code and propagate it to return from 'wfx_start_ap()' as well. Compile tested only. (CVE-2023-52593)
- In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: Fix potential array- index-out-of-bounds read in ath9k_htc_txstatus() Fix an array-index-out-of-bounds read in ath9k_htc_txstatus(). The bug occurs when txs->cnt, data from a URB provided by a USB device, is bigger than the size of the array txs->txstatus, which is HTC_MAX_TX_STATUS. WARN_ON() already checks it, but there is no bug handling code after the check. Make the function return if that is the case. Found by a modified version of syzkaller. UBSAN: array-index-out-of-bounds in htc_drv_txrx.c index 13 is out of range for type '__wmi_event_txstatus [12]' Call Trace: ath9k_htc_txstatus ath9k_wmi_event_tasklet tasklet_action_common __do_softirq irq_exit_rxu sysvec_apic_timer_interrupt (CVE-2023-52594)
- In the Linux kernel, the following vulnerability has been resolved: wifi: rt2x00: restart beacon queue when hardware reset When a hardware reset is triggered, all registers are reset, so all queues are forced to stop in hardware interface. However, mac80211 will not automatically stop the queue. If we don't manually stop the beacon queue, the queue will be deadlocked and unable to start again. This patch fixes the issue where Apple devices cannot connect to the AP after calling ieee80211_restart_hw().
(CVE-2023-52595)
- In the Linux kernel, the following vulnerability has been resolved: KVM: s390: fix setting of fpc register kvm_arch_vcpu_ioctl_set_fpu() allows to set the floating point control (fpc) register of a guest cpu. The new value is tested for validity by temporarily loading it into the fpc register. This may lead to corruption of the fpc register of the host process: if an interrupt happens while the value is temporarily loaded into the fpc register, and within interrupt context floating point or vector registers are used, the current fp/vx registers are saved with save_fpu_regs() assuming they belong to user space and will be loaded into fp/vx registers when returning to user space. test_fp_ctl() restores the original user space / host process fpc register value, however it will be discarded, when returning to user space. In result the host process will incorrectly continue to run with the value that was supposed to be used for a guest cpu.
Fix this by simply removing the test. There is another test right before the SIE context is entered which will handles invalid values. This results in a change of behaviour: invalid values will now be accepted instead of that the ioctl fails with -EINVAL. This seems to be acceptable, given that this interface is most likely not used anymore, and this is in addition the same behaviour implemented with the memory mapped interface (replace invalid values with zero) - see sync_regs() in kvm-s390.c. (CVE-2023-52597)
- In the Linux kernel, the following vulnerability has been resolved: s390/ptrace: handle setting of fpc register correctly If the content of the floating point control (fpc) register of a traced process is modified with the ptrace interface the new value is tested for validity by temporarily loading it into the fpc register. This may lead to corruption of the fpc register of the tracing process: if an interrupt happens while the value is temporarily loaded into the fpc register, and within interrupt context floating point or vector registers are used, the current fp/vx registers are saved with save_fpu_regs() assuming they belong to user space and will be loaded into fp/vx registers when returning to user space.
test_fp_ctl() restores the original user space fpc register value, however it will be discarded, when returning to user space. In result the tracer will incorrectly continue to run with the value that was supposed to be used for the traced process. Fix this by saving fpu register contents with save_fpu_regs() before using test_fp_ctl(). (CVE-2023-52598)
- In the Linux kernel, the following vulnerability has been resolved: jfs: fix array-index-out-of-bounds in diNewExt [Syz report] UBSAN: array-index-out-of-bounds in fs/jfs/jfs_imap.c:2360:2 index -878706688 is out of range for type 'struct iagctl[128]' CPU: 1 PID: 5065 Comm: syz-executor282 Not tainted 6.7.0-rc4-syzkaller-00009-gbee0e7762ad2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:217 [inline]
__ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348 diNewExt+0x3cf3/0x4000 fs/jfs/jfs_imap.c:2360 diAllocExt fs/jfs/jfs_imap.c:1949 [inline] diAllocAG+0xbe8/0x1e50 fs/jfs/jfs_imap.c:1666 diAlloc+0x1d3/0x1760 fs/jfs/jfs_imap.c:1587 ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56 jfs_mkdir+0x1c5/0xb90 fs/jfs/namei.c:225 vfs_mkdir+0x2f1/0x4b0 fs/namei.c:4106 do_mkdirat+0x264/0x3a0 fs/namei.c:4129
__do_sys_mkdir fs/namei.c:4149 [inline] __se_sys_mkdir fs/namei.c:4147 [inline] __x64_sys_mkdir+0x6e/0x80 fs/namei.c:4147 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x45/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b RIP: 0033:0x7fcb7e6a0b57 Code: ff ff 77 07 31 c0 c3 0f 1f 40 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 b8 53 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP:
002b:00007ffd83023038 EFLAGS: 00000286 ORIG_RAX: 0000000000000053 RAX: ffffffffffffffda RBX:
00000000ffffffff RCX: 00007fcb7e6a0b57 RDX: 00000000000a1020 RSI: 00000000000001ff RDI: 0000000020000140 RBP: 0000000020000140 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11:
0000000000000286 R12: 00007ffd830230d0 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [Analysis] When the agstart is too large, it can cause agno overflow. [Fix] After obtaining agno, if the value is invalid, exit the subsequent process. Modified the test from agno > MAXAG to agno >= MAXAG based on linux-next report by kernel test robot (Dan Carpenter). (CVE-2023-52599)
- In the Linux kernel, the following vulnerability has been resolved: jfs: fix uaf in jfs_evict_inode When the execution of diMount(ipimap) fails, the object ipimap that has been released may be accessed in diFreeSpecial(). Asynchronous ipimap release occurs when rcu_core() calls jfs_free_node(). Therefore, when diMount(ipimap) fails, sbi->ipimap should not be initialized as ipimap. (CVE-2023-52600)
- In the Linux kernel, the following vulnerability has been resolved: jfs: fix array-index-out-of-bounds in dbAdjTree Currently there is a bound check missing in the dbAdjTree while accessing the dmt_stree. To add the required check added the bool is_ctl which is required to determine the size as suggest in the following commit. https://lore.kernel.org/linux-kernel- mentees/[email protected]/ (CVE-2023-52601)
- In the Linux kernel, the following vulnerability has been resolved: jfs: fix slab-out-of-bounds Read in dtSearch Currently while searching for current page in the sorted entry table of the page there is a out of bound access. Added a bound check to fix the error. Dave: Set return code to -EIO (CVE-2023-52602)
- In the Linux kernel, the following vulnerability has been resolved: UBSAN: array-index-out-of-bounds in dtSplitRoot Syzkaller reported the following issue: oop0: detected capacity change from 0 to 32768 UBSAN:
array-index-out-of-bounds in fs/jfs/jfs_dtree.c:1971:9 index -2 is out of range for type 'struct dtslot [128]' CPU: 0 PID: 3613 Comm: syz-executor270 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Call Trace: <TASK>
__dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:151 [inline] __ubsan_handle_out_of_bounds+0xdb/0x130 lib/ubsan.c:283 dtSplitRoot+0x8d8/0x1900 fs/jfs/jfs_dtree.c:1971 dtSplitUp fs/jfs/jfs_dtree.c:985 [inline] dtInsert+0x1189/0x6b80 fs/jfs/jfs_dtree.c:863 jfs_mkdir+0x757/0xb00 fs/jfs/namei.c:270 vfs_mkdir+0x3b3/0x590 fs/namei.c:4013 do_mkdirat+0x279/0x550 fs/namei.c:4038 __do_sys_mkdirat fs/namei.c:4053 [inline] __se_sys_mkdirat fs/namei.c:4051 [inline] __x64_sys_mkdirat+0x85/0x90 fs/namei.c:4051 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fcdc0113fd9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffeb8bc67d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000102 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fcdc0113fd9 RDX:
0000000000000000 RSI: 0000000020000340 RDI: 0000000000000003 RBP: 00007fcdc00d37a0 R08: 0000000000000000 R09: 00007fcdc00d37a0 R10: 00005555559a72c0 R11: 0000000000000246 R12: 00000000f8008000 R13:
0000000000000000 R14: 00083878000000f8 R15: 0000000000000000 </TASK> The issue is caused when the value of fsi becomes less than -1. The check to break the loop when fsi value becomes -1 is present but syzbot was able to produce value less than -1 which cause the error. This patch simply add the change for the values less than 0. The patch is tested via syzbot. (CVE-2023-52603)
- In the Linux kernel, the following vulnerability has been resolved: FS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTree Syzkaller reported the following issue: UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:2867:6 index 196694 is out of range for type 's8[1365]' (aka 'signed char[1365]') CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:217 [inline]
__ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348 dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867 dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834 dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331 dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline] dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402 txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534 txUpdateMap+0x342/0x9e0 txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline] jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732 kthread+0x2d3/0x370 kernel/kthread.c:388 ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 </TASK> ================================================================================ Kernel panic - not syncing: UBSAN: panic_on_warn set ... CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023 Call Trace:
<TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 panic+0x30f/0x770 kernel/panic.c:340 check_panic_on_warn+0x82/0xa0 kernel/panic.c:236 ubsan_epilogue lib/ubsan.c:223 [inline] __ubsan_handle_out_of_bounds+0x13c/0x150 lib/ubsan.c:348 dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867 dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834 dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331 dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline] dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402 txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534 txUpdateMap+0x342/0x9e0 txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline] jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732 kthread+0x2d3/0x370 kernel/kthread.c:388 ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 </TASK> Kernel Offset: disabled Rebooting in 86400 seconds.. The issue is caused when the value of lp becomes greater than CTLTREESIZE which is the max size of stree. Adding a simple check solves this issue. Dave: As the function returns a void, good error handling would require a more intrusive code reorganization, so I modified Osama's patch at use WARN_ON_ONCE for lack of a cleaner option. The patch is tested via syzbot. (CVE-2023-52604)
- In the Linux kernel, the following vulnerability has been resolved: powerpc/lib: Validate size for vector operations Some of the fp/vmx code in sstep.c assume a certain maximum size for the instructions being emulated. The size of those operations however is determined separately in analyse_instr(). Add a check to validate the assumption on the maximum size of the operations, so as to prevent any unintended kernel stack corruption. (CVE-2023-52606)
- In the Linux kernel, the following vulnerability has been resolved: powerpc/mm: Fix null-pointer dereference in pgtable_cache_add kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity.
(CVE-2023-52607)
- In the Linux kernel, the following vulnerability has been resolved: crypto: lib/mpi - Fix unexpected pointer access in mpi_ec_init When the mpi_ec_ctx structure is initialized, some fields are not cleared, causing a crash when referencing the field when the structure was released. Initially, this issue was ignored because memory for mpi_ec_ctx is allocated with the __GFP_ZERO flag. For example, this error will be triggered when calculating the Za value for SM2 separately. (CVE-2023-52616)
- In the Linux kernel, the following vulnerability has been resolved: PCI: switchtec: Fix stdev_release() crash after surprise hot remove A PCI device hot removal may occur while stdev->cdev is held open. The call to stdev_release() then happens during close or exit, at a point way past switchtec_pci_remove().
Otherwise the last ref would vanish with the trailing put_device(), just before return. At that later point in time, the devm cleanup has already removed the stdev->mmio_mrpc mapping. Also, the stdev->pdev reference was not a counted one. Therefore, in DMA mode, the iowrite32() in stdev_release() will cause a fatal page fault, and the subsequent dma_free_coherent(), if reached, would pass a stale &stdev->pdev->dev pointer. Fix by moving MRPC DMA shutdown into switchtec_pci_remove(), after stdev_kill(). Counting the stdev->pdev ref is now optional, but may prevent future accidents. Reproducible via the script at https://lore.kernel.org/r/[email protected] (CVE-2023-52617)
- In the Linux kernel, the following vulnerability has been resolved: block/rnbd-srv: Check for unlikely string overflow Since dev_search_path can technically be as large as PATH_MAX, there was a risk of truncation when copying it and a second string into full_path since it was also PATH_MAX sized. The W=1 builds were reporting this warning: drivers/block/rnbd/rnbd-srv.c: In function 'process_msg_open.isra':
drivers/block/rnbd/rnbd-srv.c:616:51: warning: '%s' directive output may be truncated writing up to 254 bytes into a region of size between 0 and 4095 [-Wformat-truncation=] 616 | snprintf(full_path, PATH_MAX, %s/%s, | ^~ In function 'rnbd_srv_get_full_path', inlined from 'process_msg_open.isra' at drivers/block/rnbd/rnbd-srv.c:721:14: drivers/block/rnbd/rnbd-srv.c:616:17: note: 'snprintf' output between 2 and 4351 bytes into a destination of size 4096 616 | snprintf(full_path, PATH_MAX, %s/%s, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 617 | dev_search_path, dev_name); | ~~~~~~~~~~~~~~~~~~~~~~~~~~ To fix this, unconditionally check for truncation (as was already done for the case where %SESSNAME% was present). (CVE-2023-52618)
- In the Linux kernel, the following vulnerability has been resolved: pstore/ram: Fix crash when setting number of cpus to an odd number When the number of cpu cores is adjusted to 7 or other odd numbers, the zone size will become an odd number. The address of the zone will become: addr of zone0 = BASE addr of zone1 = BASE + zone_size addr of zone2 = BASE + zone_size*2 ... The address of zone1/3/5/7 will be mapped to non-alignment va. Eventually crashes will occur when accessing these va. So, use ALIGN_DOWN() to make sure the zone size is even to avoid this bug. (CVE-2023-52619)
- In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: disallow timeout for anonymous sets Never used from userspace, disallow these parameters. (CVE-2023-52620)
- In the Linux kernel, the following vulnerability has been resolved: bpf: Check rcu_read_lock_trace_held() before calling bpf map helpers These three bpf_map_{lookup,update,delete}_elem() helpers are also available for sleepable bpf program, so add the corresponding lock assertion for sleepable bpf program, otherwise the following warning will be reported when a sleepable bpf program manipulates bpf map under interpreter mode (aka bpf_jit_enable=0): WARNING: CPU: 3 PID: 4985 at kernel/bpf/helpers.c:40 ...... CPU:
3 PID: 4985 Comm: test_progs Not tainted 6.6.0+ #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ...... RIP: 0010:bpf_map_lookup_elem+0x54/0x60 ...... Call Trace: <TASK> ? __warn+0xa5/0x240 ? bpf_map_lookup_elem+0x54/0x60 ? report_bug+0x1ba/0x1f0 ? handle_bug+0x40/0x80 ? exc_invalid_op+0x18/0x50 ? asm_exc_invalid_op+0x1b/0x20 ? __pfx_bpf_map_lookup_elem+0x10/0x10 ? rcu_lockdep_current_cpu_online+0x65/0xb0 ? rcu_is_watching+0x23/0x50 ? bpf_map_lookup_elem+0x54/0x60 ?
__pfx_bpf_map_lookup_elem+0x10/0x10 ___bpf_prog_run+0x513/0x3b70 __bpf_prog_run32+0x9d/0xd0 ?
__bpf_prog_enter_sleepable_recur+0xad/0x120 ? __bpf_prog_enter_sleepable_recur+0x3e/0x120 bpf_trampoline_6442580665+0x4d/0x1000 __x64_sys_getpgid+0x5/0x30 ? do_syscall_64+0x36/0xb0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 </TASK> (CVE-2023-52621)
- In the Linux kernel, the following vulnerability has been resolved: ext4: avoid online resizing failures due to oversized flex bg When we online resize an ext4 filesystem with a oversized flexbg_size, mkfs.ext4
-F -G 67108864 $dev -b 4096 100M mount $dev $dir resize2fs $dev 16G the following WARN_ON is triggered:
================================================================== WARNING: CPU: 0 PID: 427 at mm/page_alloc.c:4402 __alloc_pages+0x411/0x550 Modules linked in: sg(E) CPU: 0 PID: 427 Comm: resize2fs Tainted: G E 6.6.0-rc5+ #314 RIP: 0010:__alloc_pages+0x411/0x550 Call Trace: <TASK>
__kmalloc_large_node+0xa2/0x200 __kmalloc+0x16e/0x290 ext4_resize_fs+0x481/0xd80
__ext4_ioctl+0x1616/0x1d90 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0xf0/0x150 do_syscall_64+0x3b/0x90 ================================================================== This is because flexbg_size is too large and the size of the new_group_data array to be allocated exceeds MAX_ORDER. Currently, the minimum value of MAX_ORDER is 8, the minimum value of PAGE_SIZE is 4096, the corresponding maximum number of groups that can be allocated is: (PAGE_SIZE << MAX_ORDER) / sizeof(struct ext4_new_group_data) 21845 And the value that is down-aligned to the power of 2 is 16384. Therefore, this value is defined as MAX_RESIZE_BG, and the number of groups added each time does not exceed this value during resizing, and is added multiple times to complete the online resizing. The difference is that the metadata in a flex_bg may be more dispersed. (CVE-2023-52622)
- In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Fix a suspicious RCU usage warning I received the following warning while running cthon against an ontap server running pNFS: [ 57.202521] ============================= [ 57.202522] WARNING: suspicious RCU usage [ 57.202523] 6.7.0-rc3-g2cc14f52aeb7 #41492 Not tainted [ 57.202525] ----------------------------- [ 57.202525] net/sunrpc/xprtmultipath.c:349 RCU-list traversed in non-reader section!! [ 57.202527] other info that might help us debug this: [ 57.202528] rcu_scheduler_active = 2, debug_locks = 1 [ 57.202529] no locks held by test5/3567. [ 57.202530] stack backtrace: [ 57.202532] CPU: 0 PID: 3567 Comm: test5 Not tainted 6.7.0-rc3-g2cc14f52aeb7 #41492 5b09971b4965c0aceba19f3eea324a4a806e227e [ 57.202534] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 2/2/2022 [ 57.202536] Call Trace: [ 57.202537] <TASK> [ 57.202540] dump_stack_lvl+0x77/0xb0 [ 57.202551] lockdep_rcu_suspicious+0x154/0x1a0 [ 57.202556] rpc_xprt_switch_has_addr+0x17c/0x190 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202596] rpc_clnt_setup_test_and_add_xprt+0x50/0x180 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202621] ? rpc_clnt_add_xprt+0x254/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202646] rpc_clnt_add_xprt+0x27a/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202671] ?
__pfx_rpc_clnt_setup_test_and_add_xprt+0x10/0x10 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202696] nfs4_pnfs_ds_connect+0x345/0x760 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202728] ? __pfx_nfs4_test_session_trunk+0x10/0x10 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202754] nfs4_fl_prepare_ds+0x75/0xc0 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a] [ 57.202760] filelayout_write_pagelist+0x4a/0x200 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a] [ 57.202765] pnfs_generic_pg_writepages+0xbe/0x230 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202788] __nfs_pageio_add_request+0x3fd/0x520 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202813] nfs_pageio_add_request+0x18b/0x390 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202831] nfs_do_writepage+0x116/0x1e0 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202849] nfs_writepages_callback+0x13/0x30 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202866] write_cache_pages+0x265/0x450 [ 57.202870] ?
__pfx_nfs_writepages_callback+0x10/0x10 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202891] nfs_writepages+0x141/0x230 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202913] do_writepages+0xd2/0x230 [ 57.202917] ? filemap_fdatawrite_wbc+0x5c/0x80 [ 57.202921] filemap_fdatawrite_wbc+0x67/0x80 [ 57.202924] filemap_write_and_wait_range+0xd9/0x170 [ 57.202930] nfs_wb_all+0x49/0x180 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202947] nfs4_file_flush+0x72/0xb0 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202969]
__se_sys_close+0x46/0xd0 [ 57.202972] do_syscall_64+0x68/0x100 [ 57.202975] ? do_syscall_64+0x77/0x100 [ 57.202976] ? do_syscall_64+0x77/0x100 [ 57.202979] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 57.202982] RIP: 0033:0x7fe2b12e4a94 [ 57.202985] Code: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 80 3d d5 18 0e 00 00 74 13 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 44 c3 0f 1f 00 48 83 ec 18 89 7c 24 0c e8 c3 [ 57.202987] RSP: 002b:00007ffe857ddb38 EFLAGS: 00000202 ORIG_RAX:
0000000000000003 [ 57.202989] RAX: ffffffffffffffda RBX: 00007ffe857dfd68 RCX: 00007fe2b12e4a94 [ 57.202991] RDX: 0000000000002000 RSI: 00007ffe857ddc40 RDI: 0000000000000003 [ 57.202992] RBP:
00007ffe857dfc50 R08: 7fffffffffffffff R09: 0000000065650f49 [ 57.202993] R10: 00007f ---truncated--- (CVE-2023-52623)
- In the Linux kernel, the following vulnerability has been resolved: blk-iocost: Fix an UBSAN shift-out-of- bounds warning When iocg_kick_delay() is called from a CPU different than the one which set the delay, @now may be in the past of @iocg->delay_at leading to the following warning: UBSAN: shift-out-of-bounds in block/blk-iocost.c:1359:23 shift exponent 18446744073709 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... Call Trace: <TASK> dump_stack_lvl+0x79/0xc0 __ubsan_handle_shift_out_of_bounds+0x2ab/0x300 iocg_kick_delay+0x222/0x230 ioc_rqos_merge+0x1d7/0x2c0 __rq_qos_merge+0x2c/0x80 bio_attempt_back_merge+0x83/0x190 blk_attempt_plug_merge+0x101/0x150 blk_mq_submit_bio+0x2b1/0x720 submit_bio_noacct_nocheck+0x320/0x3e0 __swap_writepage+0x2ab/0x9d0 The underflow itself doesn't really affect the behavior in any meaningful way; however, the past timestamp may exaggerate the delay amount calculated later in the code, which shouldn't be a material problem given the nature of the delay mechanism. If @now is in the past, this CPU is racing another CPU which recently set up the delay and there's nothing this CPU can contribute w.r.t. the delay. Let's bail early from iocg_kick_delay() in such cases. (CVE-2023-52630)
- In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix an NULL dereference bug The issue here is when this is called from ntfs_load_attr_list(). The size comes from le32_to_cpu(attr->res.data_size) so it can't overflow on a 64bit systems but on 32bit systems the + 1023 can overflow and the result is zero. This means that the kmalloc will succeed by returning the ZERO_SIZE_PTR and then the memcpy() will crash with an Oops on the next line. (CVE-2023-52631)
- In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix lock dependency warning with srcu ====================================================== WARNING: possible circular locking dependency detected 6.5.0-kfd-yangp #2289 Not tainted
------------------------------------------------------ kworker/0:2/996 is trying to acquire lock:
(srcu){.+.+}-{0:0}, at: __synchronize_srcu+0x5/0x1a0 but task is already holding lock:
((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}, at: process_one_work+0x211/0x560 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 svm_range_list_lock_and_flush_work+0x3d/0x110 [amdgpu] svm_range_set_attr+0xd6/0x14c0 [amdgpu] kfd_ioctl+0x1d1/0x630 [amdgpu] __x64_sys_ioctl+0x88/0xc0 -> #2 (&info->lock#2){+.+.}-{3:3}:
__mutex_lock+0x99/0xc70 amdgpu_amdkfd_gpuvm_restore_process_bos+0x54/0x740 [amdgpu] restore_process_helper+0x22/0x80 [amdgpu] restore_process_worker+0x2d/0xa0 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0 -> #1 ((work_completion)(&(&process->restore_work)->work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0
__cancel_work_timer+0x12c/0x1c0 kfd_process_notifier_release_internal+0x37/0x1f0 [amdgpu]
__mmu_notifier_release+0xad/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 do_exit+0x322/0xb90 do_group_exit+0x37/0xa0 __x64_sys_exit_group+0x18/0x20 do_syscall_64+0x38/0x80 -> #0 (srcu){.+.+}-{0:0}:
__lock_acquire+0x1521/0x2510 lock_sync+0x5f/0x90 __synchronize_srcu+0x4f/0x1a0
__mmu_notifier_release+0x128/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 svm_range_deferred_list_work+0x19f/0x350 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0 other info that might help us debug this: Chain exists of: srcu --> &info->lock#2 --> (work_completion)(&svms->deferred_list_work) Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((work_completion)(&svms->deferred_list_work)); lock(&info->lock#2);
lock((work_completion)(&svms->deferred_list_work)); sync(srcu); (CVE-2023-52632)
- In the Linux kernel, the following vulnerability has been resolved: um: time-travel: fix time corruption In 'basic' time-travel mode (without =inf-cpu or =ext), we still get timer interrupts. These can happen at arbitrary points in time, i.e. while in timer_read(), which pushes time forward just a little bit. Then, if we happen to get the interrupt after calculating the new time to push to, but before actually finishing that, the interrupt will set the time to a value that's incompatible with the forward, and we'll crash because time goes backwards when we do the forwarding. Fix this by reading the time_travel_time, calculating the adjustment, and doing the adjustment all with interrupts disabled. (CVE-2023-52633)
- In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: Synchronize devfreq_monitor_[start/stop] There is a chance if a frequent switch of the governor done in a loop result in timer list corruption where timer cancel being done from two place one from cancel_delayed_work_sync() and followed by expire_timers() can be seen from the traces[1]. while true do echo simple_ondemand > /sys/class/devfreq/1d84000.ufshc/governor echo performance > /sys/class/devfreq/1d84000.ufshc/governor done It looks to be issue with devfreq driver where device_monitor_[start/stop] need to synchronized so that delayed work should get corrupted while it is either being queued or running or being cancelled.
Let's use polling flag and devfreq lock to synchronize the queueing the timer instance twice and work data being corrupted. [1] ... .. <idle>-0 [003] 9436.209662: timer_cancel timer=0xffffff80444f0428 <idle>-0 [003] 9436.209664: timer_expire_entry timer=0xffffff80444f0428 now=0x10022da1c function=__typeid__ZTSFvP10timer_listE_global_addr baseclk=0x10022da1c <idle>-0 [003] 9436.209718:
timer_expire_exit timer=0xffffff80444f0428 kworker/u16:6-14217 [003] 9436.209863: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2b now=0x10022da1c flags=182452227 vendor.xxxyyy.ha-1593 [004] 9436.209888: timer_cancel timer=0xffffff80444f0428 vendor.xxxyyy.ha-1593 [004] 9436.216390: timer_init timer=0xffffff80444f0428 vendor.xxxyyy.ha-1593 [004] 9436.216392: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2c now=0x10022da1d flags=186646532 vendor.xxxyyy.ha-1593 [005] 9436.220992: timer_cancel timer=0xffffff80444f0428 xxxyyyTraceManag-7795 [004] 9436.261641: timer_cancel timer=0xffffff80444f0428 [2] 9436.261653][ C4] Unable to handle kernel paging request at virtual address dead00000000012a [ 9436.261664][ C4] Mem abort info: [ 9436.261666][ C4] ESR = 0x96000044 [ 9436.261669][ C4] EC = 0x25: DABT (current EL), IL = 32 bits [ 9436.261671][ C4] SET = 0, FnV = 0 [ 9436.261673][ C4] EA = 0, S1PTW = 0 [ 9436.261675][ C4] Data abort info: [ 9436.261677][ C4] ISV = 0, ISS = 0x00000044 [ 9436.261680][ C4] CM = 0, WnR = 1 [ 9436.261682][ C4] [dead00000000012a] address between user and kernel address ranges [ 9436.261685][ C4] Internal error: Oops: 96000044 [#1] PREEMPT SMP [ 9436.261701][ C4] Skip md ftrace buffer dump for: 0x3a982d0 ... [ 9436.262138][ C4] CPU: 4 PID: 7795 Comm: TraceManag Tainted: G S W O 5.10.149-android12-9-o-g17f915d29d0c #1 [ 9436.262141][ C4] Hardware name: Qualcomm Technologies, Inc. (DT) [ 9436.262144][ C4] pstate: 22400085 (nzCv daIf +PAN -UAO +TCO BTYPE=--) [ 9436.262161][ C4] pc : expire_timers+0x9c/0x438 [ 9436.262164][ C4] lr :
expire_timers+0x2a4/0x438 [ 9436.262168][ C4] sp : ffffffc010023dd0 [ 9436.262171][ C4] x29:
ffffffc010023df0 x28: ffffffd0636fdc18 [ 9436.262178][ C4] x27: ffffffd063569dd0 x26: ffffffd063536008 [ 9436.262182][ C4] x25: 0000000000000001 x24: ffffff88f7c69280 [ 9436.262185][ C4] x23: 00000000000000e0 x22: dead000000000122 [ 9436.262188][ C4] x21: 000000010022da29 x20: ffffff8af72b4e80 [ 9436.262191][ C4] x19: ffffffc010023e50 x18: ffffffc010025038 [ 9436.262195][ C4] x17: 0000000000000240 x16:
0000000000000201 [ 9436.262199][ C4] x15: ffffffffffffffff x14: ffffff889f3c3100 [ 9436.262203][ C4] x13:
ffffff889f3c3100 x12: 00000000049f56b8 [ 9436.262207][ C4] x11: 00000000049f56b8 x10: 00000000ffffffff [ 9436.262212][ C4] x9 : ffffffc010023e50 x8 : dead000000000122 [ 9436.262216][ C4] x7 : ffffffffffffffff x6 : ffffffc0100239d8 [ 9436.262220][ C4] x5 : 0000000000000000 x4 : 0000000000000101 [ 9436.262223][ C4] x3 : 0000000000000080 x2 : ffffff8 ---truncated--- (CVE-2023-52635)
- In the Linux kernel, the following vulnerability has been resolved: can: j1939: Fix UAF in j1939_sk_match_filter during setsockopt(SO_J1939_FILTER) Lock jsk->sk to prevent UAF when setsockopt(..., SO_J1939_FILTER, ...) modifies jsk->filters while receiving packets. Following trace was seen on affected system: ================================================================== BUG: KASAN: slab-use-after-free in j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] Read of size 4 at addr ffff888012144014 by task j1939/350 CPU: 0 PID: 350 Comm: j1939 Tainted: G W OE 6.5.0-rc5 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: print_report+0xd3/0x620 ? kasan_complete_mode_report_info+0x7d/0x200 ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] kasan_report+0xc2/0x100 ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] __asan_load4+0x84/0xb0 j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] j1939_sk_recv+0x20b/0x320 [can_j1939] ?
__kasan_check_write+0x18/0x20 ? __pfx_j1939_sk_recv+0x10/0x10 [can_j1939] ? j1939_simple_recv+0x69/0x280 [can_j1939] ? j1939_ac_recv+0x5e/0x310 [can_j1939] j1939_can_recv+0x43f/0x580 [can_j1939] ?
__pfx_j1939_can_recv+0x10/0x10 [can_j1939] ? raw_rcv+0x42/0x3c0 [can_raw] ? __pfx_j1939_can_recv+0x10/0x10 [can_j1939] can_rcv_filter+0x11f/0x350 [can] can_receive+0x12f/0x190 [can] ? __pfx_can_rcv+0x10/0x10 [can] can_rcv+0xdd/0x130 [can] ? __pfx_can_rcv+0x10/0x10 [can] __netif_receive_skb_one_core+0x13d/0x150 ?
__pfx___netif_receive_skb_one_core+0x10/0x10 ? __kasan_check_write+0x18/0x20 ?
_raw_spin_lock_irq+0x8c/0xe0 __netif_receive_skb+0x23/0xb0 process_backlog+0x107/0x260
__napi_poll+0x69/0x310 net_rx_action+0x2a1/0x580 ? __pfx_net_rx_action+0x10/0x10 ?
__pfx__raw_spin_lock+0x10/0x10 ? handle_irq_event+0x7d/0xa0 __do_softirq+0xf3/0x3f8 do_softirq+0x53/0x80 </IRQ> <TASK> __local_bh_enable_ip+0x6e/0x70 netif_rx+0x16b/0x180 can_send+0x32b/0x520 [can] ?
__pfx_can_send+0x10/0x10 [can] ? __check_object_size+0x299/0x410 raw_sendmsg+0x572/0x6d0 [can_raw] ?
__pfx_raw_sendmsg+0x10/0x10 [can_raw] ? apparmor_socket_sendmsg+0x2f/0x40 ? __pfx_raw_sendmsg+0x10/0x10 [can_raw] sock_sendmsg+0xef/0x100 sock_write_iter+0x162/0x220 ? __pfx_sock_write_iter+0x10/0x10 ?
__rtnl_unlock+0x47/0x80 ? security_file_permission+0x54/0x320 vfs_write+0x6ba/0x750 ?
__pfx_vfs_write+0x10/0x10 ? __fget_light+0x1ca/0x1f0 ? __rcu_read_unlock+0x5b/0x280 ksys_write+0x143/0x170 ? __pfx_ksys_write+0x10/0x10 ? __kasan_check_read+0x15/0x20 ? fpregs_assert_state_consistent+0x62/0x70
__x64_sys_write+0x47/0x60 do_syscall_64+0x60/0x90 ? do_syscall_64+0x6d/0x90 ? irqentry_exit+0x3f/0x50 ? exc_page_fault+0x79/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Allocated by task 348:
kasan_save_stack+0x2a/0x50 kasan_set_track+0x29/0x40 kasan_save_alloc_info+0x1f/0x30
__kasan_kmalloc+0xb5/0xc0 __kmalloc_node_track_caller+0x67/0x160 j1939_sk_setsockopt+0x284/0x450 [can_j1939] __sys_setsockopt+0x15c/0x2f0 __x64_sys_setsockopt+0x6b/0x80 do_syscall_64+0x60/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Freed by task 349: kasan_save_stack+0x2a/0x50 kasan_set_track+0x29/0x40 kasan_save_free_info+0x2f/0x50 __kasan_slab_free+0x12e/0x1c0
__kmem_cache_free+0x1b9/0x380 kfree+0x7a/0x120 j1939_sk_setsockopt+0x3b2/0x450 [can_j1939]
__sys_setsockopt+0x15c/0x2f0 __x64_sys_setsockopt+0x6b/0x80 do_syscall_64+0x60/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 (CVE-2023-52637)
- In the Linux kernel, the following vulnerability has been resolved: can: j1939: prevent deadlock by changing j1939_socks_lock to rwlock The following 3 locks would race against each other, causing the deadlock situation in the Syzbot bug report: - j1939_socks_lock - active_session_list_lock - sk_session_queue_lock A reasonable fix is to change j1939_socks_lock to an rwlock, since in the rare situations where a write lock is required for the linked list that j1939_socks_lock is protecting, the code does not attempt to acquire any more locks. This would break the circular lock dependency, where, for example, the current thread already locks j1939_socks_lock and attempts to acquire sk_session_queue_lock, and at the same time, another thread attempts to acquire j1939_socks_lock while holding sk_session_queue_lock. NOTE: This patch along does not fix the unregister_netdevice bug reported by Syzbot; instead, it solves a deadlock situation to prepare for one or more further patches to actually fix the Syzbot bug, which appears to be a reference counting problem within the j1939 codebase. [mkl: remove unrelated newline change] (CVE-2023-52638)
- In the Linux kernel, the following vulnerability has been resolved: KVM: s390: vsie: fix race during shadow creation Right now it is possible to see gmap->private being zero in kvm_s390_vsie_gmap_notifier resulting in a crash. This is due to the fact that we add gmap->private == kvm after creation: static int acquire_gmap_shadow(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page) { [...] gmap = gmap_shadow(vcpu->arch.gmap, asce, edat); if (IS_ERR(gmap)) return PTR_ERR(gmap); gmap->private = vcpu->kvm; Let children inherit the private field of the parent. (CVE-2023-52639)
- In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix oob in ntfs_listxattr The length of name cannot exceed the space occupied by ea. (CVE-2023-52640)
- In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add NULL ptr dereference checking at the end of attr_allocate_frame() It is preferable to exit through the out: label because internal debugging functions are located there. (CVE-2023-52641)
- A flaw was found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on `struct net_device`, and a use-after-free can be triggered by racing between the free on the struct and the access through the `skbtxq` global queue. This could lead to a denial of service condition or potential code execution. (CVE-2023-6270)
- A null pointer dereference vulnerability was found in ath10k_wmi_tlv_op_pull_mgmt_tx_compl_ev() in drivers/net/wireless/ath/ath10k/wmi-tlv.c in the Linux kernel. This issue could be exploited to trigger a denial of service. (CVE-2023-7042)
- A vulnerability was found in vhost_new_msg in drivers/vhost/vhost.c in the Linux kernel, which does not properly initialize memory in messages passed between virtual guests and the host operating system in the vhost/vhost.c:vhost_new_msg() function. This issue can allow local privileged users to read some kernel memory contents when reading from the /dev/vhost-net device file. (CVE-2024-0340)
- A null pointer dereference flaw was found in the hugetlbfs_fill_super function in the Linux kernel hugetlbfs (HugeTLB pages) functionality. This issue may allow a local user to crash the system or potentially escalate their privileges on the system. (CVE-2024-0841)
- A vulnerability was reported in the Open vSwitch sub-component in the Linux Kernel. The flaw occurs when a recursive operation of code push recursively calls into the code block. The OVS module does not validate the stack depth, pushing too many frames and causing a stack overflow. As a result, this can lead to a crash or other related issues. (CVE-2024-1151)
- NULL Pointer Dereference vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (net, bluetooth modules) allows Overflow Buffers. This vulnerability is associated with program files /net/bluetooth/rfcomm/core.C. This issue affects Linux kernel: v2.6.12-rc2. (CVE-2024-22099)
- In btrfs_get_root_ref in fs/btrfs/disk-io.c in the Linux kernel through 6.7.1, there can be an assertion failure and crash because a subvolume can be read out too soon after its root item is inserted upon subvolume creation. (CVE-2024-23850)
- copy_params in drivers/md/dm-ioctl.c in the Linux kernel through 6.7.1 can attempt to allocate more than INT_MAX bytes, and crash, because of a missing param_kernel->data_size check. This is related to ctl_ioctl. (CVE-2024-23851)
- A race condition was found in the Linux kernel's net/bluetooth device driver in conn_info_{min,max}_age_set() function. This can result in integrity overflow issue, possibly leading to bluetooth connection abnormality or denial of service. (CVE-2024-24857)
- A race condition was found in the Linux kernel's net/bluetooth in {conn,adv}_{min,max}_interval_set() function. This can result in I2cap connection or broadcast abnormality issue, possibly leading to denial of service. (CVE-2024-24858)
- In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_rbtree: skip end interval element from gc rbtree lazy gc on insert might collect an end interval element that has been just added in this transactions, skip end interval elements that are not yet active. (CVE-2024-26581)
- In the Linux kernel, the following vulnerability has been resolved: net: tls: fix use-after-free with partial reads and async decrypt tls_decrypt_sg doesn't take a reference on the pages from clear_skb, so the put_page() in tls_decrypt_done releases them, and we trigger a use-after-free in process_rx_list when we try to read from the partially-read skb. (CVE-2024-26582)
- In the Linux kernel, the following vulnerability has been resolved: tls: fix race between async notify and socket close The submitting thread (one which called recvmsg/sendmsg) may exit as soon as the async crypto handler calls complete() so any code past that point risks touching already freed data. Try to avoid the locking and extra flags altogether. Have the main thread hold an extra reference, this way we can depend solely on the atomic ref counter for synchronization. Don't futz with reiniting the completion, either, we are now tightly controlling when completion fires. (CVE-2024-26583)
- In the Linux kernel, the following vulnerability has been resolved: net: tls: handle backlogging of crypto requests Since we're setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on our requests to the crypto API, crypto_aead_{encrypt,decrypt} can return -EBUSY instead of -EINPROGRESS in valid situations. For example, when the cryptd queue for AESNI is full (easy to trigger with an artificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueued to the backlog but still processed. In that case, the async callback will also be called twice: first with err == -EINPROGRESS, which it seems we can just ignore, then with err == 0. Compared to Sabrina's original patch this version uses the new tls_*crypt_async_wait() helpers and converts the EBUSY to EINPROGRESS to avoid having to modify all the error handling paths. The handling is identical. (CVE-2024-26584)
- In the Linux kernel, the following vulnerability has been resolved: tls: fix race between tx work scheduling and socket close Similarly to previous commit, the submitting thread (recvmsg/sendmsg) may exit as soon as the async crypto handler calls complete(). Reorder scheduling the work before calling complete(). This seems more logical in the first place, as it's the inverse order of what the submitting thread will do. (CVE-2024-26585)
- In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix stack corruption When tc filters are first added to a net device, the corresponding local port gets bound to an ACL group in the device. The group contains a list of ACLs. In turn, each ACL points to a different TCAM region where the filters are stored. During forwarding, the ACLs are sequentially evaluated until a match is found. One reason to place filters in different regions is when they are added with decreasing priorities and in an alternating order so that two consecutive filters can never fit in the same region because of their key usage. In Spectrum-2 and newer ASICs the firmware started to report that the maximum number of ACLs in a group is more than 16, but the layout of the register that configures ACL groups (PAGT) was not updated to account for that. It is therefore possible to hit stack corruption [1] in the rare case where more than 16 ACLs in a group are required. Fix by limiting the maximum ACL group size to the minimum between what the firmware reports and the maximum ACLs that fit in the PAGT register. Add a test case to make sure the machine does not crash when this condition is hit. [1] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+0x116/0x120 [...] dump_stack_lvl+0x36/0x50 panic+0x305/0x330 __stack_chk_fail+0x15/0x20 mlxsw_sp_acl_tcam_group_update+0x116/0x120 mlxsw_sp_acl_tcam_group_region_attach+0x69/0x110 mlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0 mlxsw_sp_acl_rule_add+0x47/0x240 mlxsw_sp_flower_replace+0x1a9/0x1d0 tc_setup_cb_add+0xdc/0x1c0 fl_hw_replace_filter+0x146/0x1f0 fl_change+0xc17/0x1360 tc_new_tfilter+0x472/0xb90 rtnetlink_rcv_msg+0x313/0x3b0 netlink_rcv_skb+0x58/0x100 netlink_unicast+0x244/0x390 netlink_sendmsg+0x1e4/0x440 ____sys_sendmsg+0x164/0x260 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xc0 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b (CVE-2024-26586)
- In the Linux kernel, the following vulnerability has been resolved: erofs: fix inconsistent per-file compression format EROFS can select compression algorithms on a per-file basis, and each per-file compression algorithm needs to be marked in the on-disk superblock for initialization. However, syzkaller can generate inconsistent crafted images that use an unsupported algorithmtype for specific inodes, e.g.
use MicroLZMA algorithmtype even it's not set in `sbi->available_compr_algs`. This can lead to an unexpected BUG: kernel NULL pointer dereference if the corresponding decompressor isn't built-in. Fix this by checking against `sbi->available_compr_algs` for each m_algorithmformat request. Incorrect !erofs_sb_has_compr_cfgs preset bitmap is now fixed together since it was harmless previously.
(CVE-2024-26590)
- In the Linux kernel, the following vulnerability has been resolved: i2c: i801: Fix block process call transactions According to the Intel datasheets, software must reset the block buffer index twice for block process call transactions: once before writing the outgoing data to the buffer, and once again before reading the incoming data from the buffer. The driver is currently missing the second reset, causing the wrong portion of the block buffer to be read. (CVE-2024-26593)
- In the Linux kernel, the following vulnerability has been resolved: phy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRP If the external phy working together with phy-omap-usb2 does not implement send_srp(), we may still attempt to call it. This can happen on an idle Ethernet gadget triggering a wakeup for example: configfs-gadget.g1 gadget.0: ECM Suspend configfs-gadget.g1 gadget.0: Port suspended.
Triggering wakeup ... Unable to handle kernel NULL pointer dereference at virtual address 00000000 when execute ... PC is at 0x0 LR is at musb_gadget_wakeup+0x1d4/0x254 [musb_hdrc] ... musb_gadget_wakeup [musb_hdrc] from usb_gadget_wakeup+0x1c/0x3c [udc_core] usb_gadget_wakeup [udc_core] from eth_start_xmit+0x3b0/0x3d4 [u_ether] eth_start_xmit [u_ether] from dev_hard_start_xmit+0x94/0x24c dev_hard_start_xmit from sch_direct_xmit+0x104/0x2e4 sch_direct_xmit from __dev_queue_xmit+0x334/0xd88
__dev_queue_xmit from arp_solicit+0xf0/0x268 arp_solicit from neigh_probe+0x54/0x7c neigh_probe from
__neigh_event_send+0x22c/0x47c __neigh_event_send from neigh_resolve_output+0x14c/0x1c0 neigh_resolve_output from ip_finish_output2+0x1c8/0x628 ip_finish_output2 from ip_send_skb+0x40/0xd8 ip_send_skb from udp_send_skb+0x124/0x340 udp_send_skb from udp_sendmsg+0x780/0x984 udp_sendmsg from
__sys_sendto+0xd8/0x158 __sys_sendto from ret_fast_syscall+0x0/0x58 Let's fix the issue by checking for send_srp() and set_vbus() before calling them. For USB peripheral only cases these both could be NULL.
(CVE-2024-26600)
- In the Linux kernel, the following vulnerability has been resolved: ext4: regenerate buddy after block freeing failed if under fc replay This mostly reverts commit 6bd97bf273bd (ext4: remove redundant mb_regenerate_buddy()) and reintroduces mb_regenerate_buddy(). Based on code in mb_free_blocks(), fast commit replay can end up marking as free blocks that are already marked as such. This causes corruption of the buddy bitmap so we need to regenerate it in that case. (CVE-2024-26601)
- In the Linux kernel, the following vulnerability has been resolved: sched/membarrier: reduce the ability to hammer on sys_membarrier On some systems, sys_membarrier can be very expensive, causing overall slowdowns for everything. So put a lock on the path in order to serialize the accesses to prevent the ability for this to be called at too high of a frequency and saturate the machine. (CVE-2024-26602)
- In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Stop relying on userspace for info to fault in xsave buffer Before this change, the expected size of the user space buffer was taken from fx_sw->xstate_size. fx_sw->xstate_size can be changed from user-space, so it is possible construct a sigreturn frame where: * fx_sw->xstate_size is smaller than the size required by valid bits in fx_sw->xfeatures. * user-space unmaps parts of the sigrame fpu buffer so that not all of the buffer required by xrstor is accessible. In this case, xrstor tries to restore and accesses the unmapped area which results in a fault. But fault_in_readable succeeds because buf + fx_sw->xstate_size is within the still mapped area, so it goes back and tries xrstor again. It will spin in this loop forever. Instead, fault in the maximum size which can be touched by XRSTOR (taken from fpstate->user_size). [ dhansen: tweak subject / changelog ] (CVE-2024-26603)
- In the Linux kernel, the following vulnerability has been resolved: binder: signal epoll threads of self- work In (e)poll mode, threads often depend on I/O events to determine when data is ready for consumption.
Within binder, a thread may initiate a command via BINDER_WRITE_READ without a read buffer and then make use of epoll_wait() or similar to consume any responses afterwards. It is then crucial that epoll threads are signaled via wakeup when they queue their own work. Otherwise, they risk waiting indefinitely for an event leaving their work unhandled. What is worse, subsequent commands won't trigger a wakeup either as the thread has pending work. (CVE-2024-26606)
- In the Linux kernel, the following vulnerability has been resolved: mm: huge_memory: don't force huge page alignment on 32 bit commit efa7df3e3bb5 (mm: align larger anonymous mappings on THP boundaries) caused two issues [1] [2] reported on 32 bit system or compat userspace. It doesn't make too much sense to force huge page alignment on 32 bit system due to the constrained virtual address space. [1] https://lore.kernel.org/linux-mm/[email protected]/ [2] https://lore.kernel.org/linux-mm/CAJuCfpHXLdQy1a2B6xN2d7quTYwg2OoZseYPZTRpU0eHHKD-sQ@mail.gmail.com/ (CVE-2024-26621)
- In the Linux kernel, the following vulnerability has been resolved: tomoyo: fix UAF write bug in tomoyo_write_control() Since tomoyo_write_control() updates head->write_buf when write() of long lines is requested, we need to fetch head->write_buf after head->io_sem is held. Otherwise, concurrent write() requests can cause use-after-free-write and double-free problems. (CVE-2024-26622)
- In the Linux kernel, the following vulnerability has been resolved: llc: call sock_orphan() at release time syzbot reported an interesting trace [1] caused by a stale sk->sk_wq pointer in a closed llc socket.
In commit ff7b11aa481f (net: socket: set sock->sk to NULL after calling proto_ops::release()) Eric Biggers hinted that some protocols are missing a sock_orphan(), we need to perform a full audit. In net- next, I plan to clear sock->sk from sock_orphan() and amend Eric patch to add a warning. [1] BUG: KASAN:
slab-use-after-free in list_empty include/linux/list.h:373 [inline] BUG: KASAN: slab-use-after-free in waitqueue_active include/linux/wait.h:127 [inline] BUG: KASAN: slab-use-after-free in sock_def_write_space_wfree net/core/sock.c:3384 [inline] BUG: KASAN: slab-use-after-free in sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468 Read of size 8 at addr ffff88802f4fc880 by task ksoftirqd/1/27 CPU: 1 PID: 27 Comm: ksoftirqd/1 Not tainted 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0 Hardware name:
QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 Call Trace: <TASK>
__dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc4/0x620 mm/kasan/report.c:488 kasan_report+0xda/0x110 mm/kasan/report.c:601 list_empty include/linux/list.h:373 [inline] waitqueue_active include/linux/wait.h:127 [inline] sock_def_write_space_wfree net/core/sock.c:3384 [inline] sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468 skb_release_head_state+0xa3/0x2b0 net/core/skbuff.c:1080 skb_release_all net/core/skbuff.c:1092 [inline] napi_consume_skb+0x119/0x2b0 net/core/skbuff.c:1404 e1000_unmap_and_free_tx_resource+0x144/0x200 drivers/net/ethernet/intel/e1000/e1000_main.c:1970 e1000_clean_tx_irq drivers/net/ethernet/intel/e1000/e1000_main.c:3860 [inline] e1000_clean+0x4a1/0x26e0 drivers/net/ethernet/intel/e1000/e1000_main.c:3801 __napi_poll.constprop.0+0xb4/0x540 net/core/dev.c:6576 napi_poll net/core/dev.c:6645 [inline] net_rx_action+0x956/0xe90 net/core/dev.c:6778
__do_softirq+0x21a/0x8de kernel/softirq.c:553 run_ksoftirqd kernel/softirq.c:921 [inline] run_ksoftirqd+0x31/0x60 kernel/softirq.c:913 smpboot_thread_fn+0x660/0xa10 kernel/smpboot.c:164 kthread+0x2c6/0x3a0 kernel/kthread.c:388 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242 </TASK> Allocated by task 5167:
kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:314 [inline] __kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:340 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3813 [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_lru+0x142/0x6f0 mm/slub.c:3879 alloc_inode_sb include/linux/fs.h:3019 [inline] sock_alloc_inode+0x25/0x1c0 net/socket.c:308 alloc_inode+0x5d/0x220 fs/inode.c:260 new_inode_pseudo+0x16/0x80 fs/inode.c:1005 sock_alloc+0x40/0x270 net/socket.c:634
__sock_create+0xbc/0x800 net/socket.c:1535 sock_create net/socket.c:1622 [inline] __sys_socket_create net/socket.c:1659 [inline] __sys_socket+0x14c/0x260 net/socket.c:1706 __do_sys_socket net/socket.c:1720 [inline] __se_sys_socket net/socket.c:1718 [inline] __x64_sys_socket+0x72/0xb0 net/socket.c:1718 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Freed by task 0: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640 poison_slab_object mm/kasan/common.c:241 [inline] __kasan_slab_free+0x121/0x1b0 mm/kasan/common.c:257 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2121 [inlin ---truncated--- (CVE-2024-26625)
- In the Linux kernel, the following vulnerability has been resolved: ipmr: fix kernel panic when forwarding mcast packets The stacktrace was: [ 86.305548] BUG: kernel NULL pointer dereference, address:
0000000000000092 [ 86.306815] #PF: supervisor read access in kernel mode [ 86.307717] #PF:
error_code(0x0000) - not-present page [ 86.308624] PGD 0 P4D 0 [ 86.309091] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 86.309883] CPU: 2 PID: 3139 Comm: pimd Tainted: G U 6.8.0-6wind-knet #1 [ 86.311027] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.1-0-g0551a4be2c-prebuilt.qemu-project.org 04/01/2014 [ 86.312728] RIP: 0010:ip_mr_forward (/build/work/knet/net/ipv4/ipmr.c:1985) [ 86.313399] Code:
f9 1f 0f 87 85 03 00 00 48 8d 04 5b 48 8d 04 83 49 8d 44 c5 00 48 8b 40 70 48 39 c2 0f 84 d9 00 00 00 49 8b 46 58 48 83 e0 fe <80> b8 92 00 00 00 00 0f 84 55 ff ff ff 49 83 47 38 01 45 85 e4 0f [ 86.316565] RSP:
0018:ffffad21c0583ae0 EFLAGS: 00010246 [ 86.317497] RAX: 0000000000000000 RBX: 0000000000000000 RCX:
0000000000000000 [ 86.318596] RDX: ffff9559cb46c000 RSI: 0000000000000000 RDI: 0000000000000000 [ 86.319627] RBP: ffffad21c0583b30 R08: 0000000000000000 R09: 0000000000000000 [ 86.320650] R10:
0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [ 86.321672] R13: ffff9559c093a000 R14:
ffff9559cc00b800 R15: ffff9559c09c1d80 [ 86.322873] FS: 00007f85db661980(0000) GS:ffff955a79d00000(0000) knlGS:0000000000000000 [ 86.324291] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 86.325314] CR2:
0000000000000092 CR3: 000000002f13a000 CR4: 0000000000350ef0 [ 86.326589] Call Trace: [ 86.327036] <TASK> [ 86.327434] ? show_regs (/build/work/knet/arch/x86/kernel/dumpstack.c:479) [ 86.328049] ? __die (/build/work/knet/arch/x86/kernel/dumpstack.c:421 /build/work/knet/arch/x86/kernel/dumpstack.c:434) [ 86.328508] ? page_fault_oops (/build/work/knet/arch/x86/mm/fault.c:707) [ 86.329107] ? do_user_addr_fault (/build/work/knet/arch/x86/mm/fault.c:1264) [ 86.329756] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223) [ 86.330350] ? __irq_work_queue_local (/build/work/knet/kernel/irq_work.c:111 (discriminator 1)) [ 86.331013] ? exc_page_fault (/build/work/knet/./arch/x86/include/asm/paravirt.h:693 /build/work/knet/arch/x86/mm/fault.c:1515 /build/work/knet/arch/x86/mm/fault.c:1563) [ 86.331702] ? asm_exc_page_fault (/build/work/knet/./arch/x86/include/asm/idtentry.h:570) [ 86.332468] ? ip_mr_forward (/build/work/knet/net/ipv4/ipmr.c:1985) [ 86.333183] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223) [ 86.333920] ipmr_mfc_add (/build/work/knet/./include/linux/rcupdate.h:782 /build/work/knet/net/ipv4/ipmr.c:1009 /build/work/knet/net/ipv4/ipmr.c:1273) [ 86.334583] ? __pfx_ipmr_hash_cmp (/build/work/knet/net/ipv4/ipmr.c:363) [ 86.335357] ip_mroute_setsockopt (/build/work/knet/net/ipv4/ipmr.c:1470) [ 86.336135] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223) [ 86.336854] ? ip_mroute_setsockopt (/build/work/knet/net/ipv4/ipmr.c:1470) [ 86.337679] do_ip_setsockopt (/build/work/knet/net/ipv4/ip_sockglue.c:944) [ 86.338408] ? __pfx_unix_stream_read_actor (/build/work/knet/net/unix/af_unix.c:2862) [ 86.339232] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223) [ 86.339809] ? aa_sk_perm (/build/work/knet/security/apparmor/include/cred.h:153 /build/work/knet/security/apparmor/net.c:181) [ 86.340342] ip_setsockopt (/build/work/knet/net/ipv4/ip_sockglue.c:1415) [ 86.340859] raw_setsockopt (/build/work/knet/net/ipv4/raw.c:836) [ 86.341408] ? security_socket_setsockopt (/build/work/knet/security/security.c:4561 (discriminator 13)) [ 86.342116] sock_common_setsockopt (/build/work/knet/net/core/sock.c:3716) [ 86.342747] do_sock_setsockopt (/build/work/knet/net/socket.c:2313) [ 86.343363] __sys_setsockopt (/build/work/knet/./include/linux/file.h:32 /build/work/kn ---truncated--- (CVE-2024-26626)
- In the Linux kernel, the following vulnerability has been resolved: scsi: core: Move scsi_host_busy() out of host lock for waking up EH handler Inside scsi_eh_wakeup(), scsi_host_busy() is called & checked with host lock every time for deciding if error handler kthread needs to be waken up. This can be too heavy in case of recovery, such as: - N hardware queues - queue depth is M for each hardware queue - each scsi_host_busy() iterates over (N * M) tag/requests If recovery is triggered in case that all requests are in-flight, each scsi_eh_wakeup() is strictly serialized, when scsi_eh_wakeup() is called for the last in- flight request, scsi_host_busy() has been run for (N * M - 1) times, and request has been iterated for (N*M - 1) * (N * M) times. If both N and M are big enough, hard lockup can be triggered on acquiring host lock, and it is observed on mpi3mr(128 hw queues, queue depth 8169). Fix the issue by calling scsi_host_busy() outside the host lock. We don't need the host lock for getting busy count because host the lock never covers that. [mkp: Drop unnecessary 'busy' variables pointed out by Bart] (CVE-2024-26627)
- In the Linux kernel, the following vulnerability has been resolved: nfsd: fix RELEASE_LOCKOWNER The test on so_count in nfsd4_release_lockowner() is nonsense and harmful. Revert to using check_for_locks(), changing that to not sleep. First: harmful. As is documented in the kdoc comment for nfsd4_release_lockowner(), the test on so_count can transiently return a false positive resulting in a return of NFS4ERR_LOCKS_HELD when in fact no locks are held. This is clearly a protocol violation and with the Linux NFS client it can cause incorrect behaviour. If RELEASE_LOCKOWNER is sent while some other thread is still processing a LOCK request which failed because, at the time that request was received, the given owner held a conflicting lock, then the nfsd thread processing that LOCK request can hold a reference (conflock) to the lock owner that causes nfsd4_release_lockowner() to return an incorrect error.
The Linux NFS client ignores that NFS4ERR_LOCKS_HELD error because it never sends NFS4_RELEASE_LOCKOWNER without first releasing any locks, so it knows that the error is impossible. It assumes the lock owner was in fact released so it feels free to use the same lock owner identifier in some later locking request.
When it does reuse a lock owner identifier for which a previous RELEASE failed, it will naturally use a lock_seqid of zero. However the server, which didn't release the lock owner, will expect a larger lock_seqid and so will respond with NFS4ERR_BAD_SEQID. So clearly it is harmful to allow a false positive, which testing so_count allows. The test is nonsense because ... well... it doesn't mean anything. so_count is the sum of three different counts. 1/ the set of states listed on so_stateids 2/ the set of active vfs locks owned by any of those states 3/ various transient counts such as for conflicting locks. When it is tested against '2' it is clear that one of these is the transient reference obtained by find_lockowner_str_locked(). It is not clear what the other one is expected to be. In practice, the count is often 2 because there is precisely one state on so_stateids. If there were more, this would fail. In my testing I see two circumstances when RELEASE_LOCKOWNER is called. In one case, CLOSE is called before RELEASE_LOCKOWNER. That results in all the lock states being removed, and so the lockowner being discarded (it is removed when there are no more references which usually happens when the lock state is discarded).
When nfsd4_release_lockowner() finds that the lock owner doesn't exist, it returns success. The other case shows an so_count of '2' and precisely one state listed in so_stateid. It appears that the Linux client uses a separate lock owner for each file resulting in one lock state per lock owner, so this test on '2' is safe. For another client it might not be safe. So this patch changes check_for_locks() to use the (newish) find_any_file_locked() so that it doesn't take a reference on the nfs4_file and so never calls nfsd_file_put(), and so never sleeps. With this check is it safe to restore the use of check_for_locks() rather than testing so_count against the mysterious '2'. (CVE-2024-26629)
- In the Linux kernel, the following vulnerability has been resolved: mm, kmsan: fix infinite recursion due to RCU critical section Alexander Potapenko writes in [1]: For every memory access in the code instrumented by KMSAN we call kmsan_get_metadata() to obtain the metadata for the memory being accessed.
For virtual memory the metadata pointers are stored in the corresponding `struct page`, therefore we need to call virt_to_page() to get them. According to the comment in arch/x86/include/asm/page.h, virt_to_page(kaddr) returns a valid pointer iff virt_addr_valid(kaddr) is true, so KMSAN needs to call virt_addr_valid() as well. To avoid recursion, kmsan_get_metadata() must not call instrumented code, therefore ./arch/x86/include/asm/kmsan.h forks parts of arch/x86/mm/physaddr.c to check whether a virtual address is valid or not. But the introduction of rcu_read_lock() to pfn_valid() added instrumented RCU API calls to virt_to_page_or_null(), which is called by kmsan_get_metadata(), so there is an infinite recursion now. I do not think it is correct to stop that recursion by doing kmsan_enter_runtime()/kmsan_exit_runtime() in kmsan_get_metadata(): that would prevent instrumented functions called from within the runtime from tracking the shadow values, which might introduce false positives. Fix the issue by switching pfn_valid() to the _sched() variant of rcu_read_lock/unlock(), which does not require calling into RCU. Given the critical section in pfn_valid() is very small, this is a reasonable trade-off (with preemptible RCU). KMSAN further needs to be careful to suppress calls into the scheduler, which would be another source of recursion. This can be done by wrapping the call to pfn_valid() into preempt_disable/enable_no_resched(). The downside is that this sacrifices breaking scheduling guarantees; however, a kernel compiled with KMSAN has already given up any performance guarantees due to being heavily instrumented. Note, KMSAN code already disables tracing via Makefile, and since mmzone.h is included, it is not necessary to use the notrace variant, which is generally preferred in all other cases. (CVE-2024-26639)
- In the Linux kernel, the following vulnerability has been resolved: tcp: add sanity checks to rx zerocopy TCP rx zerocopy intent is to map pages initially allocated from NIC drivers, not pages owned by a fs. This patch adds to can_map_frag() these additional checks: - Page must not be a compound one. - page->mapping must be NULL. This fixes the panic reported by ZhangPeng. syzbot was able to loopback packets built with sendfile(), mapping pages owned by an ext4 file to TCP rx zerocopy. r3 = socket$inet_tcp(0x2, 0x1, 0x0) mmap(&(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0) r4 = socket$inet_tcp(0x2, 0x1, 0x0) bind$inet(r4, &(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10) connect$inet(r4, &(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10) r5 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00', 0x181e42, 0x0) fallocate(r5, 0x0, 0x0, 0x85b8) sendfile(r4, r5, 0x0, 0x8ba0) getsockopt$inet_tcp_TCP_ZEROCOPY_RECEIVE(r4, 0x6, 0x23, &(0x7f00000001c0)={&(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, &(0x7f0000000440)=0x40) r6 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00', 0x181e42, 0x0) (CVE-2024-26640)
- In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv() syzbot found __ip6_tnl_rcv() could access unitiliazed data [1]. Call pskb_inet_may_pull() to fix this, and initialize ipv6h variable after this call as it can change skb->head. [1] BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG:
KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321 ip6ip6_dscp_ecn_decapsulate+0x178/0x1b0 net/ipv6/ip6_tunnel.c:727 __ip6_tnl_rcv+0xd4e/0x1590 net/ipv6/ip6_tunnel.c:845 ip6_tnl_rcv+0xce/0x100 net/ipv6/ip6_tunnel.c:888 gre_rcv+0x143f/0x1870 ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438 ip6_input_finish net/ipv6/ip6_input.c:483 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492 ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586 dst_input include/net/dst.h:461 [inline] ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:314 [inline] ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5532 [inline]
__netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5646 netif_receive_skb_internal net/core/dev.c:5732 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5791 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2084 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0x786/0x1200 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643
__do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline]
__x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560
__alloc_skb+0x318/0x740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787 tun_alloc_skb drivers/net/tun.c:1531 [inline] tun_get_user+0x1e8a/0x66d0 drivers/net/tun.c:1846 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2084 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0x786/0x1200 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline]
__se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b CPU: 0 PID: 5034 Comm: syz-executor331 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 (CVE-2024-26641)
- In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: disallow anonymous set with timeout flag Anonymous sets are never used with timeout from userspace, reject this.
Exception to this rule is NFT_SET_EVAL to ensure legacy meters still work. (CVE-2024-26642)
- In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: mark set as dead when unbinding anonymous set with timeout While the rhashtable set gc runs asynchronously, a race allows it to collect elements from anonymous sets with timeouts while it is being released from the commit path.
Mingi Cho originally reported this issue in a different path in 6.1.x with a pipapo set with low timeouts which is not possible upstream since 7395dfacfff6 (netfilter: nf_tables: use timestamp to check for set element timeout). Fix this by setting on the dead flag for anonymous sets to skip async gc in this case.
According to 08e4c8c5919f (netfilter: nf_tables: mark newset as dead on transaction abort), Florian plans to accelerate abort path by releasing objects via workqueue, therefore, this sets on the dead flag for abort path too. (CVE-2024-26643)
- In the Linux kernel, the following vulnerability has been resolved: sr9800: Add check for usbnet_get_endpoints Add check for usbnet_get_endpoints() and return the error if it fails in order to transfer the error. (CVE-2024-26651)
- In the Linux kernel, the following vulnerability has been resolved: ALSA: sh: aica: reorder cleanup operations to avoid UAF bugs The dreamcastcard->timer could schedule the spu_dma_work and the spu_dma_work could also arm the dreamcastcard->timer. When the snd_pcm_substream is closing, the aica_channel will be deallocated. But it could still be dereferenced in the worker thread. The reason is that del_timer() will return directly regardless of whether the timer handler is running or not and the worker could be rescheduled in the timer handler. As a result, the UAF bug will happen. The racy situation is shown below:
(Thread 1) | (Thread 2) snd_aicapcm_pcm_close() | ... | run_spu_dma() //worker | mod_timer() flush_work() | del_timer() | aica_period_elapsed() //timer kfree(dreamcastcard->channel) | schedule_work() | run_spu_dma() //worker ... | dreamcastcard->channel-> //USE In order to mitigate this bug and other possible corner cases, call mod_timer() conditionally in run_spu_dma(), then implement PCM sync_stop op to cancel both the timer and worker. The sync_stop op will be called from PCM core appropriately when needed.
(CVE-2024-26654)
- In the Linux kernel, the following vulnerability has been resolved: xhci: handle isoc Babble and Buffer Overrun events properly xHCI 4.9 explicitly forbids assuming that the xHC has released its ownership of a multi-TRB TD when it reports an error on one of the early TRBs. Yet the driver makes such assumption and releases the TD, allowing the remaining TRBs to be freed or overwritten by new TDs. The xHC should also report completion of the final TRB due to its IOC flag being set by us, regardless of prior errors. This event cannot be recognized if the TD has already been freed earlier, resulting in Transfer event TRB DMA ptr not part of current TD error message. Fix this by reusing the logic for processing isoc Transaction Errors. This also handles hosts which fail to report the final completion. Fix transfer length reporting on Babble errors. They may be caused by device malfunction, no guarantee that the buffer has been filled.
(CVE-2024-26659)
- In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Implement bounds check for stream encoder creation in DCN301 'stream_enc_regs' array is an array of dcn10_stream_enc_registers structures. The array is initialized with four elements, corresponding to the four calls to stream_enc_regs() in the array initializer. This means that valid indices for this array are 0, 1, 2, and 3. The error message 'stream_enc_regs' 4 <= 5 below, is indicating that there is an attempt to access this array with an index of 5, which is out of bounds. This could lead to undefined behavior Here, eng_id is used as an index to access the stream_enc_regs array. If eng_id is 5, this would result in an out-of-bounds access on the stream_enc_regs array. Thus fixing Buffer overflow error in dcn301_stream_encoder_create reported by Smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn301/dcn301_resource.c:1011 dcn301_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 <= 5 (CVE-2024-26660)
- In the Linux kernel, the following vulnerability has been resolved: tipc: Check the bearer type before calling tipc_udp_nl_bearer_add() syzbot reported the following general protection fault [1]: general protection fault, probably for non-canonical address 0xdffffc0000000010: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000080-0x0000000000000087] ... RIP:
0010:tipc_udp_is_known_peer+0x9c/0x250 net/tipc/udp_media.c:291 ... Call Trace: <TASK> tipc_udp_nl_bearer_add+0x212/0x2f0 net/tipc/udp_media.c:646 tipc_nl_bearer_add+0x21e/0x360 net/tipc/bearer.c:1089 genl_family_rcv_msg_doit+0x1fc/0x2e0 net/netlink/genetlink.c:972 genl_family_rcv_msg net/netlink/genetlink.c:1052 [inline] genl_rcv_msg+0x561/0x800 net/netlink/genetlink.c:1067 netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2544 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x53b/0x810 net/netlink/af_netlink.c:1367 netlink_sendmsg+0x8b7/0xd70 net/netlink/af_netlink.c:1909 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745 ____sys_sendmsg+0x6ac/0x940 net/socket.c:2584 ___sys_sendmsg+0x135/0x1d0 net/socket.c:2638 __sys_sendmsg+0x117/0x1e0 net/socket.c:2667 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b The cause of this issue is that when tipc_nl_bearer_add() is called with the TIPC_NLA_BEARER_UDP_OPTS attribute, tipc_udp_nl_bearer_add() is called even if the bearer is not UDP. tipc_udp_is_known_peer() called by tipc_udp_nl_bearer_add() assumes that the media_ptr field of the tipc_bearer has an udp_bearer type object, so the function goes crazy for non-UDP bearers. This patch fixes the issue by checking the bearer type before calling tipc_udp_nl_bearer_add() in tipc_nl_bearer_add(). (CVE-2024-26663)
- In the Linux kernel, the following vulnerability has been resolved: hwmon: (coretemp) Fix out-of-bounds memory access Fix a bug that pdata->cpu_map[] is set before out-of-bounds check. The problem might be triggered on systems with more than 128 cores per package. (CVE-2024-26664)
- In the Linux kernel, the following vulnerability has been resolved: tunnels: fix out of bounds access when building IPv6 PMTU error If the ICMPv6 error is built from a non-linear skb we get the following splat, BUG: KASAN: slab-out-of-bounds in do_csum+0x220/0x240 Read of size 4 at addr ffff88811d402c80 by task netperf/820 CPU: 0 PID: 820 Comm: netperf Not tainted 6.8.0-rc1+ #543 ... kasan_report+0xd8/0x110 do_csum+0x220/0x240 csum_partial+0xc/0x20 skb_tunnel_check_pmtu+0xeb9/0x3280 vxlan_xmit_one+0x14c2/0x4080 vxlan_xmit+0xf61/0x5c00 dev_hard_start_xmit+0xfb/0x510 __dev_queue_xmit+0x7cd/0x32a0 br_dev_queue_push_xmit+0x39d/0x6a0 Use skb_checksum instead of csum_partial who cannot deal with non- linear SKBs. (CVE-2024-26665)
- In the Linux kernel, the following vulnerability has been resolved: drm/msm/dpu: check for valid hw_pp in dpu_encoder_helper_phys_cleanup The commit 8b45a26f2ba9 (drm/msm/dpu: reserve cdm blocks for writeback in case of YUV output) introduced a smatch warning about another conditional block in dpu_encoder_helper_phys_cleanup() which had assumed hw_pp will always be valid which may not necessarily be true. Lets fix the other conditional block by making sure hw_pp is valid before dereferencing it.
Patchwork: https://patchwork.freedesktop.org/patch/574878/ (CVE-2024-26667)
- In the Linux kernel, the following vulnerability has been resolved: blk-mq: fix IO hang from sbitmap wakeup race In blk_mq_mark_tag_wait(), __add_wait_queue() may be re-ordered with the following blk_mq_get_driver_tag() in case of getting driver tag failure. Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observe the added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantime blk_mq_mark_tag_wait() can't get driver tag successfully. This issue can be reproduced by running the following test in loop, and fio hang can be observed in < 30min when running it on my test VM in laptop. modprobe -r scsi_debug modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4 dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename` fio --filename=/dev/$dev --direct=1 --rw=randrw --bs=4k --iodepth=1 \ --runtime=100
--numjobs=40 --time_based --name=test \ --ioengine=libaio Fix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), which is just fine in case of running out of tag. (CVE-2024-26671)
- In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations - Disallow families other than NFPROTO_{IPV4,IPV6,INET}. - Disallow layer 4 protocol with no ports, since destination port is a mandatory attribute for this object.
(CVE-2024-26673)
- In the Linux kernel, the following vulnerability has been resolved: ppp_async: limit MRU to 64K syzbot triggered a warning [1] in __alloc_pages(): WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp) Willem fixed a similar issue in commit c0a2a1b0d631 (ppp: limit MRU to 64K) Adopt the same sanity check for ppp_async_ioctl(PPPIOCSMRU) [1]: WARNING: CPU: 1 PID: 11 at mm/page_alloc.c:4543 __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 Modules linked in: CPU: 1 PID: 11 Comm: kworker/u4:0 Not tainted 6.8.0-rc2-syzkaller-g41bccc98fb79 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 Workqueue: events_unbound flush_to_ldisc pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO
-DIT -SSBS BTYPE=--) pc : __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 lr : __alloc_pages+0xc8/0x698 mm/page_alloc.c:4537 sp : ffff800093967580 x29: ffff800093967660 x28: ffff8000939675a0 x27:
dfff800000000000 x26: ffff70001272ceb4 x25: 0000000000000000 x24: ffff8000939675c0 x23: 0000000000000000 x22: 0000000000060820 x21: 1ffff0001272ceb8 x20: ffff8000939675e0 x19: 0000000000000010 x18:
ffff800093967120 x17: ffff800083bded5c x16: ffff80008ac97500 x15: 0000000000000005 x14: 1ffff0001272cebc x13: 0000000000000000 x12: 0000000000000000 x11: ffff70001272cec1 x10: 1ffff0001272cec0 x9 :
0000000000000001 x8 : ffff800091c91000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 00000000ffffffff x4 : 0000000000000000 x3 : 0000000000000020 x2 : 0000000000000008 x1 : 0000000000000000 x0 :
ffff8000939675e0 Call trace: __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline]
__kmalloc_large_node+0xbc/0x1fc mm/slub.c:3926 __do_kmalloc_node mm/slub.c:3969 [inline]
__kmalloc_node_track_caller+0x418/0x620 mm/slub.c:4001 kmalloc_reserve+0x17c/0x23c net/core/skbuff.c:590
__alloc_skb+0x1c8/0x3d8 net/core/skbuff.c:651 __netdev_alloc_skb+0xb8/0x3e8 net/core/skbuff.c:715 netdev_alloc_skb include/linux/skbuff.h:3235 [inline] dev_alloc_skb include/linux/skbuff.h:3248 [inline] ppp_async_input drivers/net/ppp/ppp_async.c:863 [inline] ppp_asynctty_receive+0x588/0x186c drivers/net/ppp/ppp_async.c:341 tty_ldisc_receive_buf+0x12c/0x15c drivers/tty/tty_buffer.c:390 tty_port_default_receive_buf+0x74/0xac drivers/tty/tty_port.c:37 receive_buf drivers/tty/tty_buffer.c:444 [inline] flush_to_ldisc+0x284/0x6e4 drivers/tty/tty_buffer.c:494 process_one_work+0x694/0x1204 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x938/0xef4 kernel/workqueue.c:2787 kthread+0x288/0x310 kernel/kthread.c:388 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860 (CVE-2024-26675)
- In the Linux kernel, the following vulnerability has been resolved: af_unix: Call kfree_skb() for dead unix_(sk)->oob_skb in GC. syzbot reported a warning [0] in __unix_gc() with a repro, which creates a socketpair and sends one socket's fd to itself using the peer. socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0 sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base=\360, iov_len=1}], msg_iovlen=1, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, cmsg_data=[3]}], msg_controllen=24, msg_flags=0}, MSG_OOB|MSG_PROBE|MSG_DONTWAIT|MSG_ZEROCOPY) = 1 This forms a self-cyclic reference that GC should finally untangle but does not due to lack of MSG_OOB handling, resulting in memory leak. Recently, commit 11498715f266 (af_unix: Remove io_uring code for GC.) removed io_uring's dead code in GC and revealed the problem. The code was executed at the final stage of GC and unconditionally moved all GC candidates from gc_candidates to gc_inflight_list. That papered over the reported problem by always making the following WARN_ON_ONCE(!list_empty(&gc_candidates)) false. The problem has been there since commit 2aab4b969002 (af_unix: fix struct pid leaks in OOB support) added full scm support for MSG_OOB while fixing another bug. To fix this problem, we must call kfree_skb() for unix_sk(sk)->oob_skb if the socket still exists in gc_candidates after purging collected skb. Then, we need to set NULL to oob_skb before calling kfree_skb() because it calls last fput() and triggers unix_release_sock(), where we call duplicate kfree_skb(u->oob_skb) if not NULL. Note that the leaked socket remained being linked to a global list, so kmemleak also could not detect it. We need to check /proc/net/protocol to notice the unfreed socket. [0]: WARNING: CPU: 0 PID: 2863 at net/unix/garbage.c:345
__unix_gc+0xc74/0xe80 net/unix/garbage.c:345 Modules linked in: CPU: 0 PID: 2863 Comm: kworker/u4:11 Not tainted 6.8.0-rc1-syzkaller-00583-g1701940b1a02 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Workqueue: events_unbound __unix_gc RIP: 0010:__unix_gc+0xc74/0xe80 net/unix/garbage.c:345 Code: 8b 5c 24 50 e9 86 f8 ff ff e8 f8 e4 22 f8 31 d2 48 c7 c6 30 6a 69 89 4c 89 ef e8 97 ef ff ff e9 80 f9 ff ff e8 dd e4 22 f8 90 <0f> 0b 90 e9 7b fd ff ff 48 89 df e8 5c e7 7c f8 e9 d3 f8 ff ff e8 RSP: 0018:ffffc9000b03fba0 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffffc9000b03fc10 RCX:
ffffffff816c493e RDX: ffff88802c02d940 RSI: ffffffff896982f3 RDI: ffffc9000b03fb30 RBP: ffffc9000b03fce0 R08: 0000000000000001 R09: fffff52001607f66 R10: 0000000000000003 R11: 0000000000000002 R12:
dffffc0000000000 R13: ffffc9000b03fc10 R14: ffffc9000b03fc10 R15: 0000000000000001 FS:
0000000000000000(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033 CR2: 00005559c8677a60 CR3: 000000000d57a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400 Call Trace: <TASK> process_one_work+0x889/0x15e0 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x8b9/0x12a0 kernel/workqueue.c:2787 kthread+0x2c6/0x3b0 kernel/kthread.c:388 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242 </TASK> (CVE-2024-26676)
- In the Linux kernel, the following vulnerability has been resolved: inet: read sk->sk_family once in inet_recv_error() inet_recv_error() is called without holding the socket lock. IPv6 socket could mutate to IPv4 with IPV6_ADDRFORM socket option and trigger a KCSAN warning. (CVE-2024-26679)
- In the Linux kernel, the following vulnerability has been resolved: net: atlantic: Fix DMA mapping for PTP hwts ring Function aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytes for PTP HWTS ring but then generic aq_ring_free() does not take this into account. Create and use a specific function to free HWTS ring to fix this issue. Trace: [ 215.351607] ------------[ cut here ]------------ [ 215.351612] DMA-API:
atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes] [ 215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360 ... [ 215.581176] Call Trace: [ 215.583632] <TASK> [ 215.585745] ? show_trace_log_lvl+0x1c4/0x2df [ 215.590114] ? show_trace_log_lvl+0x1c4/0x2df [ 215.594497] ? debug_dma_free_coherent+0x196/0x210 [ 215.599305] ? check_unmap+0xa6f/0x2360 [ 215.603147] ?
__warn+0xca/0x1d0 [ 215.606391] ? check_unmap+0xa6f/0x2360 [ 215.610237] ? report_bug+0x1ef/0x370 [ 215.613921] ? handle_bug+0x3c/0x70 [ 215.617423] ? exc_invalid_op+0x14/0x50 [ 215.621269] ? asm_exc_invalid_op+0x16/0x20 [ 215.625480] ? check_unmap+0xa6f/0x2360 [ 215.629331] ? mark_lock.part.0+0xca/0xa40 [ 215.633445] debug_dma_free_coherent+0x196/0x210 [ 215.638079] ?
__pfx_debug_dma_free_coherent+0x10/0x10 [ 215.643242] ? slab_free_freelist_hook+0x11d/0x1d0 [ 215.648060] dma_free_attrs+0x6d/0x130 [ 215.651834] aq_ring_free+0x193/0x290 [atlantic] [ 215.656487] aq_ptp_ring_free+0x67/0x110 [atlantic] ... [ 216.127540] ---[ end trace 6467e5964dd2640b ]--- [ 216.132160] DMA-API: Mapped at: [ 216.132162] debug_dma_alloc_coherent+0x66/0x2f0 [ 216.132165] dma_alloc_attrs+0xf5/0x1b0 [ 216.132168] aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic] [ 216.132193] aq_ptp_ring_alloc+0x1bb/0x540 [atlantic] [ 216.132213] aq_nic_init+0x4a1/0x760 [atlantic] (CVE-2024-26680)
- In the Linux kernel, the following vulnerability has been resolved: netdevsim: avoid potential loop in nsim_dev_trap_report_work() Many syzbot reports include the following trace [1] If nsim_dev_trap_report_work() can not grab the mutex, it should rearm itself at least one jiffie later. [1] Sending NMI from CPU 1 to CPUs 0: NMI backtrace for cpu 0 CPU: 0 PID: 32383 Comm: kworker/0:2 Not tainted 6.8.0-rc2-syzkaller-00031-g861c0981648f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 Workqueue: events nsim_dev_trap_report_work RIP: 0010:bytes_is_nonzero mm/kasan/generic.c:89 [inline] RIP: 0010:memory_is_nonzero mm/kasan/generic.c:104 [inline] RIP:
0010:memory_is_poisoned_n mm/kasan/generic.c:129 [inline] RIP: 0010:memory_is_poisoned mm/kasan/generic.c:161 [inline] RIP: 0010:check_region_inline mm/kasan/generic.c:180 [inline] RIP:
0010:kasan_check_range+0x101/0x190 mm/kasan/generic.c:189 Code: 07 49 39 d1 75 0a 45 3a 11 b8 01 00 00 00 7c 0b 44 89 c2 e8 21 ed ff ff 83 f0 01 5b 5d 41 5c c3 48 85 d2 74 4f 48 01 ea eb 09 <48> 83 c0 01 48 39 d0 74 41 80 38 00 74 f2 eb b6 41 bc 08 00 00 00 RSP: 0018:ffffc90012dcf998 EFLAGS: 00000046 RAX:
fffffbfff258af1e RBX: fffffbfff258af1f RCX: ffffffff8168eda3 RDX: fffffbfff258af1f RSI: 0000000000000004 RDI: ffffffff92c578f0 RBP: fffffbfff258af1e R08: 0000000000000000 R09: fffffbfff258af1e R10:
ffffffff92c578f3 R11: ffffffff8acbcbc0 R12: 0000000000000002 R13: ffff88806db38400 R14: 1ffff920025b9f42 R15: ffffffff92c578e8 FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c00994e078 CR3: 000000002c250000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6:
00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <NMI> </NMI> <TASK> instrument_atomic_read include/linux/instrumented.h:68 [inline] atomic_read include/linux/atomic/atomic-instrumented.h:32 [inline] queued_spin_is_locked include/asm-generic/qspinlock.h:57 [inline] debug_spin_unlock kernel/locking/spinlock_debug.c:101 [inline] do_raw_spin_unlock+0x53/0x230 kernel/locking/spinlock_debug.c:141 __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:150 [inline] _raw_spin_unlock_irqrestore+0x22/0x70 kernel/locking/spinlock.c:194 debug_object_activate+0x349/0x540 lib/debugobjects.c:726 debug_work_activate kernel/workqueue.c:578 [inline] insert_work+0x30/0x230 kernel/workqueue.c:1650 __queue_work+0x62e/0x11d0 kernel/workqueue.c:1802
__queue_delayed_work+0x1bf/0x270 kernel/workqueue.c:1953 queue_delayed_work_on+0x106/0x130 kernel/workqueue.c:1989 queue_delayed_work include/linux/workqueue.h:563 [inline] schedule_delayed_work include/linux/workqueue.h:677 [inline] nsim_dev_trap_report_work+0x9c0/0xc80 drivers/net/netdevsim/dev.c:842 process_one_work+0x886/0x15d0 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x8b9/0x1290 kernel/workqueue.c:2787 kthread+0x2c6/0x3a0 kernel/kthread.c:388 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242 </TASK> (CVE-2024-26681)
- In the Linux kernel, the following vulnerability has been resolved: net: stmmac: xgmac: fix handling of DPP safety error for DMA channels Commit 56e58d6c8a56 (net: stmmac: Implement Safety Features in XGMAC core) checks and reports safety errors, but leaves the Data Path Parity Errors for each channel in DMA unhandled at all, lead to a storm of interrupt. Fix it by checking and clearing the DMA_DPP_Interrupt_Status register. (CVE-2024-26684)
- In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential bug in end_buffer_async_write According to a syzbot report, end_buffer_async_write(), which handles the completion of block device writes, may detect abnormal condition of the buffer async_write flag and cause a BUG_ON failure when using nilfs2. Nilfs2 itself does not use end_buffer_async_write(). But, the async_write flag is now used as a marker by commit 7f42ec394156 (nilfs2: fix issue with race condition of competition between segments for dirty blocks) as a means of resolving double list insertion of dirty blocks in nilfs_lookup_dirty_data_buffers() and nilfs_lookup_node_buffers() and the resulting crash. This modification is safe as long as it is used for file data and b-tree node blocks where the page caches are independent. However, it was irrelevant and redundant to also introduce async_write for segment summary and super root blocks that share buffers with the backing device. This led to the possibility that the BUG_ON check in end_buffer_async_write would fail as described above, if independent writebacks of the backing device occurred in parallel. The use of async_write for segment summary buffers has already been removed in a previous change. Fix this issue by removing the manipulation of the async_write flag for the remaining super root block buffer. (CVE-2024-26685)
- In the Linux kernel, the following vulnerability has been resolved: fs/proc: do_task_stat: use sig->stats_lock to gather the threads/children stats lock_task_sighand() can trigger a hard lockup. If NR_CPUS threads call do_task_stat() at the same time and the process has NR_THREADS, it will spin with irqs disabled O(NR_CPUS * NR_THREADS) time. Change do_task_stat() to use sig->stats_lock to gather the statistics outside of ->siglock protected section, in the likely case this code will run lockless.
(CVE-2024-26686)
- In the Linux kernel, the following vulnerability has been resolved: xen/events: close evtchn after mapping cleanup shutdown_pirq and startup_pirq are not taking the irq_mapping_update_lock because they can't due to lock inversion. Both are called with the irq_desc->lock being taking. The lock order, however, is first irq_mapping_update_lock and then irq_desc->lock. This opens multiple races: - shutdown_pirq can be interrupted by a function that allocates an event channel: CPU0 CPU1 shutdown_pirq { xen_evtchn_close(e)
__startup_pirq { EVTCHNOP_bind_pirq -> returns just freed evtchn e set_evtchn_to_irq(e, irq) } xen_irq_info_cleanup() { set_evtchn_to_irq(e, -1) } } Assume here event channel e refers here to the same event channel number. After this race the evtchn_to_irq mapping for e is invalid (-1). - __startup_pirq races with __unbind_from_irq in a similar way. Because __startup_pirq doesn't take irq_mapping_update_lock it can grab the evtchn that __unbind_from_irq is currently freeing and cleaning up. In this case even though the event channel is allocated, its mapping can be unset in evtchn_to_irq. The fix is to first cleanup the mappings and then close the event channel. In this way, when an event channel gets allocated it's potential previous evtchn_to_irq mappings are guaranteed to be unset already. This is also the reverse order of the allocation where first the event channel is allocated and then the mappings are setup. On a 5.10 kernel prior to commit 3fcdaf3d7634 (xen/events: modify internal [un]bind interfaces), we hit a BUG like the following during probing of NVMe devices. The issue is that during nvme_setup_io_queues, pci_free_irq is called for every device which results in a call to shutdown_pirq.
With many nvme devices it's therefore likely to hit this race during boot because there will be multiple calls to shutdown_pirq and startup_pirq are running potentially in parallel. ------------[ cut here ]------------ blkfront: xvda: barrier or flush: disabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled kernel BUG at drivers/xen/events/events_base.c:499! invalid opcode: 0000 [#1] SMP PTI CPU: 44 PID: 375 Comm: kworker/u257:23 Not tainted 5.10.201-191.748.amzn2.x86_64 #1 Hardware name: Xen HVM domU, BIOS 4.11.amazon 08/24/2006 Workqueue: nvme-reset-wq nvme_reset_work RIP:
0010:bind_evtchn_to_cpu+0xdf/0xf0 Code: 5d 41 5e c3 cc cc cc cc 44 89 f7 e8 2b 55 ad ff 49 89 c5 48 85 c0 0f 84 64 ff ff ff 4c 8b 68 30 41 83 fe ff 0f 85 60 ff ff ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046 RAX: 0000000000000000 RBX:
0000000000000000 RCX: 0000000000000006 RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff RBP: ffff888107419680 R08: 0000000000000000 R09: ffffffff82d72b00 R10: 0000000000000000 R11:
0000000000000000 R12: 00000000000001ed R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffff88bc8b500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000002610001 CR4: 00000000001706e0 DR0:
0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_trace_log_lvl+0x1c1/0x2d9 ? show_trace_log_lvl+0x1c1/0x2d9 ? set_affinity_irq+0xdc/0x1c0 ? __die_body.cold+0x8/0xd ? die+0x2b/0x50 ? do_trap+0x90/0x110 ? bind_evtchn_to_cpu+0xdf/0xf0 ? do_error_trap+0x65/0x80 ? bind_evtchn_to_cpu+0xdf/0xf0 ? exc_invalid_op+0x4e/0x70 ? bind_evtchn_to_cpu+0xdf/0xf0 ? asm_exc_invalid_op+0x12/0x20 ? bind_evtchn_to_cpu+0xdf/0x ---truncated--- (CVE-2024-26687)
- In the Linux kernel, the following vulnerability has been resolved: fs,hugetlb: fix NULL pointer dereference in hugetlbs_fill_super When configuring a hugetlb filesystem via the fsconfig() syscall, there is a possible NULL dereference in hugetlbfs_fill_super() caused by assigning NULL to ctx->hstate in hugetlbfs_parse_param() when the requested pagesize is non valid. E.g: Taking the following steps: fd = fsopen(hugetlbfs, FSOPEN_CLOEXEC); fsconfig(fd, FSCONFIG_SET_STRING, pagesize, 1024, 0);
fsconfig(fd, FSCONFIG_CMD_CREATE, NULL, NULL, 0); Given that the requested pagesize is invalid, ctxt->hstate will be replaced with NULL, losing its previous value, and we will print an error: ... ...
case Opt_pagesize: ps = memparse(param->string, &rest); ctx->hstate = h; if (!ctx->hstate) { pr_err(Unsupported page size %lu MB\n, ps / SZ_1M); return -EINVAL; } return 0; ... ... This is a problem because later on, we will dereference ctxt->hstate in hugetlbfs_fill_super() ... ...
sb->s_blocksize = huge_page_size(ctx->hstate); ... ... Causing below Oops. Fix this by replacing cxt->hstate value only when then pagesize is known to be valid. kernel: hugetlbfs: Unsupported page size 0 MB kernel: BUG: kernel NULL pointer dereference, address: 0000000000000028 kernel: #PF: supervisor read access in kernel mode kernel: #PF: error_code(0x0000) - not-present page kernel: PGD 800000010f66c067 P4D 800000010f66c067 PUD 1b22f8067 PMD 0 kernel: Oops: 0000 [#1] PREEMPT SMP PTI kernel: CPU: 4 PID: 5659 Comm: syscall Tainted: G E 6.8.0-rc2-default+ #22 5a47c3fef76212addcc6eb71344aabc35190ae8f kernel:
Hardware name: Intel Corp. GROVEPORT/GROVEPORT, BIOS GVPRCRB1.86B.0016.D04.1705030402 05/03/2017 kernel:
RIP: 0010:hugetlbfs_fill_super+0xb4/0x1a0 kernel: Code: 48 8b 3b e8 3e c6 ed ff 48 85 c0 48 89 45 20 0f 84 d6 00 00 00 48 b8 ff ff ff ff ff ff ff 7f 4c 89 e7 49 89 44 24 20 48 8b 03 <8b> 48 28 b8 00 10 00 00 48 d3 e0 49 89 44 24 18 48 8b 03 8b 40 28 kernel: RSP: 0018:ffffbe9960fcbd48 EFLAGS: 00010246 kernel: RAX:
0000000000000000 RBX: ffff9af5272ae780 RCX: 0000000000372004 kernel: RDX: ffffffffffffffff RSI:
ffffffffffffffff RDI: ffff9af555e9b000 kernel: RBP: ffff9af52ee66b00 R08: 0000000000000040 R09:
0000000000370004 kernel: R10: ffffbe9960fcbd48 R11: 0000000000000040 R12: ffff9af555e9b000 kernel: R13:
ffffffffa66b86c0 R14: ffff9af507d2f400 R15: ffff9af507d2f400 kernel: FS: 00007ffbc0ba4740(0000) GS:ffff9b0bd7000000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 0000000000000028 CR3: 00000001b1ee0000 CR4: 00000000001506f0 kernel: Call Trace: kernel:
<TASK> kernel: ? __die_body+0x1a/0x60 kernel: ? page_fault_oops+0x16f/0x4a0 kernel: ? search_bpf_extables+0x65/0x70 kernel: ? fixup_exception+0x22/0x310 kernel: ? exc_page_fault+0x69/0x150 kernel: ? asm_exc_page_fault+0x22/0x30 kernel: ? __pfx_hugetlbfs_fill_super+0x10/0x10 kernel: ? hugetlbfs_fill_super+0xb4/0x1a0 kernel: ? hugetlbfs_fill_super+0x28/0x1a0 kernel: ?
__pfx_hugetlbfs_fill_super+0x10/0x10 kernel: vfs_get_super+0x40/0xa0 kernel: ?
__pfx_bpf_lsm_capable+0x10/0x10 kernel: vfs_get_tree+0x25/0xd0 kernel: vfs_cmd_create+0x64/0xe0 kernel:
__x64_sys_fsconfig+0x395/0x410 kernel: do_syscall_64+0x80/0x160 kernel: ? syscall_exit_to_user_mode+0x82/0x240 kernel: ? do_syscall_64+0x8d/0x160 kernel: ? syscall_exit_to_user_mode+0x82/0x240 kernel: ? do_syscall_64+0x8d/0x160 kernel: ? exc_page_fault+0x69/0x150 kernel: entry_SYSCALL_64_after_hwframe+0x6e/0x76 kernel: RIP:
0033:0x7ffbc0cb87c9 kernel: Code: 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 97 96 0d 00 f7 d8 64 89 01 48 kernel: RSP: 002b:00007ffc29d2f388 EFLAGS: 00000206 ORIG_RAX: 00000000000001af kernel: RAX:
fffffffffff ---truncated--- (CVE-2024-26688)
- In the Linux kernel, the following vulnerability has been resolved: ceph: prevent use-after-free in encode_cap_msg() In fs/ceph/caps.c, in encode_cap_msg(), use after free error was caught by KASAN at this line - 'ceph_buffer_get(arg->xattr_buf);'. This implies before the refcount could be increment here, it was freed. In same file, in handle_cap_grant() refcount is decremented by this line - 'ceph_buffer_put(ci->i_xattrs.blob);'. It appears that a race occurred and resource was freed by the latter line before the former line could increment it. encode_cap_msg() is called by __send_cap() and
__send_cap() is called by ceph_check_caps() after calling __prep_cap(). __prep_cap() is where arg->xattr_buf is assigned to ci->i_xattrs.blob. This is the spot where the refcount must be increased to prevent use after free error. (CVE-2024-26689)
- In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Fix null pointer dereference in __sev_platform_shutdown_locked The SEV platform device can be shutdown with a null psp_master, e.g., using DEBUG_TEST_DRIVER_REMOVE. Found using KASAN: [ 137.148210] ccp 0000:23:00.1:
enabling device (0000 -> 0002) [ 137.162647] ccp 0000:23:00.1: no command queues available [ 137.170598] ccp 0000:23:00.1: sev enabled [ 137.174645] ccp 0000:23:00.1: psp enabled [ 137.178890] general protection fault, probably for non-canonical address 0xdffffc000000001e: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN NOPTI [ 137.182693] KASAN: null-ptr-deref in range [0x00000000000000f0-0x00000000000000f7] [ 137.182693] CPU: 93 PID: 1 Comm: swapper/0 Not tainted 6.8.0-rc1+ #311 [ 137.182693] RIP:
0010:__sev_platform_shutdown_locked+0x51/0x180 [ 137.182693] Code: 08 80 3c 08 00 0f 85 0e 01 00 00 48 8b 1d 67 b6 01 08 48 b8 00 00 00 00 00 fc ff df 48 8d bb f0 00 00 00 48 89 f9 48 c1 e9 03 <80> 3c 01 00 0f 85 fe 00 00 00 48 8b 9b f0 00 00 00 48 85 db 74 2c [ 137.182693] RSP: 0018:ffffc900000cf9b0 EFLAGS: 00010216 [ 137.182693] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 000000000000001e [ 137.182693] RDX:
0000000000000000 RSI: 0000000000000008 RDI: 00000000000000f0 [ 137.182693] RBP: ffffc900000cf9c8 R08:
0000000000000000 R09: fffffbfff58f5a66 [ 137.182693] R10: ffffc900000cf9c8 R11: ffffffffac7ad32f R12:
ffff8881e5052c28 [ 137.182693] R13: ffff8881e5052c28 R14: ffff8881758e43e8 R15: ffffffffac64abf8 [ 137.182693] FS: 0000000000000000(0000) GS:ffff889de7000000(0000) knlGS:0000000000000000 [ 137.182693] CS:
0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 137.182693] CR2: 0000000000000000 CR3: 0000001cf7c7e000 CR4: 0000000000350ef0 [ 137.182693] Call Trace: [ 137.182693] <TASK> [ 137.182693] ? show_regs+0x6c/0x80 [ 137.182693] ? __die_body+0x24/0x70 [ 137.182693] ? die_addr+0x4b/0x80 [ 137.182693] ? exc_general_protection+0x126/0x230 [ 137.182693] ? asm_exc_general_protection+0x2b/0x30 [ 137.182693] ?
__sev_platform_shutdown_locked+0x51/0x180 [ 137.182693] sev_firmware_shutdown.isra.0+0x1e/0x80 [ 137.182693] sev_dev_destroy+0x49/0x100 [ 137.182693] psp_dev_destroy+0x47/0xb0 [ 137.182693] sp_destroy+0xbb/0x240 [ 137.182693] sp_pci_remove+0x45/0x60 [ 137.182693] pci_device_remove+0xaa/0x1d0 [ 137.182693] device_remove+0xc7/0x170 [ 137.182693] really_probe+0x374/0xbe0 [ 137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] __driver_probe_device+0x199/0x460 [ 137.182693] driver_probe_device+0x4e/0xd0 [ 137.182693] __driver_attach+0x191/0x3d0 [ 137.182693] ?
__pfx___driver_attach+0x10/0x10 [ 137.182693] bus_for_each_dev+0x100/0x190 [ 137.182693] ?
__pfx_bus_for_each_dev+0x10/0x10 [ 137.182693] ? __kasan_check_read+0x15/0x20 [ 137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] ? _raw_spin_unlock+0x27/0x50 [ 137.182693] driver_attach+0x41/0x60 [ 137.182693] bus_add_driver+0x2a8/0x580 [ 137.182693] driver_register+0x141/0x480 [ 137.182693] __pci_register_driver+0x1d6/0x2a0 [ 137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] ? esrt_sysfs_init+0x1cd/0x5d0 [ 137.182693] ? __pfx_sp_mod_init+0x10/0x10 [ 137.182693] sp_pci_init+0x22/0x30 [ 137.182693] sp_mod_init+0x14/0x30 [ 137.182693] ? __pfx_sp_mod_init+0x10/0x10 [ 137.182693] do_one_initcall+0xd1/0x470 [ 137.182693] ? __pfx_do_one_initcall+0x10/0x10 [ 137.182693] ? parameq+0x80/0xf0 [ 137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] ? __kmalloc+0x3b0/0x4e0 [ 137.182693] ? kernel_init_freeable+0x92d/0x1050 [ 137.182693] ? kasan_populate_vmalloc_pte+0x171/0x190 [ 137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] kernel_init_freeable+0xa64/0x1050 [ 137.182693] ?
__pfx_kernel_init+0x10/0x10 [ 137.182693] kernel_init+0x24/0x160 [ 137.182693] ? __switch_to_asm+0x3e/0x70 [ 137.182693] ret_from_fork+0x40/0x80 [ 137.182693] ? __pfx_kernel_init+0x1 ---truncated--- (CVE-2024-26695)
- In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix hang in nilfs_lookup_dirty_data_buffers() Syzbot reported a hang issue in migrate_pages_batch() called by mbind() and nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2. While migrate_pages_batch() locks a folio and waits for the writeback to complete, the log writer thread that should bring the writeback to completion picks up the folio being written back in nilfs_lookup_dirty_data_buffers() that it calls for subsequent log creation and was trying to lock the folio. Thus causing a deadlock. In the first place, it is unexpected that folios/pages in the middle of writeback will be updated and become dirty.
Nilfs2 adds a checksum to verify the validity of the log being written and uses it for recovery at mount, so data changes during writeback are suppressed. Since this is broken, an unclean shutdown could potentially cause recovery to fail. Investigation revealed that the root cause is that the wait for writeback completion in nilfs_page_mkwrite() is conditional, and if the backing device does not require stable writes, data may be modified without waiting. Fix these issues by making nilfs_page_mkwrite() wait for writeback to finish regardless of the stable write requirement of the backing device. (CVE-2024-26696)
- In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix data corruption in dsync block recovery for small block sizes The helper function nilfs_recovery_copy_block() of nilfs_recovery_dsync_blocks(), which recovers data from logs created by data sync writes during a mount after an unclean shutdown, incorrectly calculates the on-page offset when copying repair data to the file's page cache. In environments where the block size is smaller than the page size, this flaw can cause data corruption and leak uninitialized memory bytes during the recovery process. Fix these issues by correcting this byte offset calculation on the page. (CVE-2024-26697)
- In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: Fix race condition between netvsc_probe and netvsc_remove In commit ac5047671758 (hv_netvsc: Disable NAPI before closing the VMBus channel), napi_disable was getting called for all channels, including all subchannels without confirming if they are enabled or not. This caused hv_netvsc getting hung at napi_disable, when netvsc_probe() has finished running but nvdev->subchan_work has not started yet. netvsc_subchan_work() -> rndis_set_subchannel() has not created the sub-channels and because of that netvsc_sc_open() is not running. netvsc_remove() calls cancel_work_sync(&nvdev->subchan_work), for which netvsc_subchan_work did not run. netif_napi_add() sets the bit NAPI_STATE_SCHED because it ensures NAPI cannot be scheduled. Then netvsc_sc_open() -> napi_enable will clear the NAPIF_STATE_SCHED bit, so it can be scheduled.
napi_disable() does the opposite. Now during netvsc_device_remove(), when napi_disable is called for those subchannels, napi_disable gets stuck on infinite msleep. This fix addresses this problem by ensuring that napi_disable() is not getting called for non-enabled NAPI struct. But netif_napi_del() is still necessary for these non-enabled NAPI struct for cleanup purpose. Call trace: [ 654.559417] task:modprobe state:D stack: 0 pid: 2321 ppid: 1091 flags:0x00004002 [ 654.568030] Call Trace: [ 654.571221] <TASK> [ 654.573790] __schedule+0x2d6/0x960 [ 654.577733] schedule+0x69/0xf0 [ 654.581214] schedule_timeout+0x87/0x140 [ 654.585463] ? __bpf_trace_tick_stop+0x20/0x20 [ 654.590291] msleep+0x2d/0x40 [ 654.593625] napi_disable+0x2b/0x80 [ 654.597437] netvsc_device_remove+0x8a/0x1f0 [hv_netvsc] [ 654.603935] rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc] [ 654.611101] ? do_wait_intr+0xb0/0xb0 [ 654.615753] netvsc_remove+0x7c/0x120 [hv_netvsc] [ 654.621675] vmbus_remove+0x27/0x40 [hv_vmbus] (CVE-2024-26698)
- In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix MST Null Ptr for RV The change try to fix below error specific to RV platform: BUG: kernel NULL pointer dereference, address: 0000000000000008 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 4 PID: 917 Comm: sway Not tainted 6.3.9-arch1-1 #1 124dc55df4f5272ccb409f39ef4872fc2b3376a2 Hardware name: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R12ET61W(1.31 ) 07/28/2022 RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper] Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8> RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293 RAX:
0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224 RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280 RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850 R10:
ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000 R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224 FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000010ddc6000 CR4: 00000000003506e0 Call Trace: <TASK> ? __die+0x23/0x70 ? page_fault_oops+0x171/0x4e0 ? plist_add+0xbe/0x100 ? exc_page_fault+0x7c/0x180 ? asm_exc_page_fault+0x26/0x30 ? drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026] ? drm_dp_atomic_find_time_slots+0x28/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026] compute_mst_dsc_configs_for_link+0x2ff/0xa40 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] ? fill_plane_buffer_attributes+0x419/0x510 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] compute_mst_dsc_configs_for_state+0x1e1/0x250 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] amdgpu_dm_atomic_check+0xecd/0x1190 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] drm_atomic_check_only+0x5c5/0xa40 drm_mode_atomic_ioctl+0x76e/0xbc0 ? _copy_to_user+0x25/0x30 ? drm_ioctl+0x296/0x4b0 ?
__pfx_drm_mode_atomic_ioctl+0x10/0x10 drm_ioctl_kernel+0xcd/0x170 drm_ioctl+0x26d/0x4b0 ?
__pfx_drm_mode_atomic_ioctl+0x10/0x10 amdgpu_drm_ioctl+0x4e/0x90 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] __x64_sys_ioctl+0x94/0xd0 do_syscall_64+0x60/0x90 ? do_syscall_64+0x6c/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7f4dad17f76f Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c> RSP: 002b:00007ffd9ae859f0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX:
ffffffffffffffda RBX: 000055e255a55900 RCX: 00007f4dad17f76f RDX: 00007ffd9ae85a90 RSI: 00000000c03864bc RDI: 000000000000000b RBP: 00007ffd9ae85a90 R08: 0000000000000003 R09: 0000000000000003 R10:
0000000000000000 R11: 0000000000000246 R12: 00000000c03864bc R13: 000000000000000b R14: 000055e255a7fc60 R15: 000055e255a01eb0 </TASK> Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device ccm cmac algif_hash algif_skcipher af_alg joydev mousedev bnep > typec libphy k10temp ipmi_msghandler roles i2c_scmi acpi_cpufreq mac_hid nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_mas> CR2:
0000000000000008 ---[ end trace 0000000000000000 ]--- RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper] Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8> RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293 RAX:
0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224 RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280 RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850 R10:
ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000 R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224 FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000 ---truncated--- (CVE-2024-26700)
- In the Linux kernel, the following vulnerability has been resolved: iio: magnetometer: rm3100: add boundary check for the value read from RM3100_REG_TMRC Recently, we encounter kernel crash in function rm3100_common_probe caused by out of bound access of array rm3100_samp_rates (because of underlying hardware failures). Add boundary check to prevent out of bound access. (CVE-2024-26702)
- In the Linux kernel, the following vulnerability has been resolved: ext4: fix double-free of blocks due to wrong extents moved_len In ext4_move_extents(), moved_len is only updated when all moves are successfully executed, and only discards orig_inode and donor_inode preallocations when moved_len is not zero. When the loop fails to exit after successfully moving some extents, moved_len is not updated and remains at 0, so it does not discard the preallocations. If the moved extents overlap with the preallocated extents, the overlapped extents are freed twice in ext4_mb_release_inode_pa() and ext4_process_freed_data() (as described in commit 94d7c16cbbbd (ext4: Fix double-free of blocks with EXT4_IOC_MOVE_EXT)), and bb_free is incremented twice. Hence when trim is executed, a zero-division bug is triggered in mb_update_avg_fragment_size() because bb_free is not zero and bb_fragments is zero. Therefore, update move_len after each extent move to avoid the issue. (CVE-2024-26704)
- In the Linux kernel, the following vulnerability has been resolved: parisc: Fix random data corruption from exception handler The current exception handler implementation, which assists when accessing user space memory, may exhibit random data corruption if the compiler decides to use a different register than the specified register %r29 (defined in ASM_EXCEPTIONTABLE_REG) for the error code. If the compiler choose another register, the fault handler will nevertheless store -EFAULT into %r29 and thus trash whatever this register is used for. Looking at the assembly I found that this happens sometimes in emulate_ldd(). To solve the issue, the easiest solution would be if it somehow is possible to tell the fault handler which register is used to hold the error code. Using %0 or %1 in the inline assembly is not posssible as it will show up as e.g. %r29 (with the %r prefix), which the GNU assembler can not convert to an integer. This patch takes another, better and more flexible approach: We extend the __ex_table (which is out of the execution path) by one 32-word. In this word we tell the compiler to insert the assembler instruction or %r0,%r0,%reg, where %reg references the register which the compiler choosed for the error return code. In case of an access failure, the fault handler finds the __ex_table entry and can examine the opcode. The used register is encoded in the lowest 5 bits, and the fault handler can then store -EFAULT into this register. Since we extend the __ex_table to 3 words we can't use the BUILDTIME_TABLE_SORT config option any longer. (CVE-2024-26706)
- In the Linux kernel, the following vulnerability has been resolved: net: hsr: remove WARN_ONCE() in send_hsr_supervision_frame() Syzkaller reported [1] hitting a warning after failing to allocate resources for skb in hsr_init_skb(). Since a WARN_ONCE() call will not help much in this case, it might be prudent to switch to netdev_warn_once(). At the very least it will suppress syzkaller reports such as [1]. Just in case, use netdev_warn_once() in send_prp_supervision_frame() for similar reasons. [1] HSR: Could not send supervision frame WARNING: CPU: 1 PID: 85 at net/hsr/hsr_device.c:294 send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294 RIP:
0010:send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294 ... Call Trace: <IRQ> hsr_announce+0x114/0x370 net/hsr/hsr_device.c:382 call_timer_fn+0x193/0x590 kernel/time/timer.c:1700 expire_timers kernel/time/timer.c:1751 [inline] __run_timers+0x764/0xb20 kernel/time/timer.c:2022 run_timer_softirq+0x58/0xd0 kernel/time/timer.c:2035 __do_softirq+0x21a/0x8de kernel/softirq.c:553 invoke_softirq kernel/softirq.c:427 [inline] __irq_exit_rcu kernel/softirq.c:632 [inline] irq_exit_rcu+0xb7/0x120 kernel/softirq.c:644 sysvec_apic_timer_interrupt+0x95/0xb0 arch/x86/kernel/apic/apic.c:1076 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:649 ... This issue is also found in older kernels (at least up to 5.10).
(CVE-2024-26707)
- In the Linux kernel, the following vulnerability has been resolved: powerpc/kasan: Limit KASAN thread size increase to 32KB KASAN is seen to increase stack usage, to the point that it was reported to lead to stack overflow on some 32-bit machines (see link). To avoid overflows the stack size was doubled for KASAN builds in commit 3e8635fb2e07 (powerpc/kasan: Force thread size increase with KASAN). However with a 32KB stack size to begin with, the doubling leads to a 64KB stack, which causes build errors:
arch/powerpc/kernel/switch.S:249: Error: operand out of range (0x000000000000fe50 is not between 0xffffffffffff8000 and 0x0000000000007fff) Although the asm could be reworked, in practice a 32KB stack seems sufficient even for KASAN builds - the additional usage seems to be in the 2-3KB range for a 64-bit KASAN build. So only increase the stack for KASAN if the stack size is < 32KB. (CVE-2024-26710)
- In the Linux kernel, the following vulnerability has been resolved: powerpc/kasan: Fix addr error caused by page alignment In kasan_init_region, when k_start is not page aligned, at the begin of for loop, k_cur = k_start & PAGE_MASK is less than k_start, and then `va = block + k_cur - k_start` is less than block, the addr va is invalid, because the memory address space from va to block is not alloced by memblock_alloc, which will not be reserved by memblock_reserve later, it will be used by other places. As a result, memory overwriting occurs. for example: int __init __weak kasan_init_region(void *start, size_t size) { [...] /* if say block(dcd97000) k_start(feef7400) k_end(feeff3fe) */ block = memblock_alloc(k_end
- k_start, PAGE_SIZE); [...] for (k_cur = k_start & PAGE_MASK; k_cur < k_end; k_cur += PAGE_SIZE) { /* at the begin of for loop * block(dcd97000) va(dcd96c00) k_cur(feef7000) k_start(feef7400) * va(dcd96c00) is less than block(dcd97000), va is invalid */ void *va = block + k_cur - k_start; [...] } [...] } Therefore, page alignment is performed on k_start before memblock_alloc() to ensure the validity of the VA address.
(CVE-2024-26712)
- In the Linux kernel, the following vulnerability has been resolved: interconnect: qcom: sc8180x: Mark CO0 BCM keepalive The CO0 BCM needs to be up at all times, otherwise some hardware (like the UFS controller) loses its connection to the rest of the SoC, resulting in a hang of the platform, accompanied by a spectacular logspam. Mark it as keepalive to prevent such cases. (CVE-2024-26714)
- In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend In current scenario if Plug-out and Plug-In performed continuously there could be a chance while checking for dwc->gadget_driver in dwc3_gadget_suspend, a NULL pointer dereference may occur. Call Stack: CPU1: CPU2: gadget_unbind_driver dwc3_suspend_common dwc3_gadget_stop dwc3_gadget_suspend dwc3_disconnect_gadget CPU1 basically clears the variable and CPU2 checks the variable. Consider CPU1 is running and right before gadget_driver is cleared and in parallel CPU2 executes dwc3_gadget_suspend where it finds dwc->gadget_driver which is not NULL and resumes execution and then CPU1 completes execution. CPU2 executes dwc3_disconnect_gadget where it checks dwc->gadget_driver is already NULL because of which the NULL pointer deference occur. (CVE-2024-26715)
- In the Linux kernel, the following vulnerability has been resolved: HID: i2c-hid-of: fix NULL-deref on failed power up A while back the I2C HID implementation was split in an ACPI and OF part, but the new OF driver never initialises the client pointer which is dereferenced on power-up failures. (CVE-2024-26717)
- In the Linux kernel, the following vulnerability has been resolved: dm-crypt, dm-verity: disable tasklets Tasklets have an inherent problem with memory corruption. The function tasklet_action_common calls tasklet_trylock, then it calls the tasklet callback and then it calls tasklet_unlock. If the tasklet callback frees the structure that contains the tasklet or if it calls some code that may free it, tasklet_unlock will write into free memory. The commits 8e14f610159d and d9a02e016aaf try to fix it for dm-crypt, but it is not a sufficient fix and the data corruption can still happen [1]. There is no fix for dm-verity and dm-verity will write into free memory with every tasklet-processed bio. There will be atomic workqueues implemented in the kernel 6.9 [2]. They will have better interface and they will not suffer from the memory corruption problem. But we need something that stops the memory corruption now and that can be backported to the stable kernels. So, I'm proposing this commit that disables tasklets in both dm- crypt and dm-verity. This commit doesn't remove the tasklet support, because the tasklet code will be reused when atomic workqueues will be implemented. [1] https://lore.kernel.org/all/[email protected]/T/ [2] https://lore.kernel.org/lkml/[email protected]/ (CVE-2024-26718)
- In the Linux kernel, the following vulnerability has been resolved: mm/writeback: fix possible divide-by- zero in wb_dirty_limits(), again (struct dirty_throttle_control *)->thresh is an unsigned long, but is passed as the u32 divisor argument to div_u64(). On architectures where unsigned long is 64 bytes, the argument will be implicitly truncated. Use div64_u64() instead of div_u64() so that the value used in the is this a safe division check is the same as the divisor. Also, remove redundant cast of the numerator to u64, as that should happen implicitly. This would be difficult to exploit in memcg domain, given the ratio-based arithmetic domain_drity_limits() uses, but is much easier in global writeback domain with a BDI_CAP_STRICTLIMIT-backing device, using e.g. vm.dirty_bytes=(1<<32)*PAGE_SIZE so that dtc->thresh == (1<<32) (CVE-2024-26720)
- In the Linux kernel, the following vulnerability has been resolved: ASoC: rt5645: Fix deadlock in rt5645_jack_detect_work() There is a path in rt5645_jack_detect_work(), where rt5645->jd_mutex is left locked forever. That may lead to deadlock when rt5645_jack_detect_work() is called for the second time.
Found by Linux Verification Center (linuxtesting.org) with SVACE. (CVE-2024-26722)
- In the Linux kernel, the following vulnerability has been resolved: lan966x: Fix crash when adding interface under a lag There is a crash when adding one of the lan966x interfaces under a lag interface.
The issue can be reproduced like this: ip link add name bond0 type bond miimon 100 mode balance-xor ip link set dev eth0 master bond0 The reason is because when adding a interface under the lag it would go through all the ports and try to figure out which other ports are under that lag interface. And the issue is that lan966x can have ports that are NULL pointer as they are not probed. So then iterating over these ports it would just crash as they are NULL pointers. The fix consists in actually checking for NULL pointers before accessing something from the ports. Like we do in other places. (CVE-2024-26723)
- In the Linux kernel, the following vulnerability has been resolved: btrfs: don't drop extent_map for free space inode on write error While running the CI for an unrelated change I hit the following panic with generic/648 on btrfs_holes_spacecache. assertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385 ------------[ cut here ]------------ kernel BUG at fs/btrfs/extent_io.c:1385! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G W 6.8.0-rc2+ #1 RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0 Call Trace: <TASK> extent_write_cache_pages+0x2ac/0x8f0 extent_writepages+0x87/0x110 do_writepages+0xd5/0x1f0 filemap_fdatawrite_wbc+0x63/0x90 __filemap_fdatawrite_range+0x5c/0x80 btrfs_fdatawrite_range+0x1f/0x50 btrfs_write_out_cache+0x507/0x560 btrfs_write_dirty_block_groups+0x32a/0x420 commit_cowonly_roots+0x21b/0x290 btrfs_commit_transaction+0x813/0x1360 btrfs_sync_file+0x51a/0x640
__x64_sys_fdatasync+0x52/0x90 do_syscall_64+0x9c/0x190 entry_SYSCALL_64_after_hwframe+0x6e/0x76 This happens because we fail to write out the free space cache in one instance, come back around and attempt to write it again. However on the second pass through we go to call btrfs_get_extent() on the inode to get the extent mapping. Because this is a new block group, and with the free space inode we always search the commit root to avoid deadlocking with the tree, we find nothing and return a EXTENT_MAP_HOLE for the requested range. This happens because the first time we try to write the space cache out we hit an error, and on an error we drop the extent mapping. This is normal for normal files, but the free space cache inode is special. We always expect the extent map to be correct. Thus the second time through we end up with a bogus extent map. Since we're deprecating this feature, the most straightforward way to fix this is to simply skip dropping the extent map range for this failed range. I shortened the test by using error injection to stress the area to make it easier to reproduce. With this patch in place we no longer panic with my error injection test. (CVE-2024-26726)
- In the Linux kernel, the following vulnerability has been resolved: btrfs: do not ASSERT() if the newly created subvolume already got read [BUG] There is a syzbot crash, triggered by the ASSERT() during subvolume creation: assertion failed: !anon_dev, in fs/btrfs/disk-io.c:1319 ------------[ cut here ]------------ kernel BUG at fs/btrfs/disk-io.c:1319! invalid opcode: 0000 [#1] PREEMPT SMP KASAN RIP:
0010:btrfs_get_root_ref.part.0+0x9aa/0xa60 <TASK> btrfs_get_new_fs_root+0xd3/0xf0 create_subvol+0xd02/0x1650 btrfs_mksubvol+0xe95/0x12b0 __btrfs_ioctl_snap_create+0x2f9/0x4f0 btrfs_ioctl_snap_create+0x16b/0x200 btrfs_ioctl+0x35f0/0x5cf0 __x64_sys_ioctl+0x19d/0x210 do_syscall_64+0x3f/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b ---[ end trace 0000000000000000 ]--- [CAUSE] During create_subvol(), after inserting root item for the newly created subvolume, we would trigger btrfs_get_new_fs_root() to get the btrfs_root of that subvolume. The idea here is, we have preallocated an anonymous device number for the subvolume, thus we can assign it to the new subvolume. But there is really nothing preventing things like backref walk to read the new subvolume. If that happens before we call btrfs_get_new_fs_root(), the subvolume would be read out, with a new anonymous device number assigned already. In that case, we would trigger ASSERT(), as we really expect no one to read out that subvolume (which is not yet accessible from the fs). But things like backref walk is still possible to trigger the read on the subvolume. Thus our assumption on the ASSERT() is not correct in the first place. [FIX] Fix it by removing the ASSERT(), and just free the @anon_dev, reset it to 0, and continue. If the subvolume tree is read out by something else, it should have already get a new anon_dev assigned thus we only need to free the preallocated one. (CVE-2024-26727)
- In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix NULL pointer dereference in sk_psock_verdict_data_ready() syzbot reported the following NULL pointer dereference issue [1]: BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] RIP: 0010:0x0 [...] Call Trace:
<TASK> sk_psock_verdict_data_ready+0x232/0x340 net/core/skmsg.c:1230 unix_stream_sendmsg+0x9b4/0x1230 net/unix/af_unix.c:2293 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline]
__sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 If sk_psock_verdict_data_ready() and sk_psock_stop_verdict() are called concurrently, psock->saved_data_ready can be NULL, causing the above issue. This patch fixes this issue by calling the appropriate data ready function using the sk_psock_data_ready() helper and protecting it from concurrency with sk->sk_callback_lock. (CVE-2024-26731)
- In the Linux kernel, the following vulnerability has been resolved: arp: Prevent overflow in arp_req_get(). syzkaller reported an overflown write in arp_req_get(). [0] When ioctl(SIOCGARP) is issued, arp_req_get() looks up an neighbour entry and copies neigh->ha to struct arpreq.arp_ha.sa_data. The arp_ha here is struct sockaddr, not struct sockaddr_storage, so the sa_data buffer is just 14 bytes. In the splat below, 2 bytes are overflown to the next int field, arp_flags. We initialise the field just after the memcpy(), so it's not a problem. However, when dev->addr_len is greater than 22 (e.g. MAX_ADDR_LEN), arp_netmask is overwritten, which could be set as htonl(0xFFFFFFFFUL) in arp_ioctl() before calling arp_req_get(). To avoid the overflow, let's limit the max length of memcpy(). Note that commit b5f0de6df6dc (net: dev: Convert sa_data to flexible array in struct sockaddr) just silenced syzkaller.
[0]: memcpy: detected field-spanning write (size 16) of single field r->arp_ha.sa_data at net/ipv4/arp.c:1128 (size 14) WARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128 Modules linked in: CPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014 RIP:
0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128 Code: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb <0f> 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6 RSP: 0018:ffffc900050b7998 EFLAGS: 00010286 RAX: 0000000000000000 RBX:
ffff88803a815000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001 RBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11:
203a7970636d656d R12: ffff888039c54000 R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010 FS: 00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0 DR0:
0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> arp_ioctl+0x33f/0x4b0 net/ipv4/arp.c:1261 inet_ioctl+0x314/0x3a0 net/ipv4/af_inet.c:981 sock_do_ioctl+0xdf/0x260 net/socket.c:1204 sock_ioctl+0x3ef/0x650 net/socket.c:1321 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x18e/0x220 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x37/0x90 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x64/0xce RIP: 0033:0x7f172b262b8d Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f172bf300b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f172b3abf80 RCX: 00007f172b262b8d RDX:
0000000020000000 RSI: 0000000000008954 RDI: 0000000000000003 RBP: 00007f172b2d3493 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13:
000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000 </TASK> (CVE-2024-26733)
- In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: fix possible use-after-free and null-ptr-deref The pernet operations structure for the subsystem must be registered before registering the generic netlink family. (CVE-2024-26735)
- In the Linux kernel, the following vulnerability has been resolved: afs: Increase buffer size in afs_update_volume_status() The max length of volume->vid value is 20 characters. So increase idbuf[] size up to 24 to avoid overflow. Found by Linux Verification Center (linuxtesting.org) with SVACE. [DH:
Actually, it's 20 + NUL, so increase it to 24 and use snprintf()] (CVE-2024-26736)
- In the Linux kernel, the following vulnerability has been resolved: bpf: Fix racing between bpf_timer_cancel_and_free and bpf_timer_cancel The following race is possible between bpf_timer_cancel_and_free and bpf_timer_cancel. It will lead a UAF on the timer->timer.
bpf_timer_cancel(); spin_lock(); t = timer->time; spin_unlock(); bpf_timer_cancel_and_free(); spin_lock();
t = timer->timer; timer->timer = NULL; spin_unlock(); hrtimer_cancel(&t->timer); kfree(t); /* UAF on t */ hrtimer_cancel(&t->timer); In bpf_timer_cancel_and_free, this patch frees the timer->timer after a rcu grace period. This requires a rcu_head addition to the struct bpf_hrtimer. Another kfree(t) happens in bpf_timer_init, this does not need a kfree_rcu because it is still under the spin_lock and timer->timer has not been visible by others yet. In bpf_timer_cancel, rcu_read_lock() is added because this helper can be used in a non rcu critical section context (e.g. from a sleepable bpf prog). Other timer->timer usages in helpers.c have been audited, bpf_timer_cancel() is the only place where timer->timer is used outside of the spin_lock. Another solution considered is to mark a t->flag in bpf_timer_cancel and clear it after hrtimer_cancel() is done. In bpf_timer_cancel_and_free, it busy waits for the flag to be cleared before kfree(t). This patch goes with a straight forward solution and frees timer->timer after a rcu grace period. (CVE-2024-26737)
- In the Linux kernel, the following vulnerability has been resolved: dccp/tcp: Unhash sk from ehash for tb2 alloc failure after check_estalblished(). syzkaller reported a warning [0] in inet_csk_destroy_sock() with no repro. WARN_ON(inet_sk(sk)->inet_num && !inet_csk(sk)->icsk_bind_hash); However, the syzkaller's log hinted that connect() failed just before the warning due to FAULT_INJECTION. [1] When connect() is called for an unbound socket, we search for an available ephemeral port. If a bhash bucket exists for the port, we call __inet_check_established() or __inet6_check_established() to check if the bucket is reusable. If reusable, we add the socket into ehash and set inet_sk(sk)->inet_num. Later, we look up the corresponding bhash2 bucket and try to allocate it if it does not exist. Although it rarely occurs in real use, if the allocation fails, we must revert the changes by check_established(). Otherwise, an unconnected socket could illegally occupy an ehash entry. Note that we do not put tw back into ehash because sk might have already responded to a packet for tw and it would be better to free tw earlier under such memory presure.
[0]: WARNING: CPU: 0 PID: 350830 at net/ipv4/inet_connection_sock.c:1193 inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193) Modules linked in: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193) Code: 41 5c 41 5d 41 5e e9 2d 4a 3d fd e8 28 4a 3d fd 48 89 ef e8 f0 cd 7d ff 5b 5d 41 5c 41 5d 41 5e e9 13 4a 3d fd e8 0e 4a 3d fd <0f> 0b e9 61 fe ff ff e8 02 4a 3d fd 4c 89 e7 be 03 00 00 00 e8 05 RSP: 0018:ffffc9000b21fd38 EFLAGS: 00010293 RAX: 0000000000000000 RBX:
0000000000009e78 RCX: ffffffff840bae40 RDX: ffff88806e46c600 RSI: ffffffff840bb012 RDI: ffff88811755cca8 RBP: ffff88811755c880 R08: 0000000000000003 R09: 0000000000000000 R10: 0000000000009e78 R11:
0000000000000000 R12: ffff88811755c8e0 R13: ffff88811755c892 R14: ffff88811755c918 R15: 0000000000000000 FS: 00007f03e5243800(0000) GS:ffff88811ae00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b32f21000 CR3: 0000000112ffe001 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <TASK> ? inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193) dccp_close (net/dccp/proto.c:1078) inet_release (net/ipv4/af_inet.c:434) __sock_release (net/socket.c:660) sock_close (net/socket.c:1423) __fput (fs/file_table.c:377) __fput_sync (fs/file_table.c:462) __x64_sys_close (fs/open.c:1557 fs/open.c:1539 fs/open.c:1539) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129) RIP:
0033:0x7f03e53852bb Code: 03 00 00 00 0f 05 48 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 43 c9 f5 ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 89 44 24 0c e8 a1 c9 f5 ff 8b 44 RSP: 002b:00000000005dfba0 EFLAGS: 00000293 ORIG_RAX: 0000000000000003 RAX: ffffffffffffffda RBX:
0000000000000004 RCX: 00007f03e53852bb RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000167c R10: 0000000008a79680 R11:
0000000000000293 R12: 00007f03e4e43000 R13: 00007f03e4e43170 R14: 00007f03e4e43178 R15: 00007f03e4e43170 </TASK> [1]: FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 0 CPU: 0 PID: 350833 Comm: syz-executor.1 Not tainted 6.7.0-12272-g2121c43f88f5 #9 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:107 (discriminator 1)) should_fail_ex (lib/fault- inject.c:52 lib/fault-inject.c:153) should_failslab (mm/slub.c:3748) kmem_cache_alloc (mm/slub.c:3763 mm/slub.c:3842 mm/slub.c:3867) inet_bind2_bucket_create ---truncated--- (CVE-2024-26741)
- In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix disable_managed_interrupts Correct blk-mq registration issue with module parameter disable_managed_interrupts enabled. When we turn off the default PCI_IRQ_AFFINITY flag, the driver needs to register with blk-mq using blk_mq_map_queues(). The driver is currently calling blk_mq_pci_map_queues() which results in a stack trace and possibly undefined behavior. Stack Trace: [ 7.860089] scsi host2:
smartpqi [ 7.871934] WARNING: CPU: 0 PID: 238 at block/blk-mq-pci.c:52 blk_mq_pci_map_queues+0xca/0xd0 [ 7.889231] Modules linked in: sd_mod t10_pi sg uas smartpqi(+) crc32c_intel scsi_transport_sas usb_storage dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse [ 7.924755] CPU: 0 PID: 238 Comm:
kworker/0:3 Not tainted 4.18.0-372.88.1.el8_6_smartpqi_test.x86_64 #1 [ 7.944336] Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 03/08/2022 [ 7.963026] Workqueue: events work_for_cpu_fn [ 7.978275] RIP: 0010:blk_mq_pci_map_queues+0xca/0xd0 [ 7.978278] Code: 48 89 de 89 c7 e8 f6 0f 4f 00 3b 05 c4 b7 8e 01 72 e1 5b 31 c0 5d 41 5c 41 5d 41 5e 41 5f e9 7d df 73 00 31 c0 e9 76 df 73 00 <0f> 0b eb bc 90 90 0f 1f 44 00 00 41 57 49 89 ff 41 56 41 55 41 54 [ 7.978280] RSP:
0018:ffffa95fc3707d50 EFLAGS: 00010216 [ 7.978283] RAX: 00000000ffffffff RBX: 0000000000000000 RCX:
0000000000000010 [ 7.978284] RDX: 0000000000000004 RSI: 0000000000000000 RDI: ffff9190c32d4310 [ 7.978286] RBP: 0000000000000000 R08: ffffa95fc3707d38 R09: ffff91929b81ac00 [ 7.978287] R10: 0000000000000001 R11:
ffffa95fc3707ac0 R12: 0000000000000000 [ 7.978288] R13: ffff9190c32d4000 R14: 00000000ffffffff R15:
ffff9190c4c950a8 [ 7.978290] FS: 0000000000000000(0000) GS:ffff9193efc00000(0000) knlGS:0000000000000000 [ 7.978292] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 8.172814] CR2: 000055d11166c000 CR3:
00000002dae10002 CR4: 00000000007706f0 [ 8.172816] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000 [ 8.172817] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 8.172818] PKRU: 55555554 [ 8.172819] Call Trace: [ 8.172823] blk_mq_alloc_tag_set+0x12e/0x310 [ 8.264339] scsi_add_host_with_dma.cold.9+0x30/0x245 [ 8.279302] pqi_ctrl_init+0xacf/0xc8e [smartpqi] [ 8.294085] ? pqi_pci_probe+0x480/0x4c8 [smartpqi] [ 8.309015] pqi_pci_probe+0x480/0x4c8 [smartpqi] [ 8.323286] local_pci_probe+0x42/0x80 [ 8.337855] work_for_cpu_fn+0x16/0x20 [ 8.351193] process_one_work+0x1a7/0x360 [ 8.364462] ? create_worker+0x1a0/0x1a0 [ 8.379252] worker_thread+0x1ce/0x390 [ 8.392623] ? create_worker+0x1a0/0x1a0 [ 8.406295] kthread+0x10a/0x120 [ 8.418428] ? set_kthread_struct+0x50/0x50 [ 8.431532] ret_from_fork+0x1f/0x40 [ 8.444137] ---[ end trace 1bf0173d39354506 ]--- (CVE-2024-26742)
- In the Linux kernel, the following vulnerability has been resolved: RDMA/qedr: Fix qedr_create_user_qp error flow Avoid the following warning by making sure to free the allocated resources in case that qedr_init_user_queue() fail. -----------[ cut here ]----------- WARNING: CPU: 0 PID: 143192 at drivers/infiniband/core/rdma_core.c:874 uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] Modules linked in:
tls target_core_user uio target_core_pscsi target_core_file target_core_iblock ib_srpt ib_srp scsi_transport_srp nfsd nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs 8021q garp mrp stp llc ext4 mbcache jbd2 opa_vnic ib_umad ib_ipoib sunrpc rdma_ucm ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm hfi1 intel_rapl_msr intel_rapl_common mgag200 qedr sb_edac drm_shmem_helper rdmavt x86_pkg_temp_thermal drm_kms_helper intel_powerclamp ib_uverbs coretemp i2c_algo_bit kvm_intel dell_wmi_descriptor ipmi_ssif sparse_keymap kvm ib_core rfkill syscopyarea sysfillrect video sysimgblt irqbypass ipmi_si ipmi_devintf fb_sys_fops rapl iTCO_wdt mxm_wmi iTCO_vendor_support intel_cstate pcspkr dcdbas intel_uncore ipmi_msghandler lpc_ich acpi_power_meter mei_me mei fuse drm xfs libcrc32c qede sd_mod ahci libahci t10_pi sg crct10dif_pclmul crc32_pclmul crc32c_intel qed libata tg3 ghash_clmulni_intel megaraid_sas crc8 wmi [last unloaded: ib_srpt] CPU: 0 PID: 143192 Comm: fi_rdm_tagged_p Kdump: loaded Not tainted 5.14.0-408.el9.x86_64 #1 Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.14.0 01/25/2022 RIP:
0010:uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] Code: 5d 41 5c 41 5d 41 5e e9 0f 26 1b dd 48 89 df e8 67 6a ff ff 49 8b 86 10 01 00 00 48 85 c0 74 9c 4c 89 e7 e8 83 c0 cb dd eb 92 <0f> 0b eb be 0f 0b be 04 00 00 00 48 89 df e8 8e f5 ff ff e9 6d ff RSP: 0018:ffffb7c6cadfbc60 EFLAGS: 00010286 RAX: ffff8f0889ee3f60 RBX: ffff8f088c1a5200 RCX: 00000000802a0016 RDX: 00000000802a0017 RSI: 0000000000000001 RDI:
ffff8f0880042600 RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8f11fffd5000 R11: 0000000000039000 R12: ffff8f0d5b36cd80 R13: ffff8f088c1a5250 R14: ffff8f1206d91000 R15:
0000000000000000 FS: 0000000000000000(0000) GS:ffff8f11d7c00000(0000) knlGS:0000000000000000 CS: 0010 DS:
0000 ES: 0000 CR0: 0000000080050033 CR2: 0000147069200e20 CR3: 00000001c7210002 CR4: 00000000001706f0 Call Trace: <TASK> ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? ib_uverbs_close+0x1f/0xb0 [ib_uverbs] ? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] ? __warn+0x81/0x110 ? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] ? report_bug+0x10a/0x140 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] ib_uverbs_close+0x1f/0xb0 [ib_uverbs] __fput+0x94/0x250 task_work_run+0x5c/0x90 do_exit+0x270/0x4a0 do_group_exit+0x2d/0x90 get_signal+0x87c/0x8c0 arch_do_signal_or_restart+0x25/0x100 ? ib_uverbs_ioctl+0xc2/0x110 [ib_uverbs] exit_to_user_mode_loop+0x9c/0x130 exit_to_user_mode_prepare+0xb6/0x100 syscall_exit_to_user_mode+0x12/0x40 do_syscall_64+0x69/0x90 ? syscall_exit_work+0x103/0x130 ? syscall_exit_to_user_mode+0x22/0x40 ? do_syscall_64+0x69/0x90 ? syscall_exit_work+0x103/0x130 ? syscall_exit_to_user_mode+0x22/0x40 ? do_syscall_64+0x69/0x90 ? do_syscall_64+0x69/0x90 ? common_interrupt+0x43/0xa0 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP:
0033:0x1470abe3ec6b Code: Unable to access opcode bytes at RIP 0x1470abe3ec41. RSP: 002b:00007fff13ce9108 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: fffffffffffffffc RBX: 00007fff13ce9218 RCX:
00001470abe3ec6b RDX: 00007fff13ce9200 RSI: 00000000c0181b01 RDI: 0000000000000004 RBP: 00007fff13ce91e0 R08: 0000558d9655da10 R09: 0000558d9655dd00 R10: 00007fff13ce95c0 R11: 0000000000000246 R12:
00007fff13ce9358 R13: 0000000000000013 R14: 0000558d9655db50 R15: 00007fff13ce9470 </TASK> --[ end trace 888a9b92e04c5c97 ]-- (CVE-2024-26743)
- In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: Support specifying the srpt_service_guid parameter Make loading ib_srpt with this parameter set work. The current behavior is that setting that parameter while loading the ib_srpt kernel module triggers the following kernel crash:
BUG: kernel NULL pointer dereference, address: 0000000000000000 Call Trace: <TASK> parse_one+0x18c/0x1d0 parse_args+0xe1/0x230 load_module+0x8de/0xa60 init_module_from_file+0x8b/0xd0 idempotent_init_module+0x181/0x240 __x64_sys_finit_module+0x5a/0xb0 do_syscall_64+0x5f/0xe0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 (CVE-2024-26744)
- In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries/iommu: IOMMU table is not initialized for kdump over SR-IOV When kdump kernel tries to copy dump data over SR-IOV, LPAR panics due to NULL pointer exception: Kernel attempted to read user page (0) - exploit attempt? (uid: 0) BUG:
Kernel NULL pointer dereference on read at 0x00000000 Faulting instruction address: 0xc000000020847ad4 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries Modules linked in: mlx5_core(+) vmx_crypto pseries_wdt papr_scm libnvdimm mlxfw tls psample sunrpc fuse overlay squashfs loop CPU: 12 PID: 315 Comm: systemd-udevd Not tainted 6.4.0-Test102+ #12 Hardware name:
IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries NIP:
c000000020847ad4 LR: c00000002083b2dc CTR: 00000000006cd18c REGS: c000000029162ca0 TRAP: 0300 Not tainted (6.4.0-Test102+) MSR: 800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 48288244 XER: 00000008 CFAR:
c00000002083b2d8 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 1 ... NIP _find_next_zero_bit+0x24/0x110 LR bitmap_find_next_zero_area_off+0x5c/0xe0 Call Trace: dev_printk_emit+0x38/0x48 (unreliable) iommu_area_alloc+0xc4/0x180 iommu_range_alloc+0x1e8/0x580 iommu_alloc+0x60/0x130 iommu_alloc_coherent+0x158/0x2b0 dma_iommu_alloc_coherent+0x3c/0x50 dma_alloc_attrs+0x170/0x1f0 mlx5_cmd_init+0xc0/0x760 [mlx5_core] mlx5_function_setup+0xf0/0x510 [mlx5_core] mlx5_init_one+0x84/0x210 [mlx5_core] probe_one+0x118/0x2c0 [mlx5_core] local_pci_probe+0x68/0x110 pci_call_probe+0x68/0x200 pci_device_probe+0xbc/0x1a0 really_probe+0x104/0x540 __driver_probe_device+0xb4/0x230 driver_probe_device+0x54/0x130 __driver_attach+0x158/0x2b0 bus_for_each_dev+0xa8/0x130 driver_attach+0x34/0x50 bus_add_driver+0x16c/0x300 driver_register+0xa4/0x1b0
__pci_register_driver+0x68/0x80 mlx5_init+0xb8/0x100 [mlx5_core] do_one_initcall+0x60/0x300 do_init_module+0x7c/0x2b0 At the time of LPAR dump, before kexec hands over control to kdump kernel, DDWs (Dynamic DMA Windows) are scanned and added to the FDT. For the SR-IOV case, default DMA window ibm,dma- window is removed from the FDT and DDW added, for the device. Now, kexec hands over control to the kdump kernel. When the kdump kernel initializes, PCI busses are scanned and IOMMU group/tables created, in pci_dma_bus_setup_pSeriesLP(). For the SR-IOV case, there is no ibm,dma-window. The original commit:
b1fc44eaa9ba, fixes the path where memory is pre-mapped (direct mapped) to the DDW. When TCEs are direct mapped, there is no need to initialize IOMMU tables. iommu_table_setparms_lpar() only considers ibm,dma- window property when initiallizing IOMMU table. In the scenario where TCEs are dynamically allocated for SR-IOV, newly created IOMMU table is not initialized. Later, when the device driver tries to enter TCEs for the SR-IOV device, NULL pointer execption is thrown from iommu_area_alloc(). The fix is to initialize the IOMMU table with DDW property stored in the FDT. There are 2 points to remember: 1. For the dedicated adapter, kdump kernel would encounter both default and DDW in FDT. In this case, DDW property is used to initialize the IOMMU table. 2. A DDW could be direct or dynamic mapped. kdump kernel would initialize IOMMU table and mark the existing DDW as dynamic. This works fine since, at the time of table initialization, iommu_table_clear() makes some space in the DDW, for some predefined number of TCEs which are needed for kdump to succeed. (CVE-2024-26745)
- In the Linux kernel, the following vulnerability has been resolved: usb: roles: fix NULL pointer issue when put module's reference In current design, usb role class driver will get usb_role_switch parent's module reference after the user get usb_role_switch device and put the reference after the user put the usb_role_switch device. However, the parent device of usb_role_switch may be removed before the user put the usb_role_switch. If so, then, NULL pointer issue will be met when the user put the parent module's reference. This will save the module pointer in structure of usb_role_switch. Then, we don't need to find module by iterating long relations. (CVE-2024-26747)
- In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: fix memory double free when handle zero packet 829 if (request->complete) { 830 spin_unlock(&priv_dev->lock); 831 usb_gadget_giveback_request(&priv_ep->endpoint, 832 request); 833 spin_lock(&priv_dev->lock); 834 } 835 836 if (request->buf == priv_dev->zlp_buf) 837 cdns3_gadget_ep_free_request(&priv_ep->endpoint, request);
Driver append an additional zero packet request when queue a packet, which length mod max packet size is 0. When transfer complete, run to line 831, usb_gadget_giveback_request() will free this requestion. 836 condition is true, so cdns3_gadget_ep_free_request() free this request again. Log: [ 1920.140696][ T150] BUG: KFENCE: use-after-free read in cdns3_gadget_giveback+0x134/0x2c0 [cdns3] [ 1920.140696][ T150] [ 1920.151837][ T150] Use-after-free read at 0x000000003d1cd10b (in kfence-#36): [ 1920.159082][ T150] cdns3_gadget_giveback+0x134/0x2c0 [cdns3] [ 1920.164988][ T150] cdns3_transfer_completed+0x438/0x5f8 [cdns3] Add check at line 829, skip call usb_gadget_giveback_request() if it is additional zero length packet request. Needn't call usb_gadget_giveback_request() because it is allocated in this driver.
(CVE-2024-26748)
- In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: fixed memory use after free at cdns3_gadget_ep_disable() ... cdns3_gadget_ep_free_request(&priv_ep->endpoint, &priv_req->request); list_del_init(&priv_req->list); ... 'priv_req' actually free at cdns3_gadget_ep_free_request(). But list_del_init() use priv_req->list after it. [ 1542.642868][ T534] BUG: KFENCE: use-after-free read in __list_del_entry_valid+0x10/0xd4 [ 1542.642868][ T534] [ 1542.653162][ T534] Use-after-free read at 0x000000009ed0ba99 (in kfence-#3): [ 1542.660311][ T534]
__list_del_entry_valid+0x10/0xd4 [ 1542.665375][ T534] cdns3_gadget_ep_disable+0x1f8/0x388 [cdns3] [ 1542.671571][ T534] usb_ep_disable+0x44/0xe4 [ 1542.675948][ T534] ffs_func_eps_disable+0x64/0xc8 [ 1542.680839][ T534] ffs_func_set_alt+0x74/0x368 [ 1542.685478][ T534] ffs_func_disable+0x18/0x28 Move list_del_init() before cdns3_gadget_ep_free_request() to resolve this problem. (CVE-2024-26749)
- In the Linux kernel, the following vulnerability has been resolved: af_unix: Drop oob_skb ref before purging queue in GC. syzbot reported another task hung in __unix_gc(). [0] The current while loop assumes that all of the left candidates have oob_skb and calling kfree_skb(oob_skb) releases the remaining candidates. However, I missed a case that oob_skb has self-referencing fd and another fd and the latter sk is placed before the former in the candidate list. Then, the while loop never proceeds, resulting the task hung. __unix_gc() has the same loop just before purging the collected skb, so we can call kfree_skb(oob_skb) there and let __skb_queue_purge() release all inflight sockets. [0]: Sending NMI from CPU 0 to CPUs 1: NMI backtrace for cpu 1 CPU: 1 PID: 2784 Comm: kworker/u4:8 Not tainted 6.8.0-rc4-syzkaller-01028-g71b605d32017 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Workqueue: events_unbound __unix_gc RIP:
0010:__sanitizer_cov_trace_pc+0x0/0x70 kernel/kcov.c:200 Code: 89 fb e8 23 00 00 00 48 8b 3d 84 f5 1a 0c 48 89 de 5b e9 43 26 57 00 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 <f3> 0f 1e fa 48 8b 04 24 65 48 8b 0d 90 52 70 7e 65 8b 15 91 52 70 RSP: 0018:ffffc9000a17fa78 EFLAGS: 00000287 RAX:
ffffffff8a0a6108 RBX: ffff88802b6c2640 RCX: ffff88802c0b3b80 RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000000 RBP: ffffc9000a17fbf0 R08: ffffffff89383f1d R09: 1ffff1100ee5ff84 R10:
dffffc0000000000 R11: ffffed100ee5ff85 R12: 1ffff110056d84ee R13: ffffc9000a17fae0 R14: 0000000000000000 R15: ffffffff8f47b840 FS: 0000000000000000(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffef5687ff8 CR3: 0000000029b34000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6:
00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <NMI> </NMI> <TASK> __unix_gc+0xe69/0xf40 net/unix/garbage.c:343 process_one_work kernel/workqueue.c:2633 [inline] process_scheduled_works+0x913/0x1420 kernel/workqueue.c:2706 worker_thread+0xa5f/0x1000 kernel/workqueue.c:2787 kthread+0x2ef/0x390 kernel/kthread.c:388 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242 </TASK> (CVE-2024-26750)
- In the Linux kernel, the following vulnerability has been resolved: ARM: ep93xx: Add terminator to gpiod_lookup_table Without the terminator, if a con_id is passed to gpio_find() that does not exist in the lookup table the function will not stop looping correctly, and eventually cause an oops. (CVE-2024-26751)
- In the Linux kernel, the following vulnerability has been resolved: l2tp: pass correct message length to ip6_append_data l2tp_ip6_sendmsg needs to avoid accounting for the transport header twice when splicing more data into an already partially-occupied skbuff. To manage this, we check whether the skbuff contains data using skb_queue_empty when deciding how much data to append using ip6_append_data. However, the code which performed the calculation was incorrect: ulen = len + skb_queue_empty(&sk->sk_write_queue) ? transhdrlen : 0; ...due to C operator precedence, this ends up setting ulen to transhdrlen for messages with a non-zero length, which results in corrupted packets on the wire. Add parentheses to correct the calculation in line with the original intent. (CVE-2024-26752)
- In the Linux kernel, the following vulnerability has been resolved: crypto: virtio/akcipher - Fix stack overflow on memcpy sizeof(struct virtio_crypto_akcipher_session_para) is less than sizeof(struct virtio_crypto_op_ctrl_req::u), copying more bytes from stack variable leads stack overflow. Clang reports this issue by commands: make -j CC=clang-14 mrproper >/dev/null 2>&1 make -j O=/tmp/crypto-build CC=clang-14 allmodconfig >/dev/null 2>&1 make -j O=/tmp/crypto-build W=1 CC=clang-14 drivers/crypto/virtio/ virtio_crypto_akcipher_algs.o (CVE-2024-26753)
- In the Linux kernel, the following vulnerability has been resolved: gtp: fix use-after-free and null-ptr- deref in gtp_genl_dump_pdp() The gtp_net_ops pernet operations structure for the subsystem must be registered before registering the generic netlink family. Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug: general protection fault, probably for non-canonical address 0xdffffc0000000002:
0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 1 PID: 5826 Comm: gtp Not tainted 6.8.0-rc3-std-def-alt1 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014 RIP: 0010:gtp_genl_dump_pdp+0x1be/0x800 [gtp] Code: c6 89 c6 e8 64 e9 86 df 58 45 85 f6 0f 85 4e 04 00 00 e8 c5 ee 86 df 48 8b 54 24 18 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 de 05 00 00 48 8b 44 24 18 4c 8b 30 4c 39 f0 74 RSP: 0018:ffff888014107220 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09:
0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff88800fcda588 R14: 0000000000000001 R15: 0000000000000000 FS: 00007f1be4eb05c0(0000) GS:ffff88806ce80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1be4e766cf CR3:
000000000c33e000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? show_regs+0x90/0xa0 ? die_addr+0x50/0xd0 ? exc_general_protection+0x148/0x220 ? asm_exc_general_protection+0x22/0x30 ? gtp_genl_dump_pdp+0x1be/0x800 [gtp] ? __alloc_skb+0x1dd/0x350 ? __pfx___alloc_skb+0x10/0x10 genl_dumpit+0x11d/0x230 netlink_dump+0x5b9/0xce0 ? lockdep_hardirqs_on_prepare+0x253/0x430 ?
__pfx_netlink_dump+0x10/0x10 ? kasan_save_track+0x10/0x40 ? __kasan_kmalloc+0x9b/0xa0 ? genl_start+0x675/0x970 __netlink_dump_start+0x6fc/0x9f0 genl_family_rcv_msg_dumpit+0x1bb/0x2d0 ?
__pfx_genl_family_rcv_msg_dumpit+0x10/0x10 ? genl_op_from_small+0x2a/0x440 ? cap_capable+0x1d0/0x240 ?
__pfx_genl_start+0x10/0x10 ? __pfx_genl_dumpit+0x10/0x10 ? __pfx_genl_done+0x10/0x10 ? security_capable+0x9d/0xe0 (CVE-2024-26754)
- In the Linux kernel, the following vulnerability has been resolved: mm/swap: fix race when skipping swapcache When skipping swapcache for SWP_SYNCHRONOUS_IO, if two or more threads swapin the same entry at the same time, they get different pages (A, B). Before one thread (T0) finishes the swapin and installs page (A) to the PTE, another thread (T1) could finish swapin of page (B), swap_free the entry, then swap out the possibly modified page reusing the same entry. It breaks the pte_same check in (T0) because PTE value is unchanged, causing ABA problem. Thread (T0) will install a stalled page (A) into the PTE and cause data corruption. One possible callstack is like this: CPU0 CPU1 ---- ---- do_swap_page() do_swap_page() with same entry <direct swapin path> <direct swapin path> <alloc page A> <alloc page B> swap_read_folio() <- read to page A swap_read_folio() <- read to page B <slow on later locks or interrupt> <finished swapin first> ... set_pte_at() swap_free() <- entry is free <write to page B, now page A stalled> <swap out page B to same swap entry> pte_same() <- Check pass, PTE seems unchanged, but page A is stalled! swap_free() <- page B content lost! set_pte_at() <- staled page A installed! And besides, for ZRAM, swap_free() allows the swap device to discard the entry content, so even if page (B) is not modified, if swap_read_folio() on CPU0 happens later than swap_free() on CPU1, it may also cause data loss. To fix this, reuse swapcache_prepare which will pin the swap entry using the cache flag, and allow only one thread to swap it in, also prevent any parallel code from putting the entry in the cache. Release the pin after PT unlocked. Racers just loop and wait since it's a rare and very short event. A schedule_timeout_uninterruptible(1) call is added to avoid repeated page faults wasting too much CPU, causing livelock or adding too much noise to perf statistics. A similar livelock issue was described in commit 029c4628b2eb (mm: swap: get rid of livelock in swapin readahead) Reproducer: This race issue can be triggered easily using a well constructed reproducer and patched brd (with a delay in read path) [1]:
With latest 6.8 mainline, race caused data loss can be observed easily: $ gcc -g -lpthread test-thread- swap-race.c && ./a.out Polulating 32MB of memory region... Keep swapping out... Starting round 0...
Spawning 65536 workers... 32746 workers spawned, wait for done... Round 0: Error on 0x5aa00, expected 32746, got 32743, 3 data loss! Round 0: Error on 0x395200, expected 32746, got 32743, 3 data loss! Round 0: Error on 0x3fd000, expected 32746, got 32737, 9 data loss! Round 0 Failed, 15 data loss! This reproducer spawns multiple threads sharing the same memory region using a small swap device. Every two threads updates mapped pages one by one in opposite direction trying to create a race, with one dedicated thread keep swapping out the data out using madvise. The reproducer created a reproduce rate of about once every 5 minutes, so the race should be totally possible in production. After this patch, I ran the reproducer for over a few hundred rounds and no data loss observed. Performance overhead is minimal, microbenchmark swapin 10G from 32G zram: Before: 10934698 us After: 11157121 us Cached: 13155355 us (Dropping SWP_SYNCHRONOUS_IO flag) [[email protected]: v4] Link:
https://lkml.kernel.org/r/[email protected] (CVE-2024-26759)
- In the Linux kernel, the following vulnerability has been resolved: scsi: target: pscsi: Fix bio_put() for error case As of commit 066ff571011d (block: turn bio_kmalloc into a simple kmalloc wrapper), a bio allocated by bio_kmalloc() must be freed by bio_uninit() and kfree(). That is not done properly for the error case, hitting WARN and NULL pointer dereference in bio_free(). (CVE-2024-26760)
- In the Linux kernel, the following vulnerability has been resolved: cxl/pci: Fix disabling memory if DVSEC CXL Range does not match a CFMWS window The Linux CXL subsystem is built on the assumption that HPA == SPA. That is, the host physical address (HPA) the HDM decoder registers are programmed with are system physical addresses (SPA). During HDM decoder setup, the DVSEC CXL range registers (cxl-3.1, 8.1.3.8) are checked if the memory is enabled and the CXL range is in a HPA window that is described in a CFMWS structure of the CXL host bridge (cxl-3.1, 9.18.1.3). Now, if the HPA is not an SPA, the CXL range does not match a CFMWS window and the CXL memory range will be disabled then. The HDM decoder stops working which causes system memory being disabled and further a system hang during HDM decoder initialization, typically when a CXL enabled kernel boots. Prevent a system hang and do not disable the HDM decoder if the decoder's CXL range is not found in a CFMWS window. Note the change only fixes a hardware hang, but does not implement HPA/SPA translation. Support for this can be added in a follow on patch series.
(CVE-2024-26761)
- In the Linux kernel, the following vulnerability has been resolved: dm-crypt: don't modify the data when using authenticated encryption It was said that authenticated encryption could produce invalid tag when the data that is being encrypted is modified [1]. So, fix this problem by copying the data into the clone bio first and then encrypt them inside the clone bio. This may reduce performance, but it is needed to prevent the user from corrupting the device by writing data with O_DIRECT and modifying them at the same time. [1] https://lore.kernel.org/all/[email protected]/T/ (CVE-2024-26763)
- In the Linux kernel, the following vulnerability has been resolved: fs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via libaio If kiocb_set_cancel_fn() is called for I/O submitted via io_uring, the following kernel warning appears: WARNING: CPU: 3 PID: 368 at fs/aio.c:598 kiocb_set_cancel_fn+0x9c/0xa8 Call trace: kiocb_set_cancel_fn+0x9c/0xa8 ffs_epfile_read_iter+0x144/0x1d0 io_read+0x19c/0x498 io_issue_sqe+0x118/0x27c io_submit_sqes+0x25c/0x5fc __arm64_sys_io_uring_enter+0x104/0xab0 invoke_syscall+0x58/0x11c el0_svc_common+0xb4/0xf4 do_el0_svc+0x2c/0xb0 el0_svc+0x2c/0xa4 el0t_64_sync_handler+0x68/0xb4 el0t_64_sync+0x1a4/0x1a8 Fix this by setting the IOCB_AIO_RW flag for read and write I/O that is submitted by libaio. (CVE-2024-26764)
- In the Linux kernel, the following vulnerability has been resolved: LoongArch: Disable IRQ before init_fn() for nonboot CPUs Disable IRQ before init_fn() for nonboot CPUs when hotplug, in order to silence such warnings (and also avoid potential errors due to unexpected interrupts): WARNING: CPU: 1 PID: 0 at kernel/rcu/tree.c:4503 rcu_cpu_starting+0x214/0x280 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.17+ #1198 pc 90000000048e3334 ra 90000000047bd56c tp 900000010039c000 sp 900000010039fdd0 a0 0000000000000001 a1 0000000000000006 a2 900000000802c040 a3 0000000000000000 a4 0000000000000001 a5 0000000000000004 a6 0000000000000000 a7 90000000048e3f4c t0 0000000000000001 t1 9000000005c70968 t2 0000000004000000 t3 000000000005e56e t4 00000000000002e4 t5 0000000000001000 t6 ffffffff80000000 t7 0000000000040000 t8 9000000007931638 u0 0000000000000006 s9 0000000000000004 s0 0000000000000001 s1 9000000006356ac0 s2 9000000007244000 s3 0000000000000001 s4 0000000000000001 s5 900000000636f000 s6 7fffffffffffffff s7 9000000002123940 s8 9000000001ca55f8 ra: 90000000047bd56c tlb_init+0x24c/0x528 ERA: 90000000048e3334 rcu_cpu_starting+0x214/0x280 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 00000000 (PPLV0
-PIE -PWE) EUEN: 00000000 (-FPE -SXE -ASXE -BTE) ECFG: 00071000 (LIE=12 VS=7) ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0) PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.17+ #1198 Stack : 0000000000000000 9000000006375000 9000000005b61878 900000010039c000 900000010039fa30 0000000000000000 900000010039fa38 900000000619a140 9000000006456888 9000000006456880 900000010039f950 0000000000000001 0000000000000001 cb0cb028ec7e52e1 0000000002b90000 9000000100348700 0000000000000000 0000000000000001 ffffffff916d12f1 0000000000000003 0000000000040000 9000000007930370 0000000002b90000 0000000000000004 9000000006366000 900000000619a140 0000000000000000 0000000000000004 0000000000000000 0000000000000009 ffffffffffc681f2 9000000002123940 9000000001ca55f8 9000000006366000 90000000047a4828 00007ffff057ded8 00000000000000b0 0000000000000000 0000000000000000 0000000000071000 ...
Call Trace: [<90000000047a4828>] show_stack+0x48/0x1a0 [<9000000005b61874>] dump_stack_lvl+0x84/0xcc [<90000000047f60ac>] __warn+0x8c/0x1e0 [<9000000005b0ab34>] report_bug+0x1b4/0x280 [<9000000005b63110>] do_bp+0x2d0/0x480 [<90000000047a2e20>] handle_bp+0x120/0x1c0 [<90000000048e3334>] rcu_cpu_starting+0x214/0x280 [<90000000047bd568>] tlb_init+0x248/0x528 [<90000000047a4c44>] per_cpu_trap_init+0x124/0x160 [<90000000047a19f4>] cpu_probe+0x494/0xa00 [<90000000047b551c>] start_secondary+0x3c/0xc0 [<9000000005b66134>] smpboot_entry+0x50/0x58 (CVE-2024-26765)
- In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Fix sdma.h tx->num_descs off- by-one error Unfortunately the commit `fd8958efe877` introduced another error causing the `descs` array to overflow. This reults in further crashes easily reproducible by `sendmsg` system call. [ 1080.836473] general protection fault, probably for non-canonical address 0x400300015528b00a: 0000 [#1] PREEMPT SMP PTI [ 1080.869326] RIP: 0010:hfi1_ipoib_build_ib_tx_headers.constprop.0+0xe1/0x2b0 [hfi1] -- [ 1080.974535] Call Trace: [ 1080.976990] <TASK> [ 1081.021929] hfi1_ipoib_send_dma_common+0x7a/0x2e0 [hfi1] [ 1081.027364] hfi1_ipoib_send_dma_list+0x62/0x270 [hfi1] [ 1081.032633] hfi1_ipoib_send+0x112/0x300 [hfi1] [ 1081.042001] ipoib_start_xmit+0x2a9/0x2d0 [ib_ipoib] [ 1081.046978] dev_hard_start_xmit+0xc4/0x210 -- [ 1081.148347] __sys_sendmsg+0x59/0xa0 crash> ipoib_txreq 0xffff9cfeba229f00 struct ipoib_txreq { txreq = { list = { next = 0xffff9cfeba229f00, prev = 0xffff9cfeba229f00 }, descp = 0xffff9cfeba229f40, coalesce_buf = 0x0, wait = 0xffff9cfea4e69a48, complete = 0xffffffffc0fe0760 <hfi1_ipoib_sdma_complete>, packet_len = 0x46d, tlen = 0x0, num_desc = 0x0, desc_limit = 0x6, next_descq_idx = 0x45c, coalesce_idx = 0x0, flags = 0x0, descs = {{ qw = {0x8024000120dffb00, 0x4} # SDMA_DESC0_FIRST_DESC_FLAG (bit 63) }, { qw = { 0x3800014231b108, 0x4} }, { qw = { 0x310000e4ee0fcf0, 0x8} }, { qw = { 0x3000012e9f8000, 0x8} }, { qw = { 0x59000dfb9d0000, 0x8} }, { qw = { 0x78000e02e40000, 0x8} }} }, sdma_hdr = 0x400300015528b000, <<< invalid pointer in the tx request structure sdma_status = 0x0, SDMA_DESC0_LAST_DESC_FLAG (bit 62) complete = 0x0, priv = 0x0, txq = 0xffff9cfea4e69880, skb = 0xffff9d099809f400 } If an SDMA send consists of exactly 6 descriptors and requires dword padding (in the 7th descriptor), the sdma_txreq descriptor array is not properly expanded and the packet will overflow into the container structure. This results in a panic when the send completion runs. The exact panic varies depending on what elements of the container structure get corrupted. The fix is to use the correct expression in _pad_sdma_tx_descs() to test the need to expand the descriptor array. With this patch the crashes are no longer reproducible and the machine is stable.
(CVE-2024-26766)
- In the Linux kernel, the following vulnerability has been resolved: nvmet-fc: avoid deadlock on delete association path When deleting an association the shutdown path is deadlocking because we try to flush the nvmet_wq nested. Avoid this by deadlock by deferring the put work into its own work item. (CVE-2024-26769)
- In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: edma: Add some null pointer checks to the edma_probe devm_kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity.
(CVE-2024-26771)
- In the Linux kernel, the following vulnerability has been resolved: ext4: avoid allocating blocks from corrupted group in ext4_mb_find_by_goal() Places the logic for checking if the group's block bitmap is corrupt under the protection of the group lock to avoid allocating blocks from the group with a corrupted block bitmap. (CVE-2024-26772)
- In the Linux kernel, the following vulnerability has been resolved: ext4: avoid allocating blocks from corrupted group in ext4_mb_try_best_found() Determine if the group block bitmap is corrupted before using ac_b_ex in ext4_mb_try_best_found() to avoid allocating blocks from a group with a corrupted block bitmap in the following concurrency and making the situation worse. ext4_mb_regular_allocator ext4_lock_group(sb, group) ext4_mb_good_group // check if the group bbitmap is corrupted ext4_mb_complex_scan_group // Scan group gets ac_b_ex but doesn't use it ext4_unlock_group(sb, group) ext4_mark_group_bitmap_corrupted(group) // The block bitmap was corrupted during // the group unlock gap. ext4_mb_try_best_found ext4_lock_group(ac->ac_sb, group) ext4_mb_use_best_found mb_mark_used // Allocating blocks in block bitmap corrupted group (CVE-2024-26773)
- In the Linux kernel, the following vulnerability has been resolved: ext4: avoid dividing by 0 in mb_update_avg_fragment_size() when block bitmap corrupt Determine if bb_fragments is 0 instead of determining bb_free to eliminate the risk of dividing by zero when the block bitmap is corrupted.
(CVE-2024-26774)
- In the Linux kernel, the following vulnerability has been resolved: aoe: avoid potential deadlock at set_capacity Move set_capacity() outside of the section procected by (&d->lock). To avoid possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- [1] lock(&bdev->bd_size_lock); local_irq_disable();
[2] lock(&d->lock); [3] lock(&bdev->bd_size_lock); <Interrupt> [4] lock(&d->lock); *** DEADLOCK *** Where [1](&bdev->bd_size_lock) hold by zram_add()->set_capacity(). [2]lock(&d->lock) hold by aoeblk_gdalloc().
And aoeblk_gdalloc() is trying to acquire [3](&bdev->bd_size_lock) at set_capacity() call. In this situation an attempt to acquire [4]lock(&d->lock) from aoecmd_cfg_rsp() will lead to deadlock. So the simplest solution is breaking lock dependency [2](&d->lock) -> [3](&bdev->bd_size_lock) by moving set_capacity() outside. (CVE-2024-26775)
- In the Linux kernel, the following vulnerability has been resolved: spi: hisi-sfc-v3xx: Return IRQ_NONE if no interrupts were detected Return IRQ_NONE from the interrupt handler when no interrupt was detected.
Because an empty interrupt will cause a null pointer error: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 Call trace: complete+0x54/0x100 hisi_sfc_v3xx_isr+0x2c/0x40 [spi_hisi_sfc_v3xx] __handle_irq_event_percpu+0x64/0x1e0 handle_irq_event+0x7c/0x1cc (CVE-2024-26776)
- In the Linux kernel, the following vulnerability has been resolved: fbdev: sis: Error out if pixclock equals zero The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of pixclock, it may cause divide-by-zero error. In sisfb_check_var(), var->pixclock is used as a divisor to caculate drate before it is checked against zero. Fix this by checking it at the beginning. This is similar to CVE-2022-3061 in i740fb which was fixed by commit 15cf0b8. (CVE-2024-26777)
- In the Linux kernel, the following vulnerability has been resolved: fbdev: savage: Error out if pixclock equals zero The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of pixclock, it may cause divide-by-zero error. Although pixclock is checked in savagefb_decode_var(), but it is not checked properly in savagefb_probe(). Fix this by checking whether pixclock is zero in the function savagefb_check_var() before info->var.pixclock is used as the divisor. This is similar to CVE-2022-3061 in i740fb which was fixed by commit 15cf0b8. (CVE-2024-26778)
- In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix race condition on enabling fast-xmit fast-xmit must only be enabled after the sta has been uploaded to the driver, otherwise it could end up passing the not-yet-uploaded sta via drv_tx calls to the driver, leading to potential crashes because of uninitialized drv_priv data. Add a missing sta->uploaded check and re-check fast xmit after inserting a sta. (CVE-2024-26779)
- In the Linux kernel, the following vulnerability has been resolved: af_unix: Fix task hung while purging oob_skb in GC. syzbot reported a task hung; at the same time, GC was looping infinitely in list_for_each_entry_safe() for OOB skb. [0] syzbot demonstrated that the list_for_each_entry_safe() was not actually safe in this case. A single skb could have references for multiple sockets. If we free such a skb in the list_for_each_entry_safe(), the current and next sockets could be unlinked in a single iteration. unix_notinflight() uses list_del_init() to unlink the socket, so the prefetched next socket forms a loop itself and list_for_each_entry_safe() never stops. Here, we must use while() and make sure we always fetch the first socket. [0]: Sending NMI from CPU 0 to CPUs 1: NMI backtrace for cpu 1 CPU: 1 PID:
5065 Comm: syz-executor236 Not tainted 6.8.0-rc3-syzkaller-00136-g1f719a2f3fa6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 RIP: 0010:preempt_count arch/x86/include/asm/preempt.h:26 [inline] RIP: 0010:check_kcov_mode kernel/kcov.c:173 [inline] RIP:
0010:__sanitizer_cov_trace_pc+0xd/0x60 kernel/kcov.c:207 Code: cc cc cc cc 66 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 65 48 8b 14 25 40 c2 03 00 <65> 8b 05 b4 7c 78 7e a9 00 01 ff 00 48 8b 34 24 74 0f f6 c4 01 74 RSP: 0018:ffffc900033efa58 EFLAGS: 00000283 RAX:
ffff88807b077800 RBX: ffff88807b077800 RCX: 1ffffffff27b1189 RDX: ffff88802a5a3b80 RSI: ffffffff8968488d RDI: ffff88807b077f70 RBP: ffffc900033efbb0 R08: 0000000000000001 R09: fffffbfff27a900c R10:
ffffffff93d48067 R11: ffffffff8ae000eb R12: ffff88807b077800 R13: dffffc0000000000 R14: ffff88807b077e40 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000564f4fc1e3a8 CR3: 000000000d57a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6:
00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <NMI> </NMI> <TASK> unix_gc+0x563/0x13b0 net/unix/garbage.c:319 unix_release_sock+0xa93/0xf80 net/unix/af_unix.c:683 unix_release+0x91/0xf0 net/unix/af_unix.c:1064 __sock_release+0xb0/0x270 net/socket.c:659 sock_close+0x1c/0x30 net/socket.c:1421
__fput+0x270/0xb80 fs/file_table.c:376 task_work_run+0x14f/0x250 kernel/task_work.c:180 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0xa8a/0x2ad0 kernel/exit.c:871 do_group_exit+0xd4/0x2a0 kernel/exit.c:1020 __do_sys_exit_group kernel/exit.c:1031 [inline] __se_sys_exit_group kernel/exit.c:1029 [inline] __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:1029 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd5/0x270 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP:
0033:0x7f9d6cbdac09 Code: Unable to access opcode bytes at 0x7f9d6cbdabdf. RSP: 002b:00007fff5952feb8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX:
00007f9d6cbdac09 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000 RBP: 00007f9d6cc552b0 R08: ffffffffffffffb8 R09: 0000000000000006 R10: 0000000000000006 R11: 0000000000000246 R12:
00007f9d6cc552b0 R13: 0000000000000000 R14: 00007f9d6cc55d00 R15: 00007f9d6cbabe70 </TASK> (CVE-2024-26780)
- In the Linux kernel, the following vulnerability has been resolved: mptcp: fix possible deadlock in subflow diag Syzbot and Eric reported a lockdep splat in the subflow diag: WARNING: possible circular locking dependency detected 6.8.0-rc4-syzkaller-00212-g40b9385dd8e6 #0 Not tainted syz-executor.2/24141 is trying to acquire lock: ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at: tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline] ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at:
tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137 but task is already holding lock: ffffc9000135e488 (&h->lhash2[i].lock){+.+.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffffc9000135e488 (&h->lhash2[i].lock){+.+.}-{2:2}, at: inet_diag_dump_icsk+0x39f/0x1f80 net/ipv4/inet_diag.c:1038 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&h->lhash2[i].lock){+.+.}-{2:2}: lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] __inet_hash+0x335/0xbe0 net/ipv4/inet_hashtables.c:743 inet_csk_listen_start+0x23a/0x320 net/ipv4/inet_connection_sock.c:1261 __inet_listen_sk+0x2a2/0x770 net/ipv4/af_inet.c:217 inet_listen+0xa3/0x110 net/ipv4/af_inet.c:239 rds_tcp_listen_init+0x3fd/0x5a0 net/rds/tcp_listen.c:316 rds_tcp_init_net+0x141/0x320 net/rds/tcp.c:577 ops_init+0x352/0x610 net/core/net_namespace.c:136 __register_pernet_operations net/core/net_namespace.c:1214 [inline] register_pernet_operations+0x2cb/0x660 net/core/net_namespace.c:1283 register_pernet_device+0x33/0x80 net/core/net_namespace.c:1370 rds_tcp_init+0x62/0xd0 net/rds/tcp.c:735 do_one_initcall+0x238/0x830 init/main.c:1236 do_initcall_level+0x157/0x210 init/main.c:1298 do_initcalls+0x3f/0x80 init/main.c:1314 kernel_init_freeable+0x42f/0x5d0 init/main.c:1551 kernel_init+0x1d/0x2a0 init/main.c:1441 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242 -> #0 (k-sk_lock-AF_INET6){+.+.}-{0:0}: check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x18ca/0x58e0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 lock_sock_fast include/net/sock.h:1723 [inline] subflow_get_info+0x166/0xd20 net/mptcp/diag.c:28 tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline] tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137 inet_sk_diag_fill+0x10ed/0x1e00 net/ipv4/inet_diag.c:345 inet_diag_dump_icsk+0x55b/0x1f80 net/ipv4/inet_diag.c:1061 __inet_diag_dump+0x211/0x3a0 net/ipv4/inet_diag.c:1263 inet_diag_dump_compat+0x1c1/0x2d0 net/ipv4/inet_diag.c:1371 netlink_dump+0x59b/0xc80 net/netlink/af_netlink.c:2264 __netlink_dump_start+0x5df/0x790 net/netlink/af_netlink.c:2370 netlink_dump_start include/linux/netlink.h:338 [inline] inet_diag_rcv_msg_compat+0x209/0x4c0 net/ipv4/inet_diag.c:1405 sock_diag_rcv_msg+0xe7/0x410 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543 sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:280 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 As noted by Eric we can break the lock dependency chain avoid dumping ---truncated--- (CVE-2024-26781)
- In the Linux kernel, the following vulnerability has been resolved: mptcp: fix double-free on socket dismantle when MPTCP server accepts an incoming connection, it clones its listener socket. However, the pointer to 'inet_opt' for the new socket has the same value as the original one: as a consequence, on program exit it's possible to observe the following splat: BUG: KASAN: double-free in inet_sock_destruct+0x54f/0x8b0 Free of addr ffff888485950880 by task swapper/25/0 CPU: 25 PID: 0 Comm:
swapper/25 Kdump: loaded Not tainted 6.8.0-rc1+ #609 Hardware name: Supermicro SYS-6027R-72RF/X9DRH-7TF/7F/iTF/iF, BIOS 3.0 07/26/2013 Call Trace: <IRQ> dump_stack_lvl+0x32/0x50 print_report+0xca/0x620 kasan_report_invalid_free+0x64/0x90 __kasan_slab_free+0x1aa/0x1f0 kfree+0xed/0x2e0 inet_sock_destruct+0x54f/0x8b0 __sk_destruct+0x48/0x5b0 rcu_do_batch+0x34e/0xd90 rcu_core+0x559/0xac0
__do_softirq+0x183/0x5a4 irq_exit_rcu+0x12d/0x170 sysvec_apic_timer_interrupt+0x6b/0x80 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x16/0x20 RIP: 0010:cpuidle_enter_state+0x175/0x300 Code: 30 00 0f 84 1f 01 00 00 83 e8 01 83 f8 ff 75 e5 48 83 c4 18 44 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc fb 45 85 ed <0f> 89 60 ff ff ff 48 c1 e5 06 48 c7 43 18 00 00 00 00 48 83 44 2b RSP: 0018:ffff888481cf7d90 EFLAGS: 00000202 RAX: 0000000000000000 RBX: ffff88887facddc8 RCX: 0000000000000000 RDX: 1ffff1110ff588b1 RSI: 0000000000000019 RDI: ffff88887fac4588 RBP: 0000000000000004 R08: 0000000000000002 R09:
0000000000043080 R10: 0009b02ea273363f R11: ffff88887fabf42b R12: ffffffff932592e0 R13: 0000000000000004 R14: 0000000000000000 R15: 00000022c880ec80 cpuidle_enter+0x4a/0xa0 do_idle+0x310/0x410 cpu_startup_entry+0x51/0x60 start_secondary+0x211/0x270 secondary_startup_64_no_verify+0x184/0x18b </TASK> Allocated by task 6853: kasan_save_stack+0x1c/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0xa6/0xb0
__kmalloc+0x1eb/0x450 cipso_v4_sock_setattr+0x96/0x360 netlbl_sock_setattr+0x132/0x1f0 selinux_netlbl_socket_post_create+0x6c/0x110 selinux_socket_post_create+0x37b/0x7f0 security_socket_post_create+0x63/0xb0 __sock_create+0x305/0x450 __sys_socket_create.part.23+0xbd/0x130
__sys_socket+0x37/0xb0 __x64_sys_socket+0x6f/0xb0 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Freed by task 6858: kasan_save_stack+0x1c/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x12c/0x1f0 kfree+0xed/0x2e0 inet_sock_destruct+0x54f/0x8b0 __sk_destruct+0x48/0x5b0 subflow_ulp_release+0x1f0/0x250 tcp_cleanup_ulp+0x6e/0x110 tcp_v4_destroy_sock+0x5a/0x3a0 inet_csk_destroy_sock+0x135/0x390 tcp_fin+0x416/0x5c0 tcp_data_queue+0x1bc8/0x4310 tcp_rcv_state_process+0x15a3/0x47b0 tcp_v4_do_rcv+0x2c1/0x990 tcp_v4_rcv+0x41fb/0x5ed0 ip_protocol_deliver_rcu+0x6d/0x9f0 ip_local_deliver_finish+0x278/0x360 ip_local_deliver+0x182/0x2c0 ip_rcv+0xb5/0x1c0
__netif_receive_skb_one_core+0x16e/0x1b0 process_backlog+0x1e3/0x650 __napi_poll+0xa6/0x500 net_rx_action+0x740/0xbb0 __do_softirq+0x183/0x5a4 The buggy address belongs to the object at ffff888485950880 which belongs to the cache kmalloc-64 of size 64 The buggy address is located 0 bytes inside of 64-byte region [ffff888485950880, ffff8884859508c0) The buggy address belongs to the physical page: page:0000000056d1e95e refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888485950700 pfn:0x485950 flags: 0x57ffffc0000800(slab|node=1|zone=2|lastcpupid=0x1fffff) page_type: 0xffffffff() raw:
0057ffffc0000800 ffff88810004c640 ffffea00121b8ac0 dead000000000006 raw: ffff888485950700 0000000000200019 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888485950780: fa fb fb ---truncated--- (CVE-2024-26782)
- In the Linux kernel, the following vulnerability has been resolved: mmc: mmci: stm32: fix DMA API overlapping mappings warning Turning on CONFIG_DMA_API_DEBUG_SG results in the following warning: DMA-API:
mmci-pl18x 48220000.mmc: cacheline tracking EEXIST, overlapping mappings aren't supported WARNING: CPU: 1 PID: 51 at kernel/dma/debug.c:568 add_dma_entry+0x234/0x2f4 Modules linked in: CPU: 1 PID: 51 Comm:
kworker/1:2 Not tainted 6.1.28 #1 Hardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT) Workqueue: events_freezable mmc_rescan Call trace: add_dma_entry+0x234/0x2f4 debug_dma_map_sg+0x198/0x350
__dma_map_sg_attrs+0xa0/0x110 dma_map_sg_attrs+0x10/0x2c sdmmc_idma_prep_data+0x80/0xc0 mmci_prep_data+0x38/0x84 mmci_start_data+0x108/0x2dc mmci_request+0xe4/0x190
__mmc_start_request+0x68/0x140 mmc_start_request+0x94/0xc0 mmc_wait_for_req+0x70/0x100 mmc_send_tuning+0x108/0x1ac sdmmc_execute_tuning+0x14c/0x210 mmc_execute_tuning+0x48/0xec mmc_sd_init_uhs_card.part.0+0x208/0x464 mmc_sd_init_card+0x318/0x89c mmc_attach_sd+0xe4/0x180 mmc_rescan+0x244/0x320 DMA API debug brings to light leaking dma-mappings as dma_map_sg and dma_unmap_sg are not correctly balanced. If an error occurs in mmci_cmd_irq function, only mmci_dma_error function is called and as this API is not managed on stm32 variant, dma_unmap_sg is never called in this error path.
(CVE-2024-26787)
- In the Linux kernel, the following vulnerability has been resolved: dmaengine: fsl-qdma: init irq after reg initialization Initialize the qDMA irqs after the registers are configured so that interrupts that may have been pending from a primary kernel don't get processed by the irq handler before it is ready to and cause panic with the following trace: Call trace: fsl_qdma_queue_handler+0xf8/0x3e8
__handle_irq_event_percpu+0x78/0x2b0 handle_irq_event_percpu+0x1c/0x68 handle_irq_event+0x44/0x78 handle_fasteoi_irq+0xc8/0x178 generic_handle_irq+0x24/0x38 __handle_domain_irq+0x90/0x100 gic_handle_irq+0x5c/0xb8 el1_irq+0xb8/0x180 _raw_spin_unlock_irqrestore+0x14/0x40 __setup_irq+0x4bc/0x798 request_threaded_irq+0xd8/0x190 devm_request_threaded_irq+0x74/0xe8 fsl_qdma_probe+0x4d4/0xca8 platform_drv_probe+0x50/0xa0 really_probe+0xe0/0x3f8 driver_probe_device+0x64/0x130 device_driver_attach+0x6c/0x78 __driver_attach+0xbc/0x158 bus_for_each_dev+0x5c/0x98 driver_attach+0x20/0x28 bus_add_driver+0x158/0x220 driver_register+0x60/0x110
__platform_driver_register+0x44/0x50 fsl_qdma_driver_init+0x18/0x20 do_one_initcall+0x48/0x258 kernel_init_freeable+0x1a4/0x23c kernel_init+0x10/0xf8 ret_from_fork+0x10/0x18 (CVE-2024-26788)
- In the Linux kernel, the following vulnerability has been resolved: crypto: arm64/neonbs - fix out-of- bounds access on short input The bit-sliced implementation of AES-CTR operates on blocks of 128 bytes, and will fall back to the plain NEON version for tail blocks or inputs that are shorter than 128 bytes to begin with. It will call straight into the plain NEON asm helper, which performs all memory accesses in granules of 16 bytes (the size of a NEON register). For this reason, the associated plain NEON glue code will copy inputs shorter than 16 bytes into a temporary buffer, given that this is a rare occurrence and it is not worth the effort to work around this in the asm code. The fallback from the bit-sliced NEON version fails to take this into account, potentially resulting in out-of-bounds accesses. So clone the same workaround, and use a temp buffer for short in/outputs. (CVE-2024-26789)
- In the Linux kernel, the following vulnerability has been resolved: dmaengine: fsl-qdma: fix SoC may hang on 16 byte unaligned read There is chip (ls1028a) errata: The SoC may hang on 16 byte unaligned read transactions by QDMA. Unaligned read transactions initiated by QDMA may stall in the NOC (Network On- Chip), causing a deadlock condition. Stalled transactions will trigger completion timeouts in PCIe controller. Workaround: Enable prefetch by setting the source descriptor prefetchable bit ( SD[PF] = 1 ).
Implement this workaround. (CVE-2024-26790)
- In the Linux kernel, the following vulnerability has been resolved: btrfs: dev-replace: properly validate device names There's a syzbot report that device name buffers passed to device replace are not properly checked for string termination which could lead to a read out of bounds in getname_kernel(). Add a helper that validates both source and target device name buffers. For devid as the source initialize the buffer to empty string in case something tries to read it later. This was originally analyzed and fixed in a different way by Edward Adam Davis (see links). (CVE-2024-26791)
- In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of anonymous device after snapshot creation failure When creating a snapshot we may do a double free of an anonymous device in case there's an error committing the transaction. The second free may result in freeing an anonymous device number that was allocated by some other subsystem in the kernel or another btrfs filesystem. The steps that lead to this: 1) At ioctl.c:create_snapshot() we allocate an anonymous device number and assign it to pending_snapshot->anon_dev; 2) Then we call btrfs_commit_transaction() and end up at transaction.c:create_pending_snapshot(); 3) There we call btrfs_get_new_fs_root() and pass it the anonymous device number stored in pending_snapshot->anon_dev; 4) btrfs_get_new_fs_root() frees that anonymous device number because btrfs_lookup_fs_root() returned a root - someone else did a lookup of the new root already, which could some task doing backref walking; 5) After that some error happens in the transaction commit path, and at ioctl.c:create_snapshot() we jump to the 'fail' label, and after that we free again the same anonymous device number, which in the meanwhile may have been reallocated somewhere else, because pending_snapshot->anon_dev still has the same value as in step 1. Recently syzbot ran into this and reported the following trace: ------------[ cut here ]------------ ida_free called for id=51 which is not allocated. WARNING: CPU: 1 PID: 31038 at lib/idr.c:525 ida_free+0x370/0x420 lib/idr.c:525 Modules linked in: CPU: 1 PID: 31038 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-00410-gc02197fc9076 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 RIP: 0010:ida_free+0x370/0x420 lib/idr.c:525 Code: 10 42 80 3c 28 (...) RSP: 0018:ffffc90015a67300 EFLAGS: 00010246 RAX: be5130472f5dd000 RBX: 0000000000000033 RCX:
0000000000040000 RDX: ffffc90009a7a000 RSI: 000000000003ffff RDI: 0000000000040000 RBP: ffffc90015a673f0 R08: ffffffff81577992 R09: 1ffff92002b4cdb4 R10: dffffc0000000000 R11: fffff52002b4cdb5 R12:
0000000000000246 R13: dffffc0000000000 R14: ffffffff8e256b80 R15: 0000000000000246 FS:
00007fca3f4b46c0(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033 CR2: 00007f167a17b978 CR3: 000000001ed26000 CR4: 0000000000350ef0 Call Trace: <TASK> btrfs_get_root_ref+0xa48/0xaf0 fs/btrfs/disk-io.c:1346 create_pending_snapshot+0xff2/0x2bc0 fs/btrfs/transaction.c:1837 create_pending_snapshots+0x195/0x1d0 fs/btrfs/transaction.c:1931 btrfs_commit_transaction+0xf1c/0x3740 fs/btrfs/transaction.c:2404 create_snapshot+0x507/0x880 fs/btrfs/ioctl.c:848 btrfs_mksubvol+0x5d0/0x750 fs/btrfs/ioctl.c:998 btrfs_mksnapshot+0xb5/0xf0 fs/btrfs/ioctl.c:1044 __btrfs_ioctl_snap_create+0x387/0x4b0 fs/btrfs/ioctl.c:1306 btrfs_ioctl_snap_create_v2+0x1ca/0x400 fs/btrfs/ioctl.c:1393 btrfs_ioctl+0xa74/0xd40 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:871 [inline] __se_sys_ioctl+0xfe/0x170 fs/ioctl.c:857 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7fca3e67dda9 Code: 28 00 00 00 (...) RSP: 002b:00007fca3f4b40c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX:
00007fca3e7abf80 RCX: 00007fca3e67dda9 RDX: 00000000200005c0 RSI: 0000000050009417 RDI: 0000000000000003 RBP: 00007fca3e6ca47a R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11:
0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007fca3e7abf80 R15: 00007fff6bf95658 </TASK> Where we get an explicit message where we attempt to free an anonymous device number that is not currently allocated. It happens in a different code path from the example below, at btrfs_get_root_ref(), so this change may not fix the case triggered by sy ---truncated--- (CVE-2024-26792)
- In the Linux kernel, the following vulnerability has been resolved: gtp: fix use-after-free and null-ptr- deref in gtp_newlink() The gtp_link_ops operations structure for the subsystem must be registered after registering the gtp_net_ops pernet operations structure. Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug: [ 1010.702740] gtp: GTP module unloaded [ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI [ 1010.715888] KASAN:
null-ptr-deref in range [0x0000000000000008-0x000000000000000f] [ 1010.715895] CPU: 1 PID: 128616 Comm:
a.out Not tainted 6.8.0-rc6-std-def-alt1 #1 [ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014 [ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp] [ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00 [ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203 [ 1010.715929] RAX: dffffc0000000000 RBX:
ffff88800399c000 RCX: 0000000000000000 [ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI:
0000000000000282 [ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000 [ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80 [ 1010.715947] R13:
0000000000000000 R14: 0000000000000000 R15: 0000000000000400 [ 1010.715953] FS: 00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000 [ 1010.715958] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033 [ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0 [ 1010.715968] PKRU: 55555554 [ 1010.715972] Call Trace: [ 1010.715985] ? __die_body.cold+0x1a/0x1f [ 1010.715995] ? die_addr+0x43/0x70 [ 1010.716002] ? exc_general_protection+0x199/0x2f0 [ 1010.716016] ? asm_exc_general_protection+0x1e/0x30 [ 1010.716026] ? gtp_newlink+0x4d7/0x9c0 [gtp] [ 1010.716034] ? gtp_net_exit+0x150/0x150 [gtp] [ 1010.716042] __rtnl_newlink+0x1063/0x1700 [ 1010.716051] ? rtnl_setlink+0x3c0/0x3c0 [ 1010.716063] ? is_bpf_text_address+0xc0/0x1f0 [ 1010.716070] ? kernel_text_address.part.0+0xbb/0xd0 [ 1010.716076] ? __kernel_text_address+0x56/0xa0 [ 1010.716084] ? unwind_get_return_address+0x5a/0xa0 [ 1010.716091] ? create_prof_cpu_mask+0x30/0x30 [ 1010.716098] ? arch_stack_walk+0x9e/0xf0 [ 1010.716106] ? stack_trace_save+0x91/0xd0 [ 1010.716113] ? stack_trace_consume_entry+0x170/0x170 [ 1010.716121] ? __lock_acquire+0x15c5/0x5380 [ 1010.716139] ? mark_held_locks+0x9e/0xe0 [ 1010.716148] ? kmem_cache_alloc_trace+0x35f/0x3c0 [ 1010.716155] ?
__rtnl_newlink+0x1700/0x1700 [ 1010.716160] rtnl_newlink+0x69/0xa0 [ 1010.716166] rtnetlink_rcv_msg+0x43b/0xc50 [ 1010.716172] ? rtnl_fdb_dump+0x9f0/0x9f0 [ 1010.716179] ? lock_acquire+0x1fe/0x560 [ 1010.716188] ? netlink_deliver_tap+0x12f/0xd50 [ 1010.716196] netlink_rcv_skb+0x14d/0x440 [ 1010.716202] ? rtnl_fdb_dump+0x9f0/0x9f0 [ 1010.716208] ? netlink_ack+0xab0/0xab0 [ 1010.716213] ? netlink_deliver_tap+0x202/0xd50 [ 1010.716220] ? netlink_deliver_tap+0x218/0xd50 [ 1010.716226] ? __virt_addr_valid+0x30b/0x590 [ 1010.716233] netlink_unicast+0x54b/0x800 [ 1010.716240] ? netlink_attachskb+0x870/0x870 [ 1010.716248] ?
__check_object_size+0x2de/0x3b0 [ 1010.716254] netlink_sendmsg+0x938/0xe40 [ 1010.716261] ? netlink_unicast+0x800/0x800 [ 1010.716269] ? __import_iovec+0x292/0x510 [ 1010.716276] ? netlink_unicast+0x800/0x800 [ 1010.716284] __sock_sendmsg+0x159/0x190 [ 1010.716290]
____sys_sendmsg+0x712/0x880 [ 1010.716297] ? sock_write_iter+0x3d0/0x3d0 [ 1010.716304] ?
__ia32_sys_recvmmsg+0x270/0x270 [ 1010.716309] ? lock_acquire+0x1fe/0x560 [ 1010.716315] ? drain_array_locked+0x90/0x90 [ 1010.716324] ___sys_sendmsg+0xf8/0x170 [ 1010.716331] ? sendmsg_copy_msghdr+0x170/0x170 [ 1010.716337] ? lockdep_init_map ---truncated--- (CVE-2024-26793)
- In the Linux kernel, the following vulnerability has been resolved: riscv: Sparse-Memory/vmemmap out-of- bounds fix Offset vmemmap so that the first page of vmemmap will be mapped to the first page of physical memory in order to ensure that vmemmap's bounds will be respected during pfn_to_page()/page_to_pfn() operations. The conversion macros will produce correct SV39/48/57 addresses for every possible/valid DRAM_BASE inside the physical memory limits. v2:Address Alex's comments (CVE-2024-26795)
- In the Linux kernel, the following vulnerability has been resolved: fbcon: always restore the old font data in fbcon_do_set_font() Commit a5a923038d70 (fbdev: fbcon: Properly revert changes when vc_resize() failed) started restoring old font data upon failure (of vc_resize()). But it performs so only for user fonts. It means that the system/internal fonts are not restored at all. So in result, the very first call to fbcon_do_set_font() performs no restore at all upon failing vc_resize(). This can be reproduced by Syzkaller to crash the system on the next invocation of font_get(). It's rather hard to hit the allocation failure in vc_resize() on the first font_set(), but not impossible. Esp. if fault injection is used to aid the execution/failure. It was demonstrated by Sirius: BUG: unable to handle page fault for address:
fffffffffffffff8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD cb7b067 P4D cb7b067 PUD cb7d067 PMD 0 Oops: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 8007 Comm: poc Not tainted 6.7.0-g9d1694dc91ce #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:fbcon_get_font+0x229/0x800 drivers/video/fbdev/core/fbcon.c:2286 Call Trace: <TASK> con_font_get drivers/tty/vt/vt.c:4558 [inline] con_font_op+0x1fc/0xf20 drivers/tty/vt/vt.c:4673 vt_k_ioctl drivers/tty/vt/vt_ioctl.c:474 [inline] vt_ioctl+0x632/0x2ec0 drivers/tty/vt/vt_ioctl.c:752 tty_ioctl+0x6f8/0x1570 drivers/tty/tty_io.c:2803 vfs_ioctl fs/ioctl.c:51 [inline] ... So restore the font data in any case, not only for user fonts. Note the later 'if' is now protected by 'old_userfont' and not 'old_data' as the latter is always set now. (And it is supposed to be non-NULL. Otherwise we would see the bug above again.) (CVE-2024-26798)
- In the Linux kernel, the following vulnerability has been resolved: tls: fix use-after-free on failed backlog decryption When the decrypt request goes to the backlog and crypto_aead_decrypt returns -EBUSY, tls_do_decryption will wait until all async decryptions have completed. If one of them fails, tls_do_decryption will return -EBADMSG and tls_decrypt_sg jumps to the error path, releasing all the pages. But the pages have been passed to the async callback, and have already been released by tls_decrypt_done. The only true async case is when crypto_aead_decrypt returns -EINPROGRESS. With -EBUSY, we already waited so we can tell tls_sw_recvmsg that the data is available for immediate copy, but we need to notify tls_decrypt_sg (via the new ->async_done flag) that the memory has already been released.
(CVE-2024-26800)
- In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Avoid potential use-after- free in hci_error_reset While handling the HCI_EV_HARDWARE_ERROR event, if the underlying BT controller is not responding, the GPIO reset mechanism would free the hci_dev and lead to a use-after-free in hci_error_reset. Here's the call trace observed on a ChromeOS device with Intel AX201:
queue_work_on+0x3e/0x6c __hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth <HASH:3b4a6>] ? init_wait_entry+0x31/0x31
__hci_cmd_sync+0x16/0x20 [bluetooth <HASH:3b4a 6>] hci_error_reset+0x4f/0xa4 [bluetooth <HASH:3b4a 6>] process_one_work+0x1d8/0x33f worker_thread+0x21b/0x373 kthread+0x13a/0x152 ? pr_cont_work+0x54/0x54 ? kthread_blkcg+0x31/0x31 ret_from_fork+0x1f/0x30 This patch holds the reference count on the hci_dev while processing a HCI_EV_HARDWARE_ERROR event to avoid potential crash. (CVE-2024-26801)
- In the Linux kernel, the following vulnerability has been resolved: stmmac: Clear variable when destroying workqueue Currently when suspending driver and stopping workqueue it is checked whether workqueue is not NULL and if so, it is destroyed. Function destroy_workqueue() does drain queue and does clear variable, but it does not set workqueue variable to NULL. This can cause kernel/module panic if code attempts to clear workqueue that was not initialized. This scenario is possible when resuming suspended driver in stmmac_resume(), because there is no handling for failed stmmac_hw_setup(), which can fail and return if DMA engine has failed to initialize, and workqueue is initialized after DMA engine. Should DMA engine fail to initialize, resume will proceed normally, but interface won't work and TX queue will eventually timeout, causing 'Reset adapter' error. This then does destroy workqueue during reset process. And since workqueue is initialized after DMA engine and can be skipped, it will cause kernel/module panic. To secure against this possible crash, set workqueue variable to NULL when destroying workqueue. Log/backtrace from crash goes as follows: [88.031977]------------[ cut here ]------------ [88.031985]NETDEV WATCHDOG: eth0 (sxgmac): transmit queue 1 timed out [88.032017]WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:477 dev_watchdog+0x390/0x398 <Skipping backtrace for watchdog timeout> [88.032251]---[ end trace e70de432e4d5c2c0 ]--- [88.032282]sxgmac 16d88000.ethernet eth0: Reset adapter. [88.036359]------------[ cut here ]------------ [88.036519]Call trace: [88.036523] flush_workqueue+0x3e4/0x430 [88.036528] drain_workqueue+0xc4/0x160 [88.036533] destroy_workqueue+0x40/0x270 [88.036537] stmmac_fpe_stop_wq+0x4c/0x70 [88.036541] stmmac_release+0x278/0x280 [88.036546]
__dev_close_many+0xcc/0x158 [88.036551] dev_close_many+0xbc/0x190 [88.036555] dev_close.part.0+0x70/0xc0 [88.036560] dev_close+0x24/0x30 [88.036564] stmmac_service_task+0x110/0x140 [88.036569] process_one_work+0x1d8/0x4a0 [88.036573] worker_thread+0x54/0x408 [88.036578] kthread+0x164/0x170 [88.036583] ret_from_fork+0x10/0x20 [88.036588]---[ end trace e70de432e4d5c2c1 ]--- [88.036597]Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 (CVE-2024-26802)
- In the Linux kernel, the following vulnerability has been resolved: net: veth: clear GRO when clearing XDP even when down veth sets NETIF_F_GRO automatically when XDP is enabled, because both features use the same NAPI machinery. The logic to clear NETIF_F_GRO sits in veth_disable_xdp() which is called both on ndo_stop and when XDP is turned off. To avoid the flag from being cleared when the device is brought down, the clearing is skipped when IFF_UP is not set. Bringing the device down should indeed not modify its features. Unfortunately, this means that clearing is also skipped when XDP is disabled _while_ the device is down. And there's nothing on the open path to bring the device features back into sync. IOW if user enables XDP, disables it and then brings the device up we'll end up with a stray GRO flag set but no NAPI instances. We don't depend on the GRO flag on the datapath, so the datapath won't crash. We will crash (or hang), however, next time features are sync'ed (either by user via ethtool or peer changing its config).
The GRO flag will go away, and veth will try to disable the NAPIs. But the open path never created them since XDP was off, the GRO flag was a stray. If NAPI was initialized before we'll hang in napi_disable().
If it never was we'll crash trying to stop uninitialized hrtimer. Move the GRO flag updates to the XDP enable / disable paths, instead of mixing them with the ndo_open / ndo_close paths. (CVE-2024-26803)
- In the Linux kernel, the following vulnerability has been resolved: net: ip_tunnel: prevent perpetual headroom growth syzkaller triggered following kasan splat: BUG: KASAN: use-after-free in
__skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191 [..] kasan_report+0xda/0x110 mm/kasan/report.c:588
__skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline] ___skb_get_hash net/core/flow_dissector.c:1791 [inline]
__skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856 skb_get_hash include/linux/skbuff.h:1556 [inline] ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748 ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308
__netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592 ... ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323 .. iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831 ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 ... The splat occurs because skb->data points past skb->head allocated area. This is because neigh layer does: __skb_pull(skb, skb_network_offset(skb)); ...
but skb_network_offset() returns a negative offset and __skb_pull() arg is unsigned. IOW, we skb->data gets adjusted by a huge value. The negative value is returned because skb->head and skb->data distance is more than 64k and skb->network_header (u16) has wrapped around. The bug is in the ip_tunnel infrastructure, which can cause dev->needed_headroom to increment ad infinitum. The syzkaller reproducer consists of packets getting routed via a gre tunnel, and route of gre encapsulated packets pointing at another (ipip) tunnel. The ipip encapsulation finds gre0 as next output device. This results in the following pattern: 1). First packet is to be sent out via gre0. Route lookup found an output device, ipip0. 2). ip_tunnel_xmit for gre0 bumps gre0->needed_headroom based on the future output device, rt.dev->needed_headroom (ipip0). 3). ip output / start_xmit moves skb on to ipip0. which runs the same code path again (xmit recursion). 4). Routing step for the post-gre0-encap packet finds gre0 as output device to use for ipip0 encapsulated packet. tunl0->needed_headroom is then incremented based on the (already bumped) gre0 device headroom. This repeats for every future packet: gre0->needed_headroom gets inflated because previous packets' ipip0 step incremented rt->dev (gre0) headroom, and ipip0 incremented because gre0 needed_headroom was increased. For each subsequent packet, gre/ipip0->needed_headroom grows until post-expand-head reallocations result in a skb->head/data distance of more than 64k. Once that happens, skb->network_header (u16) wraps around when pskb_expand_head tries to make sure that skb_network_offset() is unchanged after the headroom expansion/reallocation. After this skb_network_offset(skb) returns a different (and negative) result post headroom expansion. The next trip to neigh layer (or anything else that would __skb_pull the network header) makes skb->data point to a memory location outside skb->head area. v2: Cap the needed_headroom update to an arbitarily chosen upperlimit to prevent perpetual increase instead of dropping the headroom increment completely.
(CVE-2024-26804)
- In the Linux kernel, the following vulnerability has been resolved: netlink: Fix kernel-infoleak-after- free in __skb_datagram_iter syzbot reported the following uninit-value access issue [1]:
netlink_to_full_skb() creates a new `skb` and puts the `skb->data` passed as a 1st arg of netlink_to_full_skb() onto new `skb`. The data size is specified as `len` and passed to skb_put_data().
This `len` is based on `skb->end` that is not data offset but buffer offset. The `skb->end` contains data and tailroom. Since the tailroom is not initialized when the new `skb` created, KMSAN detects uninitialized memory area when copying the data. This patch resolved this issue by correct the len from `skb->end` to `skb->len`, which is the actual data offset. BUG: KMSAN: kernel-infoleak-after-free in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak-after-free in copy_to_user_iter lib/iov_iter.c:24 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_ubuf include/linux/iov_iter.h:29 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance2 include/linux/iov_iter.h:245 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance include/linux/iov_iter.h:271 [inline] BUG: KMSAN: kernel-infoleak-after-free in _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 instrument_copy_to_user include/linux/instrumented.h:114 [inline] copy_to_user_iter lib/iov_iter.c:24 [inline] iterate_ubuf include/linux/iov_iter.h:29 [inline] iterate_and_advance2 include/linux/iov_iter.h:245 [inline] iterate_and_advance include/linux/iov_iter.h:271 [inline]
_copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 copy_to_iter include/linux/uio.h:197 [inline] simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:532 __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:420 skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546 skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline] packet_recvmsg+0xd9c/0x2000 net/packet/af_packet.c:3482 sock_recvmsg_nosec net/socket.c:1044 [inline] sock_recvmsg net/socket.c:1066 [inline] sock_read_iter+0x467/0x580 net/socket.c:1136 call_read_iter include/linux/fs.h:2014 [inline] new_sync_read fs/read_write.c:389 [inline] vfs_read+0x8f6/0xe00 fs/read_write.c:470 ksys_read+0x20f/0x4c0 fs/read_write.c:613 __do_sys_read fs/read_write.c:623 [inline] __se_sys_read fs/read_write.c:621 [inline]
__x64_sys_read+0x93/0xd0 fs/read_write.c:621 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was stored to memory at: skb_put_data include/linux/skbuff.h:2622 [inline] netlink_to_full_skb net/netlink/af_netlink.c:181 [inline] __netlink_deliver_tap_skb net/netlink/af_netlink.c:298 [inline]
__netlink_deliver_tap+0x5be/0xc90 net/netlink/af_netlink.c:325 netlink_deliver_tap net/netlink/af_netlink.c:338 [inline] netlink_deliver_tap_kernel net/netlink/af_netlink.c:347 [inline] netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x10f1/0x1250 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline]
____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: free_pages_prepare mm/page_alloc.c:1087 [inline] free_unref_page_prepare+0xb0/0xa40 mm/page_alloc.c:2347 free_unref_page_list+0xeb/0x1100 mm/page_alloc.c:2533 release_pages+0x23d3/0x2410 mm/swap.c:1042 free_pages_and_swap_cache+0xd9/0xf0 mm/swap_state.c:316 tlb_batch_pages ---truncated--- (CVE-2024-26805)
- In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: release elements in clone only from destroy path Clone already always provides a current view of the lookup table, use it to destroy the set, otherwise it is possible to destroy elements twice. This fix requires:
212ed75dc5fb (netfilter: nf_tables: integrate pipapo into commit protocol) which came after:
9827a0e6e23b (netfilter: nft_set_pipapo: release elements in clone from abort path). (CVE-2024-26809)
- In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Lock external INTx masking ops Mask operations through config space changes to DisINTx may race INTx configuration changes via ioctl.
Create wrappers that add locking for paths outside of the core interrupt code. In particular, irq_type is updated holding igate, therefore testing is_intx() requires holding igate. For example clearing DisINTx from config space can otherwise race changes of the interrupt configuration. This aligns interfaces which may trigger the INTx eventfd into two camps, one side serialized by igate and the other only enabled while INTx is configured. A subsequent patch introduces synchronization for the latter flows. (CVE-2024-26810)
- In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate payload size in ipc response If installing malicious ksmbd-tools, ksmbd.mountd can return invalid ipc response to ksmbd kernel server. ksmbd should validate payload size of ipc response from ksmbd.mountd to avoid memory overrun or slab-out-of-bounds. This patch validate 3 ipc response that has payload. (CVE-2024-26811)
- In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Create persistent INTx handler A vulnerability exists where the eventfd for INTx signaling can be deconfigured, which unregisters the IRQ handler but still allows eventfds to be signaled with a NULL context through the SET_IRQS ioctl or through unmask irqfd if the device interrupt is pending. Ideally this could be solved with some additional locking; the igate mutex serializes the ioctl and config space accesses, and the interrupt handler is unregistered relative to the trigger, but the irqfd path runs asynchronous to those. The igate mutex cannot be acquired from the atomic context of the eventfd wake function. Disabling the irqfd relative to the eventfd registration is potentially incompatible with existing userspace. As a result, the solution implemented here moves configuration of the INTx interrupt handler to track the lifetime of the INTx context object and irq_type configuration, rather than registration of a particular trigger eventfd.
Synchronization is added between the ioctl path and eventfd_signal() wrapper such that the eventfd trigger can be dynamically updated relative to in-flight interrupts or irqfd callbacks. (CVE-2024-26812)
- In the Linux kernel, the following vulnerability has been resolved: vfio/platform: Create persistent IRQ handlers The vfio-platform SET_IRQS ioctl currently allows loopback triggering of an interrupt before a signaling eventfd has been configured by the user, which thereby allows a NULL pointer dereference. Rather than register the IRQ relative to a valid trigger, register all IRQs in a disabled state in the device open path. This allows mask operations on the IRQ to nest within the overall enable state governed by a valid eventfd signal. This decouples @masked, protected by the @locked spinlock from @trigger, protected via the @igate mutex. In doing so, it's guaranteed that changes to @trigger cannot race the IRQ handlers because the IRQ handler is synchronously disabled before modifying the trigger, and loopback triggering of the IRQ via ioctl is safe due to serialization with trigger changes via igate. For compatibility, request_irq() failures are maintained to be local to the SET_IRQS ioctl rather than a fatal error in the open device path. This allows, for example, a userspace driver with polling mode support to continue to work regardless of moving the request_irq() call site. This necessarily blocks all SET_IRQS access to the failed index. (CVE-2024-26813)
- In the Linux kernel, the following vulnerability has been resolved: vfio/fsl-mc: Block calling interrupt handler without trigger The eventfd_ctx trigger pointer of the vfio_fsl_mc_irq object is initially NULL and may become NULL if the user sets the trigger eventfd to -1. The interrupt handler itself is guaranteed that trigger is always valid between request_irq() and free_irq(), but the loopback testing mechanisms to invoke the handler function need to test the trigger. The triggering and setting ioctl paths both make use of igate and are therefore mutually exclusive. The vfio-fsl-mc driver does not make use of irqfds, nor does it support any sort of masking operations, therefore unlike vfio-pci and vfio-platform, the flow can remain essentially unchanged. (CVE-2024-26814)
- In the Linux kernel, the following vulnerability has been resolved: net/sched: taprio: proper TCA_TAPRIO_TC_ENTRY_INDEX check taprio_parse_tc_entry() is not correctly checking TCA_TAPRIO_TC_ENTRY_INDEX attribute: int tc; // Signed value tc = nla_get_u32(tb[TCA_TAPRIO_TC_ENTRY_INDEX]); if (tc >= TC_QOPT_MAX_QUEUE) { NL_SET_ERR_MSG_MOD(extack, TC entry index out of range); return -ERANGE; } syzbot reported that it could fed arbitary negative values:
UBSAN: shift-out-of-bounds in net/sched/sch_taprio.c:1722:18 shift exponent -2147418108 is negative CPU: 0 PID: 5066 Comm: syz-executor367 Not tainted 6.8.0-rc7-syzkaller-00136-gc8a5c731fd12 #0 Hardware name:
Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:217 [inline] __ubsan_handle_shift_out_of_bounds+0x3c7/0x420 lib/ubsan.c:386 taprio_parse_tc_entry net/sched/sch_taprio.c:1722 [inline] taprio_parse_tc_entries net/sched/sch_taprio.c:1768 [inline] taprio_change+0xb87/0x57d0 net/sched/sch_taprio.c:1877 taprio_init+0x9da/0xc80 net/sched/sch_taprio.c:2134 qdisc_create+0x9d4/0x1190 net/sched/sch_api.c:1355 tc_modify_qdisc+0xa26/0x1e40 net/sched/sch_api.c:1776 rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6617 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7f1b2dea3759 Code: 48 83 c4 28 c3 e8 d7 19 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd4de452f8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f1b2def0390 RCX: 00007f1b2dea3759 RDX:
0000000000000000 RSI: 00000000200007c0 RDI: 0000000000000004 RBP: 0000000000000003 R08: 0000555500000000 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007ffd4de45340 R13:
00007ffd4de45310 R14: 0000000000000001 R15: 00007ffd4de45340 (CVE-2024-26815)
- In the Linux kernel, the following vulnerability has been resolved: x86, relocs: Ignore relocations in .notes section When building with CONFIG_XEN_PV=y, .text symbols are emitted into the .notes section so that Xen can find the startup_xen entry point. This information is used prior to booting the kernel, so relocations are not useful. In fact, performing relocations against the .notes section means that the KASLR base is exposed since /sys/kernel/notes is world-readable. To avoid leaking the KASLR base without breaking unprivileged tools that are expecting to read /sys/kernel/notes, skip performing relocations in the .notes section. The values readable in .notes are then identical to those found in System.map.
(CVE-2024-26816)
- In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Disable auto-enable of exclusive INTx IRQ Currently for devices requiring masking at the irqchip for INTx, ie. devices without DisINTx support, the IRQ is enabled in request_irq() and subsequently disabled as necessary to align with the masked status flag. This presents a window where the interrupt could fire between these events, resulting in the IRQ incrementing the disable depth twice. This would be unrecoverable for a user since the masked flag prevents nested enables through vfio. Instead, invert the logic using IRQF_NO_AUTOEN such that exclusive INTx is never auto-enabled, then unmask as required. (CVE-2024-27437)
- This CVE was assigned by Intel. Please see CVE-2024-2201 on CVE.org for more information. (CVE-2024-2201)
Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.
Solution
Upgrade the affs-modules-6.1.0-11-4kc-malta-di packages.See Also
https://security-tracker.debian.org/tracker/source-package/linux
https://security-tracker.debian.org/tracker/CVE-2023-2176
https://security-tracker.debian.org/tracker/CVE-2023-28746
https://security-tracker.debian.org/tracker/CVE-2023-47233
https://security-tracker.debian.org/tracker/CVE-2023-52429
https://security-tracker.debian.org/tracker/CVE-2023-52434
https://security-tracker.debian.org/tracker/CVE-2023-52435
https://security-tracker.debian.org/tracker/CVE-2023-52583
https://security-tracker.debian.org/tracker/CVE-2023-52584
https://security-tracker.debian.org/tracker/CVE-2023-52587
https://security-tracker.debian.org/tracker/CVE-2023-52588
https://security-tracker.debian.org/tracker/CVE-2023-52589
https://security-tracker.debian.org/tracker/CVE-2023-52593
https://security-tracker.debian.org/tracker/CVE-2023-52594
https://security-tracker.debian.org/tracker/CVE-2023-52595
https://security-tracker.debian.org/tracker/CVE-2023-52597
https://security-tracker.debian.org/tracker/CVE-2023-52598
https://security-tracker.debian.org/tracker/CVE-2023-52599
https://security-tracker.debian.org/tracker/CVE-2023-52600
https://security-tracker.debian.org/tracker/CVE-2023-52601
https://security-tracker.debian.org/tracker/CVE-2023-52602
https://security-tracker.debian.org/tracker/CVE-2023-52603
https://security-tracker.debian.org/tracker/CVE-2023-52604
https://security-tracker.debian.org/tracker/CVE-2023-52606
https://security-tracker.debian.org/tracker/CVE-2023-52607
https://security-tracker.debian.org/tracker/CVE-2023-52616
https://security-tracker.debian.org/tracker/CVE-2023-52617
https://security-tracker.debian.org/tracker/CVE-2023-52618
https://security-tracker.debian.org/tracker/CVE-2023-52619
https://security-tracker.debian.org/tracker/CVE-2023-52620
https://security-tracker.debian.org/tracker/CVE-2023-52621
https://security-tracker.debian.org/tracker/CVE-2023-52622
https://security-tracker.debian.org/tracker/CVE-2023-52623
https://security-tracker.debian.org/tracker/CVE-2023-52630
https://security-tracker.debian.org/tracker/CVE-2023-52631
https://security-tracker.debian.org/tracker/CVE-2023-52632
https://security-tracker.debian.org/tracker/CVE-2023-52633
https://security-tracker.debian.org/tracker/CVE-2023-52635
https://security-tracker.debian.org/tracker/CVE-2023-52637
https://security-tracker.debian.org/tracker/CVE-2023-52638
https://security-tracker.debian.org/tracker/CVE-2023-52639
https://security-tracker.debian.org/tracker/CVE-2023-52640
https://security-tracker.debian.org/tracker/CVE-2023-52641
https://security-tracker.debian.org/tracker/CVE-2023-6270
https://security-tracker.debian.org/tracker/CVE-2023-7042
https://security-tracker.debian.org/tracker/CVE-2024-0340
https://security-tracker.debian.org/tracker/CVE-2024-0841
https://security-tracker.debian.org/tracker/CVE-2024-1151
https://security-tracker.debian.org/tracker/CVE-2024-2201
https://security-tracker.debian.org/tracker/CVE-2024-22099
https://security-tracker.debian.org/tracker/CVE-2024-23850
https://security-tracker.debian.org/tracker/CVE-2024-23851
https://security-tracker.debian.org/tracker/CVE-2024-24857
https://security-tracker.debian.org/tracker/CVE-2024-24858
https://security-tracker.debian.org/tracker/CVE-2024-26581
https://security-tracker.debian.org/tracker/CVE-2024-26582
https://security-tracker.debian.org/tracker/CVE-2024-26583
https://security-tracker.debian.org/tracker/CVE-2024-26584
https://security-tracker.debian.org/tracker/CVE-2024-26585
https://security-tracker.debian.org/tracker/CVE-2024-26586
https://security-tracker.debian.org/tracker/CVE-2024-26590
https://security-tracker.debian.org/tracker/CVE-2024-26593
https://security-tracker.debian.org/tracker/CVE-2024-26600
https://security-tracker.debian.org/tracker/CVE-2024-26601
https://security-tracker.debian.org/tracker/CVE-2024-26602
https://security-tracker.debian.org/tracker/CVE-2024-26603
https://security-tracker.debian.org/tracker/CVE-2024-26606
https://security-tracker.debian.org/tracker/CVE-2024-26621
https://security-tracker.debian.org/tracker/CVE-2024-26622
https://security-tracker.debian.org/tracker/CVE-2024-26625
https://security-tracker.debian.org/tracker/CVE-2024-26626
https://security-tracker.debian.org/tracker/CVE-2024-26627
https://security-tracker.debian.org/tracker/CVE-2024-26629
https://security-tracker.debian.org/tracker/CVE-2024-26639
https://security-tracker.debian.org/tracker/CVE-2024-26640
https://security-tracker.debian.org/tracker/CVE-2024-26641
https://security-tracker.debian.org/tracker/CVE-2024-26642
https://security-tracker.debian.org/tracker/CVE-2024-26643
https://security-tracker.debian.org/tracker/CVE-2024-26651
https://security-tracker.debian.org/tracker/CVE-2024-26654
https://security-tracker.debian.org/tracker/CVE-2024-26659
https://security-tracker.debian.org/tracker/CVE-2024-26660
https://security-tracker.debian.org/tracker/CVE-2024-26663
https://security-tracker.debian.org/tracker/CVE-2024-26664
https://security-tracker.debian.org/tracker/CVE-2024-26665
https://security-tracker.debian.org/tracker/CVE-2024-26667
https://security-tracker.debian.org/tracker/CVE-2024-26671
https://security-tracker.debian.org/tracker/CVE-2024-26673
https://security-tracker.debian.org/tracker/CVE-2024-26675
https://security-tracker.debian.org/tracker/CVE-2024-26676
https://security-tracker.debian.org/tracker/CVE-2024-26679
https://security-tracker.debian.org/tracker/CVE-2024-26680
https://security-tracker.debian.org/tracker/CVE-2024-26681
https://security-tracker.debian.org/tracker/CVE-2024-26684
https://security-tracker.debian.org/tracker/CVE-2024-26685
https://security-tracker.debian.org/tracker/CVE-2024-26686
https://security-tracker.debian.org/tracker/CVE-2024-26687
https://security-tracker.debian.org/tracker/CVE-2024-26688
https://security-tracker.debian.org/tracker/CVE-2024-26689
https://security-tracker.debian.org/tracker/CVE-2024-26695
https://security-tracker.debian.org/tracker/CVE-2024-26696
https://security-tracker.debian.org/tracker/CVE-2024-26697
https://security-tracker.debian.org/tracker/CVE-2024-26698
https://security-tracker.debian.org/tracker/CVE-2024-26700
https://security-tracker.debian.org/tracker/CVE-2024-26702
https://security-tracker.debian.org/tracker/CVE-2024-26704
https://security-tracker.debian.org/tracker/CVE-2024-26706
https://security-tracker.debian.org/tracker/CVE-2024-26707
https://security-tracker.debian.org/tracker/CVE-2024-26710
https://security-tracker.debian.org/tracker/CVE-2024-26712
https://security-tracker.debian.org/tracker/CVE-2024-26714
https://security-tracker.debian.org/tracker/CVE-2024-26715
https://security-tracker.debian.org/tracker/CVE-2024-26717
https://security-tracker.debian.org/tracker/CVE-2024-26718
https://security-tracker.debian.org/tracker/CVE-2024-26720
https://security-tracker.debian.org/tracker/CVE-2024-26722
https://security-tracker.debian.org/tracker/CVE-2024-26723
https://security-tracker.debian.org/tracker/CVE-2024-26726
https://security-tracker.debian.org/tracker/CVE-2024-26727
https://security-tracker.debian.org/tracker/CVE-2024-26731
https://security-tracker.debian.org/tracker/CVE-2024-26733
https://security-tracker.debian.org/tracker/CVE-2024-26735
https://security-tracker.debian.org/tracker/CVE-2024-26736
https://security-tracker.debian.org/tracker/CVE-2024-26737
https://security-tracker.debian.org/tracker/CVE-2024-26741
https://security-tracker.debian.org/tracker/CVE-2024-26742
https://security-tracker.debian.org/tracker/CVE-2024-26743
https://security-tracker.debian.org/tracker/CVE-2024-26744
https://security-tracker.debian.org/tracker/CVE-2024-26745
https://security-tracker.debian.org/tracker/CVE-2024-26747
https://security-tracker.debian.org/tracker/CVE-2024-26748
https://security-tracker.debian.org/tracker/CVE-2024-26749
https://security-tracker.debian.org/tracker/CVE-2024-26750
https://security-tracker.debian.org/tracker/CVE-2024-26751
https://security-tracker.debian.org/tracker/CVE-2024-26752
https://security-tracker.debian.org/tracker/CVE-2024-26753
https://security-tracker.debian.org/tracker/CVE-2024-26754
https://security-tracker.debian.org/tracker/CVE-2024-26759
https://security-tracker.debian.org/tracker/CVE-2024-26760
https://security-tracker.debian.org/tracker/CVE-2024-26761
https://security-tracker.debian.org/tracker/CVE-2024-26763
https://security-tracker.debian.org/tracker/CVE-2024-26764
https://security-tracker.debian.org/tracker/CVE-2024-26765
https://security-tracker.debian.org/tracker/CVE-2024-26766
https://security-tracker.debian.org/tracker/CVE-2024-26769
https://security-tracker.debian.org/tracker/CVE-2024-26771
https://security-tracker.debian.org/tracker/CVE-2024-26772
https://security-tracker.debian.org/tracker/CVE-2024-26773
https://security-tracker.debian.org/tracker/CVE-2024-26774
https://security-tracker.debian.org/tracker/CVE-2024-26775
https://security-tracker.debian.org/tracker/CVE-2024-26776
https://security-tracker.debian.org/tracker/CVE-2024-26777
https://security-tracker.debian.org/tracker/CVE-2024-26778
https://security-tracker.debian.org/tracker/CVE-2024-26779
https://security-tracker.debian.org/tracker/CVE-2024-26780
https://security-tracker.debian.org/tracker/CVE-2024-26781
https://security-tracker.debian.org/tracker/CVE-2024-26782
https://security-tracker.debian.org/tracker/CVE-2024-26787
https://security-tracker.debian.org/tracker/CVE-2024-26788
https://security-tracker.debian.org/tracker/CVE-2024-26789
https://security-tracker.debian.org/tracker/CVE-2024-26790
https://security-tracker.debian.org/tracker/CVE-2024-26791
https://security-tracker.debian.org/tracker/CVE-2024-26792
https://security-tracker.debian.org/tracker/CVE-2024-26793
https://security-tracker.debian.org/tracker/CVE-2024-26795
https://security-tracker.debian.org/tracker/CVE-2024-26798
https://security-tracker.debian.org/tracker/CVE-2024-26800
https://security-tracker.debian.org/tracker/CVE-2024-26801
https://security-tracker.debian.org/tracker/CVE-2024-26802
https://security-tracker.debian.org/tracker/CVE-2024-26803
https://security-tracker.debian.org/tracker/CVE-2024-26804
https://security-tracker.debian.org/tracker/CVE-2024-26805
https://security-tracker.debian.org/tracker/CVE-2024-26809
https://security-tracker.debian.org/tracker/CVE-2024-26810
https://security-tracker.debian.org/tracker/CVE-2024-26811
https://security-tracker.debian.org/tracker/CVE-2024-26812
https://security-tracker.debian.org/tracker/CVE-2024-26813
https://security-tracker.debian.org/tracker/CVE-2024-26814
https://security-tracker.debian.org/tracker/CVE-2024-26815
https://security-tracker.debian.org/tracker/CVE-2024-26816
Plugin Details
Severity: High
ID: 193309
File Name: debian_DSA-5658.nasl
Version: 1.1
Type: local
Agent: unix
Family: Debian Local Security Checks
Published: 4/13/2024
Updated: 4/13/2024
Supported Sensors: Agentless Assessment, Frictionless Assessment Agent, Nessus Agent, Nessus
Risk Information
VPR
Risk Factor: High
Score: 7.4
CVSS v2
Risk Factor: High
Base Score: 7.7
Temporal Score: 5.7
Vector: CVSS2#AV:A/AC:L/Au:S/C:C/I:C/A:C
CVSS Score Source: CVE-2023-52434
CVSS v3
Risk Factor: High
Base Score: 8
Temporal Score: 7
Vector: CVSS:3.0/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Temporal Vector: CVSS:3.0/E:U/RL:O/RC:C
Vulnerability Information
CPE: p-cpe:/a:debian:debian_linux:affs-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:affs-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:affs-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:affs-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:affs-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:affs-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:affs-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:affs-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:affs-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:affs-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:affs-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:affs-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:ata-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:ata-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:ata-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:ata-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:ata-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:ata-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:ata-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:ata-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:ata-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:ata-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:bpftool, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-11-s390x-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:ata-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:ata-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:ata-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:ata-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:ata-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:ata-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:ata-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:ata-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:ata-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:ata-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:ata-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:ata-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:ata-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:ata-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:ata-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:ata-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:ata-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:ata-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:ata-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:ata-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:ata-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:ata-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-20-s390x-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-11-s390x-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-12-s390x-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-17-s390x-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-20-s390x-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-11-s390x-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-12-s390x-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-17-s390x-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:crc-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-17-s390x-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:crypto-dm-modules-6.1.0-20-s390x-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-11-s390x-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-17-s390x-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-20-s390x-di, p-cpe:/a:debian:debian_linux:dasd-extra-modules-6.1.0-11-s390x-di, p-cpe:/a:debian:debian_linux:dasd-extra-modules-6.1.0-12-s390x-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-17-s390x-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-20-s390x-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-12-s390x-di, p-cpe:/a:debian:debian_linux:crypto-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:dasd-extra-modules-6.1.0-17-s390x-di, p-cpe:/a:debian:debian_linux:dasd-extra-modules-6.1.0-20-s390x-di, p-cpe:/a:debian:debian_linux:dasd-modules-6.1.0-11-s390x-di, p-cpe:/a:debian:debian_linux:dasd-modules-6.1.0-12-s390x-di, p-cpe:/a:debian:debian_linux:dasd-modules-6.1.0-17-s390x-di, p-cpe:/a:debian:debian_linux:dasd-modules-6.1.0-20-s390x-di, p-cpe:/a:debian:debian_linux:efi-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:efi-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:efi-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:efi-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:event-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:event-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:event-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:event-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:event-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:event-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:event-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:event-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:event-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:event-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:event-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:event-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:event-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:event-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:event-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:event-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:event-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:event-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:event-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:event-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:event-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:event-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:event-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:event-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:event-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:event-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:event-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:event-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:event-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:event-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:event-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:event-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:event-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:event-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:event-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-11-s390x-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-12-s390x-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:ext4-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-11-s390x-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-17-s390x-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-20-s390x-di, p-cpe:/a:debian:debian_linux:fb-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:fb-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:fb-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:fb-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:fb-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:fb-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:fb-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:fb-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:fb-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:fb-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:fb-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:fb-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:fb-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:fb-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:fb-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-12-s390x-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-17-s390x-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:f2fs-modules-6.1.0-20-s390x-di, p-cpe:/a:debian:debian_linux:fancontrol-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:fancontrol-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:fancontrol-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:fancontrol-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-11-s390x-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-12-s390x-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:fat-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:fb-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:fb-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:fb-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:fb-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:fb-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:fb-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:fb-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:fb-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:fb-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:fb-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:fb-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:fb-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:fb-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:fb-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:fb-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:fb-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:fb-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:fb-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:fb-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:fb-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:firewire-core-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:firewire-core-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:firewire-core-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:firewire-core-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-12-s390x-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-17-s390x-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-20-s390x-di, p-cpe:/a:debian:debian_linux:hyperv-daemons, p-cpe:/a:debian:debian_linux:hypervisor-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:hypervisor-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:hypervisor-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:hypervisor-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:i2c-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:i2c-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:i2c-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:i2c-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:i2c-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:i2c-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:i2c-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:i2c-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:input-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:input-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:input-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:input-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:input-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:input-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:input-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:input-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:input-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:input-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:input-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:input-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:input-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:input-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:input-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:input-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:input-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:input-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:input-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:input-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:input-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:input-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:input-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:input-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-12-s390x-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-17-s390x-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:btrfs-modules-6.1.0-20-s390x-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-11-s390x-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-12-s390x-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:cdrom-core-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:jfs-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:jfs-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:jfs-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:jfs-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:jfs-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:jfs-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:jfs-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:jfs-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:jfs-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:jfs-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:jfs-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:jfs-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:jfs-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:jfs-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:jfs-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:jfs-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:jfs-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:jfs-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:jfs-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:jfs-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:jfs-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:jfs-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:jfs-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:jfs-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:jfs-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:jfs-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:jfs-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:jfs-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:jfs-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:jfs-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:jfs-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:input-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:input-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:input-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:input-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:input-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:input-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:input-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:linux-headers-6.1.0-11-armmp, p-cpe:/a:debian:debian_linux:linux-headers-6.1.0-11-armmp-lpae, p-cpe:/a:debian:debian_linux:linux-headers-6.1.0-11-cloud-amd64, p-cpe:/a:debian:debian_linux:linux-headers-6.1.0-11-cloud-arm64, p-cpe:/a:debian:debian_linux:linux-headers-6.1.0-11-common, p-cpe:/a:debian:debian_linux:linux-headers-6.1.0-11-common-rt, p-cpe:/a:debian:debian_linux:linux-headers-6.1.0-11-loongson-3, p-cpe:/a:debian:debian_linux:linux-headers-6.1.0-11-marvell, p-cpe:/a:debian:debian_linux:linux-headers-6.1.0-11-mips32r2el, p-cpe:/a:debian:debian_linux:linux-headers-6.1.0-11-mips64r2el, p-cpe:/a:debian:debian_linux:linux-headers-6.1.0-11-octeon, p-cpe:/a:debian:debian_linux:linux-headers-6.1.0-11-powerpc64le, p-cpe:/a:debian:debian_linux:linux-headers-6.1.0-11-rpi, p-cpe:/a:debian:debian_linux:linux-headers-6.1.0-11-rt-686-pae, p-cpe:/a:debian:debian_linux:linux-headers-6.1.0-11-rt-amd64, p-cpe:/a:debian:debian_linux:linux-headers-6.1.0-11-rt-arm64, p-cpe:/a:debian:debian_linux:linux-headers-6.1.0-11-rt-armmp, p-cpe:/a:debian:debian_linux:linux-headers-6.1.0-11-s390x, p-cpe:/a:debian:debian_linux:linux-headers-armmp, p-cpe:/a:debian:debian_linux:linux-headers-armmp-lpae, p-cpe:/a:debian:debian_linux:linux-headers-loongson-3, p-cpe:/a:debian:debian_linux:linux-headers-marvell, p-cpe:/a:debian:debian_linux:linux-headers-mips32r2el, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-11-s390x-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-12-s390x-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-17-s390x-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:kernel-image-6.1.0-20-s390x-di, p-cpe:/a:debian:debian_linux:leds-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:leds-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:leds-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:leds-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:leds-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:leds-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:leds-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:libcpupower-dev, p-cpe:/a:debian:debian_linux:libcpupower1, p-cpe:/a:debian:debian_linux:linux-compiler-gcc-12-arm, p-cpe:/a:debian:debian_linux:linux-compiler-gcc-12-s390, p-cpe:/a:debian:debian_linux:linux-compiler-gcc-12-x86, p-cpe:/a:debian:debian_linux:linux-config-6.1, p-cpe:/a:debian:debian_linux:linux-cpupower, p-cpe:/a:debian:debian_linux:linux-doc, p-cpe:/a:debian:debian_linux:linux-doc-6.1, p-cpe:/a:debian:debian_linux:linux-headers-4kc-malta, p-cpe:/a:debian:debian_linux:linux-headers-5kc-malta, p-cpe:/a:debian:debian_linux:linux-headers-6.1.0-11-4kc-malta, p-cpe:/a:debian:debian_linux:linux-headers-6.1.0-11-5kc-malta, p-cpe:/a:debian:debian_linux:linux-headers-6.1.0-11-686, p-cpe:/a:debian:debian_linux:linux-headers-6.1.0-11-686-pae, p-cpe:/a:debian:debian_linux:linux-headers-6.1.0-11-amd64, p-cpe:/a:debian:debian_linux:linux-headers-6.1.0-11-arm64, p-cpe:/a:debian:debian_linux:linux-image-6.1.0-11-686-dbg, p-cpe:/a:debian:debian_linux:linux-image-6.1.0-11-686-pae-dbg, p-cpe:/a:debian:debian_linux:linux-image-6.1.0-11-amd64-dbg, p-cpe:/a:debian:debian_linux:linux-image-6.1.0-11-arm64-dbg, p-cpe:/a:debian:debian_linux:linux-image-6.1.0-11-armmp, p-cpe:/a:debian:debian_linux:linux-image-6.1.0-11-armmp-dbg, p-cpe:/a:debian:debian_linux:linux-image-6.1.0-11-armmp-lpae, p-cpe:/a:debian:debian_linux:linux-image-6.1.0-11-armmp-lpae-dbg, p-cpe:/a:debian:debian_linux:linux-image-6.1.0-11-cloud-amd64-dbg, p-cpe:/a:debian:debian_linux:linux-image-6.1.0-11-cloud-arm64-dbg, p-cpe:/a:debian:debian_linux:linux-image-6.1.0-11-loongson-3, p-cpe:/a:debian:debian_linux:linux-image-6.1.0-11-loongson-3-dbg, p-cpe:/a:debian:debian_linux:linux-image-6.1.0-11-marvell, p-cpe:/a:debian:debian_linux:linux-image-6.1.0-11-marvell-dbg, p-cpe:/a:debian:debian_linux:linux-image-6.1.0-11-mips32r2el, p-cpe:/a:debian:debian_linux:linux-image-6.1.0-11-mips32r2el-dbg, p-cpe:/a:debian:debian_linux:linux-image-6.1.0-11-mips64r2el, p-cpe:/a:debian:debian_linux:linux-image-6.1.0-11-mips64r2el-dbg, p-cpe:/a:debian:debian_linux:linux-image-6.1.0-11-octeon, p-cpe:/a:debian:debian_linux:linux-image-6.1.0-11-octeon-dbg, p-cpe:/a:debian:debian_linux:linux-image-6.1.0-11-powerpc64le, p-cpe:/a:debian:debian_linux:linux-image-6.1.0-11-powerpc64le-dbg, p-cpe:/a:debian:debian_linux:linux-image-6.1.0-11-rpi, p-cpe:/a:debian:debian_linux:linux-image-6.1.0-11-rpi-dbg, p-cpe:/a:debian:debian_linux:linux-image-6.1.0-11-rt-686-pae-dbg, p-cpe:/a:debian:debian_linux:linux-image-6.1.0-11-rt-amd64-dbg, p-cpe:/a:debian:debian_linux:linux-image-6.1.0-11-rt-arm64-dbg, p-cpe:/a:debian:debian_linux:linux-headers-mips64r2el, p-cpe:/a:debian:debian_linux:linux-headers-octeon, p-cpe:/a:debian:debian_linux:linux-headers-powerpc64le, p-cpe:/a:debian:debian_linux:linux-headers-rpi, p-cpe:/a:debian:debian_linux:linux-headers-rt-armmp, p-cpe:/a:debian:debian_linux:linux-headers-s390x, p-cpe:/a:debian:debian_linux:linux-image-4kc-malta, p-cpe:/a:debian:debian_linux:linux-image-4kc-malta-dbg, p-cpe:/a:debian:debian_linux:linux-image-5kc-malta, p-cpe:/a:debian:debian_linux:linux-image-5kc-malta-dbg, p-cpe:/a:debian:debian_linux:linux-image-6.1.0-11-4kc-malta, p-cpe:/a:debian:debian_linux:linux-image-6.1.0-11-4kc-malta-dbg, p-cpe:/a:debian:debian_linux:linux-image-6.1.0-11-5kc-malta, p-cpe:/a:debian:debian_linux:linux-image-6.1.0-11-5kc-malta-dbg, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-12-s390x-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-17-s390x-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:linux-image-6.1.0-11-rt-armmp, p-cpe:/a:debian:debian_linux:linux-image-6.1.0-11-rt-armmp-dbg, p-cpe:/a:debian:debian_linux:linux-image-6.1.0-11-s390x, p-cpe:/a:debian:debian_linux:linux-image-6.1.0-11-s390x-dbg, p-cpe:/a:debian:debian_linux:linux-image-686-dbg, p-cpe:/a:debian:debian_linux:linux-image-686-pae-dbg, p-cpe:/a:debian:debian_linux:linux-image-amd64-dbg, p-cpe:/a:debian:debian_linux:linux-image-amd64-signed-template, p-cpe:/a:debian:debian_linux:linux-image-arm64-dbg, p-cpe:/a:debian:debian_linux:linux-image-arm64-signed-template, p-cpe:/a:debian:debian_linux:linux-image-armmp, p-cpe:/a:debian:debian_linux:linux-image-armmp-dbg, p-cpe:/a:debian:debian_linux:linux-image-armmp-lpae, p-cpe:/a:debian:debian_linux:linux-image-armmp-lpae-dbg, p-cpe:/a:debian:debian_linux:linux-image-cloud-amd64-dbg, p-cpe:/a:debian:debian_linux:linux-image-cloud-arm64-dbg, p-cpe:/a:debian:debian_linux:linux-image-i386-signed-template, p-cpe:/a:debian:debian_linux:linux-image-loongson-3, p-cpe:/a:debian:debian_linux:linux-image-loongson-3-dbg, p-cpe:/a:debian:debian_linux:linux-image-marvell, p-cpe:/a:debian:debian_linux:linux-image-marvell-dbg, p-cpe:/a:debian:debian_linux:linux-image-mips32r2el, p-cpe:/a:debian:debian_linux:linux-image-mips32r2el-dbg, p-cpe:/a:debian:debian_linux:linux-image-mips64r2el, p-cpe:/a:debian:debian_linux:linux-image-mips64r2el-dbg, p-cpe:/a:debian:debian_linux:linux-image-octeon, p-cpe:/a:debian:debian_linux:linux-image-octeon-dbg, p-cpe:/a:debian:debian_linux:linux-image-powerpc64le, p-cpe:/a:debian:debian_linux:linux-image-powerpc64le-dbg, p-cpe:/a:debian:debian_linux:linux-image-rpi, p-cpe:/a:debian:debian_linux:linux-image-rpi-dbg, p-cpe:/a:debian:debian_linux:linux-image-rt-686-pae-dbg, p-cpe:/a:debian:debian_linux:linux-image-rt-amd64-dbg, p-cpe:/a:debian:debian_linux:linux-image-rt-arm64-dbg, p-cpe:/a:debian:debian_linux:linux-image-rt-armmp, p-cpe:/a:debian:debian_linux:linux-image-rt-armmp-dbg, p-cpe:/a:debian:debian_linux:linux-image-s390x, p-cpe:/a:debian:debian_linux:linux-image-s390x-dbg, p-cpe:/a:debian:debian_linux:linux-kbuild-6.1, p-cpe:/a:debian:debian_linux:linux-libc-dev, p-cpe:/a:debian:debian_linux:linux-perf, p-cpe:/a:debian:debian_linux:linux-source, p-cpe:/a:debian:debian_linux:linux-source-6.1, p-cpe:/a:debian:debian_linux:linux-support-6.1.0-11, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-11-s390x-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:minix-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:minix-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:minix-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:minix-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:minix-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:minix-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:minix-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:minix-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:minix-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:minix-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:minix-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:minix-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:minix-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:minix-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:minix-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:minix-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:minix-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:minix-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:minix-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:minix-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:minix-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:minix-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:minix-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:minix-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:minix-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:minix-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:minix-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:loop-modules-6.1.0-20-s390x-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-11-s390x-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-12-s390x-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:mmc-core-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:mmc-core-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:mmc-core-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:mmc-core-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:mmc-core-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:mmc-core-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:mmc-core-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:mmc-core-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:mmc-core-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:mmc-core-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:mmc-core-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:mmc-core-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:mmc-core-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:mmc-core-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:mmc-core-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:mmc-core-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:mmc-core-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:mmc-core-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:mmc-core-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:mmc-core-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:mmc-core-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:mmc-core-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:mmc-core-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:mmc-core-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:mmc-core-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:mmc-core-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:mmc-core-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:mmc-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:mmc-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:mmc-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:mmc-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:mmc-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:mmc-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:mmc-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:mmc-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:mmc-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:mmc-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:mmc-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:mmc-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:mmc-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:mmc-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:mmc-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:mmc-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:mmc-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:mmc-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:mmc-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:mmc-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:mmc-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:mmc-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:mmc-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:mmc-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:mmc-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:mmc-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:mmc-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:mmc-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:mmc-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:mmc-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:mmc-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:mouse-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:mouse-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:mouse-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:mouse-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:mouse-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:mouse-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:mouse-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:mouse-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:mouse-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:mouse-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:mouse-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:mouse-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:mouse-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:mouse-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:mouse-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:mouse-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:mouse-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:mouse-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:mouse-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:mouse-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:mouse-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:mouse-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:mouse-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:mouse-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:mouse-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:mouse-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:mouse-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:mouse-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-17-s390x-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:md-modules-6.1.0-20-s390x-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-11-s390x-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-12-s390x-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-11-s390x-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:mouse-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:mouse-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:mouse-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:mtd-core-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:mtd-core-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:mtd-core-modules-6.1.0-11-s390x-di, p-cpe:/a:debian:debian_linux:mtd-core-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:mtd-core-modules-6.1.0-12-s390x-di, p-cpe:/a:debian:debian_linux:mtd-core-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:mtd-core-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:mtd-core-modules-6.1.0-17-s390x-di, p-cpe:/a:debian:debian_linux:mtd-core-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:mtd-core-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:mtd-core-modules-6.1.0-20-s390x-di, p-cpe:/a:debian:debian_linux:mtd-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:mtd-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:mtd-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:mtd-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:mtd-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:mtd-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:mtd-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-11-s390x-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-12-s390x-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-17-s390x-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:multipath-modules-6.1.0-20-s390x-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-17-s390x-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:nbd-modules-6.1.0-20-s390x-di, p-cpe:/a:debian:debian_linux:nfs-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:nfs-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:nfs-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:nfs-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:nfs-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:nfs-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:nfs-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:nfs-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-12-s390x-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-17-s390x-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:pata-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:pata-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:pata-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:pata-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:pata-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:pata-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:pata-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:pata-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:pata-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:nfs-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:nfs-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:nfs-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:nfs-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:nfs-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:nfs-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:nfs-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:nfs-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:nfs-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:nfs-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:nfs-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:nfs-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:nfs-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:nfs-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:nfs-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:nfs-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:nic-modules-6.1.0-20-s390x-di, p-cpe:/a:debian:debian_linux:nic-shared-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:nic-shared-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:nic-shared-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:nic-shared-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:nic-shared-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:nic-shared-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:nic-shared-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:nic-shared-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:nic-shared-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:nic-shared-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:nic-shared-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:nic-shared-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:nic-shared-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:nic-shared-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:nic-shared-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:nic-shared-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:nic-shared-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:nic-shared-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:nic-shared-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:nic-shared-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:nic-shared-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:nic-shared-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:nic-shared-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:nic-shared-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:nic-shared-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:nic-shared-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:nic-shared-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:nic-shared-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:nic-shared-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:nic-shared-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:nic-shared-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:nic-shared-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:nic-shared-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:nic-shared-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:nic-shared-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:nic-usb-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:nic-usb-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:nic-usb-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:nic-usb-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:nic-usb-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:nic-usb-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:nic-usb-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:nic-usb-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:nic-usb-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:nic-usb-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:nic-usb-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:nic-usb-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:nic-usb-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:nic-usb-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:nic-usb-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:nic-usb-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:nic-usb-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:nic-usb-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:nic-usb-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:nic-usb-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:pata-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:pata-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:pata-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:pata-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:pata-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:pata-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:pata-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:pata-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:pata-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:pata-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:pata-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:pata-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:pata-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:pata-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:ppp-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:ppp-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:ppp-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:ppp-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:ppp-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:ppp-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:ppp-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:ppp-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:ppp-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:ppp-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:ppp-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:ppp-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:ppp-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:ppp-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:ppp-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:ppp-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:ppp-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:ppp-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:ppp-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:ppp-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:ppp-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:nic-usb-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:nic-usb-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:nic-usb-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:nic-usb-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:nic-usb-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:nic-usb-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:nic-usb-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:nic-usb-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:nic-usb-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:nic-usb-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:nic-usb-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:nic-usb-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:nic-usb-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:nic-usb-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:nic-usb-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:nic-wireless-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:nic-wireless-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:nic-wireless-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:nic-wireless-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:nic-wireless-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:nic-wireless-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:nic-wireless-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:nic-wireless-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:nic-wireless-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:nic-wireless-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:nic-wireless-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:nic-wireless-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:nic-wireless-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:nic-wireless-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:nic-wireless-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:nic-wireless-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:nic-wireless-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:nic-wireless-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:nic-wireless-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:nic-wireless-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:nic-wireless-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:nic-wireless-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:nic-wireless-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:nic-wireless-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:nic-wireless-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:nic-wireless-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:nic-wireless-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:nic-wireless-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:nic-wireless-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:nic-wireless-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:nic-wireless-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:nic-wireless-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:pata-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:pata-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:pata-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:pata-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:pata-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:sata-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:sata-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:sata-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:sata-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:sata-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:sata-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:sata-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:sata-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:sata-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:sata-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:sata-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:sata-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:sata-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:sata-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:sata-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:sata-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:sata-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:sata-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:sata-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:sata-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:sata-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:sata-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:sata-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:sata-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:sata-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:sata-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:sata-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:sata-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:ppp-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:ppp-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:ppp-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:ppp-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:ppp-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:ppp-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:ppp-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:ppp-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:ppp-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:ppp-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:ppp-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:ppp-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:ppp-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:ppp-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:rtla, p-cpe:/a:debian:debian_linux:sata-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:sata-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:sata-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:sata-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:sata-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:sata-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:sata-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:serial-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:serial-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:serial-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:sound-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:sound-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:sound-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:sound-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:sound-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:sound-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-11-s390x-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-12-s390x-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-17-s390x-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:scsi-core-modules-6.1.0-20-s390x-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-11-s390x-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-12-s390x-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-17-s390x-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:scsi-modules-6.1.0-20-s390x-di, p-cpe:/a:debian:debian_linux:scsi-nic-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:scsi-nic-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:scsi-nic-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:scsi-nic-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:scsi-nic-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:scsi-nic-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:scsi-nic-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:scsi-nic-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:scsi-nic-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:scsi-nic-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:scsi-nic-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:scsi-nic-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:scsi-nic-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:scsi-nic-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:scsi-nic-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:scsi-nic-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:sound-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:sound-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:sound-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:sound-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:sound-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:sound-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:speakup-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:speakup-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:speakup-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:speakup-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:speakup-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:speakup-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:squashfs-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:squashfs-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:squashfs-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:squashfs-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:squashfs-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:squashfs-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:squashfs-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:squashfs-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:squashfs-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:squashfs-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:squashfs-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:squashfs-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:squashfs-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:squashfs-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:squashfs-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:squashfs-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:squashfs-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:squashfs-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:squashfs-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:squashfs-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:scsi-nic-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:scsi-nic-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:scsi-nic-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:scsi-nic-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:scsi-nic-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:scsi-nic-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:scsi-nic-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:scsi-nic-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:scsi-nic-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:scsi-nic-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:scsi-nic-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:scsi-nic-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:scsi-nic-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:scsi-nic-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:scsi-nic-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:scsi-nic-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:serial-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:sound-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:sound-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:sound-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:sound-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:sound-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:sound-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:sound-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:sound-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:sound-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:sound-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:sound-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:sound-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:sound-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:sound-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:sound-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:sound-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:speakup-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:speakup-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:speakup-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:speakup-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:speakup-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:speakup-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:speakup-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:speakup-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:speakup-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:speakup-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:speakup-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:speakup-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:speakup-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:speakup-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:speakup-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:speakup-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:speakup-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:speakup-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:speakup-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:speakup-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:speakup-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:speakup-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-12-s390x-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-17-s390x-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-20-s390x-di, p-cpe:/a:debian:debian_linux:uinput-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:uinput-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:uinput-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:uinput-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:uinput-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:uinput-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:uinput-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:squashfs-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:squashfs-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:squashfs-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:squashfs-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:squashfs-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:squashfs-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:squashfs-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:squashfs-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:squashfs-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:squashfs-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:squashfs-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:squashfs-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:squashfs-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:squashfs-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:squashfs-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-11-s390x-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:udf-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:usb-storage-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:usb-storage-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:usb-storage-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:usb-storage-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:uinput-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:uinput-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:uinput-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:uinput-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:usb-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:usb-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:usb-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:usb-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:usb-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:usb-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:usb-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:usb-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:usb-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:usb-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:usb-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:usb-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:usb-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:usb-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:usb-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:usb-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:usb-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:usb-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:usb-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:usb-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:usb-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:usb-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:usb-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:usb-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:usb-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:usb-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:usb-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:usb-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:usb-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:usb-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:usb-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:usb-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:usb-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:usb-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:usb-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:usb-serial-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:usb-serial-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:usb-serial-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:usb-serial-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:usb-serial-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:usb-serial-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:usb-serial-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:usb-serial-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:usb-serial-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:usb-serial-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:usb-serial-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:usb-serial-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:usb-serial-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:usb-serial-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:usb-serial-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:usb-serial-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:usb-serial-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:usb-serial-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:usb-serial-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:usb-serial-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:usb-serial-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:usb-serial-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:usb-serial-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:usb-serial-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:usb-serial-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:usb-serial-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:usb-serial-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:usb-serial-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:usb-serial-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:usb-serial-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:usb-serial-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:usb-serial-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:usb-serial-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:usb-serial-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:usb-serial-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:usb-storage-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:usb-storage-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:usb-storage-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:usb-storage-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:usb-storage-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:usb-storage-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:usb-storage-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:usb-storage-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:usb-storage-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:usb-storage-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:usb-storage-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:usb-storage-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:usb-storage-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:usb-storage-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:usb-storage-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:usb-storage-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:usb-storage-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:usb-storage-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:usb-storage-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:usb-storage-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:usb-storage-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:usb-storage-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:usb-storage-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:usb-storage-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:usb-storage-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:usb-storage-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:usb-storage-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:usb-storage-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:usb-storage-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:usbip, p-cpe:/a:debian:debian_linux:xfs-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:xfs-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:xfs-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:xfs-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:usb-storage-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:usb-storage-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:xfs-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:xfs-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:xfs-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:xfs-modules-6.1.0-11-s390x-di, p-cpe:/a:debian:debian_linux:xfs-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:xfs-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:xfs-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:xfs-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:xfs-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:xfs-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:xfs-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:xfs-modules-6.1.0-12-s390x-di, p-cpe:/a:debian:debian_linux:xfs-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:xfs-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:xfs-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:xfs-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:xfs-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:xfs-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:xfs-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:xfs-modules-6.1.0-17-s390x-di, p-cpe:/a:debian:debian_linux:xfs-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:xfs-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:xfs-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:xfs-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:xfs-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:xfs-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:xfs-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:xfs-modules-6.1.0-20-s390x-di, cpe:/o:debian:debian_linux:12.0, p-cpe:/a:debian:debian_linux:affs-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:affs-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:affs-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:affs-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:affs-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:affs-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:affs-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:affs-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:affs-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:affs-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:affs-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:affs-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:firewire-core-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:firewire-core-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:firewire-core-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:firewire-core-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:firewire-core-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:firewire-core-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:firewire-core-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:firewire-core-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:firewire-core-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:firewire-core-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:firewire-core-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:firewire-core-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:firewire-core-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:firewire-core-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:firewire-core-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:firewire-core-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:firewire-core-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:firewire-core-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:firewire-core-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:firewire-core-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:firewire-core-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:firewire-core-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:firewire-core-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:firewire-core-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:fuse-modules-6.1.0-11-s390x-di, p-cpe:/a:debian:debian_linux:input-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:input-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:input-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:input-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:ipv6-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:ipv6-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:ipv6-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-11-loongson-3-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-11-mips32r2el-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-11-mips64r2el-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-11-octeon-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-11-powerpc64le-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-11-s390x-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-12-4kc-malta-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-12-5kc-malta-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-12-armmp-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-12-loongson-3-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-12-mips32r2el-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-12-mips64r2el-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-12-octeon-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-12-powerpc64le-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-12-s390x-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-17-4kc-malta-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-17-5kc-malta-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-17-armmp-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-17-loongson-3-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-17-mips32r2el-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-17-mips64r2el-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-17-octeon-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-17-powerpc64le-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-17-s390x-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-20-4kc-malta-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-20-5kc-malta-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-20-armmp-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-20-loongson-3-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-20-mips32r2el-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-20-mips64r2el-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-20-octeon-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-20-powerpc64le-di, p-cpe:/a:debian:debian_linux:isofs-modules-6.1.0-20-s390x-di, p-cpe:/a:debian:debian_linux:jffs2-modules-6.1.0-11-marvell-di, p-cpe:/a:debian:debian_linux:jffs2-modules-6.1.0-17-marvell-di, p-cpe:/a:debian:debian_linux:jffs2-modules-6.1.0-20-marvell-di, p-cpe:/a:debian:debian_linux:jfs-modules-6.1.0-11-4kc-malta-di, p-cpe:/a:debian:debian_linux:jfs-modules-6.1.0-11-5kc-malta-di, p-cpe:/a:debian:debian_linux:jfs-modules-6.1.0-11-armmp-di, p-cpe:/a:debian:debian_linux:jfs-modules-6.1.0-11-loongson-3-di
Required KB Items: Host/Debian/dpkg-l, Host/local_checks_enabled, Host/Debian/release
Exploit Ease: No known exploits are available
Patch Publication Date: 4/13/2024
Vulnerability Publication Date: 4/20/2023
Reference Information
CVE: CVE-2023-2176, CVE-2023-28746, CVE-2023-47233, CVE-2023-52429, CVE-2023-52434, CVE-2023-52435, CVE-2023-52583, CVE-2023-52584, CVE-2023-52587, CVE-2023-52588, CVE-2023-52589, CVE-2023-52593, CVE-2023-52594, CVE-2023-52595, CVE-2023-52597, CVE-2023-52598, CVE-2023-52599, CVE-2023-52600, CVE-2023-52601, CVE-2023-52602, CVE-2023-52603, CVE-2023-52604, CVE-2023-52606, CVE-2023-52607, CVE-2023-52616, CVE-2023-52617, CVE-2023-52618, CVE-2023-52619, CVE-2023-52620, CVE-2023-52621, CVE-2023-52622, CVE-2023-52623, CVE-2023-52630, CVE-2023-52631, CVE-2023-52632, CVE-2023-52633, CVE-2023-52635, CVE-2023-52637, CVE-2023-52638, CVE-2023-52639, CVE-2023-52640, CVE-2023-52641, CVE-2023-6270, CVE-2023-7042, CVE-2024-0340, CVE-2024-0841, CVE-2024-1151, CVE-2024-2201, CVE-2024-22099, CVE-2024-23850, CVE-2024-23851, CVE-2024-24857, CVE-2024-24858, CVE-2024-26581, CVE-2024-26582, CVE-2024-26583, CVE-2024-26584, CVE-2024-26585, CVE-2024-26586, CVE-2024-26590, CVE-2024-26593, CVE-2024-26600, CVE-2024-26601, CVE-2024-26602, CVE-2024-26603, CVE-2024-26606, CVE-2024-26621, CVE-2024-26622, CVE-2024-26625, CVE-2024-26626, CVE-2024-26627, CVE-2024-26629, CVE-2024-26639, CVE-2024-26640, CVE-2024-26641, CVE-2024-26642, CVE-2024-26643, CVE-2024-26651, CVE-2024-26654, CVE-2024-26659, CVE-2024-26660, CVE-2024-26663, CVE-2024-26664, CVE-2024-26665, CVE-2024-26667, CVE-2024-26671, CVE-2024-26673, CVE-2024-26675, CVE-2024-26676, CVE-2024-26679, CVE-2024-26680, CVE-2024-26681, CVE-2024-26684, CVE-2024-26685, CVE-2024-26686, CVE-2024-26687, CVE-2024-26688, CVE-2024-26689, CVE-2024-26695, CVE-2024-26696, CVE-2024-26697, CVE-2024-26698, CVE-2024-26700, CVE-2024-26702, CVE-2024-26704, CVE-2024-26706, CVE-2024-26707, CVE-2024-26710, CVE-2024-26712, CVE-2024-26714, CVE-2024-26715, CVE-2024-26717, CVE-2024-26718, CVE-2024-26720, CVE-2024-26722, CVE-2024-26723, CVE-2024-26726, CVE-2024-26727, CVE-2024-26731, CVE-2024-26733, CVE-2024-26735, CVE-2024-26736, CVE-2024-26737, CVE-2024-26741, CVE-2024-26742, CVE-2024-26743, CVE-2024-26744, CVE-2024-26745, CVE-2024-26747, CVE-2024-26748, CVE-2024-26749, CVE-2024-26750, CVE-2024-26751, CVE-2024-26752, CVE-2024-26753, CVE-2024-26754, CVE-2024-26759, CVE-2024-26760, CVE-2024-26761, CVE-2024-26763, CVE-2024-26764, CVE-2024-26765, CVE-2024-26766, CVE-2024-26769, CVE-2024-26771, CVE-2024-26772, CVE-2024-26773, CVE-2024-26774, CVE-2024-26775, CVE-2024-26776, CVE-2024-26777, CVE-2024-26778, CVE-2024-26779, CVE-2024-26780, CVE-2024-26781, CVE-2024-26782, CVE-2024-26787, CVE-2024-26788, CVE-2024-26789, CVE-2024-26790, CVE-2024-26791, CVE-2024-26792, CVE-2024-26793, CVE-2024-26795, CVE-2024-26798, CVE-2024-26800, CVE-2024-26801, CVE-2024-26802, CVE-2024-26803, CVE-2024-26804, CVE-2024-26805, CVE-2024-26809, CVE-2024-26810, CVE-2024-26811, CVE-2024-26812, CVE-2024-26813, CVE-2024-26814, CVE-2024-26815, CVE-2024-26816, CVE-2024-27437