Affected: AlmaLinux:9: bpftool, AlmaLinux:9: kernel, AlmaLinux:9: kernel-64k, AlmaLinux:9: kernel-64k-core, AlmaLinux:9: kernel-64k-debug, AlmaLinux:9: kernel-64k-debug-core, AlmaLinux:9: kernel-64k-debug-devel, AlmaLinux:9: kernel-64k-debug-devel-matched, AlmaLinux:9: kernel-64k-debug-modules, AlmaLinux:9: kernel-64k-debug-modules-core and 52 more

The kernel packages contain the Linux kernel, the core of any Linux operating system.

Security Fix(es):

* kernel: efivarfs: force RO when remounting if SetVariable is not supported (CVE-2023-52463) * kernel: nfsd: fix RELEASE_LOCKOWNER (CVE-2024-26629) * kernel: mm: cachestat: fix folio read-after-free in cache walk (CVE-2024-26630) * kernel: mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again (CVE-2024-26720) * kernel: Bluetooth: af_bluetooth: Fix deadlock (CVE-2024-26886) * kernel: kprobes/x86: Use copy_from_kernel_nofault() to read from unsafe address (CVE-2024-26946) * kernel: KVM: SVM: Flush pages under kvm->lock to fix UAF in svm_register_enc_region() (CVE-2024-35791) * kernel: mm: cachestat: fix two shmem bugs (CVE-2024-35797) * kernel: x86/coco: Require seeding RNG with RDRAND on CoCo systems (CVE-2024-35875) * kernel: mm/hugetlb: fix missing hugetlb_lock for resv uncharge (CVE-2024-36000) * kernel: iommufd: Fix missing update of domains_itree after splitting iopt_area (CVE-2023-52801) * kernel: net: fix out-of-bounds access in ops_init (CVE-2024-36883) * kernel: regmap: maple: Fix cache corruption in regcache_maple_drop() (CVE-2024-36019) * kernel: usb-storage: alauda: Check whether the media is initialized (CVE-2024-38619) * kernel: net: bridge: mst: fix vlan use-after-free (CVE-2024-36979) * kernel: scsi: qedf: Ensure the copied buf is NUL terminated (CVE-2024-38559) * kernel: xhci: Handle TD clearing fo…

Affected: Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts

In the Linux kernel, the following vulnerability has been resolved:

x86: stop playing stack games in profile_pc()

The 'profile_pc()' function is used for timer-based profiling, which isn't really all that relevant any more to begin with, but it also ends up making assumptions based on the stack layout that aren't necessarily valid.

Basically, the code tries to account the time spent in spinlocks to the caller rather than the spinlock, and while I support that as a concept, it's not worth the code complexity or the KASAN warnings when no serious profiling is done using timers anyway these days.

And the code really does depend on stack layout that is only true in the simplest of cases. We've lost the comment at some point (I think when the 32-bit and 64-bit code was unified), but it used to say:

Assume the lock function has either no stack frame or a copy of eflags from PUSHF.

which explains why it just blindly loads a word or two straight off the stack pointer and then takes a minimal look at the values to just check if they might be eflags or the return pc:

Eflags always has bits 22 and up cleared unlike kernel addresses

but that basic stack layout assumption assumes that there isn't any lock debugging etc going on that would complicate the code and cause a stack frame.

It causes KASAN unhappiness reported for years by syzkaller [1] and others [2].

With no real practical reason for this any more, just remove the code.

Just for historical interest, here's some…

In the Linux kernel, the following vulnerability has been resolved:

x86: stop playing stack games in profile_pc()

The 'profile_pc()' function is used for timer-based profiling, which isn't really all that relevant any more to begin with, but it also ends up making assumptions based on the stack layout that aren't necessarily valid.

Basically, the code tries to account the time spent in spinlocks to the caller rather than the spinlock, and while I support that as a concept, it's not worth the code complexity or the KASAN warnings when no serious profiling is done using timers anyway these days.

And the code really does depend on stack layout that is only true in the simplest of cases. We've lost the comment at some point (I think when the 32-bit and 64-bit code was unified), but it used to say:

Assume the lock function has either no stack frame or a copy of eflags from PUSHF.

which explains why it just blindly loads a word or two straight off the stack pointer and then takes a minimal look at the values to just check if they might be eflags or the return pc:

Eflags always has bits 22 and up cleared unlike kernel addresses

but that basic stack layout assumption assumes that there isn't any lock debugging etc going on that would complicate the code and cause a stack frame.

It causes KASAN unhappiness reported for years by syzkaller [1] and others [2].

With no real practical reason for this any more, just remove the code.

Just for historical interest, here's some…

expat 2.1.0 and earlier does not properly handle entities expansion unless an application developer uses the XML_SetEntityDeclHandler function, which allows remote attackers to cause a denial of service (resource consumption), send HTTP requests to intranet servers, or read arbitrary files via a crafted XML document, aka an XML External Entity (XXE) issue. NOTE: it could be argued that because expat already provides the ability to disable external entity expansion, the responsibility for resolving this issue lies with application developers; according to this argument, this entry should be REJECTed, and each affected application would need its own CVE. shadow: TOCTOU (time-of-check time-of-use) race condition when copying and removing directory trees run-mailcap in the Debian mime-support package before 3.52-1+deb7u1 allows context-dependent attackers to execute arbitrary commands via shell metacharacters in a filename. In Python (aka CPython) up to 3.10.8, the mailcap module does not add escape characters into commands discovered in the system mailcap file. This may allow attackers to inject shell commands into applications that call mailcap.findmatch with untrusted input (if they lack validation of user-provided filenames or arguments). The fix is also back-ported to 3.7, 3.8, 3.9 Use-after-free vulnerability in bzip2recover in bzip2 1.0.6 allows remote attackers to cause a denial of service (crash) via a crafted bzip2 file, related to block ends set to before the start o…

Affected: openEuler:22.03-LTS-SP1: kernel

The Linux Kernel, the operating system core itself. Security Fix(es): In the Linux kernel, the following vulnerability has been resolved: USB: core: Make do_proc_control() and do_proc_bulk() killable The USBDEVFS_CONTROL and USBDEVFS_BULK ioctls invoke usb_start_wait_urb(), which contains an uninterruptible wait with a user-specified timeout value. If timeout value is very large and the device being accessed does not respond in a reasonable amount of time, the kernel will complain about "Task X blocked for more than N seconds", as found in testing by syzbot: INFO: task syz-executor.0:8700 blocked for more than 143 seconds. Not tainted 5.14.0-rc7-syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz-executor.0 state:D stack:23192 pid: 8700 ppid: 8455 flags:0x00004004 Call Trace: context_switch kernel/sched/core.c:4681 [inline] __schedule+0xc07/0x11f0 kernel/sched/core.c:5938 schedule+0x14b/0x210 kernel/sched/core.c:6017 schedule_timeout+0x98/0x2f0 kernel/time/timer.c:1857 do_wait_for_common+0x2da/0x480 kernel/sched/completion.c:85 __wait_for_common kernel/sched/completion.c:106 [inline] wait_for_common kernel/sched/completion.c:117 [inline] wait_for_completion_timeout+0x46/0x60 kernel/sched/completion.c:157 usb_start_wait_urb+0x167/0x550 drivers/usb/core/message.c:63 do_proc_bulk+0x978/0x1080 drivers/usb/core/devio.c:1236 proc_bulk drivers/usb/core/devio.c:1273 [inline] usbdev…

kernel: efivarfs: force RO when remounting if SetVariable is not supported kernel: iommufd: Fix missing update of domains_itree after splitting iopt_area kernel: nfsd: fix RELEASE_LOCKOWNER kernel: mm: cachestat: fix folio read-after-free in cache walk kernel: mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again kernel: Bluetooth: af_bluetooth: Fix deadlock kernel: kprobes/x86: Use copy_from_kernel_nofault() to read from unsafe address kernel: KVM: SVM: Flush pages under kvm->lock to fix UAF in svm_register_enc_region() kernel: mm: cachestat: fix two shmem bugs kernel: x86/coco: Require seeding RNG with RDRAND on CoCo systems kernel: mm/hugetlb: fix missing hugetlb_lock for resv uncharge kernel: regmap: maple: Fix cache corruption in regcache_maple_drop() kernel: net: fix out-of-bounds access in ops_init kernel: net: bridge: mst: fix vlan use-after-free kernel: scsi: qedf: Ensure the copied buf is NUL terminated kernel: usb-storage: alauda: Check whether the media is initialized kernel: xhci: Handle TD clearing for multiple streams case kernel: cxl/region: Fix memregion leaks in devm_cxl_add_region() kernel: net/sched: Fix UAF when resolving a clash kernel: ppp: reject claimed-as-LCP but actually malformed packets kernel: mm: prevent derefencing NULL ptr in pfn_section_valid() kernel: nvme: avoid double free special payload kernel: PCI/MSI: Fix UAF in msi_capability_init kernel: xdp: Remove WARN() from __xdp_reg_mem_model() kernel: x86: stop playing stack…

kernel: kyber: fix out of bounds access when preempted kernel: Input: elantech - fix stack out of bound access in elantech_change_report_id() kernel: asix: fix uninit-value in asix_mdio_read() kernel: driver core: auxiliary bus: Fix memory leak when driver_register() fail kernel: ACPI: fix NULL pointer dereference kernel: watchdog: Fix possible use-after-free by calling del_timer_sync() kernel: fbmem: Do not delete the mode that is still in use kernel: virtio-net: Add validation for used length kernel: tty: Fix out-of-bound vmalloc access in imageblit kernel: hwmon: (w83793) Fix NULL pointer dereference by removing unnecessary structure field kernel: hwmon: (w83792d) Fix NULL pointer dereference by removing unnecessary structure field kernel: hwmon: (w83791d) Fix NULL pointer dereference by removing unnecessary structure field kernel: hwmon: (mlxreg-fan) Return non-zero value when fan current state is enforced from sysfs kernel: block: don't call rq_qos_ops->done_bio if the bio isn't tracked kernel: lib/generic-radix-tree.c: Don't overflow in peek() kernel: mlxsw: thermal: Fix out-of-bounds memory accesses kernel: ptp: Fix possible memory leak in ptp_clock_register() kernel: mm, slub: fix potential memoryleak in kmem_cache_open() kernel: nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells kernel: serial: core: fix transmit-buffer reset and memleak kernel: mlxsw: spectrum: Protect driver from buggy firmware kernel: USB: core: Make do_proc_control() and do_proc_bulk() k…

An out-of-bounds (OOB) memory write flaw was found in the NFSD in the Linux kernel. Missing sanity may lead to a write beyond bmval[bmlen-1] in nfsd4_decode_bitmap4 in fs/nfsd/nfs4xdr.c. In this flaw, a local attacker with user privilege may gain access to out-of-bounds memory, leading to a system integrity and confidentiality threat. fs/nfsd/trace.h in the Linux kernel before 5.13.4 might allow remote attackers to cause a denial of service (out-of-bounds read in strlen) by sending NFS traffic when the trace event framework is being used for nfsd. SUNRPC: null pointer dereference in svc_rqst_free(). When alloc_pages_node() returns null in svc_rqst_alloc(), the null rq_scratch_page pointer will be dereferenced when calling put_page() in svc_rqst_free(). NFSD: READDIR buffer overflow. If a client sends a READDIR count argument that is too small (say, zero), then the buffer size calculation in the new init_dirlist helper functions results in an underflow, allowing the XDR stream functions to write beyond the actual buffer. This calculation has always been suspect. NFSD has never sanity- checked the READDIR count argument, but the old entry encoders managed the problem correctly. With the commits below, entry encoding changed, exposing the underflow to the pointer arithmetic in xdr_reserve_space(). Modern NFS clients attempt to retrieve as much data as possible for each READDIR request. nfsd: NULL dereference in nfs3svc_encode_getaclres. A NULL pointer dereference vulnerability…

Security update for the Linux Kernel

Affected: Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 187 more

In the Linux kernel, the following vulnerability has been resolved: x86: stop playing stack games in profile_pc() The 'profile_pc()' function is used for timer-based profiling, which isn't really all that relevant any more to begin with, but it also ends up making assumptions based on the stack layout that aren't necessarily valid. Basically, the code tries to account the time spent in spinlocks to the caller rather than the spinlock, and while I support that as a concept, it's not worth the code complexity or the KASAN warnings when no serious profiling is done using timers anyway these days. And the code really does depend on stack layout that is only true in the simplest of cases. We've lost the comment at some point (I think when the 32-bit and 64-bit code was unified), but it used to say: Assume the lock function has either no stack frame or a copy of eflags from PUSHF. which explains why it just blindly loads a word or two straight off the stack pointer and then takes a minimal look at the values to just check if they might be eflags or the return pc: Eflags always has bits 22 and up cleared unlike kernel addresses but that basic stack layout assumption assumes that there isn't any lock debugging etc going on that would complicate the code and cause a stack frame. It causes KASAN unhappiness reported for years by syzkaller [1] and others [2]. With no real practical reason for this any more, just remove the code. Just for historical interest, here's some background…

Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen.