Vulnerabilities

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 /> 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 /> 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: Skip finding free audio for unknown engine_id<br /> <br /> [WHY]<br /> ENGINE_ID_UNKNOWN = -1 and can not be used as an array index. Plus, it<br /> also means it is uninitialized and does not need free audio.<br /> <br /> [HOW]<br /> Skip and return NULL.<br /> <br /> This fixes 2 OVERRUN issues reported by Coverity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Check pipe offset before setting vblank<br /> <br /> pipe_ctx has a size of MAX_PIPES so checking its index before accessing<br /> the array.<br /> <br /> This fixes an OVERRUN issue reported by Coverity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Check index msg_id before read or write<br /> <br /> [WHAT]<br /> msg_id is used as an array index and it cannot be a negative value, and<br /> therefore cannot be equal to MOD_HDCP_MESSAGE_ID_INVALID (-1).<br /> <br /> [HOW]<br /> Check whether msg_id is valid before reading and setting.<br /> <br /> This fixes 4 OVERRUN issues reported by Coverity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qedf: Make qedf_execute_tmf() non-preemptible<br /> <br /> Stop calling smp_processor_id() from preemptible code in<br /> qedf_execute_tmf90. This results in BUG_ON() when running an RT kernel.<br /> <br /> [ 659.343280] BUG: using smp_processor_id() in preemptible [00000000] code: sg_reset/3646<br /> [ 659.343282] caller is qedf_execute_tmf+0x8b/0x360 [qedf]

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.