Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla4xxx: Prevent a potential error pointer dereference<br /> <br /> The qla4xxx_get_ep_fwdb() function is supposed to return NULL on error,<br /> but qla4xxx_ep_connect() returns error pointers. Propagating the error<br /> pointers will lead to an Oops in the caller, so change the error pointers<br /> to NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Add null pointer check in mod_hdcp_hdcp1_create_session()<br /> <br /> The function mod_hdcp_hdcp1_create_session() calls the function<br /> get_first_active_display(), but does not check its return value.<br /> The return value is a null pointer if the display list is empty.<br /> This will lead to a null pointer dereference.<br /> <br /> Add a null pointer check for get_first_active_display() and return<br /> MOD_HDCP_STATUS_DISPLAY_NOT_FOUND if the function return null.<br /> <br /> This is similar to the commit c3e9826a2202<br /> ("drm/amd/display: Add null pointer check for get_first_active_display()").<br /> <br /> (cherry picked from commit 5e43eb3cd731649c4f8b9134f857be62a416c893)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: ufs-qcom: Fix ESI null pointer dereference<br /> <br /> ESI/MSI is a performance optimization feature that provides dedicated<br /> interrupts per MCQ hardware queue. This is optional feature and UFS MCQ<br /> should work with and without ESI feature.<br /> <br /> Commit e46a28cea29a ("scsi: ufs: qcom: Remove the MSI descriptor abuse")<br /> brings a regression in ESI (Enhanced System Interrupt) configuration that<br /> causes a null pointer dereference when Platform MSI allocation fails.<br /> <br /> The issue occurs in when platform_device_msi_init_and_alloc_irqs() in<br /> ufs_qcom_config_esi() fails (returns -EINVAL) but the current code uses<br /> __free() macro for automatic cleanup free MSI resources that were never<br /> successfully allocated.<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual<br /> address 0000000000000008<br /> <br /> Call trace:<br /> mutex_lock+0xc/0x54 (P)<br /> platform_device_msi_free_irqs_all+0x1c/0x40<br /> ufs_qcom_config_esi+0x1d0/0x220 [ufs_qcom]<br /> ufshcd_config_mcq+0x28/0x104<br /> ufshcd_init+0xa3c/0xf40<br /> ufshcd_pltfrm_init+0x504/0x7d4<br /> ufs_qcom_probe+0x20/0x58 [ufs_qcom]<br /> <br /> Fix by restructuring the ESI configuration to try MSI allocation first,<br /> before any other resource allocation and instead use explicit cleanup<br /> instead of __free() macro to avoid cleanup of unallocated resources.<br /> <br /> Tested on SM8750 platform with MCQ enabled, both with and without<br /> Platform ESI support.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Fix oops due to uninitialised variable<br /> <br /> Fix smb3_init_transform_rq() to initialise buffer to NULL before calling<br /> netfs_alloc_folioq_buffer() as netfs assumes it can append to the buffer it<br /> is given. Setting it to NULL means it should start a fresh buffer, but the<br /> value is currently undefined.

PTZOptics and possibly other ValueHD-based pan-tilt-zoom cameras use default, shared credentials for the administrative web interface.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: asix_devices: Fix PHY address mask in MDIO bus initialization<br /> <br /> Syzbot reported shift-out-of-bounds exception on MDIO bus initialization.<br /> <br /> The PHY address should be masked to 5 bits (0-31). Without this<br /> mask, invalid PHY addresses could be used, potentially causing issues<br /> with MDIO bus operations.<br /> <br /> Fix this by masking the PHY address with 0x1f (31 decimal) to ensure<br /> it stays within the valid range.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gve: prevent ethtool ops after shutdown<br /> <br /> A crash can occur if an ethtool operation is invoked<br /> after shutdown() is called.<br /> <br /> shutdown() is invoked during system shutdown to stop DMA operations<br /> without performing expensive deallocations. It is discouraged to<br /> unregister the netdev in this path, so the device may still be visible<br /> to userspace and kernel helpers.<br /> <br /> In gve, shutdown() tears down most internal data structures. If an<br /> ethtool operation is dispatched after shutdown(), it will dereference<br /> freed or NULL pointers, leading to a kernel panic. While graceful<br /> shutdown normally quiesces userspace before invoking the reboot<br /> syscall, forced shutdowns (as observed on GCP VMs) can still trigger<br /> this path.<br /> <br /> Fix by calling netif_device_detach() in shutdown().<br /> This marks the device as detached so the ethtool ioctl handler<br /> will skip dispatching operations to the driver.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_reject: don&amp;#39;t leak dst refcount for loopback packets<br /> <br /> recent patches to add a WARN() when replacing skb dst entry found an<br /> old bug:<br /> <br /> WARNING: include/linux/skbuff.h:1165 skb_dst_check_unset include/linux/skbuff.h:1164 [inline]<br /> WARNING: include/linux/skbuff.h:1165 skb_dst_set include/linux/skbuff.h:1210 [inline]<br /> WARNING: include/linux/skbuff.h:1165 nf_reject_fill_skb_dst+0x2a4/0x330 net/ipv4/netfilter/nf_reject_ipv4.c:234<br /> [..]<br /> Call Trace:<br /> nf_send_unreach+0x17b/0x6e0 net/ipv4/netfilter/nf_reject_ipv4.c:325<br /> nft_reject_inet_eval+0x4bc/0x690 net/netfilter/nft_reject_inet.c:27<br /> expr_call_ops_eval net/netfilter/nf_tables_core.c:237 [inline]<br /> ..<br /> <br /> This is because blamed commit forgot about loopback packets.<br /> Such packets already have a dst_entry attached, even at PRE_ROUTING stage.<br /> <br /> Instead of checking hook just check if the skb already has a route<br /> attached to it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Fix vm_bind_ioctl double free bug<br /> <br /> If the argument check during an array bind fails, the bind_ops are freed<br /> twice as seen below. Fix this by setting bind_ops to NULL after freeing.<br /> <br /> ==================================================================<br /> BUG: KASAN: double-free in xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]<br /> Free of addr ffff88813bb9b800 by task xe_vm/14198<br /> <br /> CPU: 5 UID: 0 PID: 14198 Comm: xe_vm Not tainted 6.16.0-xe-eudebug-cmanszew+ #520 PREEMPT(full)<br /> Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR5 RVP, BIOS ADLPFWI1.R00.2411.A02.2110081023 10/08/2021<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x82/0xd0<br /> print_report+0xcb/0x610<br /> ? __virt_addr_valid+0x19a/0x300<br /> ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]<br /> kasan_report_invalid_free+0xc8/0xf0<br /> ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]<br /> ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]<br /> check_slab_allocation+0x102/0x130<br /> kfree+0x10d/0x440<br /> ? should_fail_ex+0x57/0x2f0<br /> ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]<br /> xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]<br /> ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe]<br /> ? __lock_acquire+0xab9/0x27f0<br /> ? lock_acquire+0x165/0x300<br /> ? drm_dev_enter+0x53/0xe0 [drm]<br /> ? find_held_lock+0x2b/0x80<br /> ? drm_dev_exit+0x30/0x50 [drm]<br /> ? drm_ioctl_kernel+0x128/0x1c0 [drm]<br /> drm_ioctl_kernel+0x128/0x1c0 [drm]<br /> ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe]<br /> ? find_held_lock+0x2b/0x80<br /> ? __pfx_drm_ioctl_kernel+0x10/0x10 [drm]<br /> ? should_fail_ex+0x57/0x2f0<br /> ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe]<br /> drm_ioctl+0x352/0x620 [drm]<br /> ? __pfx_drm_ioctl+0x10/0x10 [drm]<br /> ? __pfx_rpm_resume+0x10/0x10<br /> ? do_raw_spin_lock+0x11a/0x1b0<br /> ? find_held_lock+0x2b/0x80<br /> ? __pm_runtime_resume+0x61/0xc0<br /> ? rcu_is_watching+0x20/0x50<br /> ? trace_irq_enable.constprop.0+0xac/0xe0<br /> xe_drm_ioctl+0x91/0xc0 [xe]<br /> __x64_sys_ioctl+0xb2/0x100<br /> ? rcu_is_watching+0x20/0x50<br /> do_syscall_64+0x68/0x2e0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7fa9acb24ded<br /> <br /> (cherry picked from commit a01b704527c28a2fd43a17a85f8996b75ec8492a)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/mm: Do not map lowcore with identity mapping<br /> <br /> Since the identity mapping is pinned to address zero the lowcore is always<br /> also mapped to address zero, this happens regardless of the relocate_lowcore<br /> command line option. If the option is specified the lowcore is mapped<br /> twice, instead of only once.<br /> <br /> This means that NULL pointer accesses will succeed instead of causing an<br /> exception (low address protection still applies, but covers only parts).<br /> To fix this never map the first two pages of physical memory with the<br /> identity mapping.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: fix UAF on smcsk after smc_listen_out()<br /> <br /> BPF CI testing report a UAF issue:<br /> <br /> [ 16.446633] BUG: kernel NULL pointer dereference, address: 000000000000003 0<br /> [ 16.447134] #PF: supervisor read access in kernel mod e<br /> [ 16.447516] #PF: error_code(0x0000) - not-present pag e<br /> [ 16.447878] PGD 0 P4D 0<br /> [ 16.448063] Oops: Oops: 0000 [#1] PREEMPT SMP NOPT I<br /> [ 16.448409] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Tainted: G OE 6.13.0-rc3-g89e8a75fda73-dirty #4 2<br /> [ 16.449124] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODUL E<br /> [ 16.449502] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/201 4<br /> [ 16.450201] Workqueue: smc_hs_wq smc_listen_wor k<br /> [ 16.450531] RIP: 0010:smc_listen_work+0xc02/0x159 0<br /> [ 16.452158] RSP: 0018:ffffb5ab40053d98 EFLAGS: 0001024 6<br /> [ 16.452526] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 000000000000030 0<br /> [ 16.452994] RDX: 0000000000000280 RSI: 00003513840053f0 RDI: 000000000000000 0<br /> [ 16.453492] RBP: ffffa097808e3800 R08: ffffa09782dba1e0 R09: 000000000000000 5<br /> [ 16.453987] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa0978274640 0<br /> [ 16.454497] R13: 0000000000000000 R14: 0000000000000000 R15: ffffa09782d4092 0<br /> [ 16.454996] FS: 0000000000000000(0000) GS:ffffa097bbc00000(0000) knlGS:000000000000000 0<br /> [ 16.455557] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003 3<br /> [ 16.455961] CR2: 0000000000000030 CR3: 0000000102788004 CR4: 0000000000770ef 0<br /> [ 16.456459] PKRU: 5555555 4<br /> [ 16.456654] Call Trace :<br /> [ 16.456832] <br /> [ 16.456989] ? __die+0x23/0x7 0<br /> [ 16.457215] ? page_fault_oops+0x180/0x4c 0<br /> [ 16.457508] ? __lock_acquire+0x3e6/0x249 0<br /> [ 16.457801] ? exc_page_fault+0x68/0x20 0<br /> [ 16.458080] ? asm_exc_page_fault+0x26/0x3 0<br /> [ 16.458389] ? smc_listen_work+0xc02/0x159 0<br /> [ 16.458689] ? smc_listen_work+0xc02/0x159 0<br /> [ 16.458987] ? lock_is_held_type+0x8f/0x10 0<br /> [ 16.459284] process_one_work+0x1ea/0x6d 0<br /> [ 16.459570] worker_thread+0x1c3/0x38 0<br /> [ 16.459839] ? __pfx_worker_thread+0x10/0x1 0<br /> [ 16.460144] kthread+0xe0/0x11 0<br /> [ 16.460372] ? __pfx_kthread+0x10/0x1 0<br /> [ 16.460640] ret_from_fork+0x31/0x5 0<br /> [ 16.460896] ? __pfx_kthread+0x10/0x1 0<br /> [ 16.461166] ret_from_fork_asm+0x1a/0x3 0<br /> [ 16.461453] <br /> [ 16.461616] Modules linked in: bpf_testmod(OE) [last unloaded: bpf_testmod(OE) ]<br /> [ 16.462134] CR2: 000000000000003 0<br /> [ 16.462380] ---[ end trace 0000000000000000 ]---<br /> [ 16.462710] RIP: 0010:smc_listen_work+0xc02/0x1590<br /> <br /> The direct cause of this issue is that after smc_listen_out_connected(),<br /> newclcsock-&gt;sk may be NULL since it will releases the smcsk. Therefore,<br /> if the application closes the socket immediately after accept,<br /> newclcsock-&gt;sk can be NULL. A possible execution order could be as<br /> follows:<br /> <br /> smc_listen_work | userspace<br /> -----------------------------------------------------------------<br /> lock_sock(sk) |<br /> smc_listen_out_connected() |<br /> | \- smc_listen_out |<br /> | | \- release_sock |<br /> | |- sk-&gt;sk_data_ready() |<br /> | fd = accept();<br /> | close(fd);<br /> | \- socket-&gt;sk = NULL;<br /> /* newclcsock-&gt;sk is NULL now */<br /> SMC_STAT_SERV_SUCC_INC(sock_net(newclcsock-&gt;sk))<br /> <br /> Since smc_listen_out_connected() will not fail, simply swapping the order<br /> of the code can easily fix this issue.

PTZOptics and possibly other ValueHD-based pan-tilt-zoom cameras use hard-coded, default administrative credentials. The passwords can readily be cracked. Many cameras have SSH or telnet listening on all interfaces. The passwords cannot be changed by the user, nor can the SSH or telnet service be disabled by the user.