Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc: Avoid nmi_enter/nmi_exit in real mode interrupt.<br /> <br /> nmi_enter()/nmi_exit() touches per cpu variables which can lead to kernel<br /> crash when invoked during real mode interrupt handling (e.g. early HMI/MCE<br /> interrupt handler) if percpu allocation comes from vmalloc area.<br /> <br /> Early HMI/MCE handlers are called through DEFINE_INTERRUPT_HANDLER_NMI()<br /> wrapper which invokes nmi_enter/nmi_exit calls. We don&amp;#39;t see any issue when<br /> percpu allocation is from the embedded first chunk. However with<br /> CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK enabled there are chances where percpu<br /> allocation can come from the vmalloc area.<br /> <br /> With kernel command line "percpu_alloc=page" we can force percpu allocation<br /> to come from vmalloc area and can see kernel crash in machine_check_early:<br /> <br /> [ 1.215714] NIP [c000000000e49eb4] rcu_nmi_enter+0x24/0x110<br /> [ 1.215717] LR [c0000000000461a0] machine_check_early+0xf0/0x2c0<br /> [ 1.215719] --- interrupt: 200<br /> [ 1.215720] [c000000fffd73180] [0000000000000000] 0x0 (unreliable)<br /> [ 1.215722] [c000000fffd731b0] [0000000000000000] 0x0<br /> [ 1.215724] [c000000fffd73210] [c000000000008364] machine_check_early_common+0x134/0x1f8<br /> <br /> Fix this by avoiding use of nmi_enter()/nmi_exit() in real mode if percpu<br /> first chunk is not embedded.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/lima: fix shared irq handling on driver remove<br /> <br /> lima uses a shared interrupt, so the interrupt handlers must be prepared<br /> to be called at any time. At driver removal time, the clocks are<br /> disabled early and the interrupts stay registered until the very end of<br /> the remove process due to the devm usage.<br /> This is potentially a bug as the interrupts access device registers<br /> which assumes clocks are enabled. A crash can be triggered by removing<br /> the driver in a kernel with CONFIG_DEBUG_SHIRQ enabled.<br /> This patch frees the interrupts at each lima device finishing callback<br /> so that the handlers are already unregistered by the time we fully<br /> disable clocks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Don&amp;#39;t process extts if PTP is disabled<br /> <br /> The ice_ptp_extts_event() function can race with ice_ptp_release() and<br /> result in a NULL pointer dereference which leads to a kernel panic.<br /> <br /> Panic occurs because the ice_ptp_extts_event() function calls<br /> ptp_clock_event() with a NULL pointer. The ice driver has already<br /> released the PTP clock by the time the interrupt for the next external<br /> timestamp event occurs.<br /> <br /> To fix this, modify the ice_ptp_extts_event() function to check the<br /> PTP state and bail early if PTP is not ready.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: rswitch: Avoid use-after-free in rswitch_poll()<br /> <br /> The use-after-free is actually in rswitch_tx_free(), which is inlined in<br /> rswitch_poll(). Since `skb` and `gq-&gt;skbs[gq-&gt;dirty]` are in fact the<br /> same pointer, the skb is first freed using dev_kfree_skb_any(), then the<br /> value in skb-&gt;len is used to update the interface statistics.<br /> <br /> Let&amp;#39;s move around the instructions to use skb-&gt;len before the skb is<br /> freed.<br /> <br /> This bug is trivial to reproduce using KFENCE. It will trigger a splat<br /> every few packets. A simple ARP request or ICMP echo request is enough.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: always do the basic checks for btrfs_qgroup_inherit structure<br /> <br /> [BUG]<br /> Syzbot reports the following regression detected by KASAN:<br /> <br /> BUG: KASAN: slab-out-of-bounds in btrfs_qgroup_inherit+0x42e/0x2e20 fs/btrfs/qgroup.c:3277<br /> Read of size 8 at addr ffff88814628ca50 by task syz-executor318/5171<br /> <br /> CPU: 0 PID: 5171 Comm: syz-executor318 Not tainted 6.10.0-rc2-syzkaller-00010-g2ab795141095 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114<br /> print_address_description mm/kasan/report.c:377 [inline]<br /> print_report+0x169/0x550 mm/kasan/report.c:488<br /> kasan_report+0x143/0x180 mm/kasan/report.c:601<br /> btrfs_qgroup_inherit+0x42e/0x2e20 fs/btrfs/qgroup.c:3277<br /> create_pending_snapshot+0x1359/0x29b0 fs/btrfs/transaction.c:1854<br /> create_pending_snapshots+0x195/0x1d0 fs/btrfs/transaction.c:1922<br /> btrfs_commit_transaction+0xf20/0x3740 fs/btrfs/transaction.c:2382<br /> create_snapshot+0x6a1/0x9e0 fs/btrfs/ioctl.c:875<br /> btrfs_mksubvol+0x58f/0x710 fs/btrfs/ioctl.c:1029<br /> btrfs_mksnapshot+0xb5/0xf0 fs/btrfs/ioctl.c:1075<br /> __btrfs_ioctl_snap_create+0x387/0x4b0 fs/btrfs/ioctl.c:1340<br /> btrfs_ioctl_snap_create_v2+0x1f2/0x3a0 fs/btrfs/ioctl.c:1422<br /> btrfs_ioctl+0x99e/0xc60<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:907 [inline]<br /> __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7fcbf1992509<br /> RSP: 002b:00007fcbf1928218 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 00007fcbf1a1f618 RCX: 00007fcbf1992509<br /> RDX: 0000000020000280 RSI: 0000000050009417 RDI: 0000000000000003<br /> RBP: 00007fcbf1a1f610 R08: 00007ffea1298e97 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 00007fcbf19eb660<br /> R13: 00000000200002b8 R14: 00007fcbf19e60c0 R15: 0030656c69662f2e<br /> <br /> <br /> And it also pinned it down to commit b5357cb268c4 ("btrfs: qgroup: do not<br /> check qgroup inherit if qgroup is disabled").<br /> <br /> [CAUSE]<br /> That offending commit skips the whole qgroup inherit check if qgroup is<br /> not enabled.<br /> <br /> But that also skips the very basic checks like<br /> num_ref_copies/num_excl_copies and the structure size checks.<br /> <br /> Meaning if a qgroup enable/disable race is happening at the background,<br /> and we pass a btrfs_qgroup_inherit structure when the qgroup is<br /> disabled, the check would be completely skipped.<br /> <br /> Then at the time of transaction commitment, qgroup is re-enabled and<br /> btrfs_qgroup_inherit() is going to use the incorrect structure and<br /> causing the above KASAN error.<br /> <br /> [FIX]<br /> Make btrfs_qgroup_check_inherit() only skip the source qgroup checks.<br /> So that even if invalid btrfs_qgroup_inherit structure is passed in, we<br /> can still reject invalid ones no matter if qgroup is enabled or not.<br /> <br /> Furthermore we do already have an extra safety inside<br /> btrfs_qgroup_inherit(), which would just ignore invalid qgroup sources,<br /> so even if we only skip the qgroup source check we&amp;#39;re still safe.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: txgbe: free isb resources at the right time<br /> <br /> When using MSI/INTx interrupt, the shared interrupts are still being<br /> handled in the device remove routine, before free IRQs. So isb memory<br /> is still read after it is freed. Thus move wx_free_isb_resources()<br /> from txgbe_close() to txgbe_remove(). And fix the improper isb free<br /> action in txgbe_open() error handling path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: txgbe: initialize num_q_vectors for MSI/INTx interrupts<br /> <br /> When using MSI/INTx interrupts, wx-&gt;num_q_vectors is uninitialized.<br /> Thus there will be kernel panic in wx_alloc_q_vectors() to allocate<br /> queue vectors.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix inode number range checks<br /> <br /> Patch series "nilfs2: fix potential issues related to reserved inodes".<br /> <br /> This series fixes one use-after-free issue reported by syzbot, caused by<br /> nilfs2&amp;#39;s internal inode being exposed in the namespace on a corrupted<br /> filesystem, and a couple of flaws that cause problems if the starting<br /> number of non-reserved inodes written in the on-disk super block is<br /> intentionally (or corruptly) changed from its default value. <br /> <br /> <br /> This patch (of 3):<br /> <br /> In the current implementation of nilfs2, "nilfs-&gt;ns_first_ino", which<br /> gives the first non-reserved inode number, is read from the superblock,<br /> but its lower limit is not checked.<br /> <br /> As a result, if a number that overlaps with the inode number range of<br /> reserved inodes such as the root directory or metadata files is set in the<br /> super block parameter, the inode number test macros (NILFS_MDT_INODE and<br /> NILFS_VALID_INODE) will not function properly.<br /> <br /> In addition, these test macros use left bit-shift calculations using with<br /> the inode number as the shift count via the BIT macro, but the result of a<br /> shift calculation that exceeds the bit width of an integer is undefined in<br /> the C specification, so if "ns_first_ino" is set to a large value other<br /> than the default value NILFS_USER_INO (=11), the macros may potentially<br /> malfunction depending on the environment.<br /> <br /> Fix these issues by checking the lower bound of "nilfs-&gt;ns_first_ino" and<br /> by preventing bit shifts equal to or greater than the NILFS_USER_INO<br /> constant in the inode number test macros.<br /> <br /> Also, change the type of "ns_first_ino" from signed integer to unsigned<br /> integer to avoid the need for type casting in comparisons such as the<br /> lower bound check introduced this time.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> inet_diag: Initialize pad field in struct inet_diag_req_v2<br /> <br /> KMSAN reported uninit-value access in raw_lookup() [1]. Diag for raw<br /> sockets uses the pad field in struct inet_diag_req_v2 for the<br /> underlying protocol. This field corresponds to the sdiag_raw_protocol<br /> field in struct inet_diag_req_raw.<br /> <br /> inet_diag_get_exact_compat() converts inet_diag_req to<br /> inet_diag_req_v2, but leaves the pad field uninitialized. So the issue<br /> occurs when raw_lookup() accesses the sdiag_raw_protocol field.<br /> <br /> Fix this by initializing the pad field in<br /> inet_diag_get_exact_compat(). Also, do the same fix in<br /> inet_diag_dump_compat() to avoid the similar issue in the future.<br /> <br /> [1]<br /> BUG: KMSAN: uninit-value in raw_lookup net/ipv4/raw_diag.c:49 [inline]<br /> BUG: KMSAN: uninit-value in raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71<br /> raw_lookup net/ipv4/raw_diag.c:49 [inline]<br /> raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71<br /> raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99<br /> inet_diag_cmd_exact+0x7d9/0x980<br /> inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline]<br /> inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426<br /> sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282<br /> netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564<br /> sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]<br /> netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361<br /> netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg+0x332/0x3d0 net/socket.c:745<br /> ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585<br /> ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639<br /> __sys_sendmsg net/socket.c:2668 [inline]<br /> __do_sys_sendmsg net/socket.c:2677 [inline]<br /> __se_sys_sendmsg net/socket.c:2675 [inline]<br /> __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675<br /> x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Uninit was stored to memory at:<br /> raw_sock_get+0x650/0x800 net/ipv4/raw_diag.c:71<br /> raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99<br /> inet_diag_cmd_exact+0x7d9/0x980<br /> inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline]<br /> inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426<br /> sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282<br /> netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564<br /> sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]<br /> netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361<br /> netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg+0x332/0x3d0 net/socket.c:745<br /> ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585<br /> ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639<br /> __sys_sendmsg net/socket.c:2668 [inline]<br /> __do_sys_sendmsg net/socket.c:2677 [inline]<br /> __se_sys_sendmsg net/socket.c:2675 [inline]<br /> __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675<br /> x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Local variable req.i created at:<br /> inet_diag_get_exact_compat net/ipv4/inet_diag.c:1396 [inline]<br /> inet_diag_rcv_msg_compat+0x2a6/0x530 net/ipv4/inet_diag.c:1426<br /> sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282<br /> <br /> CPU: 1 PID: 8888 Comm: syz-executor.6 Not tainted 6.10.0-rc4-00217-g35bb670d65fc #32<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: unconditionally flush pending work before notifier<br /> <br /> syzbot reports:<br /> <br /> KASAN: slab-uaf in nft_ctx_update include/net/netfilter/nf_tables.h:1831<br /> KASAN: slab-uaf in nft_commit_release net/netfilter/nf_tables_api.c:9530<br /> KASAN: slab-uaf int nf_tables_trans_destroy_work+0x152b/0x1750 net/netfilter/nf_tables_api.c:9597<br /> Read of size 2 at addr ffff88802b0051c4 by task kworker/1:1/45<br /> [..]<br /> Workqueue: events nf_tables_trans_destroy_work<br /> Call Trace:<br /> nft_ctx_update include/net/netfilter/nf_tables.h:1831 [inline]<br /> nft_commit_release net/netfilter/nf_tables_api.c:9530 [inline]<br /> nf_tables_trans_destroy_work+0x152b/0x1750 net/netfilter/nf_tables_api.c:9597<br /> <br /> Problem is that the notifier does a conditional flush, but its possible<br /> that the table-to-be-removed is still referenced by transactions being<br /> processed by the worker, so we need to flush unconditionally.<br /> <br /> We could make the flush_work depend on whether we found a table to delete<br /> in nf-next to avoid the flush for most cases.<br /> <br /> AFAICS this problem is only exposed in nf-next, with<br /> commit e169285f8c56 ("netfilter: nf_tables: do not store nft_ctx in transaction objects"),<br /> with this commit applied there is an unconditional fetch of<br /> table-&gt;family which is whats triggering the above splat.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ntb_netdev: Move ntb_netdev_rx_handler() to call netif_rx() from __netif_rx()<br /> <br /> The following is emitted when using idxd (DSA) dmanegine as the data<br /> mover for ntb_transport that ntb_netdev uses.<br /> <br /> [74412.546922] BUG: using smp_processor_id() in preemptible [00000000] code: irq/52-idxd-por/14526<br /> [74412.556784] caller is netif_rx_internal+0x42/0x130<br /> [74412.562282] CPU: 6 PID: 14526 Comm: irq/52-idxd-por Not tainted 6.9.5 #5<br /> [74412.569870] Hardware name: Intel Corporation ArcherCity/ArcherCity, BIOS EGSDCRB1.E9I.1752.P05.2402080856 02/08/2024<br /> [74412.581699] Call Trace:<br /> [74412.584514] <br /> [74412.586933] dump_stack_lvl+0x55/0x70<br /> [74412.591129] check_preemption_disabled+0xc8/0xf0<br /> [74412.596374] netif_rx_internal+0x42/0x130<br /> [74412.600957] __netif_rx+0x20/0xd0<br /> [74412.604743] ntb_netdev_rx_handler+0x66/0x150 [ntb_netdev]<br /> [74412.610985] ntb_complete_rxc+0xed/0x140 [ntb_transport]<br /> [74412.617010] ntb_rx_copy_callback+0x53/0x80 [ntb_transport]<br /> [74412.623332] idxd_dma_complete_txd+0xe3/0x160 [idxd]<br /> [74412.628963] idxd_wq_thread+0x1a6/0x2b0 [idxd]<br /> [74412.634046] irq_thread_fn+0x21/0x60<br /> [74412.638134] ? irq_thread+0xa8/0x290<br /> [74412.642218] irq_thread+0x1a0/0x290<br /> [74412.646212] ? __pfx_irq_thread_fn+0x10/0x10<br /> [74412.651071] ? __pfx_irq_thread_dtor+0x10/0x10<br /> [74412.656117] ? __pfx_irq_thread+0x10/0x10<br /> [74412.660686] kthread+0x100/0x130<br /> [74412.664384] ? __pfx_kthread+0x10/0x10<br /> [74412.668639] ret_from_fork+0x31/0x50<br /> [74412.672716] ? __pfx_kthread+0x10/0x10<br /> [74412.676978] ret_from_fork_asm+0x1a/0x30<br /> [74412.681457] <br /> <br /> The cause is due to the idxd driver interrupt completion handler uses<br /> threaded interrupt and the threaded handler is not hard or soft interrupt<br /> context. However __netif_rx() can only be called from interrupt context.<br /> Change the call to netif_rx() in order to allow completion via normal<br /> context for dmaengine drivers that utilize threaded irq handling.<br /> <br /> While the following commit changed from netif_rx() to __netif_rx(),<br /> baebdf48c360 ("net: dev: Makes sure netif_rx() can be invoked in any context."),<br /> the change should&amp;#39;ve been a noop instead. However, the code precedes this<br /> fix should&amp;#39;ve been using netif_rx_ni() or netif_rx_any_context().