Логотип exploitDog
Консоль
Логотип exploitDog

exploitDog

suse-cvrf логотип

SUSE-SU-2024:3984-1

Опубликовано: 13 нояб. 2024
Источник: suse-cvrf

Описание

Security update for the Linux Kernel

The SUSE Linux Enterprise 15 SP6 Azure kernel was updated to receive various security bugfixes.

The following security bugs were fixed:

  • CVE-2024-36244: net/sched: taprio: extend minimum interval restriction to entire cycle too (bsc#1226797).
  • CVE-2024-41031: mm/filemap: skip to create PMD-sized page cache if needed (bsc#1228454).
  • CVE-2024-41082: nvme-fabrics: use reserved tag for reg read/write command (bsc#1228620).
  • CVE-2024-44958: sched/smt: Fix unbalance sched_smt_present dec/inc (bsc#1230179).
  • CVE-2024-45016: netem: fix return value if duplicate enqueue fails (bsc#1230429).
  • CVE-2024-45025: fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE (bsc#1230456).
  • CVE-2024-46678: bonding: change ipsec_lock from spin lock to mutex (bsc#1230550).
  • CVE-2024-46721: pparmor: fix possible NULL pointer dereference (bsc#1230710)
  • CVE-2024-46754: bpf: Remove tst_run from lwt_seg6local_prog_ops (bsc#1230801).
  • CVE-2024-46766: ice: move netif_queue_set_napi to rtnl-protected sections (bsc#1230762).
  • CVE-2024-46770: ice: Add netif_device_attach/detach into PF reset flow (bsc#1230763).
  • CVE-2024-46775: drm/amd/display: Validate function returns (bsc#1230774).
  • CVE-2024-46777: udf: Avoid excessive partition lengths (bsc#1230773).
  • CVE-2024-46813: drm/amd/display: Check link_index before accessing dc->links (bsc#1231191).
  • CVE-2024-46816: drm/amd/display: Stop amdgpu_dm initialize when link nums greater than max_links (bsc#1231197).
  • CVE-2024-46826: ELF: fix kernel.randomize_va_space double read (bsc#1231115).
  • CVE-2024-46828: uprobes: fix kernel info leak via '[uprobes]' vma (bsc#1231114).
  • CVE-2024-46831: net: microchip: vcap: Fix use-after-free error in kunit test (bsc#1231117).
  • CVE-2024-46834: ethtool: fail closed if we can't get max channel used in indirection tables (bsc#1231096).
  • CVE-2024-46840: btrfs: clean up our handling of refs == 0 in snapshot delete (bsc#1231105).
  • CVE-2024-46841: btrfs: do not BUG_ON on ENOMEM from btrfs_lookup_extent_info() in walk_down_proc() (bsc#1231094).
  • CVE-2024-46843: scsi: ufs: core: Remove SCSI host only if added (bsc#1231100).
  • CVE-2024-46854: net: dpaa: Pad packets to ETH_ZLEN (bsc#1231084).
  • CVE-2024-46855: netfilter: nft_socket: fix sk refcount leaks (bsc#1231085).
  • CVE-2024-46857: net/mlx5: Fix bridge mode operations when there are no VFs (bsc#1231087).
  • CVE-2024-46870: drm/amd/display: Disable DMCUB timeout for DCN35 (bsc#1231435).
  • CVE-2024-47658: crypto: stm32/cryp - call finalize with bh disabled (bsc#1231436).
  • CVE-2024-47660: fsnotify: clear PARENT_WATCHED flags lazily (bsc#1231439).
  • CVE-2024-47664: spi: hisi-kunpeng: Add verification for the max_frequency provided by the firmware (bsc#1231442).
  • CVE-2024-47674: mm: avoid leaving partial pfn mappings around in error case (bsc#1231673).
  • CVE-2024-47684: tcp: check skb is non-NULL in tcp_rto_delta_us() (bsc#1231987).
  • CVE-2024-47685: netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() (bsc#1231998).
  • CVE-2024-47687: vdpa/mlx5: Fix invalid mr resource destroy (bsc#1232003).
  • CVE-2024-47692: nfsd: return -EINVAL when namelen is 0 (bsc#1231857).
  • CVE-2024-47704: drm/amd/display: Check link_res->hpo_dp_link_enc before using it (bsc#1231944).
  • CVE-2024-47705: block: fix potential invalid pointer dereference in blk_add_partition (bsc#1231872).
  • CVE-2024-47706: block, bfq: fix possible UAF for bfqq->bic with merge chain (bsc#1231942).
  • CVE-2024-47707: ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev() (bsc#1231935).
  • CVE-2024-47710: sock_map: Add a cond_resched() in sock_hash_free() (bsc#1232049).
  • CVE-2024-47727: x86/tdx: Fix 'in-kernel MMIO' check (bsc#1232116).
  • CVE-2024-47730: crypto: hisilicon/qm - inject error before stopping queue (bsc#1232075).
  • CVE-2024-47731: drivers/perf: Fix ali_drw_pmu driver interrupt status clearing (bsc#1232117).
  • CVE-2024-47739: padata: use integer wrap around to prevent deadlock on seq_nr overflow (bsc#1232124).
  • CVE-2024-47741: btrfs: fix race setting file private on concurrent lseek using same fd (bsc#1231869).
  • CVE-2024-47745: mm: split critical region in remap_file_pages() and invoke LSMs in between (bsc#1232135).
  • CVE-2024-47747: net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition (bsc#1232145).
  • CVE-2024-47752: media: mediatek: vcodec: Fix H264 stateless decoder smatch warning (bsc#1232130).
  • CVE-2024-47753: media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning (bsc#1231868).
  • CVE-2024-47754: media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning (bsc#1232131).
  • CVE-2024-49852: scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del() (bsc#1232819).
  • CVE-2024-49864: rxrpc: Fix a race between socket set up and I/O thread creation (bsc#1232256).
  • CVE-2024-49867: btrfs: wait for fixup workers before stopping cleaner kthread during umount (bsc#1232262).
  • CVE-2024-49881: ext4: update orig_path in ext4_find_extent() (bsc#1232201).
  • CVE-2024-49882: ext4: fix double brelse() the buffer of the extents path (bsc#1232200).
  • CVE-2024-49883: ext4: aovid use-after-free in ext4_ext_insert_extent() (bsc#1232199).
  • CVE-2024-49888: bpf: Fix a sdiv overflow issue (bsc#1232208).
  • CVE-2024-49890: drm/amd/pm: ensure the fw_info is not null before using it (bsc#1232217).
  • CVE-2024-49892: drm/amd/display: Initialize get_bytes_per_element's default to 1 (bsc#1232220).
  • CVE-2024-49894: drm/amd/display: Fix index out of bounds in degamma hardware format translation (bsc#1232354).
  • CVE-2024-49895: drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation (bsc#1232352).
  • CVE-2024-49896: drm/amd/display: Check stream before comparing them (bsc#1232221).
  • CVE-2024-49897: drm/amd/display: Check phantom_stream before it is used (bsc#1232355).
  • CVE-2024-49898: drm/amd/display: Check null-initialized variables (bsc#1232222).
  • CVE-2024-49901: drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrs (bsc#1232305).
  • CVE-2024-49906: drm/amd/display: Check null pointer before try to access it (bsc#1232332).
  • CVE-2024-49907: drm/amd/display: Check null pointers before using dc->clk_mgr (bsc#1232334).
  • CVE-2024-49908: drm/amd/display: Add null check for 'afb' in amdgpu_dm_update_cursor (bsc#1232335).
  • CVE-2024-49909: drm/amd/display: Add NULL check for function pointer in dcn32_set_output_transfer_func (bsc#1232337).
  • CVE-2024-49913: drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_stream (bsc#1232307).
  • CVE-2024-49914: drm/amd/display: Add null check for pipe_ctx->plane_state in (bsc#1232369).
  • CVE-2024-49917: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn30_init_hw (bsc#1231965).
  • CVE-2024-49918: drm/amd/display: Add null check for head_pipe in dcn32_acquire_idle_pipe_for_head_pipe_in_layer (bsc#1231967).
  • CVE-2024-49919: drm/amd/display: Add null check for head_pipe in dcn201_acquire_free_pipe_for_layer (bsc#1231968).
  • CVE-2024-49920: drm/amd/display: Check null pointers before multiple uses (bsc#1232313).
  • CVE-2024-49936: net/xen-netback: prevent UAF in xenvif_flush_hash() (bsc#1232424).
  • CVE-2024-49946: ppp: do not assume bh is held in ppp_channel_bridge_input() (bsc#1232164).
  • CVE-2024-49949: net: avoid potential underflow in qdisc_pkt_len_init() with UFO (bsc#1232160).
  • CVE-2024-49950: Bluetooth: L2CAP: Fix uaf in l2cap_connect (bsc#1232159).
  • CVE-2024-49953: net/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice (bsc#1232156).
  • CVE-2024-49954: static_call: Replace pointless WARN_ON() in static_call_module_notify() (bsc#1232155).
  • CVE-2024-49958: ocfs2: reserve space for inline xattr before attaching reflink tree (bsc#1232151).
  • CVE-2024-49959: jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error (bsc#1232149).
  • CVE-2024-49960: ext4: fix timer use-after-free on failed mount (bsc#1232395).
  • CVE-2024-49967: ext4: no need to continue when the number of entries is 1 (bsc#1232140).
  • CVE-2024-49969: drm/amd/display: Fix index out of bounds in DCN30 color transformation (bsc#1232519).
  • CVE-2024-49972: drm/amd/display: Deallocate DML memory if allocation fails (bsc#1232315).
  • CVE-2024-49973: r8169: add tally counter fields added with RTL8125 (bsc#1232105).
  • CVE-2024-49974: NFSD: Force all NFSv4.2 COPY requests to be synchronous (bsc#1232383).
  • CVE-2024-49986: platform/x86: x86-android-tablets: Fix use after free on platform_device_register() errors (bsc#1232093).
  • CVE-2024-49991: drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer (bsc#1232282).
  • CVE-2024-49993: iommu/vt-d: Fix potential lockup if qi_submit_sync called with 0 count (bsc#1232316).
  • CVE-2024-49995: tipc: guard against string buffer overrun (bsc#1232432).
  • CVE-2024-49996: cifs: Fix buffer overflow when parsing NFS reparse points (bsc#1232089).
  • CVE-2024-50000: net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc() (bsc#1232085).
  • CVE-2024-50001: net/mlx5: Fix error path in multi-packet WQE transmit (bsc#1232084).
  • CVE-2024-50002: static_call: Handle module init failure correctly in static_call_del_module() (bsc#1232083).
  • CVE-2024-50015: ext4: dax: fix overflowing extents beyond inode size when partially writing (bsc#1232079).
  • CVE-2024-50020: ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count() (bsc#1231989).
  • CVE-2024-50021: ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins() (bsc#1231957).
  • CVE-2024-50022: device-dax: correct pgoff align in dax_set_mapping() (bsc#1231956).
  • CVE-2024-50024: net: Fix an unsafe loop on the list (bsc#1231954).
  • CVE-2024-50027: thermal: core: Free tzp copy along with the thermal zone (bsc#1231951).
  • CVE-2024-50028: thermal: core: Reference count the zone in thermal_zone_get_by_id() (bsc#1231950).
  • CVE-2024-50033: slip: make slhc_remember() more robust against malicious packets (bsc#1231914).
  • CVE-2024-50035: ppp: fix ppp_async_encode() illegal access (bsc#1232392).
  • CVE-2024-50040: igb: Do not bring the device up after non-fatal error (bsc#1231908).
  • CVE-2024-50041: i40e: Fix macvlan leak by synchronizing access to mac_filter_hash (bsc#1231907).
  • CVE-2024-50042: ice: Fix increasing MSI-X on VF (bsc#1231906).
  • CVE-2024-50045: netfilter: br_netfilter: fix panic with metadata_dst skb (bsc#1231903).
  • CVE-2024-50046: kabi fix for NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies() (bsc#1231902).
  • CVE-2024-50047: smb: client: fix UAF in async decryption (bsc#1232418).
  • CVE-2024-50059: ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition (bsc#1232345).
  • CVE-2024-50060: io_uring: check if we need to reschedule during overflow flush (bsc#1232417).
  • CVE-2024-50063: kABI: bpf: struct bpf_map kABI workaround (bsc#1232435).
  • CVE-2024-50064: zram: do not free statically defined names (bsc#1231901).
  • CVE-2024-50080: ublk: do not allow user copy for unprivileged device (bsc#1232502).
  • CVE-2024-50081: blk-mq: setup queue ->tag_set before initializing hctx (bsc#1232501).

The following non-security bugs were fixed:

  • 9p: explicitly deny setlease attempts (git-fixes).
  • ACPI: CPPC: Add support for setting EPP register in FFH (stable-fixes).
  • ACPI: CPPC: Make rmw_lock a raw_spin_lock (git-fixes).
  • ACPI: EC: Do not release locks during operation region accesses (stable-fixes).
  • ACPI: PAD: fix crash in exit_round_robin() (stable-fixes).
  • ACPI: PRM: Clean up guid type in struct prm_handler_info (git-fixes).
  • ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context (git-fixes).
  • ACPI: battery: Fix possible crash when unregistering a battery hook (git-fixes).
  • ACPI: battery: Simplify battery hook locking (stable-fixes).
  • ACPI: button: Add DMI quirk for Samsung Galaxy Book2 to fix initial lid detection issue (stable-fixes).
  • ACPI: resource: Add Asus ExpertBook B2502CVA to irq1_level_low_skip_override[] (stable-fixes).
  • ACPI: resource: Add Asus Vivobook X1704VAP to irq1_level_low_skip_override[] (stable-fixes).
  • ACPI: resource: Add LG 16T90SP to irq1_level_low_skip_override[] (stable-fixes).
  • ACPI: resource: Add another DMI match for the TongFang GMxXGxx (stable-fixes).
  • ACPI: video: Add force_vendor quirk for Panasonic Toughbook CF-18 (stable-fixes).
  • ACPICA: Fix memory leak if acpi_ps_get_next_field() fails (stable-fixes).
  • ACPICA: Fix memory leak if acpi_ps_get_next_namepath() fails (stable-fixes).
  • ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package() (stable-fixes).
  • ACPICA: iasl: handle empty connection_node (stable-fixes).
  • ALSA/hda: intel-sdw-acpi: cleanup sdw_intel_scan_controller (stable-fixes).
  • ALSA/hda: intel-sdw-acpi: fetch fwnode once in sdw_intel_scan_controller() (stable-fixes).
  • ALSA/hda: intel-sdw-acpi: simplify sdw-master-count property read (stable-fixes).
  • ALSA: Reorganize kerneldoc parameter names (stable-fixes).
  • ALSA: asihpi: Fix potential OOB array access (stable-fixes).
  • ALSA: core: add isascii() check to card ID generator (stable-fixes).
  • ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size() (git-fixes).
  • ALSA: hda/conexant - Fix audio routing for HP EliteOne 1000 G2 (stable-fixes).
  • ALSA: hda/conexant - Use cached pin control for Node 0x1d on HP EliteOne 1000 G2 (git-fixes).
  • ALSA: hda/conexant: Fix conflicting quirk for System76 Pangolin (git-fixes).
  • ALSA: hda/conexant: fix some typos (stable-fixes).
  • ALSA: hda/cs8409: Fix possible NULL dereference (git-fixes).
  • ALSA: hda/generic: Unconditionally prefer preferred_dacs pairs (bsc#1219803).
  • ALSA: hda/realtek: Add a quirk for HP Pavilion 15z-ec200 (stable-fixes).
  • ALSA: hda/realtek: Add quirk for Huawei MateBook 13 KLV-WX9 (stable-fixes).
  • ALSA: hda/realtek: Add subwoofer quirk for Acer Predator G9-593 (stable-fixes).
  • ALSA: hda/realtek: Add subwoofer quirk for Infinix ZERO BOOK 13 (stable-fixes).
  • ALSA: hda/realtek: Enable mic on Vaio VJFH52 (stable-fixes).
  • ALSA: hda/realtek: Fix headset mic on TUXEDO Gemini 17 Gen3 (stable-fixes).
  • ALSA: hda/realtek: Fix headset mic on TUXEDO Stellaris 16 Gen6 mb1 (stable-fixes).
  • ALSA: hda/realtek: Fix the push button function for the ALC257 (git-fixes).
  • ALSA: hda/realtek: Limit internal Mic boost on Dell platform (stable-fixes).
  • ALSA: hda/realtek: Refactor and simplify Samsung Galaxy Book init (stable-fixes).
  • ALSA: hda/realtek: Update default depop procedure (git-fixes).
  • ALSA: hda/realtek: fix mute/micmute LED for HP mt645 G8 (stable-fixes).
  • ALSA: hda/realtek: tas2781: Fix ROG ALLY X audio (stable-fixes).
  • ALSA: hda/tas2781: Add new quirk for Lenovo Y990 Laptop (stable-fixes).
  • ALSA: hda/tas2781: Add new quirk for Lenovo, ASUS, Dell projects (stable-fixes).
  • ALSA: hda/tas2781: select CRC32 instead of CRC32_SARWATE (git-fixes).
  • ALSA: hda: Sound support for HP Spectre x360 16 inch model 2024 (stable-fixes).
  • ALSA: hda: tas2781: Fix missing setup at runtime PM (bsc#1230132).
  • ALSA: hdsp: Break infinite MIDI input flush loop (stable-fixes).
  • ALSA: line6: add hw monitor volume control to POD HD500X (stable-fixes).
  • ALSA: line6: update contact information (stable-fixes).
  • ALSA: mixer_oss: Remove some incorrect kfree_const() usages (git-fixes).
  • ALSA: silence integer wrapping warning (stable-fixes).
  • ALSA: usb-audio: Add delay quirk for VIVO USB-C HEADSET (stable-fixes).
  • ALSA: usb-audio: Add input value sanity checks for standard types (stable-fixes).
  • ALSA: usb-audio: Add logitech Audio profile quirk (stable-fixes).
  • ALSA: usb-audio: Add native DSD support for Luxman D-08u (stable-fixes).
  • ALSA: usb-audio: Add quirk for HP 320 FHD Webcam (bsc#1232768).
  • ALSA: usb-audio: Add quirks for Dell WD19 dock (stable-fixes).
  • ALSA: usb-audio: Define macros for quirk table entries (stable-fixes).
  • ALSA: usb-audio: Replace complex quirk lines with macros (stable-fixes).
  • ASoC: Intel: bytcr_rt5640: Add DMI quirk for Vexia Edu Atla 10 tablet (stable-fixes).
  • ASoC: Intel: bytcr_rt5640: Add support for non ACPI instantiated codec (stable-fixes).
  • ASoC: Intel: sst: Fix used of uninitialized ctx to log an error (git-fixes).
  • ASoC: Intel: sst: Support LPE0F28 ACPI HID (stable-fixes).
  • ASoC: amd: yc: Add quirk for HP Dragonfly pro one (stable-fixes).
  • ASoC: atmel: mchp-pdmc: Skip ALSA restoration if substream runtime is uninitialized (git-fixes).
  • ASoC: codecs: lpass-rx-macro: add missing CDC_RX_BCL_VBAT_RF_PROC2 to default regs values (stable-fixes).
  • ASoC: codecs: rt5640: Always disable IRQs from rt5640_cancel_work() (stable-fixes).
  • ASoC: codecs: wsa883x: Handle reading version failure (stable-fixes).
  • ASoC: cs42l51: Fix some error handling paths in cs42l51_probe() (git-fixes).
  • ASoC: dapm: fix bounds checker error in dapm_widget_list_create (git-fixes).
  • ASoC: fsl_sai: Enable 'FIFO continue on error' FCONT bit (stable-fixes).
  • ASoC: imx-card: Set card.owner to avoid a warning calltrace if SND=m (git-fixes).
  • ASoC: max98388: Fix missing increment of variable slot_found (git-fixes).
  • ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe() (git-fixes).
  • ASoC: qcom: sm8250: add qrb4210-rb2-sndcard compatible string (stable-fixes).
  • ASoC: tas2781: Use of_property_read_reg() (stable-fixes).
  • Bluetooth: Call iso_exit() on module unload (git-fixes).
  • Bluetooth: ISO: Fix multiple init when debugfs is disabled (git-fixes).
  • Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change (git-fixes).
  • Bluetooth: Remove debugfs directory on module init failure (git-fixes).
  • Bluetooth: bnep: fix wild-memory-access in proto_unregister (git-fixes).
  • Bluetooth: btmrvl: Use IRQF_NO_AUTOEN flag in request_irq() (git-fixes).
  • Bluetooth: btusb: Add Realtek RTL8852C support ID 0x0489:0xe122 (stable-fixes).
  • Bluetooth: btusb: Fix regression with fake CSR controllers 0a12:0001 (git-fixes).
  • Bluetooth: hci: fix null-ptr-deref in hci_read_supported_codecs (git-fixes).
  • Bluetooth: hci_event: Align BR/EDR JUST_WORKS paring with LE (git-fixes).
  • HID: Ignore battery for all ELAN I2C-HID devices (stable-fixes).
  • HID: amd_sfh: Switch to device-managed dmam_alloc_coherent() (git-fixes).
  • HID: i2c-hid: Remove I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV quirk (stable-fixes).
  • HID: multitouch: Add support for Thinkpad X12 Gen 2 Kbd Portfolio (stable-fixes).
  • HID: multitouch: Add support for lenovo Y9000P Touchpad (stable-fixes).
  • HID: plantronics: Workaround for an unexcepted opposite volume key (stable-fixes).
  • Input: adp5589-keys - fix NULL pointer dereference (git-fixes).
  • Input: adp5589-keys - fix adp5589_gpio_get_value() (git-fixes).
  • Input: edt-ft5x06 - fix regmap leak when probe fails (git-fixes).
  • Input: i8042 - add TUXEDO Stellaris 15 Slim Gen6 AMD to i8042 quirk table (stable-fixes).
  • Input: i8042 - add TUXEDO Stellaris 16 Gen5 AMD to i8042 quirk table (stable-fixes).
  • Input: i8042 - add another board name for TUXEDO Stellaris Gen5 AMD line (stable-fixes).
  • KVM: Fix coalesced_mmio_has_room() to avoid premature userspace exit (git-fixes).
  • KVM: SVM: Disallow guest from changing userspace's MSR_AMD64_DE_CFG value (git-fixes).
  • KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock (git-fixes).
  • KVM: VMX: Also clear SGX EDECCSSA in KVM CPU caps when SGX is disabled (git-fixes).
  • KVM: VMX: Set PFERR_GUEST_{FINAL,PAGE}_MASK if and only if the GVA is valid (git-fixes).
  • KVM: Write the per-page 'segment' when clearing (part of) a guest page (git-fixes).
  • KVM: s390: Change virtual to physical address access in diag 0x258 handler (git-fixes bsc#1232626).
  • KVM: s390: Fix SORTL and DFLTCC instruction format error in __insn32_query (git-fixes bsc#1231276).
  • KVM: s390: gaccess: Check if guest address is in memslot (git-fixes bsc#1232623).
  • KVM: x86/mmu: Skip emulation on page fault iff 1+ SPs were unprotected (git-fixes).
  • KVM: x86/mmu: Trigger unprotect logic only on write-protection page faults (git-fixes).
  • KVM: x86: Dedup fastpath MSR post-handling logic (git-fixes).
  • KVM: x86: Enforce x2APIC's must-be-zero reserved ICR bits (git-fixes).
  • KVM: x86: Exit to userspace if fastpath triggers one on instruction skip (git-fixes).
  • KVM: x86: Move x2APIC ICR helper above kvm_apic_write_nodecode() (git-fixes).
  • KVM: x86: Re-enter guest if WRMSR(X2APIC_ICR) fastpath is successful (git-fixes).
  • KVM: x86: Re-split x2APIC ICR into ICR+ICR2 for AMD (x2AVIC) (git-fixes).
  • NFS: Avoid unnecessary rescanning of the per-server delegation list (git-fixes).
  • NFSD: Fix NFSv4's PUTPUBFH operation (git-fixes).
  • NFSD: Mark filecache 'down' if init fails (git-fixes).
  • NFSv3: only use NFS timeout for MOUNT when protocols are compatible (bsc#1231016).
  • NFSv4: Fix clearing of layout segments in layoutreturn (git-fixes).
  • PCI: Add ACS quirk for Qualcomm SA8775P (stable-fixes).
  • PCI: Add function 0 DMA alias quirk for Glenfly Arise chip (stable-fixes).
  • PCI: Fix pci_enable_acs() support for the ACS quirks (bsc#1229019).
  • PCI: Mark Creative Labs EMU20k2 INTx masking as broken (stable-fixes).
  • RAS/AMD/ATL: Add amd_atl pr_fmt() prefix (jsc#PED-10559).
  • RAS/AMD/ATL: Expand helpers for adding and removing base and hole (jsc#PED-10559).
  • RAS/AMD/ATL: Implement DF 4.5 NP2 denormalization (jsc#PED-10559).
  • RAS/AMD/ATL: Read DRAM hole base early (jsc#PED-10559).
  • RAS/AMD/ATL: Validate address map when information is gathered (jsc#PED-10559).
  • RDMA/bnxt_re: Add a check for memory allocation (git-fixes)
  • RDMA/bnxt_re: Avoid CPU lockups due fifo occupancy check loop (git-fixes)
  • RDMA/bnxt_re: Change the sequence of updating the CQ toggle value (git-fixes)
  • RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages (git-fixes)
  • RDMA/bnxt_re: Fix a possible memory leak (git-fixes)
  • RDMA/bnxt_re: Fix incorrect AVID type in WQE structure (git-fixes)
  • RDMA/bnxt_re: Fix incorrect dereference of srq in async event (git-fixes)
  • RDMA/bnxt_re: Fix out of bound check (git-fixes)
  • RDMA/bnxt_re: Fix the GID table length (git-fixes)
  • RDMA/bnxt_re: Fix the max CQ WQEs for older adapters (git-fixes)
  • RDMA/bnxt_re: Fix the usage of control path spin locks (git-fixes)
  • RDMA/bnxt_re: Return more meaningful error (git-fixes)
  • RDMA/bnxt_re: synchronize the qp-handle table array (git-fixes)
  • RDMA/core: Fix ENODEV error for iWARP test over vlan (git-fixes)
  • RDMA/cxgb4: Dump vendor specific QP details (git-fixes)
  • RDMA/cxgb4: Fix RDMA_CM_EVENT_UNREACHABLE error for iWARP (git-fixes)
  • RDMA/irdma: Fix misspelling of 'accept*' (git-fixes)
  • RDMA/mad: Improve handling of timed out WRs of mad agent (git-fixes)
  • RDMA/mana_ib: use the correct page size for mapping user-mode doorbell page (git-fixes).
  • RDMA/mana_ib: use the correct page table index based on hardware page size (git-fixes).
  • RDMA/mlx5: Enforce umem boundaries for explicit ODP page faults (git-fixes)
  • RDMA/mlx5: Round max_rd_atomic/max_dest_rd_atomic up instead of down (git-fixes)
  • RDMA/mlx5: Use sq timestamp as QP timestamp when RoCE is disabled (git-fixes).
  • RDMA/rtrs-srv: Avoid null pointer deref during path establishment (git-fixes)
  • RDMA/srpt: Make slab cache names unique (git-fixes)
  • SUNRPC: Fix integer overflow in decode_rc_list() (git-fixes).
  • SUNRPC: Fixup gss_status tracepoint error output (git-fixes).
  • SUNRPC: clnt.c: Remove misleading comment (git-fixes).
  • USB: appledisplay: close race between probe and completion handler (git-fixes).
  • USB: misc: cypress_cy7c63: check for short transfer (git-fixes).
  • USB: misc: yurex: fix race between read and write (git-fixes).
  • USB: serial: option: add Telit FN920C04 MBIM compositions (stable-fixes).
  • USB: serial: option: add support for Quectel EG916Q-GL (stable-fixes).
  • Update config files: Enable NFSD_V2 (bsc#1230914)
  • Use pahole -j1 option for reproducible builds (bsc#1230414 bsc#1229450).
  • accel/qaic: Fix the for loop used to walk SG table (git-fixes).
  • add bug reference for a mana change (bsc#1229769).
  • add bug references to existing mana changes (bsc#1232033, bsc#1232034, bsc#1232036).
  • arm64: Subscribe Microsoft Azure Cobalt 100 to erratum 3194386 (git-fixes)
  • arm64: cputype: Add Neoverse-N3 definitions (git-fixes)
  • arm64: errata: Enable the AC03_CPU_38 workaround for ampere1a (git-fixes).
  • arm64: errata: Expand speculative SSBS workaround once more (git-fixes)
  • arm64: esr: Define ESR_ELx_EC_* constants as UL (git-fixes)
  • arm64: fix selection of HAVE_DYNAMIC_FTRACE_WITH_ARGS (git-fixes).
  • arm64: probes: Fix simulate_ldr*_literal() (git-fixes)
  • arm64: probes: Fix uprobes for big-endian kernels (git-fixes)
  • arm64: probes: Remove broken LDR (literal) uprobe support (git-fixes)
  • ata: libata: Set DID_TIME_OUT for commands that actually timed out (git-fixes).
  • ata: libata: avoid superfluous disk spin down + spin up during hibernation (git-fixes).
  • audit: do not WARN_ON_ONCE(!current->mm) in audit_exe_compare() (git-fixes).
  • audit: do not take task_lock() in audit_exe_compare() code path (git-fixes).
  • block: print symbolic error name instead of error code (bsc#1231872).
  • block: sed-opal: add ioctl IOC_OPAL_SET_SID_PW (bsc#1229677).
  • bnxt_en: Cap the size of HWRM_PORT_PHY_QCFG forwarded response (git-fixes).
  • bnxt_en: Fix error recovery for 5760X (P7) chips (git-fixes).
  • bnxt_en: Fix the PCI-AER routines (git-fixes).
  • bnxt_en: Restore PTP tx_avail count in case of skb_pad() error (git-fixes).
  • bnxt_en: refactor reset close code (git-fixes).
  • bpf, lsm: Add disabled BPF LSM hook list (git-fixes).
  • bpf, net: Fix a potential race in do_sock_getsockopt() (git-fixes).
  • bpf, verifier: Correct tail_call_reachable for bpf prog (git-fixes).
  • bpf, x64: Remove tail call detection (git-fixes).
  • bpf,perf: Fix perf_event_detach_bpf_prog error handling (git-fixes).
  • bpf: Fail verification for sign-extension of packet data/data_end/data_meta (git-fixes).
  • bpf: Fix bpf_strtol and bpf_strtoul helpers for 32bit (git-fixes).
  • bpf: Fix error message on kfunc arg type mismatch (git-fixes).
  • bpf: Fix helper writes to read-only maps (git-fixes).
  • bpf: Fix tailcall cases in test_bpf (git-fixes).
  • bpf: Fix truncation bug in coerce_reg_to_size_sx() (git-fixes).
  • bpf: Improve check_raw_mode_ok test for MEM_UNINIT-tagged types (git-fixes).
  • bpf: Remove truncation test in bpf_strtol and bpf_strtoul helpers (git-fixes).
  • bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error (git-fixes).
  • bpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos (git-fixes).
  • btf, scripts: rust: drop is_rust_module.sh (bsc#1230414 bsc#1229450).
  • btrfs: send: fix invalid clone operation for file that got its size decreased (git-fixes).
  • can: netlink: avoid call to do_set_data_bittiming callback with stale can_priv::ctrlmode (stable-fixes).
  • ceph: fix cap ref leak via netfs init_request (bsc#1231384).
  • clk: bcm: bcm53573: fix OF node leak in init (stable-fixes).
  • clk: imx: Remove CLK_SET_PARENT_GATE for DRAM mux for i.MX7D (stable-fixes).
  • comedi: ni_routing: tools: Check when the file could not be opened (stable-fixes).
  • config: Disable LAM on x86 (bsc#1217845)
  • cpufreq/amd-pstate: Fix amd_pstate mode switch on shared memory systems (git-fixes).
  • crypto: hisilicon/qm - flush all work before driver removed (bsc#1232075)
  • crypto: octeontx - Fix authenc setkey (stable-fixes).
  • crypto: octeontx* - Select CRYPTO_AUTHENC (git-fixes).
  • crypto: octeontx2 - Fix authenc setkey (stable-fixes).
  • crypto: powerpc/p10-aes-gcm - Add dependency on CRYPTO_SIMD and re-enable CRYPTO_AES_GCM_P10 (bsc#1230501 ltc#208632)
  • crypto: powerpc/p10-aes-gcm - Disable CRYPTO_AES_GCM_P10 (bsc#1230501 ltc#208632).
  • crypto: powerpc/p10-aes-gcm - Re-write AES/GCM stitched implementation (bsc#1230501 ltc#208632).
  • crypto: powerpc/p10-aes-gcm - Register modules as SIMD (bsc#1230501 ltc#208632).
  • cxgb4: Properly lock TX queue for the selftest (git-fixes).
  • cxgb4: add forgotten u64 ivlan cast before shift (git-fixes).
  • cxgb4: unnecessary check for 0 in the free_sge_txq_uld() function (git-fixes).
  • dcache: keep dentry_hashtable or d_hash_shift even when not used (git-fixes).
  • debugfs: fix automount d_fsdata usage (git-fixes).
  • devlink: Fix command annotation documentation (git-fixes).
  • dmaengine: sh: rz-dmac: handle configs where one address is zero (git-fixes).
  • dmaengine: ti: k3-udma: Set EOP for all TRs in cyclic BCDMA transfer (git-fixes).
  • driver core: bus: Fix double free in driver API bus_register() (stable-fixes).
  • driver core: bus: Return -EIO instead of 0 when show/store invalid bus attribute (stable-fixes).
  • drm/amd/amdgpu: Fix double unlock in amdgpu_mes_add_ring (git-fixes).
  • drm/amd/display: Add HDMI DSC native YCbCr422 support (stable-fixes).
  • drm/amd/display: Add disable timeout option (bsc#1231435)
  • drm/amd/display: Check link_res->hpo_dp_link_enc before using it (bsc#1231944)
  • drm/amd/display: Check null pointer before dereferencing se (stable-fixes).
  • drm/amd/display: Clean up dsc blocks in accelerated mode (stable-fixes).
  • drm/amd/display: Disable PSR-SU on Parade 08-01 TCON too (stable-fixes).
  • drm/amd/display: Remove a redundant check in authenticated_dp (stable-fixes).
  • drm/amd/display: Revert 'Check HDCP returned status' (stable-fixes).
  • drm/amd/display: Round calculated vtotal (stable-fixes).
  • drm/amd/display: Skip to enable dsc if it has been off (stable-fixes).
  • drm/amd/display: Validate backlight caps are sane (stable-fixes).
  • drm/amd/pm: Vangogh: Fix kernel memory out of bounds write (git-fixes).
  • drm/amd: Guard against bad data for ATIF ACPI method (git-fixes).
  • drm/amdgpu/swsmu: Only force workload setup on init (git-fixes).
  • drm/amdgpu/vcn: enable AV1 on both instances (stable-fixes).
  • drm/i915/gem: fix bitwise and logical AND mixup (git-fixes).
  • drm/i915/hdcp: fix connector refcounting (git-fixes).
  • drm/mediatek: Fix get efuse issue for MT8188 DPTX (git-fixes).
  • drm/msm/dpu: check for overflow in _dpu_crtc_setup_lm_bounds() (git-fixes).
  • drm/msm/dpu: do not always program merge_3d block (git-fixes).
  • drm/msm/dpu: make sure phys resources are properly initialized (git-fixes).
  • drm/msm/dpu: move CRTC resource assignment to dpu_encoder_virt_atomic_check (git-fixes).
  • drm/msm/dsi: fix 32-bit signed integer extension in pclk_rate calculation (git-fixes).
  • drm/msm/dsi: improve/fix dsc pclk calculation (git-fixes).
  • drm/msm: Allocate memory for disp snapshot with kvzalloc() (git-fixes).
  • drm/msm: Avoid NULL dereference in msm_disp_state_print_regs() (git-fixes).
  • drm/radeon: Fix encoder->possible_clones (git-fixes).
  • drm/sched: Add locking to drm_sched_entity_modify_sched (git-fixes).
  • drm/sched: Always wake up correct scheduler in drm_sched_entity_push_job (git-fixes).
  • drm/v3d: Stop the active perfmon before being destroyed (git-fixes).
  • drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real VLA (stable-fixes).
  • drm/vc4: Stop the active perfmon before being destroyed (git-fixes).
  • drm/vmwgfx: Handle surface check failure correctly (git-fixes).
  • drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS (git-fixes).
  • e1000e: Fix S0ix residency on corporate systems (git-fixes).
  • e1000e: change I219 (19) devices to ADP (git-fixes).
  • e1000e: fix force smbus during suspend flow (git-fixes).
  • e1000e: move force SMBUS near the end of enable_ulp function (git-fixes).
  • efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption (stable-fixes).
  • eth: bnxt: fix counting packets discarded due to OOM and netpoll (git-fixes).
  • ext4: do not track ranges in fast_commit if inode has inlined data (bsc#1231635).
  • ext4: fix fast commit inode enqueueing during a full journal commit (bsc#1231636).
  • ext4: fix incorrect tid assumption in ext4_fc_mark_ineligible() (bsc#1231637).
  • ext4: fix possible tid_t sequence overflows (bsc#1231634).
  • ext4: fix slab-use-after-free in ext4_split_extent_at() (bsc#1232201)
  • ext4: mark fc as ineligible using an handle in ext4_xattr_set() (bsc#1231640).
  • ext4: use handle to mark fc as ineligible in __track_dentry_update() (bsc#1231639).
  • fat: fix uninitialized variable (git-fixes).
  • fbcon: Fix a NULL pointer dereference issue in fbcon_putcs (stable-fixes).
  • fbdev: sisfb: Fix strbuf array overflow (stable-fixes).
  • fgraph: Change the name of cpuhp state to 'fgraph:online' (git-fixes).
  • fgraph: Fix missing unlock in register_ftrace_graph() (git-fixes).
  • fgraph: Use CPU hotplug mechanism to initialize idle shadow stacks (git-fixes).
  • filemap: remove use of wait bookmarks (bsc#1224088).
  • firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier() (git-fixes).
  • firmware: arm_scmi: Fix the double free in scmi_debugfs_common_setup() (git-fixes).
  • firmware: arm_sdei: Fix the input parameter of cpuhp_remove_state() (git-fixes).
  • fs/9p: drop inodes immediately on non-.L too (git-fixes).
  • fs/9p: fix the cache always being enabled on files with qid flags (git-fixes).
  • genirq/msi: Fix off-by-one error in msi_domain_alloc() (git-fixes).
  • gpio: aspeed: Add the flush write to ensure the write complete (git-fixes).
  • gpio: aspeed: Use devm_clk api to manage clock source (git-fixes).
  • gpio: davinci: fix lazy disable (git-fixes).
  • gve: Fix XDP TX completion handling when counters overflow (git-fixes).
  • gve: Fix an edge case for TSO skb validity check (git-fixes).
  • gve: ignore nonrelevant GSO type bits when processing TSO headers (git-fixes).
  • hid: intel-ish-hid: Fix uninitialized variable 'rv' in ish_fw_xfer_direct_dma (git-fixes).
  • hv_netvsc: Fix VF namespace also in synthetic NIC NETDEV_REGISTER event (git-fixes).
  • hwmon: (adm9240) Add missing dependency on REGMAP_I2C (git-fixes).
  • hwmon: (adt7470) Add missing dependency on REGMAP_I2C (git-fixes).
  • hwmon: (max16065) Fix alarm attributes (git-fixes).
  • hwmon: (max16065) Remove use of i2c_match_id() (stable-fixes).
  • hwmon: (mc34vr500) Add missing dependency on REGMAP_I2C (git-fixes).
  • hwmon: (nct6775) add G15CF to ASUS WMI monitoring list (stable-fixes).
  • hwmon: (tmp513) Add missing dependency on REGMAP_I2C (git-fixes).
  • hwmon: intel-m10-bmc-hwmon: relabel Columbiaville to CVL Die Temperature (git-fixes).
  • i2c: core: Setup i2c_adapter runtime-pm before calling device_add() (git-fixes).
  • i2c: core: fix lockdep warning for sparsely nested adapter chain (git-fixes).
  • i2c: cpm: Remove linux,i2c-index conversion from be32 (git-fixes).
  • i2c: exynos5: Calculate t_scl_l, t_scl_h according to i2c spec (git-fixes).
  • i2c: i801: Add lis3lv02d for Dell Precision 3540 (git-fixes).
  • i2c: i801: Add lis3lv02d for Dell XPS 15 7590 (git-fixes).
  • i2c: i801: Use a different adapter-name for IDF adapters (stable-fixes).
  • i2c: i801: add helper i801_restore_regs (git-fixes).
  • i2c: ismt: kill transaction in hardware on timeout (git-fixes).
  • i2c: ocores: Move system PM hooks to the NOIRQ phase (git-fixes).
  • i2c: ocores: Remove #ifdef guards for PM related functions (git-fixes).
  • i2c: omap: switch to NOIRQ_SYSTEM_SLEEP_PM_OPS() and RUNTIME_PM_OPS() (git-fixes).
  • i2c: omap: wakeup the controller during suspend() callback (git-fixes).
  • i2c: rcar: properly format a debug output (git-fixes).
  • i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume (git-fixes).
  • i2c: stm32f7: perform most of irq job in threaded handler (git-fixes).
  • i2c: synquacer: Deal with optional PCLK correctly (git-fixes).
  • i2c: synquacer: Remove a clk reference from struct synquacer_i2c (stable-fixes).
  • i2c: xiic: Try re-initialization on bus busy timeout (git-fixes).
  • i2c: xiic: improve error message when transfer fails to start (stable-fixes).
  • i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race Condition (stable-fixes).
  • i40e: Fix XDP program unloading while removing the driver (git-fixes).
  • i40e: Report MFS in decimal base instead of hex (git-fixes).
  • iavf: Fix TC config comparison with existing adapter TC config (git-fixes).
  • ice: Fix VSI list rule with ICE_SW_LKUP_LAST type (git-fixes).
  • ice: Fix checking for unsupported keys on non-tunnel device (git-fixes).
  • ice: Fix lldp packets dropping after changing the number of channels (git-fixes).
  • ice: Fix netif_is_ice() in Safe Mode (git-fixes).
  • ice: Fix package download algorithm (git-fixes).
  • ice: Fix recipe read procedure (git-fixes).
  • ice: Fix reset handler (git-fixes).
  • ice: Flush FDB entries before reset (git-fixes).
  • ice: Interpret .set_channels() input differently (git-fixes).
  • ice: Rebuild TC queues on VSI queue reconfiguration (git-fixes).
  • ice: Reject pin requests with unsupported flags (git-fixes).
  • ice: add flag to distinguish reset from .ndo_bpf in XDP rings config (git-fixes).
  • ice: add missing WRITE_ONCE when clearing ice_rx_ring::xdp_prog (git-fixes).
  • ice: avoid IRQ collision to fix init failure on ACPI S3 resume (git-fixes).
  • ice: clear port vlan config during reset (git-fixes).
  • ice: disallow DPLL_PIN_STATE_SELECTABLE for dpll output pins (git-fixes).
  • ice: do not bring the VSI up, if it was down before the XDP setup (git-fixes).
  • ice: do not busy wait for Rx queue disable in ice_qp_dis() (git-fixes).
  • ice: fix 200G PHY types to link speed mapping (git-fixes).
  • ice: fix 200G link speed message log (git-fixes).
  • ice: fix ICE_LAST_OFFSET formula (git-fixes).
  • ice: fix VLAN replay after reset (git-fixes).
  • ice: fix VSI lists confusion when adding VLANs (git-fixes).
  • ice: fix accounting for filters shared by multiple VSIs (git-fixes).
  • ice: fix accounting if a VLAN already exists (git-fixes).
  • ice: fix iteration of TLVs in Preserved Fields Area (git-fixes).
  • ice: fix page reuse when PAGE_SIZE is over 8k (git-fixes).
  • ice: fix reads from NVM Shadow RAM on E830 and E825-C devices (git-fixes).
  • ice: fix truesize operations for PAGE_SIZE >= 8192 (git-fixes).
  • ice: implement AQ download pkg retry (git-fixes).
  • ice: map XDP queues to vectors in ice_vsi_map_rings_to_vectors() (git-fixes).
  • ice: remove af_xdp_zc_qps bitmap (git-fixes).
  • ice: replace synchronize_rcu with synchronize_net (git-fixes).
  • ice: respect netif readiness in AF_XDP ZC related ndo's (git-fixes).
  • ice: set correct dst VSI in only LAN filters (git-fixes).
  • ice: tc: allow zero flags in parsing tc flower (git-fixes).
  • ice: tc: check src_vsi in case of traffic from VF (git-fixes).
  • ice: use proper macro for testing bit (git-fixes).
  • idpf: Interpret .set_channels() input differently (git-fixes).
  • idpf: avoid bloating &idpf_q_vector with big %NR_CPUS (git-fixes).
  • idpf: do not enable NAPI and interrupts prior to allocating Rx buffers (git-fixes).
  • idpf: do not skip over ethtool tcp-data-split setting (git-fixes).
  • idpf: fix UAFs when destroying the queues (git-fixes).
  • idpf: fix memleak in vport interrupt configuration (git-fixes).
  • idpf: fix memory leaks and crashes while performing a soft reset (git-fixes).
  • ieee802154: Fix build error (git-fixes).
  • igb: Always call igb_xdp_ring_update_tail() under Tx lock (git-fixes).
  • igb: Fix not clearing TimeSync interrupts for 82580 (git-fixes).
  • igc: Fix double reset adapter triggered from a single taprio cmd (git-fixes).
  • igc: Fix packet still tx after gate close by reducing i226 MAC retry buffer (git-fixes).
  • igc: Fix qbv tx latency by setting gtxoffset (git-fixes).
  • igc: Fix qbv_config_change_errors logics (git-fixes).
  • igc: Fix reset adapter logics when tx mode change (git-fixes).
  • igc: Unlock on error in igc_io_resume() (git-fixes).
  • iio: accel: bma400: Fix uninitialized variable field_value in tap event handling (git-fixes).
  • iio: accel: kx022a: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig (git-fixes).
  • iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr() (git-fixes).
  • iio: adc: ti-ads124s08: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig (git-fixes).
  • iio: adc: ti-ads8688: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig (git-fixes).
  • iio: adc: ti-lmp92064: add missing select REGMAP_SPI in Kconfig (git-fixes).
  • iio: amplifiers: ada4250: add missing select REGMAP_SPI in Kconfig (git-fixes).
  • iio: dac: ad3552r: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig (git-fixes).
  • iio: dac: ad5766: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig (git-fixes).
  • iio: dac: ad5770r: add missing select REGMAP_SPI in Kconfig (git-fixes).
  • iio: dac: ltc1660: add missing select REGMAP_SPI in Kconfig (git-fixes).
  • iio: dac: stm32-dac-core: add missing select REGMAP_MMIO in Kconfig (git-fixes).
  • iio: frequency: adf4377: add missing select REMAP_SPI in Kconfig (git-fixes).
  • iio: frequency: admv4420: fix missing select REMAP_SPI in Kconfig (git-fixes).
  • iio: gts-helper: Fix memory leaks for the error path of iio_gts_build_avail_scale_table() (git-fixes).
  • iio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table() (git-fixes).
  • iio: hid-sensors: Fix an error handling path in _hid_sensor_set_report_latency() (git-fixes).
  • iio: light: opt3001: add missing full-scale range value (git-fixes).
  • iio: light: veml6030: fix ALS sensor resolution (git-fixes).
  • iio: light: veml6030: fix IIO device retrieval from embedded device (git-fixes).
  • iio: light: veml6030: fix microlux value calculation (git-fixes).
  • iio: magnetometer: ak8975: Convert enum->pointer for data in the match tables (stable-fixes).
  • iio: magnetometer: ak8975: Fix 'Unexpected device' error (git-fixes).
  • iio: magnetometer: ak8975: drop incorrect AK09116 compatible (git-fixes).
  • iio: proximity: mb1232: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig (git-fixes).
  • io_uring/eventfd: move to more idiomatic RCU free usage (git-fixes).
  • io_uring/io-wq: do not allow pinning outside of cpuset (git-fixes).
  • io_uring/io-wq: inherit cpuset of cgroup in io worker (git-fixes).
  • io_uring/net: harden multishot termination case for recv (git-fixes).
  • io_uring/rw: fix cflags posting for single issue multishot read (git-fixes).
  • io_uring/rw: treat -EOPNOTSUPP for IOCB_NOWAIT like -EAGAIN (git-fixes).
  • io_uring/sqpoll: do not allow pinning outside of cpuset (git-fixes).
  • io_uring/sqpoll: do not put cpumask on stack (git-fixes).
  • io_uring/sqpoll: retain test for whether the CPU is valid (git-fixes).
  • io_uring: check for presence of task_work rather than TIF_NOTIFY_SIGNAL (git-fixes).
  • iommu/amd: Allocate the page table root using GFP_KERNEL (git-fixes).
  • iommu/amd: Do not set the D bit on AMD v2 table entries (git-fixes).
  • iommu/amd: Fix typo of , instead of ; (git-fixes).
  • iommu/vt-d: Always reserve a domain ID for identity setup (git-fixes).
  • iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices (git-fixes).
  • iommufd: Check the domain owner of the parent before creating a nesting domain (git-fixes).
  • iommufd: Protect against overflow of ALIGN() during iova allocation (git-fixes).
  • jbd2: correctly compare tids with tid_geq function in jbd2_fc_begin_commit (bsc#1231638).
  • jfs: Fix sanity check in dbMount (git-fixes).
  • jfs: Fix uaf in dbFreeBits (git-fixes).
  • jfs: Fix uninit-value access of new_ea in ea_buffer (git-fixes).
  • jfs: UBSAN: shift-out-of-bounds in dbFindBits (git-fixes).
  • jfs: check if leafidx greater than num leaves per dmap tree (git-fixes).
  • jump_label: Fix static_key_slow_dec() yet again (git-fixes).
  • kABI fix of VM: x86: Re-split x2APIC ICR into ICR+ICR2 for AMD (x2AVIC) (git-fixes).
  • kABI: bpf: enum bpf_{type_flag,arg_type} kABI workaround (git-fixes).
  • kABI: bpf: struct bpf_insn_acces_aux kABI workaround (git-fixes).
  • kasan: Fix Software Tag-Based KASAN with GCC (git-fixes).
  • kbuild, bpf: Use test-ge check for v1.25-only pahole (bsc#1230414 bsc#1229450).
  • kbuild,bpf: Add module-specific pahole flags for distilled base BTF (bsc#1230414 bsc#1229450).
  • kbuild,bpf: Switch to using --btf_features for pahole v1.26 and later (bsc#1230414 bsc#1229450).
  • kbuild: avoid too many execution of scripts/pahole-flags.sh (bsc#1230414 bsc#1229450).
  • kbuild: bpf: Tell pahole to DECL_TAG kfuncs (bsc#1230414 bsc#1229450).
  • kconfig: qconf: fix buffer overflow in debug links (git-fixes).
  • keys, dns: Allow key types (eg. DNS) to be reclaimed immediately on expiry (git-fixes).
  • keys: Fix overwrite of key expiration on instantiation (git-fixes).
  • kthread: unpark only parked kthread (git-fixes).
  • lib/xarray: introduce a new helper xas_get_order (bsc#1231617).
  • mac80211: MAC80211_MESSAGE_TRACING should depend on TRACING (git-fixes).
  • macsec: do not increment counters for an unrelated SA (git-fixes).
  • maple_tree: correct tree corruption on spanning store (git-fixes).
  • media: bttv: use audio defaults for winfast2000 (git-fixes).
  • media: core: v4l2-ioctl: check if ioctl is known to avoid NULL name (git-fixes).
  • media: i2c: imx335: Enable regulator supplies (stable-fixes).
  • media: imx335: Fix reset-gpio handling (git-fixes).
  • media: pci: ipu3-cio2: Initialise timing struct to avoid a compiler warning (git-fixes).
  • media: videobuf2-core: clear memory related fields in __vb2_plane_dmabuf_put() (stable-fixes).
  • media: videobuf2: fix typo: vb2_dbuf -> vb2_qbuf (git-fixes).
  • mei: use kvmalloc for read buffer (git-fixes).
  • mfd: intel_soc_pmic_chtwc: Make Lenovo Yoga Tab 3 X90F DMI match less strict (stable-fixes).
  • minmax: avoid overly complex min()/max() macro arguments in xen (git-fixes).
  • mlx5: avoid truncating error message (git-fixes).
  • mlx5: stop warning for 64KB pages (git-fixes).
  • mm/filemap: optimize filemap folio adding (bsc#1231617).
  • mm/filemap: return early if failed to allocate memory for split (bsc#1231617).
  • mm: khugepaged: fix the arguments order in khugepaged_collapse_file trace point (git-fixes).
  • mm: mmap: no need to call khugepaged_enter_vma() for stack (jsc#PED-10978).
  • modpost: fix acpi MODULE_DEVICE_TABLE built with mismatched endianness (git-fixes).
  • modpost: fix input MODULE_DEVICE_TABLE() built for 64-bit on 32-bit host (git-fixes).
  • module: abort module loading when sysfs setup suffer errors (git-fixes).
  • nbd: fix race between timeout and normal completion (bsc#1230918).
  • net/mlx5: Add missing masks and QoS bit masks for scheduling elements (git-fixes).
  • net/mlx5: Added cond_resched() to crdump collection (git-fixes).
  • net/mlx5: Check capability for fw_reset (git-fixes).
  • net/mlx5: Check for invalid vector index on EQ creation (git-fixes).
  • net/mlx5: Explicitly set scheduling element and TSAR type (git-fixes).
  • net/mlx5: Fix command bitmask initialization (git-fixes).
  • net/mlx5: Fix error handling in irq_pool_request_irq (git-fixes).
  • net/mlx5: Lag, do bond only if slaves agree on roce state (git-fixes).
  • net/mlx5: Lag, do not use the hardcoded value of the first port (git-fixes).
  • net/mlx5: Stop waiting for PCI if pci channel is offline (git-fixes).
  • net/mlx5: Unregister notifier on eswitch init failure (git-fixes).
  • net/mlx5: Update the list of the PCI supported devices (git-fixes).
  • net/mlx5e: Add a check for the return value from mlx5_port_set_eth_ptys (git-fixes).
  • net/mlx5e: Add missing link mode to ptys2ext_ethtool_map (git-fixes).
  • net/mlx5e: Add missing link modes to ptys2ethtool_map (git-fixes).
  • net/mlx5e: Add mqprio_rl cleanup and free in mlx5e_priv_cleanup() (git-fixes).
  • net/mlx5e: Correctly report errors for ethtool rx flows (git-fixes).
  • net/mlx5e: Do not call cleanup on profile rollback failure (git-fixes).
  • net/mlx5e: Fix IPsec tunnel mode offload feature check (git-fixes).
  • net/mlx5e: Fix UDP GSO for encapsulated packets (git-fixes).
  • net/mlx5e: Fix features validation check for tunneled UDP (non-VXLAN) packets (git-fixes).
  • net/mlx5e: Require mlx5 tc classifier action support for IPsec prio capability (git-fixes).
  • net/mlx5e: Use rx_missed_errors instead of rx_dropped for reporting buffer exhaustion (git-fixes).
  • net: mana: Implement get_ringparam/set_ringparam for mana (bsc#1229891).
  • net: mana: Improve mana_set_channels() in low mem conditions (bsc#1230289).
  • net: phy: Remove LED entry from LEDs list on unregister (git-fixes).
  • net: phy: bcm84881: Fix some error handling paths (git-fixes).
  • net: phy: dp83869: fix memory corruption when enabling fiber (git-fixes).
  • net: qede: sanitize 'rc' in qede_add_tc_flower_fltr() (git-fixes).
  • net: qede: use return from qede_parse_actions() (git-fixes).
  • net: qede: use return from qede_parse_flow_attr() for flow_spec (git-fixes).
  • net: qede: use return from qede_parse_flow_attr() for flower (git-fixes).
  • net: stmmac: dwmac-tegra: Fix link bring-up sequence (git-fixes)
  • net: sysfs: Fix /sys/class/net/<iface> path for statistics (git-fixes).
  • net: test for not too small csum_start in virtio_net_hdr_to_skb() (git-fixes).
  • net: usb: usbnet: fix name regression (get-fixes).
  • net: usb: usbnet: fix race in probe failure (git-fixes).
  • netdevsim: use cond_resched() in nsim_dev_trap_report_work() (git-fixes).
  • nfs: fix memory leak in error path of nfs4_do_reclaim (git-fixes).
  • nfsd: call cache_put if xdr_reserve_space returns NULL (git-fixes).
  • nfsd: cancel nfsd_shrinker_work using sync mode in nfs4_state_shutdown_net (git-fixes).
  • nfsd: fix delegation_blocked() to block correctly for at least 30 seconds (git-fixes).
  • nfsd: fix refcount leak when file is unhashed after being found (git-fixes).
  • nfsd: map the EBADMSG to nfserr_io to avoid warning (git-fixes).
  • nfsd: remove unneeded EEXIST error check in nfsd_do_file_acquire (git-fixes).
  • nfsd: return -EINVAL when namelen is 0 (git-fixes).
  • nilfs2: fix kernel bug due to missing clearing of buffer delay flag (git-fixes).
  • nouveau/dmem: Fix privileged error in copy engine channel (git-fixes).
  • nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error (git-fixes).
  • nouveau/gsp: Avoid addressing beyond end of rpc->entries (stable-fixes).
  • ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() (git-fixes).
  • nvme-multipath: suppress partition scan until the disk is ready (bsc#1228244).
  • nvme-pci: fix race condition between reset and nvme_dev_disable() (git-fixes).
  • nvme-pci: qdepth 1 quirk (git-fixes).
  • nvme-pci: set doorbell config before unquiescing (git-fixes).
  • nvme: disable CC.CRIME (NVME_CC_CRIME) (jsc#PED-9901).
  • nvme: null terminate nvme_tls_attrs (git-fixes).
  • nvme: re-fix error-handling for io_uring nvme-passthrough (git-fixes).
  • nvmet-auth: assign dh_key to NULL after kfree_sensitive (git-fixes).
  • ocfs2: fix the la space leak when unmounting an ocfs2 volume (git-fixes).
  • ocfs2: fix uninit-value in ocfs2_get_block() (git-fixes).
  • ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow (git-fixes).
  • parport: Proper fix for array out-of-bounds access (git-fixes).
  • phy: freescale: imx8m-pcie: Do CMN_RST just before PHY PLL lock check (git-fixes).
  • phy: qcom: qmp-combo: move driver data initialisation earlier (git-fixes).
  • phy: qcom: qmp-usb: fix NULL-deref on runtime suspend (git-fixes).
  • phy: tegra: xusb: Add error pointer check in xusb.c (git-fixes).
  • phy: ti: phy-j721e-wiz: fix usxgmii configuration (git-fixes).
  • pinctrl: apple: check devm_kasprintf() returned value (git-fixes).
  • pinctrl: ocelot: fix system hang on level based interrupts (stable-fixes).
  • platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug (git-fixes).
  • platform/x86: dell-sysman: add support for alienware products (stable-fixes).
  • platform/x86: dell-wmi: Ignore suspend notifications (stable-fixes).
  • platform/x86: lenovo-ymc: Ignore the 0x0 state (stable-fixes).
  • platform/x86: touchscreen_dmi: add nanote-next quirk (stable-fixes).
  • power: reset: brcmstb: Do not go into infinite loop if reset fails (stable-fixes).
  • powercap: intel_rapl: Fix off by one in get_rpi() (git-fixes).
  • powerpc/64: Convert patch_instruction() to patch_u32() (bsc#1194869).
  • powerpc/boot: Handle allocation failure in simple_realloc() (bsc#1194869).
  • powerpc/boot: Only free if realloc() succeeds (bsc#1194869).
  • powerpc/code-patching: Add generic memory patching (bsc#1194869).
  • powerpc/code-patching: Perform hwsync in __patch_instruction() in case of failure (bsc#1194869).
  • powerpc/crypto: do not build aes-gcm-p10 by default (bsc#1230501 ltc#208632).
  • powerpc/crypto: fix missing skcipher dependency for aes-gcm-p10 (bsc#1230501 ltc#208632).
  • powerpc/vdso: Fix VDSO data access when running in a non-root time namespace (bsc#1194869).
  • powerpc/xics: Check return value of kasprintf in icp_native_map_one_cpu (bsc#1194869).
  • powerpc/xmon: Fix disassembly CPU feature checks (bsc#1065729).
  • printk: Add notation to console_srcu locking (bsc#1232183).
  • qed: avoid truncating work queue length (git-fixes).
  • rcu-tasks: Fix show_rcu_tasks_trace_gp_kthread buffer overflow (bsc#1226631).
  • rcu: Fix buffer overflow in print_cpu_stall_info() (bsc#1226623).
  • rpm/check-for-config-changes: add HAVE_RUST and RUSTC_SUPPORTS_ to IGNORED_CONFIGS_RE They depend on SHADOW_CALL_STACK.
  • rpm/release-projects: Add SLFO projects (bsc#1231293).
  • rpmsg: glink: Handle rejected intent request better (git-fixes).
  • runtime constants: add default dummy infrastructure (git-fixes).
  • runtime constants: add x86 architecture support (git-fixes).
  • s390/mm: Add cond_resched() to cmm_alloc/free_pages() (bsc#1228747).
  • s390/pci: Handle PCI error codes other than 0x3a (git-fixes bsc#1232629).
  • s390/sclp: Deactivate sclp after all its users (git-fixes bsc#1232628).
  • s390/sclp_vt220: Convert newlines to CRLF instead of LFCR (git-fixes bsc#1232627).
  • scsi: fnic: Move flush_work initialization out of if block (bsc#1230055).
  • scsi: lpfc: Add ELS_RSP cmd to the list of WQEs to flush in lpfc_els_flush_cmd() (bsc#1232757).
  • scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance (bsc#1232757).
  • scsi: lpfc: Fix kref imbalance on fabric ndlps from dev_loss_tmo handler (bsc#1232757).
  • scsi: lpfc: Remove trailing space after \n newline (bsc#1232757).
  • scsi: lpfc: Restrict support for 32 byte CDBs to specific HBAs (bsc#1232757 bsc#1228119).
  • scsi: lpfc: Revise TRACE_EVENT log flag severities from KERN_ERR to KERN_WARNING (bsc#1232757).
  • scsi: lpfc: Support loopback tests with VMID enabled (bsc#1232757).
  • scsi: lpfc: Update lpfc version to 14.4.0.5 (bsc#1232757).
  • scsi: lpfc: Update phba link state conditional before sending CMF_SYNC_WQE (bsc#1232757).
  • selftests/bpf: Add a test case to write mtu result into .rodata (git-fixes).
  • selftests/bpf: Add a test case to write strtol result into .rodata (git-fixes).
  • selftests/bpf: Add test for sign extension in coerce_subreg_to_size_sx() (git-fixes).
  • selftests/bpf: Add test for truncation after sign extension in coerce_reg_to_size_sx() (git-fixes).
  • selftests/bpf: Add tests for ldsx of pkt data/data_end/data_meta accesses (git-fixes).
  • selftests/bpf: Fix ARG_PTR_TO_LONG {half-,}uninitialized test (git-fixes).
  • selftests/bpf: Rename ARG_PTR_TO_LONG test description (git-fixes).
  • selftests/bpf: test for malformed BPF_CORE_TYPE_ID_LOCAL relocation (git-fixes).
  • serial: imx: Update mctrl old_status on RTSD interrupt (git-fixes).
  • serial: protect uart_port_dtr_rts() in uart_shutdown() too (stable-fixes).
  • soundwire: intel_bus_common: enable interrupts before exiting reset (stable-fixes).
  • spi: atmel-quadspi: Fix wrong register value written to MR (git-fixes).
  • spi: mtk-snfi: fix kerneldoc for mtk_snand_is_page_ops() (git-fixes).
  • spi: s3c64xx: fix timeout counters in flush_fifo (git-fixes).
  • spi: spi-fsl-dspi: Fix crash when not using GPIO chip select (git-fixes).
  • spi: spi-imx: Fix pm_runtime_set_suspended() with runtime pm enabled (git-fixes).
  • splice: always fsnotify_access(in), fsnotify_modify(out) on success (git-fixes).
  • splice: fsnotify_access(fd)/fsnotify_modify(fd) in vmsplice (git-fixes).
  • splice: fsnotify_access(in), fsnotify_modify(out) on success in tee (git-fixes).
  • srcu: Fix callbacks acceleration mishandling (git-fixes).
  • staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg() (git-fixes).
  • sumversion: Fix a memory leak in get_src_version() (git-fixes).
  • supported.conf: mark nhpoly1305 module as supported (bsc#1231035)
  • supported.conf: mark ultravisor userspace access as supported (bsc#1232090)
  • task_work: add kerneldoc annotation for 'data' argument (git-fixes).
  • thunderbolt: Improve DisplayPort tunnel setup process to be more robust (stable-fixes).
  • tools: hv: rm .*.cmd when make clean (git-fixes).
  • tracing/hwlat: Fix a race during cpuhp processing (git-fixes).
  • tracing/osnoise: Fix build when timerlat is not enabled (git-fixes).
  • tracing/osnoise: Skip running osnoise if all instances are off (git-fixes).
  • tracing/osnoise: Switch from PF_NO_SETAFFINITY to migrate_disable (git-fixes).
  • tracing/osnoise: Use a cpumask to know what threads are kthreads (git-fixes).
  • tracing/timerlat: Add interface_lock around clearing of kthread in stop_kthread() (git-fixes).
  • tracing/timerlat: Add user-space interface (git-fixes).
  • tracing/timerlat: Drop interface_lock in stop_kthread() (git-fixes).
  • tracing/timerlat: Fix a race during cpuhp processing (git-fixes).
  • tracing/timerlat: Fix duplicated kthread creation due to CPU online/offline (git-fixes).
  • tracing/timerlat: Move hrtimer_init to timerlat_fd open() (git-fixes).
  • tracing/timerlat: Only clear timer if a kthread exists (git-fixes).
  • tracing: Consider the NULL character when validating the event length (git-fixes).
  • tty: n_gsm: Fix use-after-free in gsm_cleanup_mux (stable-fixes).
  • ubifs: Fix adding orphan entry twice for the same inode (git-fixes).
  • ubifs: Fix unattached xattr inode if powercut happens after deleting (git-fixes).
  • ubifs: add check for crypto_shash_tfm_digest (git-fixes).
  • ubifs: dbg_orphan_check: Fix missed key type checking (git-fixes).
  • unicode: Do not special case ignorable code points (stable-fixes).
  • uprobe: avoid out-of-bounds memory access of fetching args (git-fixes).
  • uprobes: encapsulate preparation of uprobe args buffer (git-fixes).
  • uprobes: introduce the global struct vm_special_mapping xol_mapping (bsc#1231114).
  • uprobes: turn xol_area->pages into xol_area->page (bsc#1231114).
  • usb: chipidea: udc: enable suspend interrupt after usb reset (stable-fixes).
  • usb: dwc2: Adjust the timing of USB Driver Interrupt Registration in the Crashkernel Scenario (stable-fixes).
  • usb: dwc3: Wait for EndXfer completion before restoring GUSB2PHYCFG (git-fixes).
  • usb: dwc3: core: Stop processing of pending events if controller is halted (git-fixes).
  • usb: gadget: core: force synchronous registration (git-fixes).
  • usb: gadget: f_uac2: Replace snprintf() with the safer scnprintf() variant (stable-fixes).
  • usb: gadget: f_uac2: fix non-newline-terminated function name (stable-fixes).
  • usb: gadget: f_uac2: fix return value for UAC2_ATTRIBUTE_STRING store (git-fixes).
  • usb: phy: Fix API devm_usb_put_phy() can not release the phy (git-fixes).
  • usb: storage: ignore bogus device raised by JieLi BR21 USB sound chip (stable-fixes).
  • usb: typec: altmode should keep reference to parent (git-fixes).
  • usb: typec: fix unreleased fwnode_handle in typec_port_register_altmodes() (git-fixes).
  • usb: xhci: Fix problem with xhci resume from suspend (stable-fixes).
  • usb: xhci: fix loss of data on Cadence xHC (git-fixes).
  • usbip: tools: Fix detach_port() invalid port error path (git-fixes).
  • usbnet: fix cyclical race on disconnect with work queue (git-fixes).
  • vdpa: Fix an error handling path in eni_vdpa_probe() (git-fixes).
  • vdpa_sim_blk: Fix the potential leak of mgmt_dev (git-fixes).
  • vdpa_sim_blk: allocate the buffer zeroed (git-fixes).
  • vduse: avoid using __GFP_NOFAIL (git-fixes).
  • vfs: dcache: move hashlen_hash() from callers into d_hash() (git-fixes).
  • vhost/scsi: null-ptr-dereference in vhost_scsi_get_req() (git-fixes).
  • vhost_vdpa: assign irq bypass producer token correctly (git-fixes).
  • virtio_console: fix misc probe bugs (git-fixes).
  • vmalloc: modify the alloc_vmap_area() error message for better diagnostics (jsc#PED-10978).
  • vmxnet3: Add XDP support (bsc#1226498).
  • vmxnet3: Fix missing reserved tailroom (bsc#1226498).
  • vmxnet3: Fix packet corruption in vmxnet3_xdp_xmit_frame (bsc#1226498).
  • vmxnet3: add command to allow disabling of offloads (bsc#1226498).
  • vmxnet3: add latency measurement support in vmxnet3 (bsc#1226498).
  • vmxnet3: prepare for version 9 changes (bsc#1226498).
  • vmxnet3: update to version 9 (bsc#1226498).
  • vt: prevent kernel-infoleak in con_font_get() (git-fixes).
  • wifi: ath10k: Fix memory leak in management tx (git-fixes).
  • wifi: ath11k: Fix invalid ring usage in full monitor mode (git-fixes).
  • wifi: ath11k: fix array out-of-bound access in SoC stats (stable-fixes).
  • wifi: ath12k: fix array out-of-bound access in SoC stats (stable-fixes).
  • wifi: ath9k: fix possible integer overflow in ath9k_get_et_stats() (stable-fixes).
  • wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit (stable-fixes).
  • wifi: brcm80211: BRCM_TRACING should depend on TRACING (git-fixes).
  • wifi: cfg80211: Set correct chandef when starting CAC (stable-fixes).
  • wifi: cfg80211: clear wdev->cqm_config pointer on free (git-fixes).
  • wifi: iwlegacy: Fix 'field-spanning write' warning in il_enqueue_hcmd() (git-fixes).
  • wifi: iwlwifi: allow only CN mcc from WRDD (stable-fixes).
  • wifi: iwlwifi: config: label 'gl' devices as discrete (git-fixes).
  • wifi: iwlwifi: mvm: Fix a race in scan abort flow (stable-fixes).
  • wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd() (git-fixes).
  • wifi: iwlwifi: mvm: avoid NULL pointer dereference (stable-fixes).
  • wifi: iwlwifi: mvm: do not add default link in fw restart flow (git-fixes).
  • wifi: iwlwifi: mvm: do not leak a link on AP removal (git-fixes).
  • wifi: iwlwifi: mvm: drop wrong STA selection in TX (stable-fixes).
  • wifi: iwlwifi: mvm: use correct key iteration (stable-fixes).
  • wifi: iwlwifi: remove AX101, AX201 and AX203 support from LNL (stable-fixes).
  • wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower (git-fixes).
  • wifi: mac80211: fix RCU list iterations (stable-fixes).
  • wifi: mac80211: skip non-uploaded keys in ieee80211_iter_keys (git-fixes).
  • wifi: mt76: mt7915: add dummy HW offload of IEEE 802.11 fragmentation (stable-fixes).
  • wifi: mt76: mt7915: disable tx worker during tx BA session enable/disable (stable-fixes).
  • wifi: mt76: mt7915: hold dev->mt76.mutex while disabling tx worker (stable-fixes).
  • wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_cmd_802_11_scan_ext() (stable-fixes).
  • wifi: rtw88: 8821cu: Remove VID/PID 0bda:c82c (stable-fixes).
  • wifi: rtw88: Fix USB/SDIO devices not transmitting beacons (git-fixes).
  • wifi: rtw88: select WANT_DEV_COREDUMP (stable-fixes).
  • wifi: rtw89: avoid reading out of bounds when loading TX power FW elements (stable-fixes).
  • wifi: rtw89: avoid to add interface to list twice when SER (stable-fixes).
  • wifi: rtw89: correct base HT rate mask for firmware (stable-fixes).
  • x86/CPU/AMD: Only apply Zenbleed fix for Zen2 during late microcode load (git-fixes).
  • x86/Documentation: Indent 'note::' directive for protocol version number note (git-fixes).
  • x86/PCI: Check pcie_find_root_port() return for NULL (git-fixes).
  • x86/amd_nb: Add new PCI IDs for AMD family 1Ah model 60h (git-fixes).
  • x86/apic: Always explicitly disarm TSC-deadline timer (git-fixes).
  • x86/apic: Make x2apic_disable() work correctly (git-fixes).
  • x86/bugs: Do not use UNTRAIN_RET with IBPB on entry (git-fixes).
  • x86/bugs: Skip RSB fill at VMEXIT (git-fixes).
  • x86/cpufeatures: Add a IBPB_NO_RET BUG flag (git-fixes).
  • x86/cpufeatures: Define X86_FEATURE_AMD_IBPB_RET (git-fixes).
  • x86/entry: Have entry_ibpb() invalidate return predictions (git-fixes).
  • x86/entry: Remove unwanted instrumentation in common_interrupt() (git-fixes).
  • x86/hyperv: Set X86_FEATURE_TSC_KNOWN_FREQ when Hyper-V provides frequency (git-fixes).
  • x86/mm: Use IPIs to synchronize LAM enablement (git-fixes).
  • x86/resctrl: Annotate get_mem_config() functions as __init (git-fixes).
  • x86/resctrl: Avoid overflow in MB settings in bw_validate() (git-fixes).
  • x86/sev: Check for MWAITX and MONITORX opcodes in the #VC handler (git-fixes).
  • x86: do the user address masking outside the user access area (git-fixes).
  • x86: fix user address masking non-canonical speculation issue (git-fixes).
  • x86: make the masked_user_access_begin() macro use its argument only once (git-fixes).
  • x86: support user address masking instead of non-speculative conditional (git-fixes).
  • xfs: check opcode and iovec count match in xlog_recover_attri_commit_pass2 (git-fixes).
  • xfs: check shortform attr entry flags specifically (git-fixes).
  • xfs: convert delayed extents to unwritten when zeroing post eof blocks (git-fixes).
  • xfs: fix finding a last resort AG in xfs_filestream_pick_ag (git-fixes).
  • xfs: fix freeing speculative preallocations for preallocated files (git-fixes).
  • xfs: make sure sb_fdblocks is non-negative (git-fixes).
  • xfs: make the seq argument to xfs_bmapi_convert_delalloc() optional (git-fixes).
  • xfs: make xfs_bmapi_convert_delalloc() to allocate the target offset (git-fixes).
  • xfs: remove a racy if_bytes check in xfs_reflink_end_cow_extent (git-fixes).
  • xfs: validate recovered name buffers when recovering xattr items (git-fixes).
  • xhci: Add a quirk for writing ERST in high-low order (git-fixes).
  • xhci: Fix Link TRB DMA in command ring stopped completion event (git-fixes).
  • xhci: Fix incorrect stream context type macro (git-fixes).
  • xhci: Mitigate failed set dequeue pointer commands (git-fixes).
  • xhci: Use pm_runtime_get to prevent RPM on unsupported systems (git-fixes).
  • xhci: tegra: fix checked USB2 port number (git-fixes).
  • zonefs: Improve error handling (git-fixes).

Список пакетов

Image SLES15-SP6-Azure-Basic
kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard
kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC
kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure
kernel-azure-6.4.0-150600.8.17.2
SUSE Linux Enterprise Module for Public Cloud 15 SP6
kernel-azure-6.4.0-150600.8.17.2
kernel-azure-devel-6.4.0-150600.8.17.2
kernel-devel-azure-6.4.0-150600.8.17.1
kernel-source-azure-6.4.0-150600.8.17.1
kernel-syms-azure-6.4.0-150600.8.17.1
openSUSE Leap 15.6
cluster-md-kmp-azure-6.4.0-150600.8.17.2
dlm-kmp-azure-6.4.0-150600.8.17.2
gfs2-kmp-azure-6.4.0-150600.8.17.2
kernel-azure-6.4.0-150600.8.17.2
kernel-azure-devel-6.4.0-150600.8.17.2
kernel-azure-extra-6.4.0-150600.8.17.2
kernel-azure-livepatch-devel-6.4.0-150600.8.17.2
kernel-azure-optional-6.4.0-150600.8.17.2
kernel-azure-vdso-6.4.0-150600.8.17.2
kernel-devel-azure-6.4.0-150600.8.17.1
kernel-source-azure-6.4.0-150600.8.17.1
kernel-syms-azure-6.4.0-150600.8.17.1
kselftests-kmp-azure-6.4.0-150600.8.17.2
ocfs2-kmp-azure-6.4.0-150600.8.17.2
reiserfs-kmp-azure-6.4.0-150600.8.17.2

Описание

In the Linux kernel, the following vulnerability has been resolved: i3c: mipi-i3c-hci: Fix out of bounds access in hci_dma_irq_handler Do not loop over ring headers in hci_dma_irq_handler() that are not allocated and enabled in hci_dma_init(). Otherwise out of bounds access will occur from rings->headers[i] access when i >= number of allocated ring headers.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix htt pktlog locking The ath11k active pdevs are protected by RCU but the htt pktlog handling code calling ath11k_mac_get_ar_by_pdev_id() was not marked as a read-side critical section. Mark the code in question as an RCU read-side critical section to avoid any potential use-after-free issues. Compile tested only.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: tcp: do not accept ACK of bytes we never sent This patch is based on a detailed report and ideas from Yepeng Pan and Christian Rossow. ACK seq validation is currently following RFC 5961 5.2 guidelines: The ACK value is considered acceptable only if it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT). All incoming segments whose ACK value doesn't satisfy the above condition MUST be discarded and an ACK sent back. It needs to be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a duplicate (SEG.ACK < SND.UNA), it can be ignored. If the ACK acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an ACK, drop the segment, and return". The "ignored" above implies that the processing of the incoming data segment continues, which means the ACK value is treated as acceptable. This mitigation makes the ACK check more stringent since any ACK < SND.UNA wouldn't be accepted, instead only ACKs that are in the range ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT) get through. This can be refined for new (and possibly spoofed) flows, by not accepting ACK for bytes that were never sent. This greatly improves TCP security at a little cost. I added a Fixes: tag to make sure this patch will reach stable trees, even if the 'blamed' patch was adhering to the RFC. tp->bytes_acked was added in linux-4.2 Following packetdrill test (courtesy of Yepeng Pan) shows the issue at hand: 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +0 bind(3, ..., ...) = 0 +0 listen(3, 1024) = 0 // ---------------- Handshake ------------------- // // when window scale is set to 14 the window size can be extended to // 65535 * (2^14) = 1073725440. Linux would accept an ACK packet // with ack number in (Server_ISN+1-1073725440. Server_ISN+1) // ,though this ack number acknowledges some data never // sent by the server. +0 < S 0:0(0) win 65535 <mss 1400,nop,wscale 14> +0 > S. 0:0(0) ack 1 <...> +0 < . 1:1(0) ack 1 win 65535 +0 accept(3, ..., ...) = 4 // For the established connection, we send an ACK packet, // the ack packet uses ack number 1 - 1073725300 + 2^32, // where 2^32 is used to wrap around. // Note: we used 1073725300 instead of 1073725440 to avoid possible // edge cases. // 1 - 1073725300 + 2^32 = 3221241997 // Oops, old kernels happily accept this packet. +0 < . 1:1001(1000) ack 3221241997 win 65535 // After the kernel fix the following will be replaced by a challenge ACK, // and prior malicious frame would be dropped. +0 > . 1:1(0) ack 1001


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

** REJECT ** This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: media: pci: cx23885: check cx23885_vdev_init() return cx23885_vdev_init() can return a NULL pointer, but that pointer is used in the next line without a check. Add a NULL pointer check and go to the error unwind if it is NULL.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix possible NULL pointer dereference in send_acknowledge() Handle memory allocation failure from nci_skb_alloc() (calling alloc_skb()) to avoid possible NULL pointer dereference.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

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.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: md: Don't ignore suspended array in md_check_recovery() mddev_suspend() never stop sync_thread, hence it doesn't make sense to ignore suspended array in md_check_recovery(), which might cause sync_thread can't be unregistered. After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following hang can be triggered by test shell/integrity-caching.sh: 1) suspend the array: raid_postsuspend mddev_suspend 2) stop the array: raid_dtr md_stop __md_stop_writes stop_sync_thread set_bit(MD_RECOVERY_INTR, &mddev->recovery); md_wakeup_thread_directly(mddev->sync_thread); wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)) 3) sync thread done: md_do_sync set_bit(MD_RECOVERY_DONE, &mddev->recovery); md_wakeup_thread(mddev->thread); 4) daemon thread can't unregister sync thread: md_check_recovery if (mddev->suspended) return; -> return directly md_read_sync_thread clear_bit(MD_RECOVERY_RUNNING, &mddev->recovery); -> MD_RECOVERY_RUNNING can't be cleared, hence step 2 hang; This problem is not just related to dm-raid, fix it by ignoring suspended array in md_check_recovery(). And follow up patches will improve dm-raid better to frozen sync thread during suspend.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

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.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fixed integer types and null check locations [why]: issues fixed: - comparison with wider integer type in loop condition which can cause infinite loops - pointer dereference before null check


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: nouveau/dmem: handle kcalloc() allocation failure The kcalloc() in nouveau_dmem_evict_chunk() will return null if the physical memory has run out. As a result, if we dereference src_pfns, dst_pfns or dma_addrs, the null pointer dereference bugs will happen. Moreover, the GPU is going away. If the kcalloc() fails, we could not evict all pages mapping a chunk. So this patch adds a __GFP_NOFAIL flag in kcalloc(). Finally, as there is no need to have physically contiguous memory, this patch switches kcalloc() to kvcalloc() in order to avoid failing allocations.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: vmxnet3: Fix missing reserved tailroom Use rbi->len instead of rcd->len for non-dataring packet. Found issue: XDP_WARN: xdp_update_frame_from_buff(line:278): Driver BUG: missing reserved tailroom WARNING: CPU: 0 PID: 0 at net/core/xdp.c:586 xdp_warn+0xf/0x20 CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W O 6.5.1 #1 RIP: 0010:xdp_warn+0xf/0x20 ... ? xdp_warn+0xf/0x20 xdp_do_redirect+0x15f/0x1c0 vmxnet3_run_xdp+0x17a/0x400 [vmxnet3] vmxnet3_process_xdp+0xe4/0x760 [vmxnet3] ? vmxnet3_tq_tx_complete.isra.0+0x21e/0x2c0 [vmxnet3] vmxnet3_rq_rx_complete+0x7ad/0x1120 [vmxnet3] vmxnet3_poll_rx_only+0x2d/0xa0 [vmxnet3] __napi_poll+0x20/0x180 net_rx_action+0x177/0x390


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: media: edia: dvbdev: fix a use-after-free In dvb_register_device, *pdvbdev is set equal to dvbdev, which is freed in several error-handling paths. However, *pdvbdev is not set to NULL after dvbdev's deallocation, causing use-after-frees in many places, for example, in the following call chain: budget_register |-> dvb_dmxdev_init |-> dvb_register_device |-> dvb_dmxdev_release |-> dvb_unregister_device |-> dvb_remove_device |-> dvb_device_put |-> kref_put When calling dvb_unregister_device, dmxdev->dvbdev (i.e. *pdvbdev in dvb_register_device) could point to memory that had been freed in dvb_register_device. Thereafter, this pointer is transferred to kref_put and triggering a use-after-free.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: arm64: tlb: Fix TLBI RANGE operand KVM/arm64 relies on TLBI RANGE feature to flush TLBs when the dirty pages are collected by VMM and the page table entries become write protected during live migration. Unfortunately, the operand passed to the TLBI RANGE instruction isn't correctly sorted out due to the commit 117940aa6e5f ("KVM: arm64: Define kvm_tlb_flush_vmid_range()"). It leads to crash on the destination VM after live migration because TLBs aren't flushed completely and some of the dirty pages are missed. For example, I have a VM where 8GB memory is assigned, starting from 0x40000000 (1GB). Note that the host has 4KB as the base page size. In the middile of migration, kvm_tlb_flush_vmid_range() is executed to flush TLBs. It passes MAX_TLBI_RANGE_PAGES as the argument to __kvm_tlb_flush_vmid_range() and __flush_s2_tlb_range_op(). SCALE#3 and NUM#31, corresponding to MAX_TLBI_RANGE_PAGES, isn't supported by __TLBI_RANGE_NUM(). In this specific case, -1 has been returned from __TLBI_RANGE_NUM() for SCALE#3/2/1/0 and rejected by the loop in the __flush_tlb_range_op() until the variable @scale underflows and becomes -9, 0xffff708000040000 is set as the operand. The operand is wrong since it's sorted out by __TLBI_VADDR_RANGE() according to invalid @scale and @num. Fix it by extending __TLBI_RANGE_NUM() to support the combination of SCALE#3 and NUM#31. With the changes, [-1 31] instead of [-1 30] can be returned from the macro, meaning the TLBs for 0x200000 pages in the above example can be flushed in one shoot with SCALE#3 and NUM#31. The macro TLBI_RANGE_MASK is dropped since no one uses it any more. The comments are also adjusted accordingly.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: net/sched: taprio: extend minimum interval restriction to entire cycle too It is possible for syzbot to side-step the restriction imposed by the blamed commit in the Fixes: tag, because the taprio UAPI permits a cycle-time different from (and potentially shorter than) the sum of entry intervals. We need one more restriction, which is that the cycle time itself must be larger than N * ETH_ZLEN bit times, where N is the number of schedule entries. This restriction needs to apply regardless of whether the cycle time came from the user or was the implicit, auto-calculated value, so we move the existing "cycle == 0" check outside the "if "(!new->cycle_time)" branch. This way covers both conditions and scenarios. Add a selftest which illustrates the issue triggered by syzbot.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: rcu: Fix buffer overflow in print_cpu_stall_info() The rcuc-starvation output from print_cpu_stall_info() might overflow the buffer if there is a huge difference in jiffies difference. The situation might seem improbable, but computers sometimes get very confused about time, which can result in full-sized integers, and, in this case, buffer overflow. Also, the unsigned jiffies difference is printed using %ld, which is normally for signed integers. This is intentional for debugging purposes, but it is not obvious from the code. This commit therefore changes sprintf() to snprintf() and adds a clarifying comment about intention of %ld format. Found by Linux Verification Center (linuxtesting.org) with SVACE.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: rcu-tasks: Fix show_rcu_tasks_trace_gp_kthread buffer overflow There is a possibility of buffer overflow in show_rcu_tasks_trace_gp_kthread() if counters, passed to sprintf() are huge. Counter numbers, needed for this are unrealistically high, but buffer overflow is still possible. Use snprintf() with buffer size instead of sprintf(). Found by Linux Verification Center (linuxtesting.org) with SVACE.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: jffs2: prevent xattr node from overflowing the eraseblock Add a check to make sure that the requested xattr node size is no larger than the eraseblock minus the cleanmarker. Unlike the usual inode nodes, the xattr nodes aren't split into parts and spread across multiple eraseblocks, which means that a xattr node must not occupy more than one eraseblock. If the requested xattr value is too large, the xattr node can spill onto the next eraseblock, overwriting the nodes and causing errors such as: jffs2: argh. node added in wrong place at 0x0000b050(2) jffs2: nextblock 0x0000a000, expected at 0000b00c jffs2: error: (823) do_verify_xattr_datum: node CRC failed at 0x01e050, read=0xfc892c93, calc=0x000000 jffs2: notice: (823) jffs2_get_inode_nodes: Node header CRC failed at 0x01e00c. {848f,2fc4,0fef511f,59a3d171} jffs2: Node at 0x0000000c with length 0x00001044 would run over the end of the erase block jffs2: Perhaps the file system was created with the wrong erase size? jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000010: 0x1044 instead This breaks the filesystem and can lead to KASAN crashes such as: BUG: KASAN: slab-out-of-bounds in jffs2_sum_add_kvec+0x125e/0x15d0 Read of size 4 at addr ffff88802c31e914 by task repro/830 CPU: 0 PID: 830 Comm: repro Not tainted 6.9.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0xc6/0x120 print_report+0xc4/0x620 ? __virt_addr_valid+0x308/0x5b0 kasan_report+0xc1/0xf0 ? jffs2_sum_add_kvec+0x125e/0x15d0 ? jffs2_sum_add_kvec+0x125e/0x15d0 jffs2_sum_add_kvec+0x125e/0x15d0 jffs2_flash_direct_writev+0xa8/0xd0 jffs2_flash_writev+0x9c9/0xef0 ? __x64_sys_setxattr+0xc4/0x160 ? do_syscall_64+0x69/0x140 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Found by Linux Verification Center (linuxtesting.org) with Syzkaller.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: ocfs2: strict bound check before memcmp in ocfs2_xattr_find_entry() xattr in ocfs2 maybe 'non-indexed', which saved with additional space requested. It's better to check if the memory is out of bound before memcmp, although this possibility mainly comes from crafted poisonous images.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: mm/filemap: skip to create PMD-sized page cache if needed On ARM64, HPAGE_PMD_ORDER is 13 when the base page size is 64KB. The PMD-sized page cache can't be supported by xarray as the following error messages indicate. ------------[ cut here ]------------ WARNING: CPU: 35 PID: 7484 at lib/xarray.c:1025 xas_split_alloc+0xf8/0x128 Modules linked in: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib \ nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct \ nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 \ ip_set rfkill nf_tables nfnetlink vfat fat virtio_balloon drm \ fuse xfs libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 \ sha1_ce virtio_net net_failover virtio_console virtio_blk failover \ dimlib virtio_mmio CPU: 35 PID: 7484 Comm: test Kdump: loaded Tainted: G W 6.10.0-rc5-gavin+ #9 Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024 pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : xas_split_alloc+0xf8/0x128 lr : split_huge_page_to_list_to_order+0x1c4/0x720 sp : ffff800087a4f6c0 x29: ffff800087a4f6c0 x28: ffff800087a4f720 x27: 000000001fffffff x26: 0000000000000c40 x25: 000000000000000d x24: ffff00010625b858 x23: ffff800087a4f720 x22: ffffffdfc0780000 x21: 0000000000000000 x20: 0000000000000000 x19: ffffffdfc0780000 x18: 000000001ff40000 x17: 00000000ffffffff x16: 0000018000000000 x15: 51ec004000000000 x14: 0000e00000000000 x13: 0000000000002000 x12: 0000000000000020 x11: 51ec000000000000 x10: 51ece1c0ffff8000 x9 : ffffbeb961a44d28 x8 : 0000000000000003 x7 : ffffffdfc0456420 x6 : ffff0000e1aa6eb8 x5 : 20bf08b4fe778fca x4 : ffffffdfc0456420 x3 : 0000000000000c40 x2 : 000000000000000d x1 : 000000000000000c x0 : 0000000000000000 Call trace: xas_split_alloc+0xf8/0x128 split_huge_page_to_list_to_order+0x1c4/0x720 truncate_inode_partial_folio+0xdc/0x160 truncate_inode_pages_range+0x1b4/0x4a8 truncate_pagecache_range+0x84/0xa0 xfs_flush_unmap_range+0x70/0x90 [xfs] xfs_file_fallocate+0xfc/0x4d8 [xfs] vfs_fallocate+0x124/0x2e8 ksys_fallocate+0x4c/0xa0 __arm64_sys_fallocate+0x24/0x38 invoke_syscall.constprop.0+0x7c/0xd8 do_el0_svc+0xb4/0xd0 el0_svc+0x44/0x1d8 el0t_64_sync_handler+0x134/0x150 el0t_64_sync+0x17c/0x180 Fix it by skipping to allocate PMD-sized page cache when its size is larger than MAX_PAGECACHE_ORDER. For this specific case, we will fall to regular path where the readahead window is determined by BDI's sysfs file (read_ahead_kb).


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: i40e: Fix XDP program unloading while removing the driver The commit 6533e558c650 ("i40e: Fix reset path while removing the driver") introduced a new PF state "__I40E_IN_REMOVE" to block modifying the XDP program while the driver is being removed. Unfortunately, such a change is useful only if the ".ndo_bpf()" callback was called out of the rmmod context because unloading the existing XDP program is also a part of driver removing procedure. In other words, from the rmmod context the driver is expected to unload the XDP program without reporting any errors. Otherwise, the kernel warning with callstack is printed out to dmesg. Example failing scenario: 1. Load the i40e driver. 2. Load the XDP program. 3. Unload the i40e driver (using "rmmod" command). The example kernel warning log: [ +0.004646] WARNING: CPU: 94 PID: 10395 at net/core/dev.c:9290 unregister_netdevice_many_notify+0x7a9/0x870 [...] [ +0.010959] RIP: 0010:unregister_netdevice_many_notify+0x7a9/0x870 [...] [ +0.002726] Call Trace: [ +0.002457] <TASK> [ +0.002119] ? __warn+0x80/0x120 [ +0.003245] ? unregister_netdevice_many_notify+0x7a9/0x870 [ +0.005586] ? report_bug+0x164/0x190 [ +0.003678] ? handle_bug+0x3c/0x80 [ +0.003503] ? exc_invalid_op+0x17/0x70 [ +0.003846] ? asm_exc_invalid_op+0x1a/0x20 [ +0.004200] ? unregister_netdevice_many_notify+0x7a9/0x870 [ +0.005579] ? unregister_netdevice_many_notify+0x3cc/0x870 [ +0.005586] unregister_netdevice_queue+0xf7/0x140 [ +0.004806] unregister_netdev+0x1c/0x30 [ +0.003933] i40e_vsi_release+0x87/0x2f0 [i40e] [ +0.004604] i40e_remove+0x1a1/0x420 [i40e] [ +0.004220] pci_device_remove+0x3f/0xb0 [ +0.003943] device_release_driver_internal+0x19f/0x200 [ +0.005243] driver_detach+0x48/0x90 [ +0.003586] bus_remove_driver+0x6d/0xf0 [ +0.003939] pci_unregister_driver+0x2e/0xb0 [ +0.004278] i40e_exit_module+0x10/0x5f0 [i40e] [ +0.004570] __do_sys_delete_module.isra.0+0x197/0x310 [ +0.005153] do_syscall_64+0x85/0x170 [ +0.003684] ? syscall_exit_to_user_mode+0x69/0x220 [ +0.004886] ? do_syscall_64+0x95/0x170 [ +0.003851] ? exc_page_fault+0x7e/0x180 [ +0.003932] entry_SYSCALL_64_after_hwframe+0x71/0x79 [ +0.005064] RIP: 0033:0x7f59dc9347cb [ +0.003648] Code: 73 01 c3 48 8b 0d 65 16 0c 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 b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 35 16 0c 00 f7 d8 64 89 01 48 [ +0.018753] RSP: 002b:00007ffffac99048 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 [ +0.007577] RAX: ffffffffffffffda RBX: 0000559b9bb2f6e0 RCX: 00007f59dc9347cb [ +0.007140] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 0000559b9bb2f748 [ +0.007146] RBP: 00007ffffac99070 R08: 1999999999999999 R09: 0000000000000000 [ +0.007133] R10: 00007f59dc9a5ac0 R11: 0000000000000206 R12: 0000000000000000 [ +0.007141] R13: 00007ffffac992d8 R14: 0000559b9bb2f6e0 R15: 0000000000000000 [ +0.007151] </TASK> [ +0.002204] ---[ end trace 0000000000000000 ]--- Fix this by checking if the XDP program is being loaded or unloaded. Then, block only loading a new program while "__I40E_IN_REMOVE" is set. Also, move testing "__I40E_IN_REMOVE" flag to the beginning of XDP_SETUP callback to avoid unnecessary operations and checks.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: nvme-fabrics: use reserved tag for reg read/write command In some scenarios, if too many commands are issued by nvme command in the same time by user tasks, this may exhaust all tags of admin_q. If a reset (nvme reset or IO timeout) occurs before these commands finish, reconnect routine may fail to update nvme regs due to insufficient tags, which will cause kernel hang forever. In order to workaround this issue, maybe we can let reg_read32()/reg_read64()/reg_write32() use reserved tags. This maybe safe for nvmf: 1. For the disable ctrl path, we will not issue connect command 2. For the enable ctrl / fw activate path, since connect and reg_xx() are called serially. So the reserved tags may still be enough while reg_xx() use reserved tags.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: IB/core: Implement a limit on UMAD receive List The existing behavior of ib_umad, which maintains received MAD packets in an unbounded list, poses a risk of uncontrolled growth. As user-space applications extract packets from this list, the rate of extraction may not match the rate of incoming packets, leading to potential list overflow. To address this, we introduce a limit to the size of the list. After considering typical scenarios, such as OpenSM processing, which can handle approximately 100k packets per second, and the 1-second retry timeout for most packets, we set the list size limit to 200k. Packets received beyond this limit are dropped, assuming they are likely timed out by the time they are handled by user-space. Notably, packets queued on the receive list due to reasons like timed-out sends are preserved even when the list is full.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: idpf: fix UAFs when destroying the queues The second tagged commit started sometimes (very rarely, but possible) throwing WARNs from net/core/page_pool.c:page_pool_disable_direct_recycling(). Turned out idpf frees interrupt vectors with embedded NAPIs *before* freeing the queues making page_pools' NAPI pointers lead to freed memory before these pools are destroyed by libeth. It's not clear whether there are other accesses to the freed vectors when destroying the queues, but anyway, we usually free queue/interrupt vectors only when the queues are destroyed and the NAPIs are guaranteed to not be referenced anywhere. Invert the allocation and freeing logic making queue/interrupt vectors be allocated first and freed last. Vectors don't require queues to be present, so this is safe. Additionally, this change allows to remove that useless queue->q_vector pointer cleanup, as vectors are still valid when freeing the queues (+ both are freed within one function, so it's not clear why nullify the pointers at all).


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: sched/smt: Fix unbalance sched_smt_present dec/inc I got the following warn report while doing stress test: jump label: negative count! WARNING: CPU: 3 PID: 38 at kernel/jump_label.c:263 static_key_slow_try_dec+0x9d/0xb0 Call Trace: <TASK> __static_key_slow_dec_cpuslocked+0x16/0x70 sched_cpu_deactivate+0x26e/0x2a0 cpuhp_invoke_callback+0x3ad/0x10d0 cpuhp_thread_fun+0x3f5/0x680 smpboot_thread_fn+0x56d/0x8d0 kthread+0x309/0x400 ret_from_fork+0x41/0x70 ret_from_fork_asm+0x1b/0x30 </TASK> Because when cpuset_cpu_inactive() fails in sched_cpu_deactivate(), the cpu offline failed, but sched_smt_present is decremented before calling sched_cpu_deactivate(), it leads to unbalanced dec/inc, so fix it by incrementing sched_smt_present in the error path.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: idpf: fix memory leaks and crashes while performing a soft reset The second tagged commit introduced a UAF, as it removed restoring q_vector->vport pointers after reinitializating the structures. This is due to that all queue allocation functions are performed here with the new temporary vport structure and those functions rewrite the backpointers to the vport. Then, this new struct is freed and the pointers start leading to nowhere. But generally speaking, the current logic is very fragile. It claims to be more reliable when the system is low on memory, but in fact, it consumes two times more memory as at the moment of running this function, there are two vports allocated with their queues and vectors. Moreover, it claims to prevent the driver from running into "bad state", but in fact, any error during the rebuild leaves the old vport in the partially allocated state. Finally, if the interface is down when the function is called, it always allocates a new queue set, but when the user decides to enable the interface later on, vport_open() allocates them once again, IOW there's a clear memory leak here. Just don't allocate a new queue set when performing a reset, that solves crashes and memory leaks. Readd the old queue number and reopen the interface on rollback - that solves limbo states when the device is left disabled and/or without HW queues enabled.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: netem: fix return value if duplicate enqueue fails There is a bug in netem_enqueue() introduced by commit 5845f706388a ("net: netem: fix skb length BUG_ON in __skb_to_sgvec") that can lead to a use-after-free. This commit made netem_enqueue() always return NET_XMIT_SUCCESS when a packet is duplicated, which can cause the parent qdisc's q.qlen to be mistakenly incremented. When this happens qlen_notify() may be skipped on the parent during destruction, leaving a dangling pointer for some classful qdiscs like DRR. There are two ways for the bug happen: - If the duplicated packet is dropped by rootq->enqueue() and then the original packet is also dropped. - If rootq->enqueue() sends the duplicated packet to a different qdisc and the original packet is dropped. In both cases NET_XMIT_SUCCESS is returned even though no packets are enqueued at the netem qdisc. The fix is to defer the enqueue of the duplicate packet until after the original packet has been guaranteed to return NET_XMIT_SUCCESS.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE copy_fd_bitmaps(new, old, count) is expected to copy the first count/BITS_PER_LONG bits from old->full_fds_bits[] and fill the rest with zeroes. What it does is copying enough words (BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest. That works fine, *if* all bits past the cutoff point are clear. Otherwise we are risking garbage from the last word we'd copied. For most of the callers that is true - expand_fdtable() has count equal to old->max_fds, so there's no open descriptors past count, let alone fully occupied words in ->open_fds[], which is what bits in ->full_fds_bits[] correspond to. The other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds), which is the smallest multiple of BITS_PER_LONG that covers all opened descriptors below max_fds. In the common case (copying on fork()) max_fds is ~0U, so all opened descriptors will be below it and we are fine, by the same reasons why the call in expand_fdtable() is safe. Unfortunately, there is a case where max_fds is less than that and where we might, indeed, end up with junk in ->full_fds_bits[] - close_range(from, to, CLOSE_RANGE_UNSHARE) with * descriptor table being currently shared * 'to' being above the current capacity of descriptor table * 'from' being just under some chunk of opened descriptors. In that case we end up with observably wrong behaviour - e.g. spawn a child with CLONE_FILES, get all descriptors in range 0..127 open, then close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) ending up with descriptor #128, despite #64 being observably not open. The minimally invasive fix would be to deal with that in dup_fd(). If this proves to add measurable overhead, we can go that way, but let's try to fix copy_fd_bitmaps() first. * new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size). * make copy_fd_bitmaps() take the bitmap size in words, rather than bits; it's 'count' argument is always a multiple of BITS_PER_LONG, so we are not losing any information, and that way we can use the same helper for all three bitmaps - compiler will see that count is a multiple of BITS_PER_LONG for the large ones, so it'll generate plain memcpy()+memset(). Reproducer added to tools/testing/selftests/core/close_range_test.c


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: bonding: change ipsec_lock from spin lock to mutex In the cited commit, bond->ipsec_lock is added to protect ipsec_list, hence xdo_dev_state_add and xdo_dev_state_delete are called inside this lock. As ipsec_lock is a spin lock and such xfrmdev ops may sleep, "scheduling while atomic" will be triggered when changing bond's active slave. [ 101.055189] BUG: scheduling while atomic: bash/902/0x00000200 [ 101.055726] Modules linked in: [ 101.058211] CPU: 3 PID: 902 Comm: bash Not tainted 6.9.0-rc4+ #1 [ 101.058760] Hardware name: [ 101.059434] Call Trace: [ 101.059436] <TASK> [ 101.060873] dump_stack_lvl+0x51/0x60 [ 101.061275] __schedule_bug+0x4e/0x60 [ 101.061682] __schedule+0x612/0x7c0 [ 101.062078] ? __mod_timer+0x25c/0x370 [ 101.062486] schedule+0x25/0xd0 [ 101.062845] schedule_timeout+0x77/0xf0 [ 101.063265] ? asm_common_interrupt+0x22/0x40 [ 101.063724] ? __bpf_trace_itimer_state+0x10/0x10 [ 101.064215] __wait_for_common+0x87/0x190 [ 101.064648] ? usleep_range_state+0x90/0x90 [ 101.065091] cmd_exec+0x437/0xb20 [mlx5_core] [ 101.065569] mlx5_cmd_do+0x1e/0x40 [mlx5_core] [ 101.066051] mlx5_cmd_exec+0x18/0x30 [mlx5_core] [ 101.066552] mlx5_crypto_create_dek_key+0xea/0x120 [mlx5_core] [ 101.067163] ? bonding_sysfs_store_option+0x4d/0x80 [bonding] [ 101.067738] ? kmalloc_trace+0x4d/0x350 [ 101.068156] mlx5_ipsec_create_sa_ctx+0x33/0x100 [mlx5_core] [ 101.068747] mlx5e_xfrm_add_state+0x47b/0xaa0 [mlx5_core] [ 101.069312] bond_change_active_slave+0x392/0x900 [bonding] [ 101.069868] bond_option_active_slave_set+0x1c2/0x240 [bonding] [ 101.070454] __bond_opt_set+0xa6/0x430 [bonding] [ 101.070935] __bond_opt_set_notify+0x2f/0x90 [bonding] [ 101.071453] bond_opt_tryset_rtnl+0x72/0xb0 [bonding] [ 101.071965] bonding_sysfs_store_option+0x4d/0x80 [bonding] [ 101.072567] kernfs_fop_write_iter+0x10c/0x1a0 [ 101.073033] vfs_write+0x2d8/0x400 [ 101.073416] ? alloc_fd+0x48/0x180 [ 101.073798] ksys_write+0x5f/0xe0 [ 101.074175] do_syscall_64+0x52/0x110 [ 101.074576] entry_SYSCALL_64_after_hwframe+0x4b/0x53 As bond_ipsec_add_sa_all and bond_ipsec_del_sa_all are only called from bond_change_active_slave, which requires holding the RTNL lock. And bond_ipsec_add_sa and bond_ipsec_del_sa are xfrm state xdo_dev_state_add and xdo_dev_state_delete APIs, which are in user context. So ipsec_lock doesn't have to be spin lock, change it to mutex, and thus the above issue can be resolved.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: apparmor: fix possible NULL pointer dereference profile->parent->dents[AAFS_PROF_DIR] could be NULL only if its parent is made from __create_missing_ancestors(..) and 'ent->old' is NULL in aa_replace_profiles(..). In that case, it must return an error code and the code, -ENOENT represents its state that the path of its parent is not existed yet. BUG: kernel NULL pointer dereference, address: 0000000000000030 PGD 0 P4D 0 PREEMPT SMP PTI CPU: 4 PID: 3362 Comm: apparmor_parser Not tainted 6.8.0-24-generic #24 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 RIP: 0010:aafs_create.constprop.0+0x7f/0x130 Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae RSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82baac10 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007be9f22cf740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000030 CR3: 0000000134b08000 CR4: 00000000000006f0 Call Trace: <TASK> ? show_regs+0x6d/0x80 ? __die+0x24/0x80 ? page_fault_oops+0x99/0x1b0 ? kernelmode_fixup_or_oops+0xb2/0x140 ? __bad_area_nosemaphore+0x1a5/0x2c0 ? find_vma+0x34/0x60 ? bad_area_nosemaphore+0x16/0x30 ? do_user_addr_fault+0x2a2/0x6b0 ? exc_page_fault+0x83/0x1b0 ? asm_exc_page_fault+0x27/0x30 ? aafs_create.constprop.0+0x7f/0x130 ? aafs_create.constprop.0+0x51/0x130 __aafs_profile_mkdir+0x3d6/0x480 aa_replace_profiles+0x83f/0x1270 policy_update+0xe3/0x180 profile_load+0xbc/0x150 ? rw_verify_area+0x47/0x140 vfs_write+0x100/0x480 ? __x64_sys_openat+0x55/0xa0 ? syscall_exit_to_user_mode+0x86/0x260 ksys_write+0x73/0x100 __x64_sys_write+0x19/0x30 x64_sys_call+0x7e/0x25c0 do_syscall_64+0x7f/0x180 entry_SYSCALL_64_after_hwframe+0x78/0x80 RIP: 0033:0x7be9f211c574 Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89 RSP: 002b:00007ffd26f2b8c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00005d504415e200 RCX: 00007be9f211c574 RDX: 0000000000001fc1 RSI: 00005d504418bc80 RDI: 0000000000000004 RBP: 0000000000001fc1 R08: 0000000000001fc1 R09: 0000000080000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00005d504418bc80 R13: 0000000000000004 R14: 00007ffd26f2b9b0 R15: 00007ffd26f2ba30 </TASK> Modules linked in: snd_seq_dummy snd_hrtimer qrtr snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device i2c_i801 snd_timer i2c_smbus qxl snd soundcore drm_ttm_helper lpc_ich ttm joydev input_leds serio_raw mac_hid binfmt_misc msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs qemu_fw_cfg ip_tables x_tables autofs4 hid_generic usbhid hid ahci libahci psmouse virtio_rng xhci_pci xhci_pci_renesas CR2: 0000000000000030 ---[ end trace 0000000000000000 ]--- RIP: 0010:aafs_create.constprop.0+0x7f/0x130 Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae RSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000 ---truncated---


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: bpf: Remove tst_run from lwt_seg6local_prog_ops. The syzbot reported that the lwt_seg6 related BPF ops can be invoked via bpf_test_run() without without entering input_action_end_bpf() first. Martin KaFai Lau said that self test for BPF_PROG_TYPE_LWT_SEG6LOCAL probably didn't work since it was introduced in commit 04d4b274e2a ("ipv6: sr: Add seg6local action End.BPF"). The reason is that the per-CPU variable seg6_bpf_srh_states::srh is never assigned in the self test case but each BPF function expects it. Remove test_run for BPF_PROG_TYPE_LWT_SEG6LOCAL.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: ice: move netif_queue_set_napi to rtnl-protected sections Currently, netif_queue_set_napi() is called from ice_vsi_rebuild() that is not rtnl-locked when called from the reset. This creates the need to take the rtnl_lock just for a single function and complicates the synchronization with .ndo_bpf. At the same time, there no actual need to fill napi-to-queue information at this exact point. Fill napi-to-queue information when opening the VSI and clear it when the VSI is being closed. Those routines are already rtnl-locked. Also, rewrite napi-to-queue assignment in a way that prevents inclusion of XDP queues, as this leads to out-of-bounds writes, such as one below. [ +0.000004] BUG: KASAN: slab-out-of-bounds in netif_queue_set_napi+0x1c2/0x1e0 [ +0.000012] Write of size 8 at addr ffff889881727c80 by task bash/7047 [ +0.000006] CPU: 24 PID: 7047 Comm: bash Not tainted 6.10.0-rc2+ #2 [ +0.000004] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0014.082620210524 08/26/2021 [ +0.000003] Call Trace: [ +0.000003] <TASK> [ +0.000002] dump_stack_lvl+0x60/0x80 [ +0.000007] print_report+0xce/0x630 [ +0.000007] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ +0.000007] ? __virt_addr_valid+0x1c9/0x2c0 [ +0.000005] ? netif_queue_set_napi+0x1c2/0x1e0 [ +0.000003] kasan_report+0xe9/0x120 [ +0.000004] ? netif_queue_set_napi+0x1c2/0x1e0 [ +0.000004] netif_queue_set_napi+0x1c2/0x1e0 [ +0.000005] ice_vsi_close+0x161/0x670 [ice] [ +0.000114] ice_dis_vsi+0x22f/0x270 [ice] [ +0.000095] ice_pf_dis_all_vsi.constprop.0+0xae/0x1c0 [ice] [ +0.000086] ice_prepare_for_reset+0x299/0x750 [ice] [ +0.000087] pci_dev_save_and_disable+0x82/0xd0 [ +0.000006] pci_reset_function+0x12d/0x230 [ +0.000004] reset_store+0xa0/0x100 [ +0.000006] ? __pfx_reset_store+0x10/0x10 [ +0.000002] ? __pfx_mutex_lock+0x10/0x10 [ +0.000004] ? __check_object_size+0x4c1/0x640 [ +0.000007] kernfs_fop_write_iter+0x30b/0x4a0 [ +0.000006] vfs_write+0x5d6/0xdf0 [ +0.000005] ? fd_install+0x180/0x350 [ +0.000005] ? __pfx_vfs_write+0x10/0xA10 [ +0.000004] ? do_fcntl+0x52c/0xcd0 [ +0.000004] ? kasan_save_track+0x13/0x60 [ +0.000003] ? kasan_save_free_info+0x37/0x60 [ +0.000006] ksys_write+0xfa/0x1d0 [ +0.000003] ? __pfx_ksys_write+0x10/0x10 [ +0.000002] ? __x64_sys_fcntl+0x121/0x180 [ +0.000004] ? _raw_spin_lock+0x87/0xe0 [ +0.000005] do_syscall_64+0x80/0x170 [ +0.000007] ? _raw_spin_lock+0x87/0xe0 [ +0.000004] ? __pfx__raw_spin_lock+0x10/0x10 [ +0.000003] ? file_close_fd_locked+0x167/0x230 [ +0.000005] ? syscall_exit_to_user_mode+0x7d/0x220 [ +0.000005] ? do_syscall_64+0x8c/0x170 [ +0.000004] ? do_syscall_64+0x8c/0x170 [ +0.000003] ? do_syscall_64+0x8c/0x170 [ +0.000003] ? fput+0x1a/0x2c0 [ +0.000004] ? filp_close+0x19/0x30 [ +0.000004] ? do_dup2+0x25a/0x4c0 [ +0.000004] ? __x64_sys_dup2+0x6e/0x2e0 [ +0.000002] ? syscall_exit_to_user_mode+0x7d/0x220 [ +0.000004] ? do_syscall_64+0x8c/0x170 [ +0.000003] ? __count_memcg_events+0x113/0x380 [ +0.000005] ? handle_mm_fault+0x136/0x820 [ +0.000005] ? do_user_addr_fault+0x444/0xa80 [ +0.000004] ? clear_bhb_loop+0x25/0x80 [ +0.000004] ? clear_bhb_loop+0x25/0x80 [ +0.000002] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ +0.000005] RIP: 0033:0x7f2033593154


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: ice: Add netif_device_attach/detach into PF reset flow Ethtool callbacks can be executed while reset is in progress and try to access deleted resources, e.g. getting coalesce settings can result in a NULL pointer dereference seen below. Reproduction steps: Once the driver is fully initialized, trigger reset: # echo 1 > /sys/class/net/<interface>/device/reset when reset is in progress try to get coalesce settings using ethtool: # ethtool -c <interface> BUG: kernel NULL pointer dereference, address: 0000000000000020 PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 11 PID: 19713 Comm: ethtool Tainted: G S 6.10.0-rc7+ #7 RIP: 0010:ice_get_q_coalesce+0x2e/0xa0 [ice] RSP: 0018:ffffbab1e9bcf6a8 EFLAGS: 00010206 RAX: 000000000000000c RBX: ffff94512305b028 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff9451c3f2e588 RDI: ffff9451c3f2e588 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: ffff9451c3f2e580 R11: 000000000000001f R12: ffff945121fa9000 R13: ffffbab1e9bcf760 R14: 0000000000000013 R15: ffffffff9e65dd40 FS: 00007faee5fbe740(0000) GS:ffff94546fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000020 CR3: 0000000106c2e005 CR4: 00000000001706f0 Call Trace: <TASK> ice_get_coalesce+0x17/0x30 [ice] coalesce_prepare_data+0x61/0x80 ethnl_default_doit+0xde/0x340 genl_family_rcv_msg_doit+0xf2/0x150 genl_rcv_msg+0x1b3/0x2c0 netlink_rcv_skb+0x5b/0x110 genl_rcv+0x28/0x40 netlink_unicast+0x19c/0x290 netlink_sendmsg+0x222/0x490 __sys_sendto+0x1df/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x82/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7faee60d8e27 Calling netif_device_detach() before reset makes the net core not call the driver when ethtool command is issued, the attempt to execute an ethtool command during reset will result in the following message: netlink error: No such device instead of NULL pointer dereference. Once reset is done and ice_rebuild() is executing, the netif_device_attach() is called to allow for ethtool operations to occur again in a safe manner.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Validate function returns [WHAT & HOW] Function return values must be checked before data can be used in subsequent functions. This fixes 4 CHECKED_RETURN issues reported by Coverity.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: udf: Avoid excessive partition lengths Avoid mounting filesystems where the partition would overflow the 32-bits used for block number. Also refuse to mount filesystems where the partition length is so large we cannot safely index bits in a block bitmap.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: powerpc/qspinlock: Fix deadlock in MCS queue If an interrupt occurs in queued_spin_lock_slowpath() after we increment qnodesp->count and before node->lock is initialized, another CPU might see stale lock values in get_tail_qnode(). If the stale lock value happens to match the lock on that CPU, then we write to the "next" pointer of the wrong qnode. This causes a deadlock as the former CPU, once it becomes the head of the MCS queue, will spin indefinitely until it's "next" pointer is set by its successor in the queue. Running stress-ng on a 16 core (16EC/16VP) shared LPAR, results in occasional lockups similar to the following: $ stress-ng --all 128 --vm-bytes 80% --aggressive \ --maximize --oomable --verify --syslog \ --metrics --times --timeout 5m watchdog: CPU 15 Hard LOCKUP ...... NIP [c0000000000b78f4] queued_spin_lock_slowpath+0x1184/0x1490 LR [c000000001037c5c] _raw_spin_lock+0x6c/0x90 Call Trace: 0xc000002cfffa3bf0 (unreliable) _raw_spin_lock+0x6c/0x90 raw_spin_rq_lock_nested.part.135+0x4c/0xd0 sched_ttwu_pending+0x60/0x1f0 __flush_smp_call_function_queue+0x1dc/0x670 smp_ipi_demux_relaxed+0xa4/0x100 xive_muxed_ipi_action+0x20/0x40 __handle_irq_event_percpu+0x80/0x240 handle_irq_event_percpu+0x2c/0x80 handle_percpu_irq+0x84/0xd0 generic_handle_irq+0x54/0x80 __do_irq+0xac/0x210 __do_IRQ+0x74/0xd0 0x0 do_IRQ+0x8c/0x170 hardware_interrupt_common_virt+0x29c/0x2a0 --- interrupt: 500 at queued_spin_lock_slowpath+0x4b8/0x1490 ...... NIP [c0000000000b6c28] queued_spin_lock_slowpath+0x4b8/0x1490 LR [c000000001037c5c] _raw_spin_lock+0x6c/0x90 --- interrupt: 500 0xc0000029c1a41d00 (unreliable) _raw_spin_lock+0x6c/0x90 futex_wake+0x100/0x260 do_futex+0x21c/0x2a0 sys_futex+0x98/0x270 system_call_exception+0x14c/0x2f0 system_call_vectored_common+0x15c/0x2ec The following code flow illustrates how the deadlock occurs. For the sake of brevity, assume that both locks (A and B) are contended and we call the queued_spin_lock_slowpath() function. CPU0 CPU1 ---- ---- spin_lock_irqsave(A) | spin_unlock_irqrestore(A) | spin_lock(B) | | | ▼ | id = qnodesp->count++; | (Note that nodes[0].lock == A) | | | ▼ | Interrupt | (happens before "nodes[0].lock = B") | | | ▼ | spin_lock_irqsave(A) | | | ▼ | id = qnodesp->count++ | nodes[1].lock = A | | | ▼ | Tail of MCS queue | | spin_lock_irqsave(A) ▼ | Head of MCS queue ▼ | CPU0 is previous tail ▼ | Spin indefinitely ▼ (until "nodes[1].next != NULL") prev = get_tail_qnode(A, CPU0) | ▼ prev == &qnodes[CPU0].nodes[0] (as qnodes ---truncated---


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: added NULL check at start of dc_validate_stream [Why] prevent invalid memory access [How] check if dc and stream are NULL


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check debug trap enable before write dbg_ev_file In interrupt context, write dbg_ev_file will be run by work queue. It will cause write dbg_ev_file execution after debug_trap_disable, which will cause NULL pointer access. v2: cancel work "debug_event_workarea" before set dbg_ev_file as NULL.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add array index check for hdcp ddc access [Why] Coverity reports OVERRUN warning. Do not check if array index valid. [How] Check msg_id valid and valid array index.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix the waring dereferencing hive Check the amdgpu_hive_info *hive that maybe is NULL.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix the warning division or modulo by zero Checks the partition mode and returns an error for an invalid mode.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/amdgpu: Check tbo resource pointer Validate tbo resource pointer, skip if NULL


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check BIOS images before it is used BIOS images may fail to load and null checks are added before they are used. This fixes 6 NULL_RETURNS issues reported by Coverity.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/bridge: tc358767: Check if fully initialized before signalling HPD event via IRQ Make sure the connector is fully initialized before signalling any HPD events via drm_kms_helper_hotplug_event(), otherwise this may lead to NULL pointer dereference.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index may exceed array range within fpu_update_bw_bounding_box [Why] Coverity reports OVERRUN warning. soc.num_states could be 40. But array range of bw_params->clk_table.entries is 8. [How] Assert if soc.num_states greater than 8.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Skip inactive planes within ModeSupportAndSystemConfiguration [Why] Coverity reports Memory - illegal accesses. [How] Skip inactive planes.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check link_index before accessing dc->links[] [WHY & HOW] dc->links[] has max size of MAX_LINKS and NULL is return when trying to access with out-of-bound index. This fixes 3 OVERRUN and 1 RESOURCE_LEAK issues reported by Coverity.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check msg_id before processing transcation [WHY & HOW] HDCP_MESSAGE_ID_INVALID (-1) is not a valid msg_id nor is it a valid array index, and it needs checking before used. This fixes 4 OVERRUN issues reported by Coverity.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check num_valid_sets before accessing reader_wm_sets[] [WHY & HOW] num_valid_sets needs to be checked to avoid a negative index when accessing reader_wm_sets[num_valid_sets - 1]. This fixes an OVERRUN issue reported by Coverity.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Stop amdgpu_dm initialize when link nums greater than max_links [Why] Coverity report OVERRUN warning. There are only max_links elements within dc->links. link count could up to AMDGPU_DM_MAX_DISPLAY_INDEX 31. [How] Make sure link count less than max_links.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Stop amdgpu_dm initialize when stream nums greater than 6 [Why] Coverity reports OVERRUN warning. Should abort amdgpu_dm initialize. [How] Return failure to amdgpu_dm_init.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check gpio_id before used as array index [WHY & HOW] GPIO_ID_UNKNOWN (-1) is not a valid value for array index and therefore should be checked in advance. This fixes 5 OVERRUN issues reported by Coverity.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: the warning dereferencing obj for nbio_v7_4 if ras_manager obj null, don't print NBIO err data


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Fix negative array index read Avoid using the negative values for clk_idex as an index into an array pptable->DpmDescriptor. V2: fix clk_index return check (Tim Huang)


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: use IWL_FW_CHECK for link ID check The lookup function iwl_mvm_rcu_fw_link_id_to_link_conf() is normally called with input from the firmware, so it should use IWL_FW_CHECK() instead of WARN_ON().


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: ELF: fix kernel.randomize_va_space double read ELF loader uses "randomize_va_space" twice. It is sysctl and can change at any moment, so 2 loads could see 2 different values in theory with unpredictable consequences. Issue exactly one load for consistent value across one exec.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix firmware crash due to invalid peer nss Currently, if the access point receives an association request containing an Extended HE Capabilities Information Element with an invalid MCS-NSS, it triggers a firmware crash. This issue arises when EHT-PHY capabilities shows support for a bandwidth and MCS-NSS set for that particular bandwidth is filled by zeros and due to this, driver obtains peer_nss as 0 and sending this value to firmware causes crash. Address this issue by implementing a validation step for the peer_nss value before passing it to the firmware. If the value is greater than zero, proceed with forwarding it to the firmware. However, if the value is invalid, reject the association request to prevent potential firmware crashes. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: sched: sch_cake: fix bulk flow accounting logic for host fairness In sch_cake, we keep track of the count of active bulk flows per host, when running in dst/src host fairness mode, which is used as the round-robin weight when iterating through flows. The count of active bulk flows is updated whenever a flow changes state. This has a peculiar interaction with the hash collision handling: when a hash collision occurs (after the set-associative hashing), the state of the hash bucket is simply updated to match the new packet that collided, and if host fairness is enabled, that also means assigning new per-host state to the flow. For this reason, the bulk flow counters of the host(s) assigned to the flow are decremented, before new state is assigned (and the counters, which may not belong to the same host anymore, are incremented again). Back when this code was introduced, the host fairness mode was always enabled, so the decrement was unconditional. When the configuration flags were introduced the *increment* was made conditional, but the *decrement* was not. Which of course can lead to a spurious decrement (and associated wrap-around to U16_MAX). AFAICT, when host fairness is disabled, the decrement and wrap-around happens as soon as a hash collision occurs (which is not that common in itself, due to the set-associative hashing). However, in most cases this is harmless, as the value is only used when host fairness mode is enabled. So in order to trigger an array overflow, sch_cake has to first be configured with host fairness disabled, and while running in this mode, a hash collision has to occur to cause the overflow. Then, the qdisc has to be reconfigured to enable host fairness, which leads to the array out-of-bounds because the wrapped-around value is retained and used as an array index. It seems that syzbot managed to trigger this, which is quite impressive in its own right. This patch fixes the issue by introducing the same conditional check on decrement as is used on increment. The original bug predates the upstreaming of cake, but the commit listed in the Fixes tag touched that code, meaning that this patch won't apply before that.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Acquire kvm->srcu when handling KVM_SET_VCPU_EVENTS Grab kvm->srcu when processing KVM_SET_VCPU_EVENTS, as KVM will forcibly leave nested VMX/SVM if SMM mode is being toggled, and leaving nested VMX reads guest memory. Note, kvm_vcpu_ioctl_x86_set_vcpu_events() can also be called from KVM_RUN via sync_regs(), which already holds SRCU. I.e. trying to precisely use kvm_vcpu_srcu_read_lock() around the problematic SMM code would cause problems. Acquiring SRCU isn't all that expensive, so for simplicity, grab it unconditionally for KVM_SET_VCPU_EVENTS. ============================= WARNING: suspicious RCU usage 6.10.0-rc7-332d2c1d713e-next-vm #552 Not tainted ----------------------------- include/linux/kvm_host.h:1027 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by repro/1071: #0: ffff88811e424430 (&vcpu->mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x7d/0x970 [kvm] stack backtrace: CPU: 15 PID: 1071 Comm: repro Not tainted 6.10.0-rc7-332d2c1d713e-next-vm #552 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dump_stack_lvl+0x7f/0x90 lockdep_rcu_suspicious+0x13f/0x1a0 kvm_vcpu_gfn_to_memslot+0x168/0x190 [kvm] kvm_vcpu_read_guest+0x3e/0x90 [kvm] nested_vmx_load_msr+0x6b/0x1d0 [kvm_intel] load_vmcs12_host_state+0x432/0xb40 [kvm_intel] vmx_leave_nested+0x30/0x40 [kvm_intel] kvm_vcpu_ioctl_x86_set_vcpu_events+0x15d/0x2b0 [kvm] kvm_arch_vcpu_ioctl+0x1107/0x1750 [kvm] ? mark_held_locks+0x49/0x70 ? kvm_vcpu_ioctl+0x7d/0x970 [kvm] ? kvm_vcpu_ioctl+0x497/0x970 [kvm] kvm_vcpu_ioctl+0x497/0x970 [kvm] ? lock_acquire+0xba/0x2d0 ? find_held_lock+0x2b/0x80 ? do_user_addr_fault+0x40c/0x6f0 ? lock_release+0xb7/0x270 __x64_sys_ioctl+0x82/0xb0 do_syscall_64+0x6c/0x170 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7ff11eb1b539 </TASK>


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: net: microchip: vcap: Fix use-after-free error in kunit test This is a clear use-after-free error. We remove it, and rely on checking the return code of vcap_del_rule.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: ethtool: fail closed if we can't get max channel used in indirection tables Commit 0d1b7d6c9274 ("bnxt: fix crashes when reducing ring count with active RSS contexts") proves that allowing indirection table to contain channels with out of bounds IDs may lead to crashes. Currently the max channel check in the core gets skipped if driver can't fetch the indirection table or when we can't allocate memory. Both of those conditions should be extremely rare but if they do happen we should try to be safe and fail the channel change.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix smatch static checker warning adev->gfx.imu.funcs could be NULL


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: usb: gadget: aspeed_udc: validate endpoint index for ast udc We should verify the bound of the array to assure that host may not manipulate the index to point past endpoint array. Found by static analysis.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: btrfs: clean up our handling of refs == 0 in snapshot delete In reada we BUG_ON(refs == 0), which could be unkind since we aren't holding a lock on the extent leaf and thus could get a transient incorrect answer. In walk_down_proc we also BUG_ON(refs == 0), which could happen if we have extent tree corruption. Change that to return -EUCLEAN. In do_walk_down() we catch this case and handle it correctly, however we return -EIO, which -EUCLEAN is a more appropriate error code. Finally in walk_up_proc we have the same BUG_ON(refs == 0), so convert that to proper error handling. Also adjust the error message so we can actually do something with the information.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: btrfs: don't BUG_ON on ENOMEM from btrfs_lookup_extent_info() in walk_down_proc() We handle errors here properly, ENOMEM isn't fatal, return the error.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Handle mailbox timeouts in lpfc_get_sfp_info The MBX_TIMEOUT return code is not handled in lpfc_get_sfp_info and the routine unconditionally frees submitted mailbox commands regardless of return status. The issue is that for MBX_TIMEOUT cases, when firmware returns SFP information at a later time, that same mailbox memory region references previously freed memory in its cmpl routine. Fix by adding checks for the MBX_TIMEOUT return code. During mailbox resource cleanup, check the mbox flag to make sure that the wait did not timeout. If the MBOX_WAKE flag is not set, then do not free the resources because it will be freed when firmware completes the mailbox at a later time in its cmpl routine. Also, increase the timeout from 30 to 60 seconds to accommodate boot scripts requiring longer timeouts.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Remove SCSI host only if added If host tries to remove ufshcd driver from a UFS device it would cause a kernel panic if ufshcd_async_scan fails during ufshcd_probe_hba before adding a SCSI host with scsi_add_host and MCQ is enabled since SCSI host has been defered after MCQ configuration introduced by commit 0cab4023ec7b ("scsi: ufs: core: Defer adding host to SCSI if MCQ is supported"). To guarantee that SCSI host is removed only if it has been added, set the scsi_host_added flag to true after adding a SCSI host and check whether it is set or not before removing it.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: spi: rockchip: Resolve unbalanced runtime PM / system PM handling Commit e882575efc77 ("spi: rockchip: Suspend and resume the bus during NOIRQ_SYSTEM_SLEEP_PM ops") stopped respecting runtime PM status and simply disabled clocks unconditionally when suspending the system. This causes problems when the device is already runtime suspended when we go to sleep -- in which case we double-disable clocks and produce a WARNing. Switch back to pm_runtime_force_{suspend,resume}(), because that still seems like the right thing to do, and the aforementioned commit makes no explanation why it stopped using it. Also, refactor some of the resume() error handling, because it's not actually a good idea to re-disable clocks on failure.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: Limit the period on Haswell Running the ltp test cve-2015-3290 concurrently reports the following warnings. perfevents: irq loop stuck! WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174 intel_pmu_handle_irq+0x285/0x370 Call Trace: <NMI> ? __warn+0xa4/0x220 ? intel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? intel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? intel_pmu_handle_irq+0x285/0x370 ? report_bug+0x3e/0xa0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x18/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? irq_work_claim+0x1e/0x40 ? intel_pmu_handle_irq+0x285/0x370 perf_event_nmi_handler+0x3d/0x60 nmi_handle+0x104/0x330 Thanks to Thomas Gleixner's analysis, the issue is caused by the low initial period (1) of the frequency estimation algorithm, which triggers the defects of the HW, specifically erratum HSW11 and HSW143. (For the details, please refer https://lore.kernel.org/lkml/87plq9l5d2.ffs@tglx/) The HSW11 requires a period larger than 100 for the INST_RETIRED.ALL event, but the initial period in the freq mode is 1. The erratum is the same as the BDM11, which has been supported in the kernel. A minimum period of 128 is enforced as well on HSW. HSW143 is regarding that the fixed counter 1 may overcount 32 with the Hyper-Threading is enabled. However, based on the test, the hardware has more issues than it tells. Besides the fixed counter 1, the message 'interrupt took too long' can be observed on any counter which was armed with a period < 32 and two events expired in the same NMI. A minimum period of 32 is enforced for the rest of the events. The recommended workaround code of the HSW143 is not implemented. Because it only addresses the issue for the fixed counter. It brings extra overhead through extra MSR writing. No related overcounting issue has been reported so far.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: ASoC: meson: axg-card: fix 'use-after-free' Buffer 'card->dai_link' is reallocated in 'meson_card_reallocate_links()', so move 'pad' pointer initialization after this function when memory is already reallocated. Kasan bug report: ================================================================== BUG: KASAN: slab-use-after-free in axg_card_add_link+0x76c/0x9bc Read of size 8 at addr ffff000000e8b260 by task modprobe/356 CPU: 0 PID: 356 Comm: modprobe Tainted: G O 6.9.12-sdkernel #1 Call trace: dump_backtrace+0x94/0xec show_stack+0x18/0x24 dump_stack_lvl+0x78/0x90 print_report+0xfc/0x5c0 kasan_report+0xb8/0xfc __asan_load8+0x9c/0xb8 axg_card_add_link+0x76c/0x9bc [snd_soc_meson_axg_sound_card] meson_card_probe+0x344/0x3b8 [snd_soc_meson_card_utils] platform_probe+0x8c/0xf4 really_probe+0x110/0x39c __driver_probe_device+0xb8/0x18c driver_probe_device+0x108/0x1d8 __driver_attach+0xd0/0x25c bus_for_each_dev+0xe0/0x154 driver_attach+0x34/0x44 bus_add_driver+0x134/0x294 driver_register+0xa8/0x1e8 __platform_driver_register+0x44/0x54 axg_card_pdrv_init+0x20/0x1000 [snd_soc_meson_axg_sound_card] do_one_initcall+0xdc/0x25c do_init_module+0x10c/0x334 load_module+0x24c4/0x26cc init_module_from_file+0xd4/0x128 __arm64_sys_finit_module+0x1f4/0x41c invoke_syscall+0x60/0x188 el0_svc_common.constprop.0+0x78/0x13c do_el0_svc+0x30/0x40 el0_svc+0x38/0x78 el0t_64_sync_handler+0x100/0x12c el0t_64_sync+0x190/0x194


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid race between dcn10_set_drr() and dc_state_destruct() dc_state_destruct() nulls the resource context of the DC state. The pipe context passed to dcn10_set_drr() is a member of this resource context. If dc_state_destruct() is called parallel to the IRQ processing (which calls dcn10_set_drr() at some point), we can end up using already nulled function callback fields of struct stream_resource. The logic in dcn10_set_drr() already tries to avoid this, by checking tg against NULL. But if the nulling happens exactly after the NULL check and before the next access, then we get a race. Avoid this by copying tg first to a local variable, and then use this variable for all the operations. This should work, as long as nobody frees the resource pool where the timing generators live. (cherry picked from commit a3cc326a43bdc48fbdf53443e1027a03e309b643)


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: dma-buf: heaps: Fix off-by-one in CMA heap fault handler Until VM_DONTEXPAND was added in commit 1c1914d6e8c6 ("dma-buf: heaps: Don't track CMA dma-buf pages under RssFile") it was possible to obtain a mapping larger than the buffer size via mremap and bypass the overflow check in dma_buf_mmap_internal. When using such a mapping to attempt to fault past the end of the buffer, the CMA heap fault handler also checks the fault offset against the buffer size, but gets the boundary wrong by 1. Fix the boundary check so that we don't read off the end of the pages array and insert an arbitrary page in the mapping.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: spi: nxp-fspi: fix the KASAN report out-of-bounds bug Change the memcpy length to fix the out-of-bounds issue when writing the data that is not 4 byte aligned to TX FIFO. To reproduce the issue, write 3 bytes data to NOR chip. dd if=3b of=/dev/mtd0 [ 36.926103] ================================================================== [ 36.933409] BUG: KASAN: slab-out-of-bounds in nxp_fspi_exec_op+0x26ec/0x2838 [ 36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455 [ 36.946721] [ 36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070 [ 36.956185] Hardware name: Freescale i.MX8QM MEK (DT) [ 36.961260] Call trace: [ 36.963723] dump_backtrace+0x90/0xe8 [ 36.967414] show_stack+0x18/0x24 [ 36.970749] dump_stack_lvl+0x78/0x90 [ 36.974451] print_report+0x114/0x5cc [ 36.978151] kasan_report+0xa4/0xf0 [ 36.981670] __asan_report_load_n_noabort+0x1c/0x28 [ 36.986587] nxp_fspi_exec_op+0x26ec/0x2838 [ 36.990800] spi_mem_exec_op+0x8ec/0xd30 [ 36.994762] spi_mem_no_dirmap_read+0x190/0x1e0 [ 36.999323] spi_mem_dirmap_write+0x238/0x32c [ 37.003710] spi_nor_write_data+0x220/0x374 [ 37.007932] spi_nor_write+0x110/0x2e8 [ 37.011711] mtd_write_oob_std+0x154/0x1f0 [ 37.015838] mtd_write_oob+0x104/0x1d0 [ 37.019617] mtd_write+0xb8/0x12c [ 37.022953] mtdchar_write+0x224/0x47c [ 37.026732] vfs_write+0x1e4/0x8c8 [ 37.030163] ksys_write+0xec/0x1d0 [ 37.033586] __arm64_sys_write+0x6c/0x9c [ 37.037539] invoke_syscall+0x6c/0x258 [ 37.041327] el0_svc_common.constprop.0+0x160/0x22c [ 37.046244] do_el0_svc+0x44/0x5c [ 37.049589] el0_svc+0x38/0x78 [ 37.052681] el0t_64_sync_handler+0x13c/0x158 [ 37.057077] el0t_64_sync+0x190/0x194 [ 37.060775] [ 37.062274] Allocated by task 455: [ 37.065701] kasan_save_stack+0x2c/0x54 [ 37.069570] kasan_save_track+0x20/0x3c [ 37.073438] kasan_save_alloc_info+0x40/0x54 [ 37.077736] __kasan_kmalloc+0xa0/0xb8 [ 37.081515] __kmalloc_noprof+0x158/0x2f8 [ 37.085563] mtd_kmalloc_up_to+0x120/0x154 [ 37.089690] mtdchar_write+0x130/0x47c [ 37.093469] vfs_write+0x1e4/0x8c8 [ 37.096901] ksys_write+0xec/0x1d0 [ 37.100332] __arm64_sys_write+0x6c/0x9c [ 37.104287] invoke_syscall+0x6c/0x258 [ 37.108064] el0_svc_common.constprop.0+0x160/0x22c [ 37.112972] do_el0_svc+0x44/0x5c [ 37.116319] el0_svc+0x38/0x78 [ 37.119401] el0t_64_sync_handler+0x13c/0x158 [ 37.123788] el0t_64_sync+0x190/0x194 [ 37.127474] [ 37.128977] The buggy address belongs to the object at ffff00081037c2a0 [ 37.128977] which belongs to the cache kmalloc-8 of size 8 [ 37.141177] The buggy address is located 0 bytes inside of [ 37.141177] allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3) [ 37.153465] [ 37.154971] The buggy address belongs to the physical page: [ 37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c [ 37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff) [ 37.175149] page_type: 0xfdffffff(slab) [ 37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000 [ 37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000 [ 37.194553] page dumped because: kasan: bad access detected [ 37.200144] [ 37.201647] Memory state around the buggy address: [ 37.206460] ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc [ 37.213701] ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc [ 37.220946] >ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc [ 37.228186] ^ [ 37.232473] ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 37.239718] ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 37.246962] ============================================================== ---truncated---


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: net: dpaa: Pad packets to ETH_ZLEN When sending packets under 60 bytes, up to three bytes of the buffer following the data may be leaked. Avoid this by extending all packets to ETH_ZLEN, ensuring nothing is leaked in the padding. This bug can be reproduced by running $ ping -s 11 destination


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_socket: fix sk refcount leaks We must put 'sk' reference before returning.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix bridge mode operations when there are no VFs Currently, trying to set the bridge mode attribute when numvfs=0 leads to a crash: bridge link set dev eth2 hwmode vepa [ 168.967392] BUG: kernel NULL pointer dereference, address: 0000000000000030 [...] [ 168.969989] RIP: 0010:mlx5_add_flow_rules+0x1f/0x300 [mlx5_core] [...] [ 168.976037] Call Trace: [ 168.976188] <TASK> [ 168.978620] _mlx5_eswitch_set_vepa_locked+0x113/0x230 [mlx5_core] [ 168.979074] mlx5_eswitch_set_vepa+0x7f/0xa0 [mlx5_core] [ 168.979471] rtnl_bridge_setlink+0xe9/0x1f0 [ 168.979714] rtnetlink_rcv_msg+0x159/0x400 [ 168.980451] netlink_rcv_skb+0x54/0x100 [ 168.980675] netlink_unicast+0x241/0x360 [ 168.980918] netlink_sendmsg+0x1f6/0x430 [ 168.981162] ____sys_sendmsg+0x3bb/0x3f0 [ 168.982155] ___sys_sendmsg+0x88/0xd0 [ 168.985036] __sys_sendmsg+0x59/0xa0 [ 168.985477] do_syscall_64+0x79/0x150 [ 168.987273] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 168.987773] RIP: 0033:0x7f8f7950f917 (esw->fdb_table.legacy.vepa_fdb is null) The bridge mode is only relevant when there are multiple functions per port. Therefore, prevent setting and getting this setting when there are no VFs. Note that after this change, there are no settings to change on the PF interface using `bridge link` when there are no VFs, so the interface no longer appears in the `bridge link` output.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: platform/x86: panasonic-laptop: Fix SINF array out of bounds accesses The panasonic laptop code in various places uses the SINF array with index values of 0 - SINF_CUR_BRIGHT(0x0d) without checking that the SINF array is big enough. Not all panasonic laptops have this many SINF array entries, for example the Toughbook CF-18 model only has 10 SINF array entries. So it only supports the AC+DC brightness entries and mute. Check that the SINF array has a minimum size which covers all AC+DC brightness entries and refuse to load if the SINF array is smaller. For higher SINF indexes hide the sysfs attributes when the SINF array does not contain an entry for that attribute, avoiding show()/store() accessing the array out of bounds and add bounds checking to the probe() and resume() code accessing these.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: fix NULL pointer access in mt7921_ipv6_addr_change When disabling wifi mt7921_ipv6_addr_change() is called as a notifier. At this point mvif->phy is already NULL so we cannot use it here.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: usbnet: ipheth: do not stop RX on failing RX callback RX callbacks can fail for multiple reasons: * Payload too short * Payload formatted incorrecly (e.g. bad NCM framing) * Lack of memory None of these should cause the driver to seize up. Make such failures non-critical and continue processing further incoming URBs.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: x86/hyperv: fix kexec crash due to VP assist page corruption commit 9636be85cc5b ("x86/hyperv: Fix hyperv_pcpu_input_arg handling when CPUs go online/offline") introduces a new cpuhp state for hyperv initialization. cpuhp_setup_state() returns the state number if state is CPUHP_AP_ONLINE_DYN or CPUHP_BP_PREPARE_DYN and 0 for all other states. For the hyperv case, since a new cpuhp state was introduced it would return 0. However, in hv_machine_shutdown(), the cpuhp_remove_state() call is conditioned upon "hyperv_init_cpuhp > 0". This will never be true and so hv_cpu_die() won't be called on all CPUs. This means the VP assist page won't be reset. When the kexec kernel tries to setup the VP assist page again, the hypervisor corrupts the memory region of the old VP assist page causing a panic in case the kexec kernel is using that memory elsewhere. This was originally fixed in commit dfe94d4086e4 ("x86/hyperv: Fix kexec panic/hang issues"). Get rid of hyperv_init_cpuhp entirely since we are no longer using a dynamic cpuhp state and use CPUHP_AP_HYPERV_ONLINE directly with cpuhp_remove_state().


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Disable DMCUB timeout for DCN35 [Why] DMCUB can intermittently take longer than expected to process commands. Old ASIC policy was to continue while logging a diagnostic error - which works fine for ASIC without IPS, but with IPS this could lead to a race condition where we attempt to access DCN state while it's inaccessible, leading to a system hang when the NIU port is not disabled or register accesses that timeout and the display configuration in an undefined state. [How] We need to investigate why these accesses take longer than expected, but for now we should disable the timeout on DCN35 to avoid this race condition. Since the waits happen only at lower interrupt levels the risk of taking too long at higher IRQ and causing a system watchdog timeout are minimal.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Correct the defined value for AMDGPU_DMUB_NOTIFICATION_MAX [Why & How] It actually exposes '6' types in enum dmub_notification_type. Not 5. Using smaller number to create array dmub_callback & dmub_thread_offload has potential to access item out of array bound. Fix it.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: crypto: stm32/cryp - call finalize with bh disabled The finalize operation in interrupt mode produce a produces a spinlock recursion warning. The reason is the fact that BH must be disabled during this process.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: fsnotify: clear PARENT_WATCHED flags lazily In some setups directories can have many (usually negative) dentries. Hence __fsnotify_update_child_dentry_flags() function can take a significant amount of time. Since the bulk of this function happens under inode->i_lock this causes a significant contention on the lock when we remove the watch from the directory as the __fsnotify_update_child_dentry_flags() call from fsnotify_recalc_mask() races with __fsnotify_update_child_dentry_flags() calls from __fsnotify_parent() happening on children. This can lead upto softlockup reports reported by users. Fix the problem by calling fsnotify_update_children_dentry_flags() to set PARENT_WATCHED flags only when parent starts watching children. When parent stops watching children, clear false positive PARENT_WATCHED flags lazily in __fsnotify_parent() for each accessed child.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid overflow from uint32_t to uint8_t [WHAT & HOW] dmub_rb_cmd's ramping_boundary has size of uint8_t and it is assigned 0xFFFF. Fix it by changing it to uint8_t with value of 0xFF. This fixes 2 INTEGER_OVERFLOW issues reported by Coverity.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Remove register from DCN35 DMCUB diagnostic collection [Why] These registers should not be read from driver and triggering the security violation when DMCUB work times out and diagnostics are collected blocks Z8 entry. [How] Remove the register read from DCN35.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: staging: iio: frequency: ad9834: Validate frequency parameter value In ad9834_write_frequency() clk_get_rate() can return 0. In such case ad9834_calc_freqreg() call will lead to division by zero. Checking 'if (fout > (clk_freq / 2))' doesn't protect in case of 'fout' is 0. ad9834_write_frequency() is called from ad9834_write(), where fout is taken from text buffer, which can contain any value. Modify parameters checking. Found by Linux Verification Center (linuxtesting.org) with SVACE.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: spi: hisi-kunpeng: Add verification for the max_frequency provided by the firmware If the value of max_speed_hz is 0, it may cause a division by zero error in hisi_calc_effective_speed(). The value of max_speed_hz is provided by firmware. Firmware is generally considered as a trusted domain. However, as division by zero errors can cause system failure, for defense measure, the value of max_speed is validated here. So 0 is regarded as invalid and an error code is returned.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: i3c: mipi-i3c-hci: Error out instead on BUG_ON() in IBI DMA setup Definitely condition dma_get_cache_alignment * defined value > 256 during driver initialization is not reason to BUG_ON(). Turn that to graceful error out with -EINVAL.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: PCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0) Errata #i2037 in AM65x/DRA80xM Processors Silicon Revision 1.0 (SPRZ452D_July 2018_Revised December 2019 [1]) mentions when an inbound PCIe TLP spans more than two internal AXI 128-byte bursts, the bus may corrupt the packet payload and the corrupt data may cause associated applications or the processor to hang. The workaround for Errata #i2037 is to limit the maximum read request size and maximum payload size to 128 bytes. Add workaround for Errata #i2037 here. The errata and workaround is applicable only to AM65x SR 1.0 and later versions of the silicon will have this fixed. [1] -> https://www.ti.com/lit/er/sprz452i/sprz452i.pdf


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: lib/generic-radix-tree.c: Fix rare race in __genradix_ptr_alloc() If we need to increase the tree depth, allocate a new node, and then race with another thread that increased the tree depth before us, we'll still have a preallocated node that might be used later. If we then use that node for a new non-root node, it'll still have a pointer to the old root instead of being zeroed - fix this by zeroing it in the cmpxchg failure path.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix state management in error path of log writing function After commit a694291a6211 ("nilfs2: separate wait function from nilfs_segctor_write") was applied, the log writing function nilfs_segctor_do_construct() was able to issue I/O requests continuously even if user data blocks were split into multiple logs across segments, but two potential flaws were introduced in its error handling. First, if nilfs_segctor_begin_construction() fails while creating the second or subsequent logs, the log writing function returns without calling nilfs_segctor_abort_construction(), so the writeback flag set on pages/folios will remain uncleared. This causes page cache operations to hang waiting for the writeback flag. For example, truncate_inode_pages_final(), which is called via nilfs_evict_inode() when an inode is evicted from memory, will hang. Second, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared. As a result, if the next log write involves checkpoint creation, that's fine, but if a partial log write is performed that does not, inodes with NILFS_I_COLLECTED set are erroneously removed from the "sc_dirty_files" list, and their data and b-tree blocks may not be written to the device, corrupting the block mapping. Fix these issues by uniformly calling nilfs_segctor_abort_construction() on failure of each step in the loop in nilfs_segctor_do_construct(), having it clean up logs and segment usages according to progress, and correcting the conditions for calling nilfs_redirty_inodes() to ensure that the NILFS_I_COLLECTED flag is cleared.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: ocfs2: add bounds checking to ocfs2_xattr_find_entry() Add a paranoia check to make sure it doesn't stray beyond valid memory region containing ocfs2 xattr entries when scanning for a match. It will prevent out-of-bound access in case of crafted images.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: USB: usbtmc: prevent kernel-usb-infoleak The syzbot reported a kernel-usb-infoleak in usbtmc_write, we need to clear the structure before filling fields.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't wait for tx queues if firmware is dead There is a WARNING in iwl_trans_wait_tx_queues_empty() (that was recently converted from just a message), that can be hit if we wait for TX queues to become empty after firmware died. Clearly, we can't expect anything from the firmware after it's declared dead. Don't call iwl_trans_wait_tx_queues_empty() in this case. While it could be a good idea to stop the flow earlier, the flush functions do some maintenance work that is not related to the firmware, so keep that part of the code running even when the firmware is not running. [edit commit message]


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: pause TCM when the firmware is stopped Not doing so will make us send a host command to the transport while the firmware is not alive, which will trigger a WARNING. bad state = 0 WARNING: CPU: 2 PID: 17434 at drivers/net/wireless/intel/iwlwifi/iwl-trans.c:115 iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi] RIP: 0010:iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi] Call Trace: <TASK> iwl_mvm_send_cmd+0x40/0xc0 [iwlmvm] iwl_mvm_config_scan+0x198/0x260 [iwlmvm] iwl_mvm_recalc_tcm+0x730/0x11d0 [iwlmvm] iwl_mvm_tcm_work+0x1d/0x30 [iwlmvm] process_one_work+0x29e/0x640 worker_thread+0x2df/0x690 ? rescuer_thread+0x540/0x540 kthread+0x192/0x1e0 ? set_kthread_struct+0x90/0x90 ret_from_fork+0x22/0x30


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: mm: avoid leaving partial pfn mappings around in error case As Jann points out, PFN mappings are special, because unlike normal memory mappings, there is no lifetime information associated with the mapping - it is just a raw mapping of PFNs with no reference counting of a 'struct page'. That's all very much intentional, but it does mean that it's easy to mess up the cleanup in case of errors. Yes, a failed mmap() will always eventually clean up any partial mappings, but without any explicit lifetime in the page table mapping itself, it's very easy to do the error handling in the wrong order. In particular, it's easy to mistakenly free the physical backing store before the page tables are actually cleaned up and (temporarily) have stale dangling PTE entries. To make this situation less error-prone, just make sure that any partial pfn mapping is torn down early, before any other error handling.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free in bpf_uprobe_multi_link_attach() If bpf_link_prime() fails, bpf_uprobe_multi_link_attach() goes to the error_free label and frees the array of bpf_uprobe's without calling bpf_uprobe_unregister(). This leaks bpf_uprobe->uprobe and worse, this frees bpf_uprobe->consumer without removing it from the uprobe->consumers list.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix NULL pointer dereference in mt7996_mcu_sta_bfer_he Fix the NULL pointer dereference in mt7996_mcu_sta_bfer_he routine adding an sta interface to the mt7996 driver. Found by code review.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: scsi: sd: Fix off-by-one error in sd_read_block_characteristics() Ff the device returns page 0xb1 with length 8 (happens with qemu v2.x, for example), sd_read_block_characteristics() may attempt an out-of-bounds memory access when accessing the zoned field at offset 8.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: tcp: check skb is non-NULL in tcp_rto_delta_us() We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases: Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even ---truncated---


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th->res1) Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put() BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit include/linux/netdevice.h:3105 [inline] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [inline] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [inline] __se_sys_connect net/socket.c:2085 [inline] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was stored to memory at: nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core ---truncated---


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate() The psc->div[] array has psc->num_div elements. These values come from when we call clk_hw_register_div(). It's adc_divisors and ARRAY_SIZE(adc_divisors)) and so on. So this condition needs to be >= instead of > to prevent an out of bounds read.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: Fix invalid mr resource destroy Certain error paths from mlx5_vdpa_dev_add() can end up releasing mr resources which never got initialized in the first place. This patch adds the missing check in mlx5_vdpa_destroy_mr_resources() to block releasing non-initialized mr resources. Reference trace: mlx5_core 0000:08:00.2: mlx5_vdpa_dev_add:3274:(pid 2700) warning: No mac address provisioned? BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 140216067 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 8 PID: 2700 Comm: vdpa Kdump: loaded Not tainted 5.14.0-496.el9.x86_64 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb] Code: [...] RSP: 0018:ff1c823ac23077f0 EFLAGS: 00010246 RAX: ffffffffc1a21a60 RBX: ffffffff899567a0 RCX: 0000000000000000 RDX: ffffffffffffffff RSI: 0000000000000000 RDI: 0000000000000000 RBP: ff1bda1f7c21e800 R08: 0000000000000000 R09: ff1c823ac2307670 R10: ff1c823ac2307668 R11: ffffffff8a9e7b68 R12: 0000000000000000 R13: 0000000000000000 R14: ff1bda1f43e341a0 R15: 00000000ffffffea FS: 00007f56eba7c740(0000) GS:ff1bda269f800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000104d90001 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa] ? __die_body.cold+0x8/0xd ? page_fault_oops+0x134/0x170 ? __irq_work_queue_local+0x2b/0xc0 ? irq_work_queue+0x2c/0x50 ? exc_page_fault+0x62/0x150 ? asm_exc_page_fault+0x22/0x30 ? __pfx_mlx5_vdpa_free+0x10/0x10 [mlx5_vdpa] ? vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb] mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa] vdpa_release_dev+0x1e/0x50 [vdpa] device_release+0x31/0x90 kobject_cleanup+0x37/0x130 mlx5_vdpa_dev_add+0x2d2/0x7a0 [mlx5_vdpa] vdpa_nl_cmd_dev_add_set_doit+0x277/0x4c0 [vdpa] genl_family_rcv_msg_doit+0xd9/0x130 genl_family_rcv_msg+0x14d/0x220 ? __pfx_vdpa_nl_cmd_dev_add_set_doit+0x10/0x10 [vdpa] ? _copy_to_user+0x1a/0x30 ? move_addr_to_user+0x4b/0xe0 genl_rcv_msg+0x47/0xa0 ? __import_iovec+0x46/0x150 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x245/0x370 netlink_sendmsg+0x206/0x440 __sys_sendto+0x1dc/0x1f0 ? do_read_fault+0x10c/0x1d0 ? do_pte_missing+0x10d/0x190 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x5c/0xf0 ? __count_memcg_events+0x4f/0xb0 ? mm_account_fault+0x6c/0x100 ? handle_mm_fault+0x116/0x270 ? do_user_addr_fault+0x1d6/0x6a0 ? do_syscall_64+0x6b/0xf0 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 entry_SYSCALL_64_after_hwframe+0x78/0x80


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: driver core: Fix a potential null-ptr-deref in module_add_driver() Inject fault while probing of-fpga-region, if kasprintf() fails in module_add_driver(), the second sysfs_remove_link() in exit path will cause null-ptr-deref as below because kernfs_name_hash() will call strlen() with NULL driver_name. Fix it by releasing resources based on the exit path sequence. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [dfffffc000000000] address between user and kernel address ranges Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: of_fpga_region(+) fpga_region fpga_bridge cfg80211 rfkill 8021q garp mrp stp llc ipv6 [last unloaded: of_fpga_region] CPU: 2 UID: 0 PID: 2036 Comm: modprobe Not tainted 6.11.0-rc2-g6a0e38264012 #295 Hardware name: linux,dummy-virt (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : strlen+0x24/0xb0 lr : kernfs_name_hash+0x1c/0xc4 sp : ffffffc081f97380 x29: ffffffc081f97380 x28: ffffffc081f97b90 x27: ffffff80c821c2a0 x26: ffffffedac0be418 x25: 0000000000000000 x24: ffffff80c09d2000 x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000 x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000001840 x17: 0000000000000000 x16: 0000000000000000 x15: 1ffffff8103f2e42 x14: 00000000f1f1f1f1 x13: 0000000000000004 x12: ffffffb01812d61d x11: 1ffffff01812d61c x10: ffffffb01812d61c x9 : dfffffc000000000 x8 : 0000004fe7ed29e4 x7 : ffffff80c096b0e7 x6 : 0000000000000001 x5 : ffffff80c096b0e0 x4 : 1ffffffdb990efa2 x3 : 0000000000000000 x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000000 Call trace: strlen+0x24/0xb0 kernfs_name_hash+0x1c/0xc4 kernfs_find_ns+0x118/0x2e8 kernfs_remove_by_name_ns+0x80/0x100 sysfs_remove_link+0x74/0xa8 module_add_driver+0x278/0x394 bus_add_driver+0x1f0/0x43c driver_register+0xf4/0x3c0 __platform_driver_register+0x60/0x88 of_fpga_region_init+0x20/0x1000 [of_fpga_region] do_one_initcall+0x110/0x788 do_init_module+0x1dc/0x5c8 load_module+0x3c38/0x4cac init_module_from_file+0xd4/0x128 idempotent_init_module+0x2cc/0x528 __arm64_sys_finit_module+0xac/0x100 invoke_syscall+0x6c/0x258 el0_svc_common.constprop.0+0x160/0x22c do_el0_svc+0x44/0x5c el0_svc+0x48/0xb8 el0t_64_sync_handler+0x13c/0x158 el0t_64_sync+0x190/0x194 Code: f2fbffe1 a90157f4 12000802 aa0003f5 (38e16861) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: nfsd: return -EINVAL when namelen is 0 When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered. [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205] dump_stack+0x9a/0xd0 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] __kasan_report.cold+0x34/0x84 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] kasan_report+0x3a/0x50 [ T1205] nfs4_client_to_reclaim+0xe9/0x260 [ T1205] ? nfsd4_release_lockowner+0x410/0x410 [ T1205] cld_pipe_downcall+0x5ca/0x760 [ T1205] ? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205] ? down_write_killable_nested+0x170/0x170 [ T1205] ? avc_policy_seqno+0x28/0x40 [ T1205] ? selinux_file_permission+0x1b4/0x1e0 [ T1205] rpc_pipe_write+0x84/0xb0 [ T1205] vfs_write+0x143/0x520 [ T1205] ksys_write+0xc9/0x170 [ T1205] ? __ia32_sys_read+0x50/0x50 [ T1205] ? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205] ? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205] do_syscall_64+0x33/0x40 [ T1205] entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ================================================================== Fix it by checking namelen.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: IB/core: Fix ib_cache_setup_one error flow cleanup When ib_cache_update return an error, we exit ib_cache_setup_one instantly with no proper cleanup, even though before this we had already successfully done gid_table_setup_one, that results in the kernel WARN below. Do proper cleanup using gid_table_cleanup_one before returning the err in order to fix the issue. WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0 Modules linked in: CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:gid_table_release_one+0x181/0x1a0 Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff <0f> 0b 4c 8b 75 30 e9 54 ff ff ff 48 8 3 c4 10 5b 5d 41 5c 41 5d 41 RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527 RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001 RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631 R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001 R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001 FS: 00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? show_regs+0x94/0xa0 ? __warn+0x9e/0x1c0 ? gid_table_release_one+0x181/0x1a0 ? report_bug+0x1f9/0x340 ? gid_table_release_one+0x181/0x1a0 ? handle_bug+0xa2/0x110 ? exc_invalid_op+0x31/0xa0 ? asm_exc_invalid_op+0x16/0x20 ? __warn_printk+0xc7/0x180 ? __warn_printk+0xd4/0x180 ? gid_table_release_one+0x181/0x1a0 ib_device_release+0x71/0xe0 ? __pfx_ib_device_release+0x10/0x10 device_release+0x44/0xd0 kobject_put+0x135/0x3d0 put_device+0x20/0x30 rxe_net_add+0x7d/0xa0 rxe_newlink+0xd7/0x190 nldev_newlink+0x1b0/0x2a0 ? __pfx_nldev_newlink+0x10/0x10 rdma_nl_rcv_msg+0x1ad/0x2e0 rdma_nl_rcv_skb.constprop.0+0x176/0x210 netlink_unicast+0x2de/0x400 netlink_sendmsg+0x306/0x660 __sock_sendmsg+0x110/0x120 ____sys_sendmsg+0x30e/0x390 ___sys_sendmsg+0x9b/0xf0 ? kstrtouint+0x6e/0xa0 ? kstrtouint_from_user+0x7c/0xb0 ? get_pid_task+0xb0/0xd0 ? proc_fail_nth_write+0x5b/0x140 ? __fget_light+0x9a/0x200 ? preempt_count_add+0x47/0xa0 __sys_sendmsg+0x61/0xd0 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds In the function init_conns(), after the create_con() and create_cm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to clt_path->s.con_num. This commits resets the cid to clt_path->s.con_num - 1, to stay in bounds in the cleanup loop later.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency In the commit aee2424246f9 ("RDMA/iwcm: Fix a use-after-free related to destroying CM IDs"), the function flush_workqueue is invoked to flush the work queue iwcm_wq. But at that time, the work queue iwcm_wq was created via the function alloc_ordered_workqueue without the flag WQ_MEM_RECLAIM. Because the current process is trying to flush the whole iwcm_wq, if iwcm_wq doesn't have the flag WQ_MEM_RECLAIM, verify that the current process is not reclaiming memory or running on a workqueue which doesn't have the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee leading to a deadlock. The call trace is as below: [ 125.350876][ T1430] Call Trace: [ 125.356281][ T1430] <TASK> [ 125.361285][ T1430] ? __warn (kernel/panic.c:693) [ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239) [ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621) [ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970) [ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151) [ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm [ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910) [ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161) [ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm [ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma [ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma [ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231) [ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393) [ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339) [ 125.531837][ T1430] kthread (kernel/kthread.c:389) [ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147) [ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257) [ 125.566487][ T1430] </TASK> [ 125.566488][ T1430] ---[ end trace 0000000000000000 ]---


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error Ensure index in rtl2830_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue. [hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg]


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential null-ptr-deref in nilfs_btree_insert() Patch series "nilfs2: fix potential issues with empty b-tree nodes". This series addresses three potential issues with empty b-tree nodes that can occur with corrupted filesystem images, including one recently discovered by syzbot. This patch (of 3): If a b-tree is broken on the device, and the b-tree height is greater than 2 (the level of the root node is greater than 1) even if the number of child nodes of the b-tree root is 0, a NULL pointer dereference occurs in nilfs_btree_prepare_insert(), which is called from nilfs_btree_insert(). This is because, when the number of child nodes of the b-tree root is 0, nilfs_btree_do_lookup() does not set the block buffer head in any of path[x].bp_bh, leaving it as the initial value of NULL, but if the level of the b-tree root node is greater than 1, nilfs_btree_get_nonroot_node(), which accesses the buffer memory of path[x].bp_bh, is called. Fix this issue by adding a check to nilfs_btree_root_broken(), which performs sanity checks when reading the root node from the device, to detect this inconsistency. Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause early on.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: bpf: Fail verification for sign-extension of packet data/data_end/data_meta syzbot reported a kernel crash due to commit 1f1e864b6555 ("bpf: Handle sign-extenstin ctx member accesses"). The reason is due to sign-extension of 32-bit load for packet data/data_end/data_meta uapi field. The original code looks like: r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ r3 = *(u32 *)(r1 + 80) /* load __sk_buff->data_end */ r0 = r2 r0 += 8 if r3 > r0 goto +1 ... Note that __sk_buff->data load has 32-bit sign extension. After verification and convert_ctx_accesses(), the final asm code looks like: r2 = *(u64 *)(r1 +208) r2 = (s32)r2 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 ... Note that 'r2 = (s32)r2' may make the kernel __sk_buff->data address invalid which may cause runtime failure. Currently, in C code, typically we have void *data = (void *)(long)skb->data; void *data_end = (void *)(long)skb->data_end; ... and it will generate r2 = *(u64 *)(r1 +208) r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 If we allow sign-extension, void *data = (void *)(long)(int)skb->data; void *data_end = (void *)(long)skb->data_end; ... the generated code looks like r2 = *(u64 *)(r1 +208) r2 <<= 32 r2 s>>= 32 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 and this will cause verification failure since "r2 <<= 32" is not allowed as "r2" is a packet pointer. To fix this issue for case r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ this patch added additional checking in is_valid_access() callback function for packet data/data_end/data_meta access. If those accesses are with sign-extenstion, the verification will fail. [1] https://lore.kernel.org/bpf/000000000000c90eee061d236d37@google.com/


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check link_res->hpo_dp_link_enc before using it [WHAT & HOW] Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res without initializing hpo_dp_link_enc and it is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: block: fix potential invalid pointer dereference in blk_add_partition The blk_add_partition() function initially used a single if-condition (IS_ERR(part)) to check for errors when adding a partition. This was modified to handle the specific case of -ENXIO separately, allowing the function to proceed without logging the error in this case. However, this change unintentionally left a path where md_autodetect_dev() could be called without confirming that part is a valid pointer. This commit separates the error handling logic by splitting the initial if-condition, improving code readability and handling specific error scenarios explicitly. The function now distinguishes the general error case from -ENXIO without altering the existing behavior of md_autodetect_dev() calls.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix possible UAF for bfqq->bic with merge chain 1) initial state, three tasks: Process 1 Process 2 Process 3 (BIC1) (BIC2) (BIC3) | Λ | Λ | Λ | | | | | | V | V | V | bfqq1 bfqq2 bfqq3 process ref: 1 1 1 2) bfqq1 merged to bfqq2: Process 1 Process 2 Process 3 (BIC1) (BIC2) (BIC3) | | | Λ \--------------\| | | V V | bfqq1--------->bfqq2 bfqq3 process ref: 0 2 1 3) bfqq2 merged to bfqq3: Process 1 Process 2 Process 3 (BIC1) (BIC2) (BIC3) here -> Λ | | \--------------\ \-------------\| V V bfqq1--------->bfqq2---------->bfqq3 process ref: 0 1 3 In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then get bfqq3 through merge chain, and finially handle IO by bfqq3. Howerver, current code will think bfqq2 is owned by BIC1, like initial state, and set bfqq2->bic to BIC1. bfq_insert_request -> by Process 1 bfqq = bfq_init_rq(rq) bfqq = bfq_get_bfqq_handle_split bfqq = bic_to_bfqq -> get bfqq2 from BIC1 bfqq->ref++ rq->elv.priv[0] = bic rq->elv.priv[1] = bfqq if (bfqq_process_refs(bfqq) == 1) bfqq->bic = bic -> record BIC1 to bfqq2 __bfq_insert_request new_bfqq = bfq_setup_cooperator -> get bfqq3 from bfqq2->new_bfqq bfqq_request_freed(bfqq) new_bfqq->ref++ rq->elv.priv[1] = new_bfqq -> handle IO by bfqq3 Fix the problem by checking bfqq is from merge chain fist. And this might fix a following problem reported by our syzkaller(unreproducible): ================================================================== BUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] BUG: KASAN: slab-use-after-free in bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] BUG: KASAN: slab-use-after-free in bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595 CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G L 6.6.0-07439-gba2303cacfda #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blk_mq_requeue_work Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0x10d/0x610 mm/kasan/report.c:475 kasan_report+0x8e/0xc0 mm/kasan/report.c:588 bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 bfq_get_bfqq_handle_split+0x169/0x5d0 block/bfq-iosched.c:6757 bfq_init_rq block/bfq-iosched.c:6876 [inline] bfq_insert_request block/bfq-iosched.c:6254 [inline] bfq_insert_requests+0x1112/0x5cf0 block/bfq-iosched.c:6304 blk_mq_insert_request+0x290/0x8d0 block/blk-mq.c:2593 blk_mq_requeue_work+0x6bc/0xa70 block/blk-mq.c:1502 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700 worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781 kthread+0x33c/0x440 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305 </TASK> Allocated by task 20776: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:188 [inline] slab_post_alloc_hook mm/slab.h:763 [inline] slab_alloc_node mm/slub.c:3458 [inline] kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503 ioc_create_icq block/blk-ioc.c:370 [inline] ---truncated---


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev() Blamed commit accidentally removed a check for rt->rt6i_idev being NULL, as spotted by syzbot: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c R10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18 R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930 FS: 0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856 addrconf_notify+0x3cb/0x1020 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 call_netdevice_notifiers_extack net/core/dev.c:2032 [inline] call_netdevice_notifiers net/core/dev.c:2046 [inline] unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352 unregister_netdevice_many net/core/dev.c:11414 [inline] unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289 unregister_netdevice include/linux/netdevice.h:3129 [inline] __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685 tun_detach drivers/net/tun.c:701 [inline] tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f1acc77def9 Code: Unable to access opcode bytes at 0x7f1acc77decf. RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043 RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 R ---truncated---


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: can: bcm: Clear bo->bcm_proc_read after remove_proc_entry(). syzbot reported a warning in bcm_release(). [0] The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered. However, if the socket is just close()d without the 2nd connect(), the remaining bo->bcm_proc_read triggers unnecessary remove_proc_entry() in bcm_release(). Let's clear bo->bcm_proc_read after remove_proc_entry() in bcm_notify(). [0] name '4986' WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 <0f> 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> bcm_release+0x250/0x880 net/can/bcm.c:1578 __sock_release net/socket.c:659 [inline] sock_close+0xbc/0x240 net/socket.c:1421 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160 </TASK>


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: sock_map: Add a cond_resched() in sock_hash_free() Several syzbot soft lockup reports all have in common sock_hash_free() If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: fix potential RCU dereference issue in wilc_parse_join_bss_param In the `wilc_parse_join_bss_param` function, the TSF field of the `ies` structure is accessed after the RCU read-side critical section is unlocked. According to RCU usage rules, this is illegal. Reusing this pointer can lead to unpredictable behavior, including accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the TSF value is now stored in a local variable `ies_tsf` before the RCU lock is released. The `param->tsf_lo` field is then assigned using this local variable, ensuring that the TSF value is safely accessed.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop() Since '__dev_queue_xmit()' should be called with interrupts enabled, the following backtrace: ieee80211_do_stop() ... spin_lock_irqsave(&local->queue_stop_reason_lock, flags) ... ieee80211_free_txskb() ieee80211_report_used_skb() ieee80211_report_ack_skb() cfg80211_mgmt_tx_status_ext() nl80211_frame_tx_status() genlmsg_multicast_netns() genlmsg_multicast_netns_filtered() nlmsg_multicast_filtered() netlink_broadcast_filtered() do_one_broadcast() netlink_broadcast_deliver() __netlink_sendskb() netlink_deliver_tap() __netlink_deliver_tap_skb() dev_queue_xmit() __dev_queue_xmit() ; with IRQS disabled ... spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags) issues the warning (as reported by syzbot reproducer): WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120 Fix this by implementing a two-phase skb reclamation in 'ieee80211_do_stop()', where actual work is performed outside of a section with interrupts disabled.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: use hweight16 to get correct tx antenna The chainmask is u16 so using hweight8 cannot get correct tx_ant. Without this patch, the tx_ant of band 2 would be -1 and lead to the following issue: BUG: KASAN: stack-out-of-bounds in mt7996_mcu_add_sta+0x12e0/0x16e0 [mt7996e]


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix oops on non-dbdc mt7986 mt7915_band_config() sets band_idx = 1 on the main phy for mt7986 with MT7975_ONE_ADIE or MT7976_ONE_ADIE. Commit 0335c034e726 ("wifi: mt76: fix race condition related to checking tx queue fill status") introduced a dereference of the phys array indirectly indexed by band_idx via wcid->phy_idx in mt76_wcid_cleanup(). This caused the following Oops on affected mt7986 devices: Unable to handle kernel read from unreadable memory at virtual address 0000000000000024 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005 CM = 0, WnR = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=0000000042545000 [0000000000000024] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 Internal error: Oops: 0000000096000005 [#1] SMP Modules linked in: ... mt7915e mt76_connac_lib mt76 mac80211 cfg80211 ... CPU: 2 PID: 1631 Comm: hostapd Not tainted 5.15.150 #0 Hardware name: ZyXEL EX5700 (Telenor) (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mt76_wcid_cleanup+0x84/0x22c [mt76] lr : mt76_wcid_cleanup+0x64/0x22c [mt76] sp : ffffffc00a803700 x29: ffffffc00a803700 x28: ffffff80008f7300 x27: ffffff80003f3c00 x26: ffffff80000a7880 x25: ffffffc008c26e00 x24: 0000000000000001 x23: ffffffc000a68114 x22: 0000000000000000 x21: ffffff8004172cc8 x20: ffffffc00a803748 x19: ffffff8004152020 x18: 0000000000000000 x17: 00000000000017c0 x16: ffffffc008ef5000 x15: 0000000000000be0 x14: ffffff8004172e28 x13: ffffff8004172e28 x12: 0000000000000000 x11: 0000000000000000 x10: ffffff8004172e30 x9 : ffffff8004172e28 x8 : 0000000000000000 x7 : ffffff8004156020 x6 : 0000000000000000 x5 : 0000000000000031 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : ffffff80008f7300 x0 : 0000000000000024 Call trace: mt76_wcid_cleanup+0x84/0x22c [mt76] __mt76_sta_remove+0x70/0xbc [mt76] mt76_sta_state+0x8c/0x1a4 [mt76] mt7915_eeprom_get_power_delta+0x11e4/0x23a0 [mt7915e] drv_sta_state+0x144/0x274 [mac80211] sta_info_move_state+0x1cc/0x2a4 [mac80211] sta_set_sinfo+0xaf8/0xc24 [mac80211] sta_info_destroy_addr_bss+0x4c/0x6c [mac80211] ieee80211_color_change_finish+0x1c08/0x1e70 [mac80211] cfg80211_check_station_change+0x1360/0x4710 [cfg80211] genl_family_rcv_msg_doit+0xb4/0x110 genl_rcv_msg+0xd0/0x1bc netlink_rcv_skb+0x58/0x120 genl_rcv+0x34/0x50 netlink_unicast+0x1f0/0x2ec netlink_sendmsg+0x198/0x3d0 ____sys_sendmsg+0x1b0/0x210 ___sys_sendmsg+0x80/0xf0 __sys_sendmsg+0x44/0xa0 __arm64_sys_sendmsg+0x20/0x30 invoke_syscall.constprop.0+0x4c/0xe0 do_el0_svc+0x40/0xd0 el0_svc+0x14/0x4c el0t_64_sync_handler+0x100/0x110 el0t_64_sync+0x15c/0x160 Code: d2800002 910092c0 52800023 f9800011 (885f7c01) ---[ end trace 7e42dd9a39ed2281 ]--- Fix by using mt76_dev_phy() which will map band_idx to the correct phy for all hardware combinations.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: always wait for both firmware loading attempts In 'rtw_wait_firmware_completion()', always wait for both (regular and wowlan) firmware loading attempts. Otherwise if 'rtw_usb_intf_init()' has failed in 'rtw_usb_probe()', 'rtw_usb_disconnect()' may issue 'ieee80211_free_hw()' when one of 'rtw_load_firmware_cb()' (usually the wowlan one) is still in progress, causing UAF detected by KASAN.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: iommufd: Protect against overflow of ALIGN() during iova allocation Userspace can supply an iova and uptr such that the target iova alignment becomes really big and ALIGN() overflows which corrupts the selected area range during allocation. CONFIG_IOMMUFD_TEST can detect this: WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline] WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Modules linked in: CPU: 1 PID: 5092 Comm: syz-executor294 Not tainted 6.10.0-rc5-syzkaller-00294-g3ffea9a7a6f7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 RIP: 0010:iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline] RIP: 0010:iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Code: fc e9 a4 f3 ff ff e8 1a 8b 4c fc 41 be e4 ff ff ff e9 8a f3 ff ff e8 0a 8b 4c fc 90 0f 0b 90 e9 37 f5 ff ff e8 fc 8a 4c fc 90 <0f> 0b 90 e9 68 f3 ff ff 48 c7 c1 ec 82 ad 8f 80 e1 07 80 c1 03 38 RSP: 0018:ffffc90003ebf9e0 EFLAGS: 00010293 RAX: ffffffff85499fa4 RBX: 00000000ffffffef RCX: ffff888079b49e00 RDX: 0000000000000000 RSI: 00000000ffffffef RDI: 0000000000000000 RBP: ffffc90003ebfc50 R08: ffffffff85499b30 R09: ffffffff85499942 R10: 0000000000000002 R11: ffff888079b49e00 R12: ffff8880228e0010 R13: 0000000000000000 R14: 1ffff920007d7f68 R15: ffffc90003ebfd00 FS: 000055557d760380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000005fdeb8 CR3: 000000007404a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> iommufd_ioas_copy+0x610/0x7b0 drivers/iommu/iommufd/ioas.c:274 iommufd_fops_ioctl+0x4d9/0x5a0 drivers/iommu/iommufd/main.c:421 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Cap the automatic alignment to the huge page size, which is probably a better idea overall. Huge automatic alignments can fragment and chew up the available IOVA space without any reason.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn30_set_output_transfer_func function. Previously, set_output_gamma was being checked for nullity at line 386, but then it was being dereferenced without any nullity check at line 401. This could potentially lead to a null pointer dereference error if set_output_gamma is indeed null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a nullity check for set_output_gamma before the call to set_output_gamma at line 401. If set_output_gamma is null, we log an error message and do not call the function. This fix prevents a potential null pointer dereference error. drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func() error: we previously assumed 'mpc->funcs->set_output_gamma' could be null (see line 386) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c 373 bool dcn30_set_output_transfer_func(struct dc *dc, 374 struct pipe_ctx *pipe_ctx, 375 const struct dc_stream_state *stream) 376 { 377 int mpcc_id = pipe_ctx->plane_res.hubp->inst; 378 struct mpc *mpc = pipe_ctx->stream_res.opp->ctx->dc->res_pool->mpc; 379 const struct pwl_params *params = NULL; 380 bool ret = false; 381 382 /* program OGAM or 3DLUT only for the top pipe*/ 383 if (pipe_ctx->top_pipe == NULL) { 384 /*program rmu shaper and 3dlut in MPC*/ 385 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream); 386 if (ret == false && mpc->funcs->set_output_gamma) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL 387 if (stream->out_transfer_func.type == TF_TYPE_HWPWL) 388 params = &stream->out_transfer_func.pwl; 389 else if (pipe_ctx->stream->out_transfer_func.type == 390 TF_TYPE_DISTRIBUTED_POINTS && 391 cm3_helper_translate_curve_to_hw_format( 392 &stream->out_transfer_func, 393 &mpc->blender_params, false)) 394 params = &mpc->blender_params; 395 /* there are no ROM LUTs in OUTGAM */ 396 if (stream->out_transfer_func.type == TF_TYPE_PREDEFINED) 397 BREAK_TO_DEBUGGER(); 398 } 399 } 400 --> 401 mpc->funcs->set_output_gamma(mpc, mpcc_id, params); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash 402 return ret; 403 }


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: jfs: fix out-of-bounds in dbNextAG() and diAlloc() In dbNextAG() , there is no check for the case where bmp->db_numag is greater or same than MAXAG due to a polluted image, which causes an out-of-bounds. Therefore, a bounds check should be added in dbMount(). And in dbNextAG(), a check for the case where agpref is greater than bmp->db_numag should be added, so an out-of-bounds exception should be prevented. Additionally, a check for the case where agno is greater or same than MAXAG should be added in diAlloc() to prevent out-of-bounds.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: x86/tdx: Fix "in-kernel MMIO" check TDX only supports kernel-initiated MMIO operations. The handle_mmio() function checks if the #VE exception occurred in the kernel and rejects the operation if it did not. However, userspace can deceive the kernel into performing MMIO on its behalf. For example, if userspace can point a syscall to an MMIO address, syscall does get_user() or put_user() on it, triggering MMIO #VE. The kernel will treat the #VE as in-kernel MMIO. Ensure that the target MMIO address is within the kernel before decoding instruction.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error For all non-tracing helpers which formerly had ARG_PTR_TO_{LONG,INT} as input arguments, zero the value for the case of an error as otherwise it could leak memory. For tracing, it is not needed given CAP_PERFMON can already read all kernel memory anyway hence bpf_get_func_arg() and bpf_get_func_ret() is skipped in here. Also, the MTU helpers mtu_len pointer value is being written but also read. Technically, the MEM_UNINIT should not be there in order to always force init. Removing MEM_UNINIT needs more verifier rework though: MEM_UNINIT right now implies two things actually: i) write into memory, ii) memory does not have to be initialized. If we lift MEM_UNINIT, it then becomes: i) read into memory, ii) memory must be initialized. This means that for bpf_*_check_mtu() we're readding the issue we're trying to fix, that is, it would then be able to write back into things like .rodata BPF maps. Follow-up work will rework the MEM_UNINIT semantics such that the intent can be better expressed. For now just clear the *mtu_len on error path which can be lifted later again.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/qm - inject error before stopping queue The master ooo cannot be completely closed when the accelerator core reports memory error. Therefore, the driver needs to inject the qm error to close the master ooo. Currently, the qm error is injected after stopping queue, memory may be released immediately after stopping queue, causing the device to access the released memory. Therefore, error is injected to close master ooo before stopping queue to ensure that the device does not access the released memory.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drivers/perf: Fix ali_drw_pmu driver interrupt status clearing The alibaba_uncore_pmu driver forgot to clear all interrupt status in the interrupt processing function. After the PMU counter overflow interrupt occurred, an interrupt storm occurred, causing the system to hang. Therefore, clear the correct interrupt status in the interrupt handling function to fix it.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: crypto: iaa - Fix potential use after free bug The free_device_compression_mode(iaa_device, device_mode) function frees "device_mode" but it iss passed to iaa_compression_modes[i]->free() a few lines later resulting in a use after free. The good news is that, so far as I can tell, nothing implements the ->free() function and the use after free happens in dead code. But, with this fix, when something does implement it, we'll be ready. :)


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled Fix missuse of spin_lock_irq()/spin_unlock_irq() when spin_lock_irqsave()/spin_lock_irqrestore() was hold. This was discovered through the lock debugging, and the corresponding log is as follows: raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Call trace: warn_bogus_irq_restore+0x30/0x40 _raw_spin_unlock_irqrestore+0x84/0xc8 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2] hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2] hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2] create_qp+0x138/0x258 ib_create_qp_kernel+0x50/0xe8 create_mad_qp+0xa8/0x128 ib_mad_port_open+0x218/0x448 ib_mad_init_device+0x70/0x1f8 add_client_context+0xfc/0x220 enable_device_and_get+0xd0/0x140 ib_register_device.part.0+0xf4/0x1c8 ib_register_device+0x34/0x50 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2] hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2]


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: nfsd: call cache_put if xdr_reserve_space returns NULL If not enough buffer space available, but idmap_lookup has triggered lookup_fn which calls cache_get and returns successfully. Then we missed to call cache_put here which pairs with cache_get. Reviwed-by: Jeff Layton <jlayton@kernel.org>


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't use rate mask for offchannel TX either Like the commit ab9177d83c04 ("wifi: mac80211: don't use rate mask for scanning"), ignore incorrect settings to avoid no supported rate warning reported by syzbot. The syzbot did bisect and found cause is commit 9df66d5b9f45 ("cfg80211: fix default HE tx bitrate mask in 2G band"), which however corrects bitmask of HE MCS and recognizes correctly settings of empty legacy rate plus HE MCS rate instead of returning -EINVAL. As suggestions [1], follow the change of SCAN TX to consider this case of offchannel TX as well. [1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: padata: use integer wrap around to prevent deadlock on seq_nr overflow When submitting more than 2^32 padata objects to padata_do_serial, the current sorting implementation incorrectly sorts padata objects with overflowed seq_nr, causing them to be placed before existing objects in the reorder list. This leads to a deadlock in the serialization process as padata_find_next cannot match padata->seq_nr and pd->processed because the padata instance with overflowed seq_nr will be selected next. To fix this, we use an unsigned integer wrap around to correctly sort padata objects in scenarios with integer overflow.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race setting file private on concurrent lseek using same fd When doing concurrent lseek(2) system calls against the same file descriptor, using multiple threads belonging to the same process, we have a short time window where a race happens and can result in a memory leak. The race happens like this: 1) A program opens a file descriptor for a file and then spawns two threads (with the pthreads library for example), lets call them task A and task B; 2) Task A calls lseek with SEEK_DATA or SEEK_HOLE and ends up at file.c:find_desired_extent() while holding a read lock on the inode; 3) At the start of find_desired_extent(), it extracts the file's private_data pointer into a local variable named 'private', which has a value of NULL; 4) Task B also calls lseek with SEEK_DATA or SEEK_HOLE, locks the inode in shared mode and enters file.c:find_desired_extent(), where it also extracts file->private_data into its local variable 'private', which has a NULL value; 5) Because it saw a NULL file private, task A allocates a private structure and assigns to the file structure; 6) Task B also saw a NULL file private so it also allocates its own file private and then assigns it to the same file structure, since both tasks are using the same file descriptor. At this point we leak the private structure allocated by task A. Besides the memory leak, there's also the detail that both tasks end up using the same cached state record in the private structure (struct btrfs_file_private::llseek_cached_state), which can result in a use-after-free problem since one task can free it while the other is still using it (only one task took a reference count on it). Also, sharing the cached state is not a good idea since it could result in incorrect results in the future - right now it should not be a problem because it end ups being used only in extent-io-tree.c:count_range_bits() where we do range validation before using the cached state. Fix this by protecting the private assignment and check of a file while holding the inode's spinlock and keep track of the task that allocated the private, so that it's used only by that task in order to prevent user-after-free issues with the cached state record as well as potentially using it incorrectly in the future.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: firmware_loader: Block path traversal Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such. However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are: - lpfc_sli4_request_firmware_update() seems to construct the firmware filename from "ModelName", a string that was previously parsed out of some descriptor ("Vital Product Data") in lpfc_fill_vpd() - nfp_net_fw_find() seems to construct a firmware filename from a model name coming from nfp_hwinfo_lookup(pf->hwinfo, "nffw.partno"), which I think parses some descriptor that was read from the device. (But this case likely isn't exploitable because the format string looks like "netronome/nic_%s", and there shouldn't be any *folders* starting with "netronome/nic_". The previous case was different because there, the "%s" is *at the start* of the format string.) - module_flash_fw_schedule() is reachable from the ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is enough to pass the privilege check), and takes a userspace-provided firmware name. (But I think to reach this case, you need to have CAP_NET_ADMIN over a network namespace that a special kind of ethernet device is mapped into, so I think this is not a viable attack path in practice.) Fix it by rejecting any firmware names containing ".." path components. For what it's worth, I went looking and haven't found any USB device drivers that use the firmware loader dangerously.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: KEYS: prevent NULL pointer dereference in find_asymmetric_key() In find_asymmetric_key(), if all NULLs are passed in the id_{0,1,2} arguments, the kernel will first emit WARN but then have an oops because id_2 gets dereferenced anyway. Add the missing id_2 check and move WARN_ON() to the final else branch to avoid duplicate NULL checks. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock Use a dedicated mutex to guard kvm_usage_count to fix a potential deadlock on x86 due to a chain of locks and SRCU synchronizations. Translating the below lockdep splat, CPU1 #6 will wait on CPU0 #1, CPU0 #8 will wait on CPU2 #3, and CPU2 #7 will wait on CPU1 #4 (if there's a writer, due to the fairness of r/w semaphores). CPU0 CPU1 CPU2 1 lock(&kvm->slots_lock); 2 lock(&vcpu->mutex); 3 lock(&kvm->srcu); 4 lock(cpu_hotplug_lock); 5 lock(kvm_lock); 6 lock(&kvm->slots_lock); 7 lock(cpu_hotplug_lock); 8 sync(&kvm->srcu); Note, there are likely more potential deadlocks in KVM x86, e.g. the same pattern of taking cpu_hotplug_lock outside of kvm_lock likely exists with __kvmclock_cpufreq_notifier(): cpuhp_cpufreq_online() | -> cpufreq_online() | -> cpufreq_gov_performance_limits() | -> __cpufreq_driver_target() | -> __target_index() | -> cpufreq_freq_transition_begin() | -> cpufreq_notify_transition() | -> ... __kvmclock_cpufreq_notifier() But, actually triggering such deadlocks is beyond rare due to the combination of dependencies and timings involved. E.g. the cpufreq notifier is only used on older CPUs without a constant TSC, mucking with the NX hugepage mitigation while VMs are running is very uncommon, and doing so while also onlining/offlining a CPU (necessary to generate contention on cpu_hotplug_lock) would be even more unusual. The most robust solution to the general cpu_hotplug_lock issue is likely to switch vm_list to be an RCU-protected list, e.g. so that x86's cpufreq notifier doesn't to take kvm_lock. For now, settle for fixing the most blatant deadlock, as switching to an RCU-protected list is a much more involved change, but add a comment in locking.rst to call out that care needs to be taken when walking holding kvm_lock and walking vm_list. ====================================================== WARNING: possible circular locking dependency detected 6.10.0-smp--c257535a0c9d-pip #330 Tainted: G S O ------------------------------------------------------ tee/35048 is trying to acquire lock: ff6a80eced71e0a8 (&kvm->slots_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x179/0x1e0 [kvm] but task is already holding lock: ffffffffc07abb08 (kvm_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x14a/0x1e0 [kvm] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (kvm_lock){+.+.}-{3:3}: __mutex_lock+0x6a/0xb40 mutex_lock_nested+0x1f/0x30 kvm_dev_ioctl+0x4fb/0xe50 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #2 (cpu_hotplug_lock){++++}-{0:0}: cpus_read_lock+0x2e/0xb0 static_key_slow_inc+0x16/0x30 kvm_lapic_set_base+0x6a/0x1c0 [kvm] kvm_set_apic_base+0x8f/0xe0 [kvm] kvm_set_msr_common+0x9ae/0xf80 [kvm] vmx_set_msr+0xa54/0xbe0 [kvm_intel] __kvm_set_msr+0xb6/0x1a0 [kvm] kvm_arch_vcpu_ioctl+0xeca/0x10c0 [kvm] kvm_vcpu_ioctl+0x485/0x5b0 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&kvm->srcu){.+.+}-{0:0}: __synchronize_srcu+0x44/0x1a0 ---truncated---


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: mm: call the security_mmap_file() LSM hook in remap_file_pages() The remap_file_pages syscall handler calls do_mmap() directly, which doesn't contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux. So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1]. The PoC: $ cat > test.c int main(void) { size_t pagesz = sysconf(_SC_PAGE_SIZE); int mfd = syscall(SYS_memfd_create, "test", 0); const char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, MAP_SHARED, mfd, 0); unsigned int old = syscall(SYS_personality, 0xffffffff); syscall(SYS_personality, READ_IMPLIES_EXEC | old); syscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); syscall(SYS_personality, old); // show the RWX page exists even if W^X policy is enforced int fd = open("/proc/self/maps", O_RDONLY); unsigned char buf2[1024]; while (1) { int ret = read(fd, buf2, 1024); if (ret <= 0) break; write(1, buf2, ret); } close(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) [PM: subject line tweaks]


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition In the ether3_probe function, a timer is initialized with a callback function ether3_ledoff, bound to &prev(dev)->timer. Once the timer is started, there is a risk of a race condition if the module or device is removed, triggering the ether3_remove function to perform cleanup. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | ether3_ledoff ether3_remove | free_netdev(dev); | put_devic | kfree(dev); | | ether3_outw(priv(dev)->regs.config2 |= CFG2_CTRLO, REG_CONFIG2); | // use dev Fix it by ensuring that the timer is canceled before proceeding with the cleanup in ether3_remove.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: vhost_vdpa: assign irq bypass producer token correctly We used to call irq_bypass_unregister_producer() in vhost_vdpa_setup_vq_irq() which is problematic as we don't know if the token pointer is still valid or not. Actually, we use the eventfd_ctx as the token so the life cycle of the token should be bound to the VHOST_SET_VRING_CALL instead of vhost_vdpa_setup_vq_irq() which could be called by set_status(). Fixing this by setting up irq bypass producer's token when handling VHOST_SET_VRING_CALL and un-registering the producer before calling vhost_vring_ioctl() to prevent a possible use after free as eventfd could have been released in vhost_vring_ioctl(). And such registering and unregistering will only be done if DRIVER_OK is set.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Added NULL check for lookup_atid The lookup_atid() function can return NULL if the ATID is invalid or does not exist in the identifier table, which could lead to dereferencing a null pointer without a check in the `act_establish()` and `act_open_rpl()` functions. Add a NULL check to prevent null pointer dereferencing. Found by Linux Verification Center (linuxtesting.org) with SVACE.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08 Currently rsv_qp is freed before ib_unregister_device() is called on HIP08. During the time interval, users can still dereg MR and rsv_qp will be used in this process, leading to a UAF. Move the release of rsv_qp after calling ib_unregister_device() to fix it.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: PCI: kirin: Fix buffer overflow in kirin_pcie_parse_port() Within kirin_pcie_parse_port(), the pcie->num_slots is compared to pcie->gpio_id_reset size (MAX_PCI_SLOTS) which is correct and would lead to an overflow. Thus, fix condition to pcie->num_slots + 1 >= MAX_PCI_SLOTS and move pcie->num_slots increment below the if-statement to avoid out-of-bounds array access. Found by Linux Verification Center (linuxtesting.org) with SVACE. [kwilczynski: commit log]


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_if.c. Which leads to a kernel crash when fb is NULL.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning Fix a smatch static checker warning on vdec_vp8_req_if.c. Which leads to a kernel crash when fb is NULL.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_multi_if.c. Which leads to a kernel crash when fb is NULL.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: PCI: keystone: Fix if-statement expression in ks_pcie_quirk() This code accidentally uses && where || was intended. It potentially results in a NULL dereference. Thus, fix the if-statement expression to use the correct condition. [kwilczynski: commit log]


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential oob read in nilfs_btree_check_delete() The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries. This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself. However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: bpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos In case of malformed relocation record of kind BPF_CORE_TYPE_ID_LOCAL referencing a non-existing BTF type, function bpf_core_calc_relo_insn would cause a null pointer deference. Fix this by adding a proper check upper in call stack, as malformed relocation records could be passed from user space. Simplest reproducer is a program: r0 = 0 exit With a single relocation record: .insn_off = 0, /* patch first instruction */ .type_id = 100500, /* this type id does not exist */ .access_str_off = 6, /* offset of string "0" */ .kind = BPF_CORE_TYPE_ID_LOCAL, See the link for original reproducer or next commit for a test case.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: tpm: Clean up TPM space after command failure tpm_dev_transmit prepares the TPM space before attempting command transmission. However if the command fails no rollback of this preparation is done. This can result in transient handles being leaked if the device is subsequently closed with no further commands performed. Fix this by flushing the space in the event of command transmission failure.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del() The kref_put() function will call nport->release if the refcount drops to zero. The nport->release release function is _efc_nport_free() which frees "nport". But then we dereference "nport" on the next line which is a use after free. Re-order these lines to avoid the use after free.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix double free in OPTEE transport Channels can be shared between protocols, avoid freeing the same channel descriptors twice when unloading the stack.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: nbd: fix race between timeout and normal completion If request timetout is handled by nbd_requeue_cmd(), normal completion has to be stopped for avoiding to complete this requeued request, other use-after-free can be triggered. Fix the race by clearing NBD_CMD_INFLIGHT in nbd_requeue_cmd(), meantime make sure that cmd->lock is grabbed for clearing the flag and the requeue.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption The TPM event log table is a Linux specific construct, where the data produced by the GetEventLog() boot service is cached in memory, and passed on to the OS using an EFI configuration table. The use of EFI_LOADER_DATA here results in the region being left unreserved in the E820 memory map constructed by the EFI stub, and this is the memory description that is passed on to the incoming kernel by kexec, which is therefore unaware that the region should be reserved. Even though the utility of the TPM2 event log after a kexec is questionable, any corruption might send the parsing code off into the weeds and crash the kernel. So let's use EFI_ACPI_RECLAIM_MEMORY instead, which is always treated as reserved by the E820 conversion logic.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: ACPI: sysfs: validate return type of _STR method Only buffer objects are valid return values of _STR. If something else is returned description_show() will access invalid memory.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix helper writes to read-only maps Lonial found an issue that despite user- and BPF-side frozen BPF map (like in case of .rodata), it was still possible to write into it from a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT} as arguments. In check_func_arg() when the argument is as mentioned, the meta->raw_mode is never set. Later, check_helper_mem_access(), under the case of PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the subsequent call to check_map_access_type() and given the BPF map is read-only it succeeds. The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT when results are written into them as opposed to read out of them. The latter indicates that it's okay to pass a pointer to uninitialized memory as the memory is written to anyway. However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM just with additional alignment requirement. So it is better to just get rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the fixed size memory types. For this, add MEM_ALIGNED to additionally ensure alignment given these helpers write directly into the args via *<ptr> = val. The .arg*_size has been initialized reflecting the actual sizeof(*<ptr>). MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated argument types, since in !MEM_FIXED_SIZE cases the verifier does not know the buffer size a priori and therefore cannot blindly write *<ptr> = val.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: powercap: intel_rapl: Fix off by one in get_rpi() The rp->priv->rpi array is either rpi_msr or rpi_tpmi which have NR_RAPL_PRIMITIVES number of elements. Thus the > needs to be >= to prevent an off by one access.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: vhost/scsi: null-ptr-dereference in vhost_scsi_get_req() Since commit 3f8ca2e115e5 ("vhost/scsi: Extract common handling code from control queue handler") a null pointer dereference bug can be triggered when guest sends an SCSI AN request. In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with `&v_req.tmf.lun[1]` within a switch-case block and is then passed to vhost_scsi_get_req() which extracts `vc->req` and `tpg`. However, for a `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` is set to NULL in this branch. Later, in vhost_scsi_get_req(), `vc->target` is dereferenced without being checked, leading to a null pointer dereference bug. This bug can be triggered from guest. When this bug occurs, the vhost_worker process is killed while holding `vq->mutex` and the corresponding tpg will remain occupied indefinitely. Below is the KASAN report: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1 Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:vhost_scsi_get_req+0x165/0x3a0 Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 <0f> b6 04 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00 RSP: 0018:ffff888017affb50 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8 RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000 FS: 000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0 Call Trace: <TASK> ? show_regs+0x86/0xa0 ? die_addr+0x4b/0xd0 ? exc_general_protection+0x163/0x260 ? asm_exc_general_protection+0x27/0x30 ? vhost_scsi_get_req+0x165/0x3a0 vhost_scsi_ctl_handle_vq+0x2a4/0xca0 ? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10 ? __switch_to+0x721/0xeb0 ? __schedule+0xda5/0x5710 ? __kasan_check_write+0x14/0x30 ? _raw_spin_lock+0x82/0xf0 vhost_scsi_ctl_handle_kick+0x52/0x90 vhost_run_work_list+0x134/0x1b0 vhost_task_fn+0x121/0x350 ... </TASK> ---[ end trace 0000000000000000 ]--- Let's add a check in vhost_scsi_get_req. [whitespace fixes]


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix a race between socket set up and I/O thread creation In rxrpc_open_socket(), it sets up the socket and then sets up the I/O thread that will handle it. This is a problem, however, as there's a gap between the two phases in which a packet may come into rxrpc_encap_rcv() from the UDP packet but we oops when trying to wake the not-yet created I/O thread. As a quick fix, just make rxrpc_encap_rcv() discard the packet if there's no I/O thread yet. A better, but more intrusive fix would perhaps be to rearrange things such that the socket creation is done by the I/O thread.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Fix a race during cpuhp processing There is another found exception that the "timerlat/1" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: <TASK> ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> ``` After tracing the scheduling event, it was discovered that the migration of the "timerlat/1" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: btrfs: wait for fixup workers before stopping cleaner kthread during umount During unmount, at close_ctree(), we have the following steps in this order: 1) Park the cleaner kthread - this doesn't destroy the kthread, it basically halts its execution (wake ups against it work but do nothing); 2) We stop the cleaner kthread - this results in freeing the respective struct task_struct; 3) We call btrfs_stop_all_workers() which waits for any jobs running in all the work queues and then free the work queues. Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don't wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources. Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs. The stack traces reported by syzbot were the following: BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-fixup btrfs_work_helper Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154 btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842 btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:247 [inline] slab_post_alloc_hook mm/slub.c:4086 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1107 copy_process+0x5d1/0x3d50 kernel/fork.c:2206 kernel_clone+0x223/0x880 kernel/fork.c:2787 kernel_thread+0x1bc/0x240 kernel/fork.c:2849 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:765 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 61: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:230 [inline] slab_free_h ---truncated---


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix dentry leak in cachefiles_open_file() A dentry leak may be caused when a lookup cookie and a cull are concurrent: P1 | P2 ----------------------------------------------------------- cachefiles_lookup_cookie cachefiles_look_up_object lookup_one_positive_unlocked // get dentry cachefiles_cull inode->i_flags |= S_KERNEL_FILE; cachefiles_open_file cachefiles_mark_inode_in_use __cachefiles_mark_inode_in_use can_use = false if (!(inode->i_flags & S_KERNEL_FILE)) can_use = true return false return false // Returns an error but doesn't put dentry After that the following WARNING will be triggered when the backend folder is umounted: ================================================================== BUG: Dentry 000000008ad87947{i=7a,n=Dx_1_1.img} still in use (1) [unmount of ext4 sda] WARNING: CPU: 4 PID: 359261 at fs/dcache.c:1767 umount_check+0x5d/0x70 CPU: 4 PID: 359261 Comm: umount Not tainted 6.6.0-dirty #25 RIP: 0010:umount_check+0x5d/0x70 Call Trace: <TASK> d_walk+0xda/0x2b0 do_one_tree+0x20/0x40 shrink_dcache_for_umount+0x2c/0x90 generic_shutdown_super+0x20/0x160 kill_block_super+0x1a/0x40 ext4_kill_sb+0x22/0x40 deactivate_locked_super+0x35/0x80 cleanup_mnt+0x104/0x160 ================================================================== Whether cachefiles_open_file() returns true or false, the reference count obtained by lookup_positive_unlocked() in cachefiles_look_up_object() should be released. Therefore release that reference count in cachefiles_look_up_object() to fix the above issue and simplify the code.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: Input: adp5589-keys - fix NULL pointer dereference We register a devm action to call adp5589_clear_config() and then pass the i2c client as argument so that we can call i2c_get_clientdata() in order to get our device object. However, i2c_set_clientdata() is only being set at the end of the probe function which means that we'll get a NULL pointer dereference in case the probe function fails early.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver Due to Race Condition In the svc_i3c_master_probe function, &master->hj_work is bound with svc_i3c_master_hj_work, &master->ibi_work is bound with svc_i3c_master_ibi_work. And svc_i3c_master_ibi_work can start the hj_work, svc_i3c_master_irq_handler can start the ibi_work. If we remove the module which will call svc_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | svc_i3c_master_hj_work svc_i3c_master_remove | i3c_master_unregister(&master->base)| device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in svc_i3c_master_remove.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: nfsd: map the EBADMSG to nfserr_io to avoid warning Ext4 will throw -EBADMSG through ext4_readdir when a checksum error occurs, resulting in the following WARNING. Fix it by mapping EBADMSG to nfserr_io. nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING [ 161.115610] ------------[ cut here ]------------ [ 161.116465] nfsd: non-standard errno: -74 [ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0 [ 161.118596] Modules linked in: [ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138 [ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe mu.org 04/01/2014 [ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0 [ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33 [ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286 [ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a [ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827 [ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021 [ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8 [ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000 [ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0 [ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 161.141519] PKRU: 55555554 [ 161.142076] Call Trace: [ 161.142575] ? __warn+0x9b/0x140 [ 161.143229] ? nfserrno+0x9d/0xd0 [ 161.143872] ? report_bug+0x125/0x150 [ 161.144595] ? handle_bug+0x41/0x90 [ 161.145284] ? exc_invalid_op+0x14/0x70 [ 161.146009] ? asm_exc_invalid_op+0x12/0x20 [ 161.146816] ? nfserrno+0x9d/0xd0 [ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0 [ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0 [ 161.150093] ? wait_for_concurrent_writes+0x170/0x170 [ 161.151004] ? generic_file_llseek_size+0x48/0x160 [ 161.151895] nfsd_readdir+0x132/0x190 [ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.153516] ? nfsd_unlink+0x380/0x380 [ 161.154256] ? override_creds+0x45/0x60 [ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0 [ 161.155850] ? nfsd4_encode_readlink+0x210/0x210 [ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0 [ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0 [ 161.158494] ? lock_downgrade+0x90/0x90 [ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10 [ 161.160092] nfsd4_encode_operation+0x15a/0x440 [ 161.160959] nfsd4_proc_compound+0x718/0xe90 [ 161.161818] nfsd_dispatch+0x18e/0x2c0 [ 161.162586] svc_process_common+0x786/0xc50 [ 161.163403] ? nfsd_svc+0x380/0x380 [ 161.164137] ? svc_printk+0x160/0x160 [ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380 [ 161.165808] ? nfsd_svc+0x380/0x380 [ 161.166523] ? rcu_is_watching+0x23/0x40 [ 161.167309] svc_process+0x1a5/0x200 [ 161.168019] nfsd+0x1f5/0x380 [ 161.168663] ? nfsd_shutdown_threads+0x260/0x260 [ 161.169554] kthread+0x1c4/0x210 [ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80 [ 161.171246] ret_from_fork+0x1f/0x30


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if bh is NULL.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: resource: fix region_intersects() vs add_memory_driver_managed() On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows. 490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem) Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes "System RAM (kmem)" a descendant of "CXL Window X". This confuses region_intersects(), which expects all "System RAM" resources to be at the top level of iomem_resource. This can lead to bugs. For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s the command fails as expected. However, the error code is wrong. It should be "Operation not permitted" instead of "Bad address". More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly. Although the accessing is prevented later because ioremap() isn't allowed to map system RAM, it is a potential security issue. During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53 The details of command execution process are as follows. In the above resource tree, "System RAM" is a descendant of "CXL Window 0" instead of a top level resource. So, region_intersects() will report no System RAM resources in the CXL memory region incorrectly, because it only checks the top level resources. Consequently, devmem_is_allowed() will return 1 (allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn't allow to map System RAM and reject the access. So, region_intersects() needs to be fixed to work correctly with the resource tree with "System RAM" not at top level as above. To fix it, if we found a unmatched resource in the top level, we will continue to search matched resources in its descendant resources. So, we will not miss any matched resources in resource tree anymore. In the new implementation, an example resource tree |------------- "CXL Window 0" ------------| |-- "System RAM" --| will behave similar as the following fake resource tree for region_intersects(, IORESOURCE_SYSTEM_RAM, ), |-- "System RAM" --||-- "CXL Window 0a" --| Where "CXL Window 0a" is part of the original "CXL Window 0" that isn't covered by "System RAM".


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm: omapdrm: Add missing check for alloc_ordered_workqueue As it may return NULL pointer and cause NULL pointer dereference. Add check for the return value of alloc_ordered_workqueue.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: ext4: update orig_path in ext4_find_extent() In ext4_find_extent(), if the path is not big enough, we free it and set *orig_path to NULL. But after reallocating and successfully initializing the path, we don't update *orig_path, in which case the caller gets a valid path but a NULL ppath, and this may cause a NULL pointer dereference or a path memory leak. For example: ext4_split_extent path = *ppath = 2000 ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path = 2000); *orig_path = path = NULL; path = kcalloc() = 3000 ext4_split_extent_at(*ppath = NULL) path = *ppath; ex = path[depth].p_ext; // NULL pointer dereference! ================================================================== BUG: kernel NULL pointer dereference, address: 0000000000000010 CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847 RIP: 0010:ext4_split_extent_at+0x6d/0x560 Call Trace: <TASK> ext4_split_extent.isra.0+0xcb/0x1b0 ext4_ext_convert_to_initialized+0x168/0x6c0 ext4_ext_handle_unwritten_extents+0x325/0x4d0 ext4_ext_map_blocks+0x520/0xdb0 ext4_map_blocks+0x2b0/0x690 ext4_iomap_begin+0x20e/0x2c0 [...] ================================================================== Therefore, *orig_path is updated when the extent lookup succeeds, so that the caller can safely use path or *ppath.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: ext4: fix double brelse() the buffer of the extents path In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been released, otherwise it may be released twice. An example of what triggers this is as follows: split2 map split1 |--------|-------|--------| ext4_ext_map_blocks ext4_ext_handle_unwritten_extents ext4_split_convert_extents // path->p_depth == 0 ext4_split_extent // 1. do split1 ext4_split_extent_at |ext4_ext_insert_extent | ext4_ext_create_new_leaf | ext4_ext_grow_indepth | le16_add_cpu(&neh->eh_depth, 1) | ext4_find_extent | // return -ENOMEM |// get error and try zeroout |path = ext4_find_extent | path->p_depth = 1 |ext4_ext_try_to_merge | ext4_ext_try_to_merge_up | path->p_depth = 0 | brelse(path[1].p_bh) ---> not set to NULL here |// zeroout success // 2. update path ext4_find_extent // 3. do split2 ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth le16_add_cpu(&neh->eh_depth, 1) ext4_find_extent path[0].p_bh = NULL; path->p_depth = 1 read_extent_tree_block ---> return err // path[1].p_bh is still the old value ext4_free_ext_path ext4_ext_drop_refs // path->p_depth == 1 brelse(path[1].p_bh) ---> brelse a buffer twice Finally got the following WARRNING when removing the buffer from lru: ============================================ VFS: brelse: Trying to free free buffer WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90 CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716 RIP: 0010:__brelse+0x58/0x90 Call Trace: <TASK> __find_get_block+0x6e7/0x810 bdev_getblk+0x2b/0x480 __ext4_get_inode_loc+0x48a/0x1240 ext4_get_inode_loc+0xb2/0x150 ext4_reserve_inode_write+0xb7/0x230 __ext4_mark_inode_dirty+0x144/0x6a0 ext4_ext_insert_extent+0x9c8/0x3230 ext4_ext_map_blocks+0xf45/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ============================================


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: ext4: aovid use-after-free in ext4_ext_insert_extent() As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is reallocated in ext4_ext_create_new_leaf(), we'll use the stale path and cause UAF. Below is a sample trace with dummy values: ext4_ext_insert_extent path = *ppath = 2000 ext4_ext_create_new_leaf(ppath) ext4_find_extent(ppath) path = *ppath = 2000 if (depth > path[0].p_maxdepth) kfree(path = 2000); *ppath = path = NULL; path = kcalloc() = 3000 *ppath = 3000; return path; /* here path is still 2000, UAF! */ eh = path[depth].p_hdr ================================================================== BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330 Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179 CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866 Call Trace: <TASK> ext4_ext_insert_extent+0x26d4/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 [...] Allocated by task 179: ext4_find_extent+0x81c/0x1f70 ext4_ext_map_blocks+0x146/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] Freed by task 179: kfree+0xcb/0x240 ext4_find_extent+0x7c0/0x1f70 ext4_ext_insert_extent+0xa26/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] ================================================================== So use *ppath to update the path to avoid the above problem.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug Attaching SST PCI device to VM causes "BUG: KASAN: slab-out-of-bounds". kasan report: [ 19.411889] ================================================================== [ 19.413702] BUG: KASAN: slab-out-of-bounds in _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113 [ 19.417368] [ 19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: G E 6.9.0 #10 [ 19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022 [ 19.422687] Call Trace: [ 19.424091] <TASK> [ 19.425448] dump_stack_lvl+0x5d/0x80 [ 19.426963] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.428694] print_report+0x19d/0x52e [ 19.430206] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 19.431837] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.433539] kasan_report+0xf0/0x170 [ 19.435019] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.436709] _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.438379] ? __pfx_sched_clock_cpu+0x10/0x10 [ 19.439910] isst_if_cpu_online+0x406/0x58f [isst_if_common] [ 19.441573] ? __pfx_isst_if_cpu_online+0x10/0x10 [isst_if_common] [ 19.443263] ? ttwu_queue_wakelist+0x2c1/0x360 [ 19.444797] cpuhp_invoke_callback+0x221/0xec0 [ 19.446337] cpuhp_thread_fun+0x21b/0x610 [ 19.447814] ? __pfx_cpuhp_thread_fun+0x10/0x10 [ 19.449354] smpboot_thread_fn+0x2e7/0x6e0 [ 19.450859] ? __pfx_smpboot_thread_fn+0x10/0x10 [ 19.452405] kthread+0x29c/0x350 [ 19.453817] ? __pfx_kthread+0x10/0x10 [ 19.455253] ret_from_fork+0x31/0x70 [ 19.456685] ? __pfx_kthread+0x10/0x10 [ 19.458114] ret_from_fork_asm+0x1a/0x30 [ 19.459573] </TASK> [ 19.460853] [ 19.462055] Allocated by task 1198: [ 19.463410] kasan_save_stack+0x30/0x50 [ 19.464788] kasan_save_track+0x14/0x30 [ 19.466139] __kasan_kmalloc+0xaa/0xb0 [ 19.467465] __kmalloc+0x1cd/0x470 [ 19.468748] isst_if_cdev_register+0x1da/0x350 [isst_if_common] [ 19.470233] isst_if_mbox_init+0x108/0xff0 [isst_if_mbox_msr] [ 19.471670] do_one_initcall+0xa4/0x380 [ 19.472903] do_init_module+0x238/0x760 [ 19.474105] load_module+0x5239/0x6f00 [ 19.475285] init_module_from_file+0xd1/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.478920] do_syscall_64+0x82/0x160 [ 19.480036] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 19.481292] [ 19.482205] The buggy address belongs to the object at ffff888829e65000 which belongs to the cache kmalloc-512 of size 512 [ 19.484818] The buggy address is located 0 bytes to the right of allocated 512-byte region [ffff888829e65000, ffff888829e65200) [ 19.487447] [ 19.488328] The buggy address belongs to the physical page: [ 19.489569] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888829e60c00 pfn:0x829e60 [ 19.491140] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 19.492466] anon flags: 0x57ffffc0000840(slab|head|node=1|zone=2|lastcpupid=0x1fffff) [ 19.493914] page_type: 0xffffffff() [ 19.494988] raw: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.496451] raw: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.497906] head: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.499379] head: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.500844] head: 0057ffffc0000003 ffffea0020a79801 ffffea0020a79848 00000000ffffffff [ 19.502316] head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000 [ 19.503784] page dumped because: k ---truncated---


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix a sdiv overflow issue Zac Ecob reported a problem where a bpf program may cause kernel crash due to the following error: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI The failure is due to the below signed divide: LLONG_MIN/-1 where LLONG_MIN equals to -9,223,372,036,854,775,808. LLONG_MIN/-1 is supposed to give a positive number 9,223,372,036,854,775,808, but it is impossible since for 64-bit system, the maximum positive number is 9,223,372,036,854,775,807. On x86_64, LLONG_MIN/-1 will cause a kernel exception. On arm64, the result for LLONG_MIN/-1 is LLONG_MIN. Further investigation found all the following sdiv/smod cases may trigger an exception when bpf program is running on x86_64 platform: - LLONG_MIN/-1 for 64bit operation - INT_MIN/-1 for 32bit operation - LLONG_MIN%-1 for 64bit operation - INT_MIN%-1 for 32bit operation where -1 can be an immediate or in a register. On arm64, there are no exceptions: - LLONG_MIN/-1 = LLONG_MIN - INT_MIN/-1 = INT_MIN - LLONG_MIN%-1 = 0 - INT_MIN%-1 = 0 where -1 can be an immediate or in a register. Insn patching is needed to handle the above cases and the patched codes produced results aligned with above arm64 result. The below are pseudo codes to handle sdiv/smod exceptions including both divisor -1 and divisor 0 and the divisor is stored in a register. sdiv: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L2 if tmp == 0 goto L1 rY = 0 L1: rY = -rY; goto L3 L2: rY /= rX L3: smod: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L1 if tmp == 1 (is64 ? goto L2 : goto L3) rY = 0; goto L2 L1: rY %= rX L2: goto L4 // only when !is64 L3: wY = wY // only when !is64 L4: [1] https://lore.kernel.org/bpf/tPJLTEh7S_DxFEqAI2Ji5MBSoZVg7_G-Py2iaZpAaWtM961fFTWtsnlzwvTbzBzaUzwQAoNATXKUlt0LZOFgnDcIyKCswAnAGdUF3LBrhGQ=@protonmail.com/


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: ensure the fw_info is not null before using it This resolves the dereference null return value warning reported by Coverity.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata paths When the HBA is undergoing a reset or is handling an errata event, NULL ptr dereference crashes may occur in routines such as lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), or lpfc_abort_handler(). Add NULL ptr checks before dereferencing hdwq pointers that may have been freed due to operations colliding with a reset or errata event handler.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize get_bytes_per_element's default to 1 Variables, used as denominators and maybe not assigned to other values, should not be 0. bytes_per_element_y & bytes_per_element_c are initialized by get_bytes_per_element() which should never return 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in degamma hardware format translation Fixes index out of bounds issue in `cm_helper_translate_curve_to_degamma_hw_format` function. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream before comparing them [WHAT & HOW] amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It is necessary to check for null before dereferencing them. This fixes 1 FORWARD_NULL issue reported by Coverity.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check phantom_stream before it is used dcn32_enable_phantom_stream can return null, so returned value must be checked before used. This fixes 1 NULL_RETURNS issue reported by Coverity.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null-initialized variables [WHAT & HOW] drr_timing and subvp_pipe are initialized to null and they are not always assigned new values. It is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uninit-value access of new_ea in ea_buffer syzbot reports that lzo1x_1_do_compress is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178 ... Uninit was stored to memory at: ea_put fs/jfs/xattr.c:639 [inline] ... Local variable ea_buf created at: __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662 __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934 ===================================================== The reason is ea_buf->new_ea is not initialized properly. Fix this by using memset to empty its content at the beginning in ea_get().


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrs There are some cases, such as the one uncovered by Commit 46d4efcccc68 ("drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails") where msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL); is called on gpu->pdev == NULL, as the GPU device has not been fully initialized yet. Turns out that there's more than just the aforementioned path that causes this to happen (e.g. the case when there's speedbin data in the catalog, but opp-supported-hw is missing in DT). Assigning msm_gpu->pdev earlier seems like the least painful solution to this, therefore do so. Patchwork: https://patchwork.freedesktop.org/patch/602742/


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: jfs: check if leafidx greater than num leaves per dmap tree syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf. Shaggy: Modified sanity check to apply to control pages as well as leaf pages.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uaf in dbFreeBits [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216 CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 __mutex_lock_common kernel/locking/mutex.c:587 [inline] __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390 dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline] dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409 dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650 jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100 jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Freed by task 5218: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2252 [inline] slab_free mm/slub.c:4473 [inline] kfree+0x149/0x360 mm/slub.c:4594 dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278 jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247 jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454 reconfigure_super+0x445/0x880 fs/super.c:1083 vfs_cmd_reconfigure fs/fsopen.c:263 [inline] vfs_fsconfig_locked fs/fsopen.c:292 [inline] __do_sys_fsconfig fs/fsopen.c:473 [inline] __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [Analysis] There are two paths (dbUnmount and jfs_ioc_trim) that generate race condition when accessing bmap, which leads to the occurrence of uaf. Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before try to access it [why & how] Change the order of the pipe_ctx->plane_state check to ensure that plane_state is not null before accessing it.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using dc->clk_mgr [WHY & HOW] dc->clk_mgr is null checked previously in the same function, indicating it might be null. Passing "dc" to "dc->hwss.apply_idle_power_optimizations", which dereferences null "dc->clk_mgr". (The function pointer resolves to "dcn35_apply_idle_power_optimizations".) This fixes 1 FORWARD_NULL issue reported by Coverity.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_update_cursor (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_update_cursor function. Previously, 'afb' was assumed to be null at line 8388, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8433 amdgpu_dm_update_cursor() error: we previously assumed 'afb' could be null (see line 8388)


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn32_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn32_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_stream This commit addresses a null pointer dereference issue in the `commit_planes_for_stream` function at line 4140. The issue could occur when `top_pipe_to_program` is null. The fix adds a check to ensure `top_pipe_to_program` is not null before accessing its stream_res. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commit_planes_for_stream() error: we previously assumed 'top_pipe_to_program' could be null (see line 3906)


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for pipe_ctx->plane_state in dcn20_program_pipe This commit addresses a null pointer dereference issue in the `dcn20_program_pipe` function. The issue could occur when `pipe_ctx->plane_state` is null. The fix adds a check to ensure `pipe_ctx->plane_state` is not null before accessing. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c:1925 dcn20_program_pipe() error: we previously assumed 'pipe_ctx->plane_state' could be null (see line 1877)


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn30_init_hw This commit addresses a potential null pointer dereference issue in the `dcn30_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:789 dcn30_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 628)


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn32_acquire_idle_pipe_for_head_pipe_in_layer This commit addresses a potential null pointer dereference issue in the `dcn32_acquire_idle_pipe_for_head_pipe_in_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn32/dcn32_resource.c:2690 dcn32_acquire_idle_pipe_for_head_pipe_in_layer() error: we previously assumed 'head_pipe' could be null (see line 2681)


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn201_acquire_free_pipe_for_layer This commit addresses a potential null pointer dereference issue in the `dcn201_acquire_free_pipe_for_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn201/dcn201_resource.c:1016 dcn201_acquire_free_pipe_for_layer() error: we previously assumed 'head_pipe' could be null (see line 1010)


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before multiple uses [WHAT & HOW] Poniters, such as stream_enc and dc->bw_vbios, are null checked previously in the same function, so Coverity warns "implies that stream_enc and dc->bw_vbios might be null". They are used multiple times in the subsequent code and need to be checked. This fixes 10 FORWARD_NULL issues reported by Coverity.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid reading out of bounds when loading TX power FW elements Because the loop-expression will do one more time before getting false from cond-expression, the original code copied one more entry size beyond valid region. Fix it by moving the entry copy to loop-body.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: avoid NULL pointer dereference iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta pointer is not NULL. It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is dereferencing the ieee80211_sta pointer. If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL pointer. Fix this by checking the sta pointer before retrieving the mvmsta from it. If sta is not NULL, then mvmsta isn't either.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix array out-of-bound access in SoC stats Currently, the ath11k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath11k_dp_process_rx() function access ath11k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath11k_dp_process_rx() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix array out-of-bound access in SoC stats Currently, the ath12k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath12k_dp_rx_process() function access ath12k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath12k_dp_rx_process() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: ACPI: PAD: fix crash in exit_round_robin() The kernel occasionally crashes in cpumask_clear_cpu(), which is called within exit_round_robin(), because when executing clear_bit(nr, addr) with nr set to 0xffffffff, the address calculation may cause misalignment within the memory, leading to access to an invalid memory address. ---------- BUG: unable to handle kernel paging request at ffffffffe0740618 ... CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G OE X --------- - - 4.18.0-425.19.2.el8_7.x86_64 #1 ... RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad] Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 <f0> 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31 RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202 RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8 R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000e R13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000e FS: 0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? acpi_pad_add+0x120/0x120 [acpi_pad] kthread+0x10b/0x130 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x1f/0x40 ... CR2: ffffffffe0740618 crash> dis -lr ffffffffc0726923 ... /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 114 0xffffffffc0726918 <power_saving_thread+776>: mov %r12d,%r12d /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 325 0xffffffffc072691b <power_saving_thread+779>: mov -0x3f8d7de0(,%r12,4),%eax /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 80 0xffffffffc0726923 <power_saving_thread+787>: lock btr %rax,0x19cf4(%rip) # 0xffffffffc0740620 <pad_busy_cpus_bits> crash> px tsk_in_cpu[14] $66 = 0xffffffff crash> px 0xffffffffc072692c+0x19cf4 $99 = 0xffffffffc0740620 crash> sym 0xffffffffc0740620 ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad] crash> px pad_busy_cpus_bits[0] $42 = 0xfffc0 ---------- To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before calling cpumask_clear_cpu() in exit_round_robin(), just as it is done in round_robin_cpu(). [ rjw: Subject edit, avoid updates to the same value ]


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: net/xen-netback: prevent UAF in xenvif_flush_hash() During the list_for_each_entry_rcu iteration call of xenvif_flush_hash, kfree_rcu does not exist inside the rcu read critical section, so if kfree_rcu is called when the rcu grace period ends during the iteration, UAF occurs when accessing head->next after the entry becomes free. Therefore, to solve this, you need to change it to list_for_each_entry_safe.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Set correct chandef when starting CAC When starting CAC in a mode other than AP mode, it return a "WARNING: CPU: 0 PID: 63 at cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]" caused by the chandef.chan being null at the end of CAC. Solution: Ensure the channel definition is set for the different modes when starting CAC to avoid getting a NULL 'chan' at the end of CAC. Call Trace: ? show_regs.part.0+0x14/0x16 ? __warn+0x67/0xc0 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? report_bug+0xa7/0x130 ? exc_overflow+0x30/0x30 ? handle_bug+0x27/0x50 ? exc_invalid_op+0x18/0x60 ? handle_exception+0xf6/0xf6 ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? regulatory_propagate_dfs_state.cold+0x1b/0x4c [cfg80211] ? cfg80211_propagate_cac_done_wk+0x1a/0x30 [cfg80211] ? process_one_work+0x165/0x280 ? worker_thread+0x120/0x3f0 ? kthread+0xc2/0xf0 ? process_one_work+0x280/0x280 ? kthread_complete_and_exit+0x20/0x20 ? ret_from_fork+0x19/0x24 [shorten subject, remove OCB, reorder cases to match previous list]


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit Syzbot points out that skb_trim() has a sanity check on the existing length of the skb, which can be uninitialised in some error paths. The intent here is clearly just to reset the length to zero before resubmitting, so switch to calling __skb_set_length(skb, 0) directly. In addition, __skb_set_length() already contains a call to skb_reset_tail_pointer(), so remove the redundant call. The syzbot report came from ath9k_hif_usb_reg_in_cb(), but there's a similar usage of skb_trim() in ath9k_hif_usb_rx_cb(), change both while we're at it.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid to add interface to list twice when SER If SER L2 occurs during the WoWLAN resume flow, the add interface flow is triggered by ieee80211_reconfig(). However, due to rtw89_wow_resume() return failure, it will cause the add interface flow to be executed again, resulting in a double add list and causing a kernel panic. Therefore, we have added a check to prevent double adding of the list. list_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:37! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W O 6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7 Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 06/24/2021 Workqueue: events_freezable ieee80211_restart_work [mac80211] RIP: 0010:__list_add_valid_or_report+0x5e/0xb0 Code: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 <0f> 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 00 00 0f 0b 48 c7 c7 c8 bc 12 RSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246 RAX: 0000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900 RDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001 RBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0 R10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060 R13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010 FS: 0000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0 Call Trace: <TASK> ? __die_body+0x1f/0x70 ? die+0x3d/0x60 ? do_trap+0xa4/0x110 ? __list_add_valid_or_report+0x5e/0xb0 ? do_error_trap+0x6d/0x90 ? __list_add_valid_or_report+0x5e/0xb0 ? handle_invalid_op+0x30/0x40 ? __list_add_valid_or_report+0x5e/0xb0 ? exc_invalid_op+0x3c/0x50 ? asm_exc_invalid_op+0x16/0x20 ? __list_add_valid_or_report+0x5e/0xb0 rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f] drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ? finish_wait+0x3e/0x90 ? synchronize_rcu_expedited+0x174/0x260 ? sync_rcu_exp_done_unlocked+0x50/0x50 ? wake_bit_function+0x40/0x40 ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] process_scheduled_works+0x1e5/0x480 worker_thread+0xea/0x1e0 kthread+0xdb/0x110 ? move_linked_works+0x90/0x90 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork+0x3b/0x50 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork_asm+0x11/0x20 </TASK> Modules linked in: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydev gsmi: Log Shutdown Reason 0x03 ---[ end trace 0000000000000000 ]---


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: ppp: do not assume bh is held in ppp_channel_bridge_input() Networking receive path is usually handled from BH handler. However, some protocols need to acquire the socket lock, and packets might be stored in the socket backlog is the socket was owned by a user process. In this case, release_sock(), __release_sock(), and sk_backlog_rcv() might call the sk->sk_backlog_rcv() handler in process context. sybot caught ppp was not considering this case in ppp_channel_bridge_input() : WARNING: inconsistent lock state 6.11.0-rc7-syzkaller-g5f5673607153 #0 Not tainted -------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. ksoftirqd/1/24 [HC0[0]:SC1[1]:HE1:SE0] takes: ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 {SOFTIRQ-ON-W} state was registered at: lock_acquire+0x240/0x728 kernel/locking/lockdep.c:5759 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x48/0x60 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0xfc/0x314 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv include/net/sock.h:1111 [inline] __release_sock+0x1a8/0x3d8 net/core/sock.c:3004 release_sock+0x68/0x1b8 net/core/sock.c:3558 pppoe_sendmsg+0xc8/0x5d8 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x374/0x4f4 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __arm64_sys_sendto+0xd8/0xf8 net/socket.c:2212 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 irq event stamp: 282914 hardirqs last enabled at (282914): [<ffff80008b42e30c>] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:151 [inline] hardirqs last enabled at (282914): [<ffff80008b42e30c>] _raw_spin_unlock_irqrestore+0x38/0x98 kernel/locking/spinlock.c:194 hardirqs last disabled at (282913): [<ffff80008b42e13c>] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline] hardirqs last disabled at (282913): [<ffff80008b42e13c>] _raw_spin_lock_irqsave+0x2c/0x7c kernel/locking/spinlock.c:162 softirqs last enabled at (282904): [<ffff8000801f8e88>] softirq_handle_end kernel/softirq.c:400 [inline] softirqs last enabled at (282904): [<ffff8000801f8e88>] handle_softirqs+0xa3c/0xbfc kernel/softirq.c:582 softirqs last disabled at (282909): [<ffff8000801fbdf8>] run_ksoftirqd+0x70/0x158 kernel/softirq.c:928 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&pch->downl); <Interrupt> lock(&pch->downl); *** DEADLOCK *** 1 lock held by ksoftirqd/1/24: #0: ffff80008f74dfa0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x10/0x4c include/linux/rcupdate.h:325 stack backtrace: CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call trace: dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:319 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:326 __dump_sta ---truncated---


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: net: test for not too small csum_start in virtio_net_hdr_to_skb() syzbot was able to trigger this warning [1], after injecting a malicious packet through af_packet, setting skb->csum_start and thus the transport header to an incorrect value. We can at least make sure the transport header is after the end of the network header (with a estimated minimal size). [1] [ 67.873027] skb len=4096 headroom=16 headlen=14 tailroom=0 mac=(-1,-1) mac_len=0 net=(16,-6) trans=10 shinfo(txflags=0 nr_frags=1 gso(size=0 type=0 segs=0)) csum(0xa start=10 offset=0 ip_summed=3 complete_sw=0 valid=0 level=0) hash(0x0 sw=0 l4=0) proto=0x0800 pkttype=0 iif=0 priority=0x0 mark=0x0 alloc_cpu=10 vlan_all=0x0 encapsulation=0 inner(proto=0x0000, mac=0, net=0, trans=0) [ 67.877172] dev name=veth0_vlan feat=0x000061164fdd09e9 [ 67.877764] sk family=17 type=3 proto=0 [ 67.878279] skb linear: 00000000: 00 00 10 00 00 00 00 00 0f 00 00 00 08 00 [ 67.879128] skb frag: 00000000: 0e 00 07 00 00 00 28 00 08 80 1c 00 04 00 00 02 [ 67.879877] skb frag: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.880647] skb frag: 00000020: 00 00 02 00 00 00 08 00 1b 00 00 00 00 00 00 00 [ 67.881156] skb frag: 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.881753] skb frag: 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882173] skb frag: 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882790] skb frag: 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883171] skb frag: 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883733] skb frag: 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.884206] skb frag: 00000090: 00 00 00 00 00 00 00 00 00 00 69 70 76 6c 61 6e [ 67.884704] skb frag: 000000a0: 31 00 00 00 00 00 00 00 00 00 2b 00 00 00 00 00 [ 67.885139] skb frag: 000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.885677] skb frag: 000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886042] skb frag: 000000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886408] skb frag: 000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887020] skb frag: 000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887384] skb frag: 00000100: 00 00 [ 67.887878] ------------[ cut here ]------------ [ 67.887908] offset (-6) >= skb_headlen() (14) [ 67.888445] WARNING: CPU: 10 PID: 2088 at net/core/dev.c:3332 skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.889353] Modules linked in: macsec macvtap macvlan hsr wireguard curve25519_x86_64 libcurve25519_generic libchacha20poly1305 chacha_x86_64 libchacha poly1305_x86_64 dummy bridge sr_mod cdrom evdev pcspkr i2c_piix4 9pnet_virtio 9p 9pnet netfs [ 67.890111] CPU: 10 UID: 0 PID: 2088 Comm: b363492833 Not tainted 6.11.0-virtme #1011 [ 67.890183] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 67.890309] RIP: 0010:skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891043] Call Trace: [ 67.891173] <TASK> [ 67.891274] ? __warn (kernel/panic.c:741) [ 67.891320] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891333] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 67.891348] ? handle_bug (arch/x86/kernel/traps.c:239) [ 67.891363] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 67.891372] ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) [ 67.891388] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891399] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891416] ip_do_fragment (net/ipv4/ip_output.c:777 (discriminator 1)) [ 67.891448] ? __ip_local_out (./include/linux/skbuff.h:1146 ./include/net/l3mdev.h:196 ./include/net/l3mdev.h:213 ne ---truncated---


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: net: avoid potential underflow in qdisc_pkt_len_init() with UFO After commit 7c6d2ecbda83 ("net: be more gentle about silly gso requests coming from user") virtio_net_hdr_to_skb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet. Then commit cf9acc90c80ec ("net: virtio_net_hdr_to_skb: count transport header in UFO") while fixing one issue, allowed user space to cook a GSO packet with the following characteristic : IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28. When this packet arrives in qdisc_pkt_len_init(), we end up with hdr_len = 28 (IPv4 header + UDP header), matching skb->len Then the following sets gso_segs to 0 : gso_segs = DIV_ROUND_UP(skb->len - hdr_len, shinfo->gso_size); Then later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/ qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len; This leads to the following crash in fq_codel [1] qdisc_pkt_len_init() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel. This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug. [1] [ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 70.724561] #PF: supervisor read access in kernel mode [ 70.724561] #PF: error_code(0x0000) - not-present page [ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991 [ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49 All code ======== 0: 24 08 and $0x8,%al 2: 49 c1 e1 06 shl $0x6,%r9 6: 44 89 7c 24 18 mov %r15d,0x18(%rsp) b: 45 31 ed xor %r13d,%r13d e: 45 31 c0 xor %r8d,%r8d 11: 31 ff xor %edi,%edi 13: 89 44 24 14 mov %eax,0x14(%rsp) 17: 4c 03 8b 90 01 00 00 add 0x190(%rbx),%r9 1e: eb 04 jmp 0x24 20: 39 ca cmp %ecx,%edx 22: 73 37 jae 0x5b 24: 4d 8b 39 mov (%r9),%r15 27: 83 c7 01 add $0x1,%edi 2a:* 49 8b 17 mov (%r15),%rdx <-- trapping instruction 2d: 49 89 11 mov %rdx,(%r9) 30: 41 8b 57 28 mov 0x28(%r15),%edx 34: 45 8b 5f 34 mov 0x34(%r15),%r11d 38: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 3f: 49 rex.WB Code starting with the faulting instruction =========================================== 0: 49 8b 17 mov (%r15),%rdx 3: 49 89 11 mov %rdx,(%r9) 6: 41 8b 57 28 mov 0x28(%r15),%edx a: 45 8b 5f 34 mov 0x34(%r15),%r11d e: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 15: 49 rex.WB [ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000 [ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 [ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000 [ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 [ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [ 70.724561] CS: 0010 DS: 0000 ES: 0000 C ---truncated---


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix uaf in l2cap_connect [Syzbot reported] BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54 CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Workqueue: hci2 hci_rx_work Call Trace: <TASK> __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline] l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline] l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825 l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514 hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline] hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ... Freed by task 5245: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:579 poison_slab_object+0xf7/0x160 mm/kasan/common.c:240 __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2256 [inline] slab_free mm/slub.c:4477 [inline] kfree+0x12a/0x3b0 mm/slub.c:4598 l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline] kref_put include/linux/kref.h:65 [inline] l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline] l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802 l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241 hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline] hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265 hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583 abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917 hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice The km.state is not checked in driver's delayed work. When xfrm_state_check_expire() is called, the state can be reset to XFRM_STATE_EXPIRED, even if it is XFRM_STATE_DEAD already. This happens when xfrm state is deleted, but not freed yet. As __xfrm_state_delete() is called again in xfrm timer, the following crash occurs. To fix this issue, skip xfrm_state_check_expire() if km.state is not XFRM_STATE_VALID. Oops: general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP CPU: 5 UID: 0 PID: 7448 Comm: kworker/u102:2 Not tainted 6.11.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5e_ipsec: eth%d mlx5e_ipsec_handle_sw_limits [mlx5_core] RIP: 0010:__xfrm_state_delete+0x3d/0x1b0 Code: 0f 84 8b 01 00 00 48 89 fd c6 87 c8 00 00 00 05 48 8d bb 40 10 00 00 e8 11 04 1a 00 48 8b 95 b8 00 00 00 48 8b 85 c0 00 00 00 <48> 89 42 08 48 89 10 48 8b 55 10 48 b8 00 01 00 00 00 00 ad de 48 RSP: 0018:ffff88885f945ec8 EFLAGS: 00010246 RAX: dead000000000122 RBX: ffffffff82afa940 RCX: 0000000000000036 RDX: dead000000000100 RSI: 0000000000000000 RDI: ffffffff82afb980 RBP: ffff888109a20340 R08: ffff88885f945ea0 R09: 0000000000000000 R10: 0000000000000000 R11: ffff88885f945ff8 R12: 0000000000000246 R13: ffff888109a20340 R14: ffff88885f95f420 R15: ffff88885f95f400 FS: 0000000000000000(0000) GS:ffff88885f940000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2163102430 CR3: 00000001128d6001 CR4: 0000000000370eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> ? die_addr+0x33/0x90 ? exc_general_protection+0x1a2/0x390 ? asm_exc_general_protection+0x22/0x30 ? __xfrm_state_delete+0x3d/0x1b0 ? __xfrm_state_delete+0x2f/0x1b0 xfrm_timer_handler+0x174/0x350 ? __xfrm_state_delete+0x1b0/0x1b0 __hrtimer_run_queues+0x121/0x270 hrtimer_run_softirq+0x88/0xd0 handle_softirqs+0xcc/0x270 do_softirq+0x3c/0x50 </IRQ> <TASK> __local_bh_enable_ip+0x47/0x50 mlx5e_ipsec_handle_sw_limits+0x7d/0x90 [mlx5_core] process_one_work+0x137/0x2d0 worker_thread+0x28d/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 </TASK>


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: static_call: Replace pointless WARN_ON() in static_call_module_notify() static_call_module_notify() triggers a WARN_ON(), when memory allocation fails in __static_call_add_module(). That's not really justified, because the failure case must be correctly handled by the well known call chain and the error code is passed through to the initiating userspace application. A memory allocation fail is not a fatal problem, but the WARN_ON() takes the machine out when panic_on_warn is set. Replace it with a pr_warn().


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: ACPI: battery: Fix possible crash when unregistering a battery hook When a battery hook returns an error when adding a new battery, then the battery hook is automatically unregistered. However the battery hook provider cannot know that, so it will later call battery_hook_unregister() on the already unregistered battery hook, resulting in a crash. Fix this by using the list head to mark already unregistered battery hooks as already being unregistered so that they can be ignored by battery_hook_unregister().


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix null-ptr-deref when journal load failed. During the mounting process, if journal_reset() fails because of too short journal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer. Subsequently, ocfs2_journal_shutdown() calls jbd2_journal_flush()->jbd2_cleanup_journal_tail()-> __jbd2_update_log_tail()->jbd2_journal_update_sb_log_tail() ->lock_buffer(journal->j_sb_buffer), resulting in a null-pointer dereference error. To resolve this issue, we should check the JBD2_LOADED flag to ensure the journal was properly loaded. Additionally, use journal instead of osb->journal directly to simplify the code.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: ocfs2: reserve space for inline xattr before attaching reflink tree One of our customers reported a crash and a corrupted ocfs2 filesystem. The crash was due to the detection of corruption. Upon troubleshooting, the fsck -fn output showed the below corruption [EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record, but fsck believes the largest valid value is 227. Clamp the next record value? n The stat output from the debugfs.ocfs2 showed the following corruption where the "Next Free Rec:" had overshot the "Count:" in the root metadata block. Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856) FS Generation: 904309833 (0x35e6ac49) CRC32: 00000000 ECC: 0000 Type: Regular Attr: 0x0 Flags: Valid Dynamic Features: (0x16) HasXattr InlineXattr Refcounted Extended Attributes Block: 0 Extended Attributes Inline Size: 256 User: 0 (root) Group: 0 (root) Size: 281320357888 Links: 1 Clusters: 141738 ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024 atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024 mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024 dtime: 0x0 -- Wed Dec 31 17:00:00 1969 Refcount Block: 2777346 Last Extblk: 2886943 Orphan Slot: 0 Sub Alloc Slot: 0 Sub Alloc Bit: 14 Tree Depth: 1 Count: 227 Next Free Rec: 230 ## Offset Clusters Block# 0 0 2310 2776351 1 2310 2139 2777375 2 4449 1221 2778399 3 5670 731 2779423 4 6401 566 2780447 ....... .... ....... ....... .... ....... The issue was in the reflink workfow while reserving space for inline xattr. The problematic function is ocfs2_reflink_xattr_inline(). By the time this function is called the reflink tree is already recreated at the destination inode from the source inode. At this point, this function reserves space for inline xattrs at the destination inode without even checking if there is space at the root metadata block. It simply reduces the l_count from 243 to 227 thereby making space of 256 bytes for inline xattr whereas the inode already has extents beyond this index (in this case up to 230), thereby causing corruption. The fix for this is to reserve space for inline metadata at the destination inode before the reflink tree gets recreated. The customer has verified the fix.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: <TASK> add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corrupt when updating journal superblock fails") to make jbd2_cleanup_journal_tail return the correct error code.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: ext4: fix timer use-after-free on failed mount Syzbot has found an ODEBUG bug in ext4_fill_super The del_timer_sync function cancels the s_err_report timer, which reminds about filesystem errors daily. We should guarantee the timer is no longer active before kfree(sbi). When filesystem mounting fails, the flow goes to failed_mount3, where an error occurs when ext4_stop_mmpd is called, causing a read I/O failure. This triggers the ext4_handle_error function that ultimately re-arms the timer, leaving the s_err_report timer active before kfree(sbi) is called. Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: media: i2c: ar0521: Use cansleep version of gpiod_set_value() If we use GPIO reset from I2C port expander, we must use *_cansleep() variant of GPIO functions. This was not done in ar0521_power_on()/ar0521_power_off() functions. Let's fix that. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x74/0x7c Modules linked in: CPU: 0 PID: 11 Comm: kworker/u16:0 Not tainted 6.10.0 #53 Hardware name: Diasom DS-RK3568-SOM-EVB (DT) Workqueue: events_unbound deferred_probe_work_func pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : gpiod_set_value+0x74/0x7c lr : ar0521_power_on+0xcc/0x290 sp : ffffff8001d7ab70 x29: ffffff8001d7ab70 x28: ffffff80027dcc90 x27: ffffff8003c82000 x26: ffffff8003ca9250 x25: ffffffc080a39c60 x24: ffffff8003ca9088 x23: ffffff8002402720 x22: ffffff8003ca9080 x21: ffffff8003ca9088 x20: 0000000000000000 x19: ffffff8001eb2a00 x18: ffffff80efeeac80 x17: 756d2d6332692f30 x16: 0000000000000000 x15: 0000000000000000 x14: ffffff8001d91d40 x13: 0000000000000016 x12: ffffffc080e98930 x11: ffffff8001eb2880 x10: 0000000000000890 x9 : ffffff8001d7a9f0 x8 : ffffff8001d92570 x7 : ffffff80efeeac80 x6 : 000000003fc6e780 x5 : ffffff8001d91c80 x4 : 0000000000000002 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: gpiod_set_value+0x74/0x7c ar0521_power_on+0xcc/0x290 ...


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package() ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0 ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will cause NULL pointer dereference later. [ rjw: Subject and changelog edits ]


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: mailbox: bcm2835: Fix timeout during suspend mode During noirq suspend phase the Raspberry Pi power driver suffer of firmware property timeouts. The reason is that the IRQ of the underlying BCM2835 mailbox is disabled and rpi_firmware_property_list() will always run into a timeout [1]. Since the VideoCore side isn't consider as a wakeup source, set the IRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled during suspend-resume cycle. [1] PM: late suspend of devices complete after 1.754 msecs WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x204/0x22c Firmware transaction 0x00028001 timeout Modules linked in: CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x44 dump_stack_lvl from __warn+0x88/0xec __warn from warn_slowpath_fmt+0x7c/0xb0 warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c rpi_firmware_property_list from rpi_firmware_property+0x68/0x8c rpi_firmware_property from rpi_firmware_set_power+0x54/0xc0 rpi_firmware_set_power from _genpd_power_off+0xe4/0x148 _genpd_power_off from genpd_sync_power_off+0x7c/0x11c genpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0 genpd_finish_suspend from dpm_run_callback+0x78/0xd0 dpm_run_callback from device_suspend_noirq+0xc0/0x238 device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168 dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac suspend_devices_and_enter from pm_suspend+0x254/0x2e4 pm_suspend from state_store+0xa8/0xd4 state_store from kernfs_fop_write_iter+0x154/0x1a0 kernfs_fop_write_iter from vfs_write+0x12c/0x184 vfs_write from ksys_write+0x78/0xc0 ksys_write from ret_fast_syscall+0x0/0x54 Exception stack(0xcc93dfa8 to 0xcc93dff0) [...] PM: noirq suspend of devices complete after 3095.584 msecs


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove unreasonable unlock in ocfs2_read_blocks Patch series "Misc fixes for ocfs2_read_blocks", v5. This series contains 2 fixes for ocfs2_read_blocks(). The first patch fix the issue reported by syzbot, which detects bad unlock balance in ocfs2_read_blocks(). The second patch fixes an issue reported by Heming Zhao when reviewing above fix. This patch (of 2): There was a lock release before exiting, so remove the unreasonable unlock.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: ocfs2: cancel dqi_sync_work before freeing oinfo ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled: ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqi_sync_work first. BTW, return status instead of -1 when .read_file_info fails.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

** REJECT ** This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 color transformation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Deallocate DML memory if allocation fails [Why] When DC state create DML memory allocation fails, memory is not deallocated subsequently, resulting in uninitialized structure that is not NULL. [How] Deallocate memory if DML memory allocation fails.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: r8169: add tally counter fields added with RTL8125 RTL8125 added fields to the tally counter, what may result in the chip dma'ing these new fields to unallocated memory. Therefore make sure that the allocated memory area is big enough to hold all of the tally counter values, even if we use only parts of it.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: NFSD: Limit the number of concurrent async COPY operations Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector. Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit. An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy. If there is need to make the mechanism more sophisticated, we can visit that in future patches.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: media: venus: fix use after free bug in venus_remove due to race condition in venus_probe, core->work is bound with venus_sys_error_handler, which is used to handle error. The code use core->sys_err_done to make sync work. The core->work is started in venus_event_notify. If we call venus_remove, there might be an unfished work. The possible sequence is as follows: CPU0 CPU1 |venus_sys_error_handler venus_remove | hfi_destroy | venus_hfi_destroy | kfree(hdev); | |hfi_reinit |venus_hfi_queues_reinit |//use hdev Fix it by canceling the work in venus_remove.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: aoe: fix the potential use-after-free problem in more places For fixing CVE-2023-6270, f98364e92662 ("aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts") makes tx() calling dev_put() instead of doing in aoecmd_cfg_pkts(). It avoids that the tx() runs into use-after-free. Then Nicolai Stange found more places in aoe have potential use-after-free problem with tx(). e.g. revalidate(), aoecmd_ata_rw(), resend(), probe() and aoecmd_cfg_rsp(). Those functions also use aoenet_xmit() to push packet to tx queue. So they should also use dev_hold() to increase the refcnt of skb->dev. On the other hand, moving dev_put() to tx() causes that the refcnt of skb->dev be reduced to a negative value, because corresponding dev_hold() are not called in revalidate(), aoecmd_ata_rw(), resend(), probe(), and aoecmd_cfg_rsp(). This patch fixed this issue.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex. This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks. Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: platform/x86: x86-android-tablets: Fix use after free on platform_device_register() errors x86_android_tablet_remove() frees the pdevs[] array, so it should not be used after calling x86_android_tablet_remove(). When platform_device_register() fails, store the pdevs[x] PTR_ERR() value into the local ret variable before calling x86_android_tablet_remove() to avoid using pdevs[] after it has been freed.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer Pass pointer reference to amdgpu_bo_unref to clear the correct pointer, otherwise amdgpu_bo_unref clear the local variable, the original pointer not set to NULL, this could cause use-after-free bug.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

** REJECT ** This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: tipc: guard against string buffer overrun Smatch reports that copying media_name and if_name to name_parts may overwrite the destination. .../bearer.c:166 bearer_name_validate() error: strcpy() 'media_name' too large for 'name_parts->media_name' (32 vs 16) .../bearer.c:167 bearer_name_validate() error: strcpy() 'if_name' too large for 'name_parts->if_name' (1010102 vs 16) This does seem to be the case so guard against this possibility by using strscpy() and failing if truncation occurs. Introduced by commit b97bf3fd8f6a ("[TIPC] Initial merge") Compile tested only.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: cifs: Fix buffer overflow when parsing NFS reparse points ReparseDataLength is sum of the InodeType size and DataBuffer size. So to get DataBuffer size it is needed to subtract InodeType's size from ReparseDataLength. Function cifs_strndup_from_utf16() is currentlly accessing buf->DataBuffer at position after the end of the buffer because it does not subtract InodeType size from the length. Fix this problem and correctly subtract variable len. Member InodeType is present only when reparse buffer is large enough. Check for ReparseDataLength before accessing InodeType to prevent another invalid memory access. Major and minor rdev values are present also only when reparse buffer is large enough. Check for reparse buffer size before calling reparse_mkdev().


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc() In mlx5e_tir_builder_alloc() kvzalloc() may return NULL which is dereferenced on the next line in a reference to the modify field. Found by Linux Verification Center (linuxtesting.org) with SVACE.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix error path in multi-packet WQE transmit Remove the erroneous unmap in case no DMA mapping was established The multi-packet WQE transmit code attempts to obtain a DMA mapping for the skb. This could fail, e.g. under memory pressure, when the IOMMU driver just can't allocate more memory for page tables. While the code tries to handle this in the path below the err_unmap label it erroneously unmaps one entry from the sq's FIFO list of active mappings. Since the current map attempt failed this unmap is removing some random DMA mapping that might still be required. If the PCI function now presents that IOVA, the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI function in error state. The erroneous behavior was seen in a stress-test environment that created memory pressure.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: static_call: Handle module init failure correctly in static_call_del_module() Module insertion invokes static_call_add_module() to initialize the static calls in a module. static_call_add_module() invokes __static_call_init(), which allocates a struct static_call_mod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain. If that allocation fails the function returns with an error code and the module core invokes static_call_del_module() to clean up eventually added static_call_mod entries. This works correctly, when all keys used by the module were converted over to a module chain before the failure. If not then static_call_del_module() causes a #GP as it blindly assumes that key::mods points to a valid struct static_call_mod. The problem is that key::mods is not a individual struct member of struct static_call_key, it's part of a union to save space: union { /* bit 0: 0 = mods, 1 = sites */ unsigned long type; struct static_call_mod *mods; struct static_call_site *sites; }; key::sites is a pointer to the list of built-in usage sites of the static call. The type of the pointer is differentiated by bit 0. A mods pointer has the bit clear, the sites pointer has the bit set. As static_call_del_module() blidly assumes that the pointer is a valid static_call_mod type, it fails to check for this failure case and dereferences the pointer to the list of built-in call sites, which is obviously bogus. Cure it by checking whether the key has a sites or a mods pointer. If it's a sites pointer then the key is not to be touched. As the sites are walked in the same order as in __static_call_init() the site walk can be terminated because all subsequent sites have not been touched by the init code due to the error exit. If it was converted before the allocation fail, then the inner loop which searches for a module match will find nothing. A fail in the second allocation in __static_call_init() is harmless and does not require special treatment. The first allocation succeeded and converted the key to a module chain. That first entry has mod::mod == NULL and mod::next == NULL, so the inner loop of static_call_del_module() will neither find a module match nor a module chain. The next site in the walk was either already converted, but can't match the module, or it will exit the outer loop because it has a static_call_site pointer and not a static_call_mod pointer.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: ALSA: asihpi: Fix potential OOB array access ASIHPI driver stores some values in the static array upon a response from the driver, and its index depends on the firmware. We shouldn't trust it blindly. This patch adds a sanity check of the array index to fit in the array size.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_cmd_802_11_scan_ext() Replace one-element array with a flexible-array member in `struct host_cmd_ds_802_11_scan_ext`. With this, fix the following warning: elo 16 17:51:58 surfacebook kernel: ------------[ cut here ]------------ elo 16 17:51:58 surfacebook kernel: memcpy: detected field-spanning write (size 243) of single field "ext_scan->tlv_buffer" at drivers/net/wireless/marvell/mwifiex/scan.c:2239 (size 1) elo 16 17:51:58 surfacebook kernel: WARNING: CPU: 0 PID: 498 at drivers/net/wireless/marvell/mwifiex/scan.c:2239 mwifiex_cmd_802_11_scan_ext+0x83/0x90 [mwifiex]


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: exfat: fix memory leak in exfat_load_bitmap() If the first directory entry in the root directory is not a bitmap directory entry, 'bh' will not be released and reassigned, which will cause a memory leak.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: ext4: dax: fix overflowing extents beyond inode size when partially writing The dax_iomap_rw() does two things in each iteration: map written blocks and copy user data to blocks. If the process is killed by user(See signal handling in dax_iomap_iter()), the copied data will be returned and added on inode size, which means that the length of written extents may exceed the inode size, then fsck will fail. An example is given as: dd if=/dev/urandom of=file bs=4M count=1 dax_iomap_rw iomap_iter // round 1 ext4_iomap_begin ext4_iomap_alloc // allocate 0~2M extents(written flag) dax_iomap_iter // copy 2M data iomap_iter // round 2 iomap_iter_advance iter->pos += iter->processed // iter->pos = 2M ext4_iomap_begin ext4_iomap_alloc // allocate 2~4M extents(written flag) dax_iomap_iter fatal_signal_pending done = iter->pos - iocb->ki_pos // done = 2M ext4_handle_inode_extension ext4_update_inode_size // inode size = 2M fsck reports: Inode 13, i_size is 2097152, should be 4194304. Fix? Fix the problem by truncating extents if the written length is smaller than expected.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: x86/mm/ident_map: Use gbpages only where full GB page should be mapped. When ident_pud_init() uses only GB pages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. This can include a lot of extra address space past that requested, including areas marked reserved by the BIOS. That allows processor speculation into reserved regions, that on UV systems can cause system halts. Only use GB pages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request. No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full GB page. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: kthread: unpark only parked kthread Calling into kthread unparking unconditionally is mostly harmless when the kthread is already unparked. The wake up is then simply ignored because the target is not in TASK_PARKED state. However if the kthread is per CPU, the wake up is preceded by a call to kthread_bind() which expects the task to be inactive and in TASK_PARKED state, which obviously isn't the case if it is unparked. As a result, calling kthread_stop() on an unparked per-cpu kthread triggers such a warning: WARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525 <TASK> kthread_stop+0x17a/0x630 kernel/kthread.c:707 destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810 wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257 netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693 default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769 ops_exit_list net/core/net_namespace.c:178 [inline] cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd70 kernel/workqueue.c:3393 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Fix this with skipping unecessary unparking while stopping a kthread.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count() This patch addresses an issue with improper reference count handling in the ice_sriov_set_msix_vec_count() function. First, the function calls ice_get_vf_by_id(), which increments the reference count of the vf pointer. If the subsequent call to ice_get_vf_vsi() fails, the function currently returns an error without decrementing the reference count of the vf pointer, leading to a reference count leak. The correct behavior, as implemented in this patch, is to decrement the reference count using ice_put_vf(vf) before returning an error when vsi is NULL. Second, the function calls ice_sriov_get_irqs(), which sets vf->first_vector_idx. If this call returns a negative value, indicating an error, the function returns an error without decrementing the reference count of the vf pointer, resulting in another reference count leak. The patch addresses this by adding a call to ice_put_vf(vf) before returning an error when vf->first_vector_idx < 0. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and identifying potential mismanagement of reference counts. In this case, the tool flagged the missing decrement operation as a potential issue, leading to this patch.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins() This patch addresses a reference count handling issue in the ice_dpll_init_rclk_pins() function. The function calls ice_dpll_get_pins(), which increments the reference count of the relevant resources. However, if the condition WARN_ON((!vsi || !vsi->netdev)) is met, the function currently returns an error without properly releasing the resources acquired by ice_dpll_get_pins(), leading to a reference count leak. To resolve this, the check has been moved to the top of the function. This ensures that the function verifies the state before any resources are acquired, avoiding the need for additional resource management in the error path. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and detecting potential issues where resources are not properly managed. In this case, the tool flagged the missing release operation as a potential problem, which led to the development of this patch.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: device-dax: correct pgoff align in dax_set_mapping() pgoff should be aligned using ALIGN_DOWN() instead of ALIGN(). Otherwise, vmf->address not aligned to fault_size will be aligned to the next alignment, that can result in memory failure getting the wrong address. It's a subtle situation that only can be observed in page_mapped_in_vma() after the page is page fault handled by dev_dax_huge_fault. Generally, there is little chance to perform page_mapped_in_vma in dev-dax's page unless in specific error injection to the dax device to trigger an MCE - memory-failure. In that case, page_mapped_in_vma() will be triggered to determine which task is accessing the failure address and kill that task in the end. We used self-developed dax device (which is 2M aligned mapping) , to perform error injection to random address. It turned out that error injected to non-2M-aligned address was causing endless MCE until panic. Because page_mapped_in_vma() kept resulting wrong address and the task accessing the failure address was never killed properly: [ 3783.719419] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.049006] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.049190] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.448042] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.448186] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.792026] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.792179] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.162502] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.162633] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.461116] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.461247] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.764730] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.764859] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.042128] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.042259] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.464293] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.464423] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.818090] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.818217] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3787.085297] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3787.085424] Memory failure: 0x200c9742: recovery action for dax page: Recovered It took us several weeks to pinpoint this problem, but we eventually used bpftrace to trace the page fault and mce address and successfully identified the issue. Joao added: ; Likely we never reproduce in production because we always pin : device-dax regions in the region align they provide (Qemu does : similarly with prealloc in hugetlb/file backed memory). I think this : bug requires that we touch *unpinned* device-dax regions unaligned to : the device-dax selected alignment (page size i.e. 4K/2M/1G)


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: net: phy: Remove LED entry from LEDs list on unregister Commit c938ab4da0eb ("net: phy: Manual remove LEDs to ensure correct ordering") correctly fixed a problem with using devm_ but missed removing the LED entry from the LEDs list. This cause kernel panic on specific scenario where the port for the PHY is torn down and up and the kmod for the PHY is removed. On setting the port down the first time, the assosiacted LEDs are correctly unregistered. The associated kmod for the PHY is now removed. The kmod is now added again and the port is now put up, the associated LED are registered again. On putting the port down again for the second time after these step, the LED list now have 4 elements. With the first 2 already unregistered previously and the 2 new one registered again. This cause a kernel panic as the first 2 element should have been removed. Fix this by correctly removing the element when LED is unregistered.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: net: Fix an unsafe loop on the list The kernel may crash when deleting a genetlink family if there are still listeners for that family: Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0 LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0 Call Trace: __netlink_clear_multicast_users+0x74/0xc0 genl_unregister_family+0xd4/0x2d0 Change the unsafe loop on the list to a safe one, because inside the loop there is an element removal from this list.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: scsi: fnic: Move flush_work initialization out of if block After commit 379a58caa199 ("scsi: fnic: Move fnic_fnic_flush_tx() to a work queue"), it can happen that a work item is sent to an uninitialized work queue. This may has the effect that the item being queued is never actually queued, and any further actions depending on it will not proceed. The following warning is observed while the fnic driver is loaded: kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 kernel: <IRQ> kernel: queue_work_on+0x3a/0x50 kernel: fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: __handle_irq_event_percpu+0x36/0x1a0 kernel: handle_irq_event_percpu+0x30/0x70 kernel: handle_irq_event+0x34/0x60 kernel: handle_edge_irq+0x7e/0x1a0 kernel: __common_interrupt+0x3b/0xb0 kernel: common_interrupt+0x58/0xa0 kernel: </IRQ> It has been observed that this may break the rediscovery of Fibre Channel devices after a temporary fabric failure. This patch fixes it by moving the work queue initialization out of an if block in fnic_probe().


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: thermal: core: Free tzp copy along with the thermal zone The object pointed to by tz->tzp may still be accessed after being freed in thermal_zone_device_unregister(), so move the freeing of it to the point after the removal completion has been completed at which it cannot be accessed any more.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: thermal: core: Reference count the zone in thermal_zone_get_by_id() There are places in the thermal netlink code where nothing prevents the thermal zone object from going away while being accessed after it has been returned by thermal_zone_get_by_id(). To address this, make thermal_zone_get_by_id() get a reference on the thermal zone device object to be returned with the help of get_device(), under thermal_list_lock, and adjust all of its callers to this change with the help of the cleanup.h infrastructure.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Stop the active perfmon before being destroyed When running `kmscube` with one or more performance monitors enabled via `GALLIUM_HUD`, the following kernel panic can occur: [ 55.008324] Unable to handle kernel paging request at virtual address 00000000052004a4 [ 55.008368] Mem abort info: [ 55.008377] ESR = 0x0000000096000005 [ 55.008387] EC = 0x25: DABT (current EL), IL = 32 bits [ 55.008402] SET = 0, FnV = 0 [ 55.008412] EA = 0, S1PTW = 0 [ 55.008421] FSC = 0x05: level 1 translation fault [ 55.008434] Data abort info: [ 55.008442] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 55.008455] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 55.008467] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 55.008481] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001046c6000 [ 55.008497] [00000000052004a4] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 55.008525] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 55.008542] Modules linked in: rfcomm [...] vc4 v3d snd_soc_hdmi_codec drm_display_helper gpu_sched drm_shmem_helper cec drm_dma_helper drm_kms_helper i2c_brcmstb drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight [ 55.008799] CPU: 2 PID: 166 Comm: v3d_bin Tainted: G C 6.6.47+rpt-rpi-v8 #1 Debian 1:6.6.47-1+rpt1 [ 55.008824] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [ 55.008838] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 55.008855] pc : __mutex_lock.constprop.0+0x90/0x608 [ 55.008879] lr : __mutex_lock.constprop.0+0x58/0x608 [ 55.008895] sp : ffffffc080673cf0 [ 55.008904] x29: ffffffc080673cf0 x28: 0000000000000000 x27: ffffff8106188a28 [ 55.008926] x26: ffffff8101e78040 x25: ffffff8101baa6c0 x24: ffffffd9d989f148 [ 55.008947] x23: ffffffda1c2a4008 x22: 0000000000000002 x21: ffffffc080673d38 [ 55.008968] x20: ffffff8101238000 x19: ffffff8104f83188 x18: 0000000000000000 [ 55.008988] x17: 0000000000000000 x16: ffffffda1bd04d18 x15: 00000055bb08bc90 [ 55.009715] x14: 0000000000000000 x13: 0000000000000000 x12: ffffffda1bd4cbb0 [ 55.010433] x11: 00000000fa83b2da x10: 0000000000001a40 x9 : ffffffda1bd04d04 [ 55.011162] x8 : ffffff8102097b80 x7 : 0000000000000000 x6 : 00000000030a5857 [ 55.011880] x5 : 00ffffffffffffff x4 : 0300000005200470 x3 : 0300000005200470 [ 55.012598] x2 : ffffff8101238000 x1 : 0000000000000021 x0 : 0300000005200470 [ 55.013292] Call trace: [ 55.013959] __mutex_lock.constprop.0+0x90/0x608 [ 55.014646] __mutex_lock_slowpath+0x1c/0x30 [ 55.015317] mutex_lock+0x50/0x68 [ 55.015961] v3d_perfmon_stop+0x40/0xe0 [v3d] [ 55.016627] v3d_bin_job_run+0x10c/0x2d8 [v3d] [ 55.017282] drm_sched_main+0x178/0x3f8 [gpu_sched] [ 55.017921] kthread+0x11c/0x128 [ 55.018554] ret_from_fork+0x10/0x20 [ 55.019168] Code: f9400260 f1001c1f 54001ea9 927df000 (b9403401) [ 55.019776] ---[ end trace 0000000000000000 ]--- [ 55.020411] note: v3d_bin[166] exited with preempt_count 1 This issue arises because, upon closing the file descriptor (which happens when we interrupt `kmscube`), the active performance monitor is not stopped. Although all perfmons are destroyed in `v3d_perfmon_close_file()`, the active performance monitor's pointer (`v3d->active_perfmon`) is still retained. If `kmscube` is run again, the driver will attempt to stop the active performance monitor using the stale pointer in `v3d->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: slip: make slhc_remember() more robust against malicious packets syzbot found that slhc_remember() was missing checks against malicious packets [1]. slhc_remember() only checked the size of the packet was at least 20, which is not good enough. We need to make sure the packet includes the IPv4 and TCP header that are supposed to be carried. Add iph and th pointers to make the code more readable. [1] BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455 ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline] ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212 ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: ppp: fix ppp_async_encode() illegal access syzbot reported an issue in ppp_async_encode() [1] In this case, pppoe_sendmsg() is called with a zero size. Then ppp_async_encode() is called with an empty skb. BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline] ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:4092 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: igb: Do not bring the device up after non-fatal error Commit 004d25060c78 ("igb: Fix igb_down hung on surprise removal") changed igb_io_error_detected() to ignore non-fatal pcie errors in order to avoid hung task that can happen when igb_down() is called multiple times. This caused an issue when processing transient non-fatal errors. igb_io_resume(), which is called after igb_io_error_detected(), assumes that device is brought down by igb_io_error_detected() if the interface is up. This resulted in panic with stacktrace below. [ T3256] igb 0000:09:00.0 haeth0: igb: haeth0 NIC Link is Down [ T292] pcieport 0000:00:1c.5: AER: Uncorrected (Non-Fatal) error received: 0000:09:00.0 [ T292] igb 0000:09:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID) [ T292] igb 0000:09:00.0: device [8086:1537] error status/mask=00004000/00000000 [ T292] igb 0000:09:00.0: [14] CmpltTO [ 200.105524,009][ T292] igb 0000:09:00.0: AER: TLP Header: 00000000 00000000 00000000 00000000 [ T292] pcieport 0000:00:1c.5: AER: broadcast error_detected message [ T292] igb 0000:09:00.0: Non-correctable non-fatal error reported. [ T292] pcieport 0000:00:1c.5: AER: broadcast mmio_enabled message [ T292] pcieport 0000:00:1c.5: AER: broadcast resume message [ T292] ------------[ cut here ]------------ [ T292] kernel BUG at net/core/dev.c:6539! [ T292] invalid opcode: 0000 [#1] PREEMPT SMP [ T292] RIP: 0010:napi_enable+0x37/0x40 [ T292] Call Trace: [ T292] <TASK> [ T292] ? die+0x33/0x90 [ T292] ? do_trap+0xdc/0x110 [ T292] ? napi_enable+0x37/0x40 [ T292] ? do_error_trap+0x70/0xb0 [ T292] ? napi_enable+0x37/0x40 [ T292] ? napi_enable+0x37/0x40 [ T292] ? exc_invalid_op+0x4e/0x70 [ T292] ? napi_enable+0x37/0x40 [ T292] ? asm_exc_invalid_op+0x16/0x20 [ T292] ? napi_enable+0x37/0x40 [ T292] igb_up+0x41/0x150 [ T292] igb_io_resume+0x25/0x70 [ T292] report_resume+0x54/0x70 [ T292] ? report_frozen_detected+0x20/0x20 [ T292] pci_walk_bus+0x6c/0x90 [ T292] ? aer_print_port_info+0xa0/0xa0 [ T292] pcie_do_recovery+0x22f/0x380 [ T292] aer_process_err_devices+0x110/0x160 [ T292] aer_isr+0x1c1/0x1e0 [ T292] ? disable_irq_nosync+0x10/0x10 [ T292] irq_thread_fn+0x1a/0x60 [ T292] irq_thread+0xe3/0x1a0 [ T292] ? irq_set_affinity_notifier+0x120/0x120 [ T292] ? irq_affinity_notify+0x100/0x100 [ T292] kthread+0xe2/0x110 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork+0x2d/0x50 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork_asm+0x11/0x20 [ T292] </TASK> To fix this issue igb_io_resume() checks if the interface is running and the device is not down this means igb_io_error_detected() did not bring the device down and there is no need to bring it up.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: i40e: Fix macvlan leak by synchronizing access to mac_filter_hash This patch addresses a macvlan leak issue in the i40e driver caused by concurrent access to vsi->mac_filter_hash. The leak occurs when multiple threads attempt to modify the mac_filter_hash simultaneously, leading to inconsistent state and potential memory leaks. To fix this, we now wrap the calls to i40e_del_mac_filter() and zeroing vf->default_lan_addr.addr with spin_lock/unlock_bh(&vsi->mac_filter_hash_lock), ensuring atomic operations and preventing concurrent access. Additionally, we add lockdep_assert_held(&vsi->mac_filter_hash_lock) in i40e_add_mac_filter() to help catch similar issues in the future. Reproduction steps: 1. Spawn VFs and configure port vlan on them. 2. Trigger concurrent macvlan operations (e.g., adding and deleting portvlan and/or mac filters). 3. Observe the potential memory leak and inconsistent state in the mac_filter_hash. This synchronization ensures the integrity of the mac_filter_hash and prevents the described leak.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: ice: Fix increasing MSI-X on VF Increasing MSI-X value on a VF leads to invalid memory operations. This is caused by not reallocating some arrays. Reproducer: modprobe ice echo 0 > /sys/bus/pci/devices/$PF_PCI/sriov_drivers_autoprobe echo 1 > /sys/bus/pci/devices/$PF_PCI/sriov_numvfs echo 17 > /sys/bus/pci/devices/$VF0_PCI/sriov_vf_msix_count Default MSI-X is 16, so 17 and above triggers this issue. KASAN reports: BUG: KASAN: slab-out-of-bounds in ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] Read of size 8 at addr ffff8888b937d180 by task bash/28433 (...) Call Trace: (...) ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] kasan_report+0xed/0x120 ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_cfg_def+0x3360/0x4770 [ice] ? mutex_unlock+0x83/0xd0 ? __pfx_ice_vsi_cfg_def+0x10/0x10 [ice] ? __pfx_ice_remove_vsi_lkup_fltr+0x10/0x10 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vf_reconfig_vsi+0x114/0x210 [ice] ice_sriov_set_msix_vec_count+0x3d0/0x960 [ice] sriov_vf_msix_count_store+0x21c/0x300 (...) Allocated by task 28201: (...) ice_vsi_cfg_def+0x1c8e/0x4770 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vsi_setup+0x179/0xa30 [ice] ice_sriov_configure+0xcaa/0x1520 [ice] sriov_numvfs_store+0x212/0x390 (...) To fix it, use ice_vsi_rebuild() instead of ice_vf_reconfig_vsi(). This causes the required arrays to be reallocated taking the new queue count into account (ice_vsi_realloc_stat_arrays()). Set req_txq and req_rxq before ice_vsi_rebuild(), so that realloc uses the newly set queue count. Additionally, ice_vsi_rebuild() does not remove VSI filters (ice_fltr_remove_all()), so ice_vf_init_host_cfg() is no longer necessary.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change rfcomm_sk_state_change attempts to use sock_lock so it must never be called with it locked but rfcomm_sock_ioctl always attempt to lock it causing the following trace: ====================================================== WARNING: possible circular locking dependency detected 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted ------------------------------------------------------ syz-executor386/5093 is trying to acquire lock: ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline] ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73 but task is already holding lock: ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: netfilter: br_netfilter: fix panic with metadata_dst skb Fix a kernel panic in the br_netfilter module when sending untagged traffic via a VxLAN device. This happens during the check for fragmentation in br_nf_dev_queue_xmit. It is dependent on: 1) the br_netfilter module being loaded; 2) net.bridge.bridge-nf-call-iptables set to 1; 3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port; 4) untagged frames with size higher than the VxLAN MTU forwarded/flooded When forwarding the untagged packet to the VxLAN bridge port, before the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type of dst, i.e., skb_valid_dst(skb) is false, and metadata->dst.dev is NULL. Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a check for frames that needs to be fragmented: frames with higher MTU than the VxLAN device end up calling br_nf_ip_fragment, which in turns call ip_skb_dst_mtu. The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst with valid dst->dev, thus the crash. This case was never supported in the first place, so drop the packet instead. PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data. [ 176.291791] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000110 [ 176.292101] Mem abort info: [ 176.292184] ESR = 0x0000000096000004 [ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits [ 176.292530] SET = 0, FnV = 0 [ 176.292709] EA = 0, S1PTW = 0 [ 176.292862] FSC = 0x04: level 0 translation fault [ 176.293013] Data abort info: [ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000 [ 176.294166] [0000000000000110] pgd=0000000000000000, p4d=0000000000000000 [ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth br_netfilter bridge stp llc ipv6 crct10dif_ce [ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted 6.8.0-rc3-g5b3fbd61b9d1 #2 [ 176.296314] Hardware name: linux,dummy-virt (DT) [ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter] [ 176.297636] sp : ffff800080003630 [ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27: ffff6828c49ad9f8 [ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24: 00000000000003e8 [ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21: ffff6828c3b16d28 [ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18: 0000000000000014 [ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15: 0000000095744632 [ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12: ffffb7e137926a70 [ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 : 0000000000000000 [ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 : f20e0100bebafeca [ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 : 0000000000000000 [ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 : ffff6828c7f918f0 [ 176.300889] Call trace: [ 176.301123] br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.301411] br_nf_post_routing+0x2a8/0x3e4 [br_netfilter] [ 176.301703] nf_hook_slow+0x48/0x124 [ 176.302060] br_forward_finish+0xc8/0xe8 [bridge] [ 176.302371] br_nf_hook_thresh+0x124/0x134 [br_netfilter] [ 176.302605] br_nf_forward_finish+0x118/0x22c [br_netfilter] [ 176.302824] br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter] [ 176.303136] br_nf_forward+0x2b8/0x4e0 [br_netfilter] [ 176.303359] nf_hook_slow+0x48/0x124 [ 176.303 ---truncated---


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies() On the node of an NFS client, some files saved in the mountpoint of the NFS server were copied to another location of the same NFS server. Accidentally, the nfs42_complete_copies() got a NULL-pointer dereference crash with the following syslog: [232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 [232066.588586] Mem abort info: [232066.588701] ESR = 0x0000000096000007 [232066.588862] EC = 0x25: DABT (current EL), IL = 32 bits [232066.589084] SET = 0, FnV = 0 [232066.589216] EA = 0, S1PTW = 0 [232066.589340] FSC = 0x07: level 3 translation fault [232066.589559] Data abort info: [232066.589683] ISV = 0, ISS = 0x00000007 [232066.589842] CM = 0, WnR = 0 [232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400 [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000 [232066.590757] Internal error: Oops: 96000007 [#1] SMP [232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2 [232066.591052] vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1 [232066.597356] Hardware name: Great Wall .\x93\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06 [232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4] [232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4] [232066.598595] sp : ffff8000f568fc70 [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000 [232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001 [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050 [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000 [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000 [232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6 [232066.600498] x11: 00000000000000 ---truncated---


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix UAF in async decryption Doing an async decryption (large read) crashes with a slab-use-after-free way down in the crypto API. Reproducer: # mount.cifs -o ...,seal,esize=1 //srv/share /mnt # dd if=/mnt/largefile of=/dev/null ... [ 194.196391] ================================================================== [ 194.196844] BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xc1/0x110 [ 194.197269] Read of size 8 at addr ffff888112bd0448 by task kworker/u77:2/899 [ 194.197707] [ 194.197818] CPU: 12 UID: 0 PID: 899 Comm: kworker/u77:2 Not tainted 6.11.0-lku-00028-gfca3ca14a17a-dirty #43 [ 194.198400] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 [ 194.199046] Workqueue: smb3decryptd smb2_decrypt_offload [cifs] [ 194.200032] Call Trace: [ 194.200191] <TASK> [ 194.200327] dump_stack_lvl+0x4e/0x70 [ 194.200558] ? gf128mul_4k_lle+0xc1/0x110 [ 194.200809] print_report+0x174/0x505 [ 194.201040] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 194.201352] ? srso_return_thunk+0x5/0x5f [ 194.201604] ? __virt_addr_valid+0xdf/0x1c0 [ 194.201868] ? gf128mul_4k_lle+0xc1/0x110 [ 194.202128] kasan_report+0xc8/0x150 [ 194.202361] ? gf128mul_4k_lle+0xc1/0x110 [ 194.202616] gf128mul_4k_lle+0xc1/0x110 [ 194.202863] ghash_update+0x184/0x210 [ 194.203103] shash_ahash_update+0x184/0x2a0 [ 194.203377] ? __pfx_shash_ahash_update+0x10/0x10 [ 194.203651] ? srso_return_thunk+0x5/0x5f [ 194.203877] ? crypto_gcm_init_common+0x1ba/0x340 [ 194.204142] gcm_hash_assoc_remain_continue+0x10a/0x140 [ 194.204434] crypt_message+0xec1/0x10a0 [cifs] [ 194.206489] ? __pfx_crypt_message+0x10/0x10 [cifs] [ 194.208507] ? srso_return_thunk+0x5/0x5f [ 194.209205] ? srso_return_thunk+0x5/0x5f [ 194.209925] ? srso_return_thunk+0x5/0x5f [ 194.210443] ? srso_return_thunk+0x5/0x5f [ 194.211037] decrypt_raw_data+0x15f/0x250 [cifs] [ 194.212906] ? __pfx_decrypt_raw_data+0x10/0x10 [cifs] [ 194.214670] ? srso_return_thunk+0x5/0x5f [ 194.215193] smb2_decrypt_offload+0x12a/0x6c0 [cifs] This is because TFM is being used in parallel. Fix this by allocating a new AEAD TFM for async decryption, but keep the existing one for synchronous READ cases (similar to what is done in smb3_calc_signature()). Also remove the calls to aead_request_set_callback() and crypto_wait_req() since it's always going to be a synchronous operation.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: fbcon: Fix a NULL pointer dereference issue in fbcon_putcs syzbot has found a NULL pointer dereference bug in fbcon. Here is the simplified C reproducer: struct param { uint8_t type; struct tiocl_selection ts; }; int main() { struct fb_con2fbmap con2fb; struct param param; int fd = open("/dev/fb1", 0, 0); con2fb.console = 0x19; con2fb.framebuffer = 0; ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); param.type = 2; param.ts.xs = 0; param.ts.ys = 0; param.ts.xe = 0; param.ts.ye = 0; param.ts.sel_mode = 0; int fd1 = open("/dev/tty1", O_RDWR, 0); ioctl(fd1, TIOCLINUX, &param); con2fb.console = 1; con2fb.framebuffer = 0; ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); return 0; } After calling ioctl(fd1, TIOCLINUX, &param), the subsequent ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb) causes the kernel to follow a different execution path: set_con2fb_map -> con2fb_init_display -> fbcon_set_disp -> redraw_screen -> hide_cursor -> clear_selection -> highlight -> invert_screen -> do_update_region -> fbcon_putcs -> ops->putcs Since ops->putcs is a NULL pointer, this leads to a kernel panic. To prevent this, we need to call set_blitting_type() within set_con2fb_map() to properly initialize ops->putcs.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before dereferencing se [WHAT & HOW] se is null checked previously in the same function, indicating it might be null; therefore, it must be checked when used again. This fixes 1 FORWARD_NULL issue reported by Coverity.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: driver core: bus: Fix double free in driver API bus_register() For bus_register(), any error which happens after kset_register() will cause that @priv are freed twice, fixed by setting @priv with NULL after the first free.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: serial: protect uart_port_dtr_rts() in uart_shutdown() too Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected "uart_port_dtr_rts(uport, false);" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition In the switchtec_ntb_add function, it can call switchtec_ntb_init_sndev function, then &sndev->check_link_status_work is bound with check_link_status_work. switchtec_ntb_link_notification may be called to start the work. If we remove the module which will call switchtec_ntb_remove to make cleanup, it will free sndev through kfree(sndev), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | check_link_status_work switchtec_ntb_remove | kfree(sndev); | | if (sndev->link_force_down) | // use sndev Fix it by ensuring that the work is canceled before proceeding with the cleanup in switchtec_ntb_remove.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: io_uring: check if we need to reschedule during overflow flush In terms of normal application usage, this list will always be empty. And if an application does overflow a bit, it'll have a few entries. However, nothing obviously prevents syzbot from running a test case that generates a ton of overflow entries, and then flushing them can take quite a while. Check for needing to reschedule while flushing, and drop our locks and do so if necessary. There's no state to maintain here as overflows always prune from head-of-list, hence it's fine to drop and reacquire the locks at the end of the loop.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race Condition In the cdns_i3c_master_probe function, &master->hj_work is bound with cdns_i3c_master_hj. And cdns_i3c_master_interrupt can call cnds_i3c_master_demux_ibis function to start the work. If we remove the module which will call cdns_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | cdns_i3c_master_hj cdns_i3c_master_remove | i3c_master_unregister(&master->base) | device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in cdns_i3c_master_remove.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Avoid null pointer deref during path establishment For RTRS path establishment, RTRS client initiates and completes con_num of connections. After establishing all its connections, the information is exchanged between the client and server through the info_req message. During this exchange, it is essential that all connections have been established, and the state of the RTRS srv path is CONNECTED. So add these sanity checks, to make sure we detect and abort process in error scenarios to avoid null pointer deref.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: bpf: Prevent tail call between progs attached to different hooks bpf progs can be attached to kernel functions, and the attached functions can take different parameters or return different return values. If prog attached to one kernel function tail calls prog attached to another kernel function, the ctx access or return value verification could be bypassed. For example, if prog1 is attached to func1 which takes only 1 parameter and prog2 is attached to func2 which takes two parameters. Since verifier assumes the bpf ctx passed to prog2 is constructed based on func2's prototype, verifier allows prog2 to access the second parameter from the bpf ctx passed to it. The problem is that verifier does not prevent prog1 from passing its bpf ctx to prog2 via tail call. In this case, the bpf ctx passed to prog2 is constructed from func1 instead of func2, that is, the assumption for ctx access verification is bypassed. Another example, if BPF LSM prog1 is attached to hook file_alloc_security, and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier knows the return value rules for these two hooks, e.g. it is legal for bpf_lsm_audit_rule_known to return positive number 1, and it is illegal for file_alloc_security to return positive number. So verifier allows prog2 to return positive number 1, but does not allow prog1 to return positive number. The problem is that verifier does not prevent prog1 from calling prog2 via tail call. In this case, prog2's return value 1 will be used as the return value for prog1's hook file_alloc_security. That is, the return value rule is bypassed. This patch adds restriction for tail call to prevent such bypasses.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: zram: free secondary algorithms names We need to kfree() secondary algorithms names when reset zram device that had multi-streams, otherwise we leak memory. [senozhatsky@chromium.org: kfree(NULL) is legal] Link: https://lkml.kernel.org/r/20240917013021.868769-1-senozhatsky@chromium.org


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: pinctrl: apple: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: Fix use-after-free in gsm_cleanup_mux BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: <TASK> gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm] __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389 update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500 __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846 __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107 __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm] ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195 ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79 __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338 __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 Allocated by task 65: gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm] gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm] gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm] gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm] tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391 tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39 flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445 process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229 worker_thread+0x3dc/0x950 kernel/workqueue.c:3391 kthread+0x2a3/0x370 kernel/kthread.c:389 ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257 Freed by task 3367: kfree+0x126/0x420 mm/slub.c:4580 gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 [Analysis] gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: parport: Proper fix for array out-of-bounds access The recent fix for array out-of-bounds accesses replaced sprintf() calls blindly with snprintf(). However, since snprintf() returns the would-be-printed size, not the actually output size, the length calculation can still go over the given limit. Use scnprintf() instead of snprintf(), which returns the actually output letters, for addressing the potential out-of-bounds access properly.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: xhci: tegra: fix checked USB2 port number If USB virtualizatoin is enabled, USB2 ports are shared between all Virtual Functions. The USB2 port number owned by an USB2 root hub in a Virtual Function may be less than total USB2 phy number supported by the Tegra XUSB controller. Using total USB2 phy number as port number to check all PORTSC values would cause invalid memory access. [ 116.923438] Unable to handle kernel paging request at virtual address 006c622f7665642f ... [ 117.213640] Call trace: [ 117.216783] tegra_xusb_enter_elpg+0x23c/0x658 [ 117.222021] tegra_xusb_runtime_suspend+0x40/0x68 [ 117.227260] pm_generic_runtime_suspend+0x30/0x50 [ 117.232847] __rpm_callback+0x84/0x3c0 [ 117.237038] rpm_suspend+0x2dc/0x740 [ 117.241229] pm_runtime_work+0xa0/0xb8 [ 117.245769] process_scheduled_works+0x24c/0x478 [ 117.251007] worker_thread+0x23c/0x328 [ 117.255547] kthread+0x104/0x1b0 [ 117.259389] ret_from_fork+0x10/0x20 [ 117.263582] Code: 54000222 f9461ae8 f8747908 b4ffff48 (f9400100)


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: vt: prevent kernel-infoleak in con_font_get() font.data may not initialize all memory spaces depending on the implementation of vc->vc_sw->con_font_get. This may cause info-leak, so to prevent this, it is safest to modify it to initialize the allocated memory space to 0, and it generally does not affect the overall performance of the system.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix multiple init when debugfs is disabled If bt_debugfs is not created successfully, which happens if either CONFIG_DEBUG_FS or CONFIG_DEBUG_FS_ALLOW_ALL is unset, then iso_init() returns early and does not set iso_inited to true. This means that a subsequent call to iso_init() will result in duplicate calls to proto_register(), bt_sock_register(), etc. With CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, the duplicate call to proto_register() triggers this BUG(): list_add double add: new=ffffffffc0b280d0, prev=ffffffffbab56250, next=ffffffffc0b280d0. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:35! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 2 PID: 887 Comm: bluetoothd Not tainted 6.10.11-1-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x9a/0xa0 ... __list_add_valid_or_report+0x9a/0xa0 proto_register+0x2b5/0x340 iso_init+0x23/0x150 [bluetooth] set_iso_socket_func+0x68/0x1b0 [bluetooth] kmem_cache_free+0x308/0x330 hci_sock_sendmsg+0x990/0x9e0 [bluetooth] __sock_sendmsg+0x7b/0x80 sock_write_iter+0x9a/0x110 do_iter_readv_writev+0x11d/0x220 vfs_writev+0x180/0x3e0 do_writev+0xca/0x100 ... This change removes the early return. The check for iso_debugfs being NULL was unnecessary, it is always NULL when iso_inited is false.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Call iso_exit() on module unload If iso_init() has been called, iso_exit() must be called on module unload. Without that, the struct proto that iso_init() registered with proto_register() becomes invalid, which could cause unpredictable problems later. In my case, with CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, loading the module again usually triggers this BUG(): list_add corruption. next->prev should be prev (ffffffffb5355fd0), but was 0000000000000068. (next=ffffffffc0a010d0). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:29! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 4159 Comm: modprobe Not tainted 6.10.11-4+bt2-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x61/0xa0 ... __list_add_valid_or_report+0x61/0xa0 proto_register+0x299/0x320 hci_sock_init+0x16/0xc0 [bluetooth] bt_init+0x68/0xd0 [bluetooth] __pfx_bt_init+0x10/0x10 [bluetooth] do_one_initcall+0x80/0x2f0 do_init_module+0x8b/0x230 __do_sys_init_module+0x15f/0x190 do_syscall_64+0x68/0x110 ...


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: ublk: don't allow user copy for unprivileged device UBLK_F_USER_COPY requires userspace to call write() on ublk char device for filling request buffer, and unprivileged device can't be trusted. So don't allow user copy for unprivileged device.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: blk-mq: setup queue ->tag_set before initializing hctx Commit 7b815817aa58 ("blk-mq: add helper for checking if one CPU is mapped to specified hctx") needs to check queue mapping via tag set in hctx's cpuhp handler. However, q->tag_set may not be setup yet when the cpuhp handler is enabled, then kernel oops is triggered. Fix the issue by setup queue tag_set before initializing hctx.


Затронутые продукты
Image SLES15-SP6-Azure-Basic:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-Azure-Standard:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC-Azure:kernel-azure-6.4.0-150600.8.17.2
Image SLES15-SP6-HPC:kernel-azure-6.4.0-150600.8.17.2

Ссылки
Уязвимость SUSE-SU-2024:3984-1