Vulnerabilities

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 /> leds: an30259a: Use devm_mutex_init() for mutex initialization<br /> <br /> In this driver LEDs are registered using devm_led_classdev_register()<br /> so they are automatically unregistered after module&amp;#39;s remove() is done.<br /> led_classdev_unregister() calls module&amp;#39;s led_set_brightness() to turn off<br /> the LEDs and that callback uses mutex which was destroyed already<br /> in module&amp;#39;s remove() so use devm API instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> leds: mlxreg: Use devm_mutex_init() for mutex initialization<br /> <br /> In this driver LEDs are registered using devm_led_classdev_register()<br /> so they are automatically unregistered after module&amp;#39;s remove() is done.<br /> led_classdev_unregister() calls module&amp;#39;s led_set_brightness() to turn off<br /> the LEDs and that callback uses mutex which was destroyed already<br /> in module&amp;#39;s remove() so use devm API instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Add NULL pointer check for kzalloc<br /> <br /> [Why &amp; How]<br /> Check return pointer of kzalloc before using it.

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 /> 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().

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM values<br /> <br /> syzbot is able to trigger softlockups, setting NL80211_ATTR_TXQ_QUANTUM<br /> to 2^31.<br /> <br /> We had a similar issue in sch_fq, fixed with commit<br /> d9e15a273306 ("pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM")<br /> <br /> watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24]<br /> Modules linked in:<br /> irq event stamp: 131135<br /> hardirqs last enabled at (131134): [] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline]<br /> hardirqs last enabled at (131134): [] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95<br /> hardirqs last disabled at (131135): [] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]<br /> hardirqs last disabled at (131135): [] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551<br /> softirqs last enabled at (125892): [] neigh_hh_init net/core/neighbour.c:1538 [inline]<br /> softirqs last enabled at (125892): [] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553<br /> softirqs last disabled at (125896): [] local_bh_disable+0x10/0x34 include/linux/bottom_half.h:19<br /> CPU: 1 PID: 24 Comm: kworker/1:0 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024<br /> Workqueue: mld mld_ifc_work<br /> pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : __list_del include/linux/list.h:195 [inline]<br /> pc : __list_del_entry include/linux/list.h:218 [inline]<br /> pc : list_move_tail include/linux/list.h:310 [inline]<br /> pc : fq_tin_dequeue include/net/fq_impl.h:112 [inline]<br /> pc : ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854<br /> lr : __list_del_entry include/linux/list.h:218 [inline]<br /> lr : list_move_tail include/linux/list.h:310 [inline]<br /> lr : fq_tin_dequeue include/net/fq_impl.h:112 [inline]<br /> lr : ieee80211_tx_dequeue+0x67c/0x3b4c net/mac80211/tx.c:3854<br /> sp : ffff800093d36700<br /> x29: ffff800093d36a60 x28: ffff800093d36960 x27: dfff800000000000<br /> x26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0<br /> x23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0<br /> x20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0<br /> x17: 000000000000d476 x16: ffff8000805519dc x15: ffff7000127a6cc8<br /> x14: 1ffff000127a6cc8 x13: 0000000000000004 x12: ffffffffffffffff<br /> x11: ffff7000127a6cc8 x10: 0000000000ff0100 x9 : 0000000000000000<br /> x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000<br /> x5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fc<br /> x2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0032470<br /> Call trace:<br /> __list_del include/linux/list.h:195 [inline]<br /> __list_del_entry include/linux/list.h:218 [inline]<br /> list_move_tail include/linux/list.h:310 [inline]<br /> fq_tin_dequeue include/net/fq_impl.h:112 [inline]<br /> ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854<br /> wake_tx_push_queue net/mac80211/util.c:294 [inline]<br /> ieee80211_handle_wake_tx_queue+0x118/0x274 net/mac80211/util.c:315<br /> drv_wake_tx_queue net/mac80211/driver-ops.h:1350 [inline]<br /> schedule_and_wake_txq net/mac80211/driver-ops.h:1357 [inline]<br /> ieee80211_queue_skb+0x18e8/0x2244 net/mac80211/tx.c:1664<br /> ieee80211_tx+0x260/0x400 net/mac80211/tx.c:1966<br /> ieee80211_xmit+0x278/0x354 net/mac80211/tx.c:2062<br /> __ieee80211_subif_start_xmit+0xab8/0x122c net/mac80211/tx.c:4338<br /> ieee80211_subif_start_xmit+0xe0/0x438 net/mac80211/tx.c:4532<br /> __netdev_start_xmit include/linux/netdevice.h:4903 [inline]<br /> netdev_start_xmit include/linux/netdevice.h:4917 [inline]<br /> xmit_one net/core/dev.c:3531 [inline]<br /> dev_hard_start_xmit+0x27c/0x938 net/core/dev.c:3547<br /> __dev_queue_xmit+0x1678/0x33fc net/core/dev.c:4341<br /> dev_queue_xmit include/linux/netdevice.h:3091 [inline]<br /> neigh_resolve_output+0x558/0x658 net/core/neighbour.c:1563<br /> neigh_output include/net/neighbour.h:542 [inline]<br /> ip6_fini<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jffs2: Fix potential illegal address access in jffs2_free_inode<br /> <br /> During the stress testing of the jffs2 file system,the following<br /> abnormal printouts were found:<br /> [ 2430.649000] Unable to handle kernel paging request at virtual address 0069696969696948<br /> [ 2430.649622] Mem abort info:<br /> [ 2430.649829] ESR = 0x96000004<br /> [ 2430.650115] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 2430.650564] SET = 0, FnV = 0<br /> [ 2430.650795] EA = 0, S1PTW = 0<br /> [ 2430.651032] FSC = 0x04: level 0 translation fault<br /> [ 2430.651446] Data abort info:<br /> [ 2430.651683] ISV = 0, ISS = 0x00000004<br /> [ 2430.652001] CM = 0, WnR = 0<br /> [ 2430.652558] [0069696969696948] address between user and kernel address ranges<br /> [ 2430.653265] Internal error: Oops: 96000004 [#1] PREEMPT SMP<br /> [ 2430.654512] CPU: 2 PID: 20919 Comm: cat Not tainted 5.15.25-g512f31242bf6 #33<br /> [ 2430.655008] Hardware name: linux,dummy-virt (DT)<br /> [ 2430.655517] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 2430.656142] pc : kfree+0x78/0x348<br /> [ 2430.656630] lr : jffs2_free_inode+0x24/0x48<br /> [ 2430.657051] sp : ffff800009eebd10<br /> [ 2430.657355] x29: ffff800009eebd10 x28: 0000000000000001 x27: 0000000000000000<br /> [ 2430.658327] x26: ffff000038f09d80 x25: 0080000000000000 x24: ffff800009d38000<br /> [ 2430.658919] x23: 5a5a5a5a5a5a5a5a x22: ffff000038f09d80 x21: ffff8000084f0d14<br /> [ 2430.659434] x20: ffff0000bf9a6ac0 x19: 0169696969696940 x18: 0000000000000000<br /> [ 2430.659969] x17: ffff8000b6506000 x16: ffff800009eec000 x15: 0000000000004000<br /> [ 2430.660637] x14: 0000000000000000 x13: 00000001000820a1 x12: 00000000000d1b19<br /> [ 2430.661345] x11: 0004000800000000 x10: 0000000000000001 x9 : ffff8000084f0d14<br /> [ 2430.662025] x8 : ffff0000bf9a6b40 x7 : ffff0000bf9a6b48 x6 : 0000000003470302<br /> [ 2430.662695] x5 : ffff00002e41dcc0 x4 : ffff0000bf9aa3b0 x3 : 0000000003470342<br /> [ 2430.663486] x2 : 0000000000000000 x1 : ffff8000084f0d14 x0 : fffffc0000000000<br /> [ 2430.664217] Call trace:<br /> [ 2430.664528] kfree+0x78/0x348<br /> [ 2430.664855] jffs2_free_inode+0x24/0x48<br /> [ 2430.665233] i_callback+0x24/0x50<br /> [ 2430.665528] rcu_do_batch+0x1ac/0x448<br /> [ 2430.665892] rcu_core+0x28c/0x3c8<br /> [ 2430.666151] rcu_core_si+0x18/0x28<br /> [ 2430.666473] __do_softirq+0x138/0x3cc<br /> [ 2430.666781] irq_exit+0xf0/0x110<br /> [ 2430.667065] handle_domain_irq+0x6c/0x98<br /> [ 2430.667447] gic_handle_irq+0xac/0xe8<br /> [ 2430.667739] call_on_irq_stack+0x28/0x54<br /> The parameter passed to kfree was 5a5a5a5a, which corresponds to the target field of<br /> the jffs_inode_info structure. It was found that all variables in the jffs_inode_info<br /> structure were 5a5a5a5a, except for the first member sem. It is suspected that these<br /> variables are not initialized because they were set to 5a5a5a5a during memory testing,<br /> which is meant to detect uninitialized memory.The sem variable is initialized in the<br /> function jffs2_i_init_once, while other members are initialized in<br /> the function jffs2_init_inode_info.<br /> <br /> The function jffs2_init_inode_info is called after iget_locked,<br /> but in the iget_locked function, the destroy_inode process is triggered,<br /> which releases the inode and consequently, the target member of the inode<br /> is not initialized.In concurrent high pressure scenarios, iget_locked<br /> may enter the destroy_inode branch as described in the code.<br /> <br /> Since the destroy_inode functionality of jffs2 only releases the target,<br /> the fix method is to set target to NULL in jffs2_i_init_once.