Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/stm: ltdc: fix late dereference check<br /> <br /> In ltdc_crtc_set_crc_source(), struct drm_crtc was dereferenced in a<br /> container_of() before the pointer check. This could cause a kernel panic.<br /> <br /> Fix this smatch warning:<br /> drivers/gpu/drm/stm/ltdc.c:1124 ltdc_crtc_set_crc_source() warn: variable dereferenced before check &amp;#39;crtc&amp;#39; (see line 1119)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: brcmfmac: cfg80211: Pass the PMK in binary instead of hex<br /> <br /> Apparently the hex passphrase mechanism does not work on newer<br /> chips/firmware (e.g. BCM4387). It seems there was a simple way of<br /> passing it in binary all along, so use that and avoid the hexification.<br /> <br /> OpenBSD has been doing it like this from the beginning, so this should<br /> work on all chips.<br /> <br /> Also clear the structure before setting the PMK. This was leaking<br /> uninitialized stack contents to the device.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fix skb leak in __skb_tstamp_tx()<br /> <br /> Commit 50749f2dd685 ("tcp/udp: Fix memleaks of sk and zerocopy skbs with<br /> TX timestamp.") added a call to skb_orphan_frags_rx() to fix leaks with<br /> zerocopy skbs. But it ended up adding a leak of its own. When<br /> skb_orphan_frags_rx() fails, the function just returns, leaking the skb<br /> it just cloned. Free it before returning.<br /> <br /> This bug was discovered and resolved using Coverity Static Analysis<br /> Security Testing (SAST) by Synopsys, Inc.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath9k: Fix potential stack-out-of-bounds write in ath9k_wmi_rsp_callback()<br /> <br /> Fix a stack-out-of-bounds write that occurs in a WMI response callback<br /> function that is called after a timeout occurs in ath9k_wmi_cmd().<br /> The callback writes to wmi-&gt;cmd_rsp_buf, a stack-allocated buffer that<br /> could no longer be valid when a timeout occurs. Set wmi-&gt;last_seq_id to<br /> 0 when a timeout occurred.<br /> <br /> Found by a modified version of syzkaller.<br /> <br /> BUG: KASAN: stack-out-of-bounds in ath9k_wmi_ctrl_rx<br /> Write of size 4<br /> Call Trace:<br /> memcpy<br /> ath9k_wmi_ctrl_rx<br /> ath9k_htc_rx_msg<br /> ath9k_hif_usb_reg_in_cb<br /> __usb_hcd_giveback_urb<br /> usb_hcd_giveback_urb<br /> dummy_timer<br /> call_timer_fn<br /> run_timer_softirq<br /> __do_softirq<br /> irq_exit_rcu<br /> sysvec_apic_timer_interrupt

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ring-buffer: Do not swap cpu_buffer during resize process<br /> <br /> When ring_buffer_swap_cpu was called during resize process,<br /> the cpu buffer was swapped in the middle, resulting in incorrect state.<br /> Continuing to run in the wrong state will result in oops.<br /> <br /> This issue can be easily reproduced using the following two scripts:<br /> /tmp # cat test1.sh<br /> //#! /bin/sh<br /> for i in `seq 0 100000`<br /> do<br /> echo 2000 &gt; /sys/kernel/debug/tracing/buffer_size_kb<br /> sleep 0.5<br /> echo 5000 &gt; /sys/kernel/debug/tracing/buffer_size_kb<br /> sleep 0.5<br /> done<br /> /tmp # cat test2.sh<br /> //#! /bin/sh<br /> for i in `seq 0 100000`<br /> do<br /> echo irqsoff &gt; /sys/kernel/debug/tracing/current_tracer<br /> sleep 1<br /> echo nop &gt; /sys/kernel/debug/tracing/current_tracer<br /> sleep 1<br /> done<br /> /tmp # ./test1.sh &amp;<br /> /tmp # ./test2.sh &amp;<br /> <br /> A typical oops log is as follows, sometimes with other different oops logs.<br /> <br /> [ 231.711293] WARNING: CPU: 0 PID: 9 at kernel/trace/ring_buffer.c:2026 rb_update_pages+0x378/0x3f8<br /> [ 231.713375] Modules linked in:<br /> [ 231.714735] CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W 6.5.0-rc1-00276-g20edcec23f92 #15<br /> [ 231.716750] Hardware name: linux,dummy-virt (DT)<br /> [ 231.718152] Workqueue: events update_pages_handler<br /> [ 231.719714] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 231.721171] pc : rb_update_pages+0x378/0x3f8<br /> [ 231.722212] lr : rb_update_pages+0x25c/0x3f8<br /> [ 231.723248] sp : ffff800082b9bd50<br /> [ 231.724169] x29: ffff800082b9bd50 x28: ffff8000825f7000 x27: 0000000000000000<br /> [ 231.726102] x26: 0000000000000001 x25: fffffffffffff010 x24: 0000000000000ff0<br /> [ 231.728122] x23: ffff0000c3a0b600 x22: ffff0000c3a0b5c0 x21: fffffffffffffe0a<br /> [ 231.730203] x20: ffff0000c3a0b600 x19: ffff0000c0102400 x18: 0000000000000000<br /> [ 231.732329] x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffffe7aa8510<br /> [ 231.734212] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000002<br /> [ 231.736291] x11: ffff8000826998a8 x10: ffff800082b9baf0 x9 : ffff800081137558<br /> [ 231.738195] x8 : fffffc00030e82c8 x7 : 0000000000000000 x6 : 0000000000000001<br /> [ 231.740192] x5 : ffff0000ffbafe00 x4 : 0000000000000000 x3 : 0000000000000000<br /> [ 231.742118] x2 : 00000000000006aa x1 : 0000000000000001 x0 : ffff0000c0007208<br /> [ 231.744196] Call trace:<br /> [ 231.744892] rb_update_pages+0x378/0x3f8<br /> [ 231.745893] update_pages_handler+0x1c/0x38<br /> [ 231.746893] process_one_work+0x1f0/0x468<br /> [ 231.747852] worker_thread+0x54/0x410<br /> [ 231.748737] kthread+0x124/0x138<br /> [ 231.749549] ret_from_fork+0x10/0x20<br /> [ 231.750434] ---[ end trace 0000000000000000 ]---<br /> [ 233.720486] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> [ 233.721696] Mem abort info:<br /> [ 233.721935] ESR = 0x0000000096000004<br /> [ 233.722283] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 233.722596] SET = 0, FnV = 0<br /> [ 233.722805] EA = 0, S1PTW = 0<br /> [ 233.723026] FSC = 0x04: level 0 translation fault<br /> [ 233.723458] Data abort info:<br /> [ 233.723734] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> [ 233.724176] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 233.724589] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 233.725075] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000104943000<br /> [ 233.725592] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000<br /> [ 233.726231] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP<br /> [ 233.726720] Modules linked in:<br /> [ 233.727007] CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W 6.5.0-rc1-00276-g20edcec23f92 #15<br /> [ 233.727777] Hardware name: linux,dummy-virt (DT)<br /> [ 233.728225] Workqueue: events update_pages_handler<br /> [ 233.728655] pstate: 200000c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 233.729054] pc : rb_update_pages+0x1a8/0x3f8<br /> [ 233.729334] lr : rb_update_pages+0x154/0x3f8<br /> [ 233.729592] sp : ffff800082b9bd50<br /> [ 233.729792] x29: ffff800082b9bd50 x28: ffff8000825f7000 x27: 00000000<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: arc_uart: fix of_iomap leak in `arc_serial_probe`<br /> <br /> Smatch reports:<br /> <br /> drivers/tty/serial/arc_uart.c:631 arc_serial_probe() warn:<br /> &amp;#39;port-&gt;membase&amp;#39; from of_iomap() not released on lines: 631.<br /> <br /> In arc_serial_probe(), if uart_add_one_port() fails,<br /> port-&gt;membase is not released, which would cause a resource leak.<br /> <br /> To fix this, I replace of_iomap with devm_platform_ioremap_resource.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: Fix out-of-bounds access in ipv6_find_tlv()<br /> <br /> optlen is fetched without checking whether there is more than one byte to parse.<br /> It can lead to out-of-bounds access.<br /> <br /> Found by InfoTeCS on behalf of Linux Verification Center<br /> (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/vmemmap/devdax: fix kernel crash when probing devdax devices<br /> <br /> commit 4917f55b4ef9 ("mm/sparse-vmemmap: improve memory savings for<br /> compound devmaps") added support for using optimized vmmemap for devdax<br /> devices. But how vmemmap mappings are created are architecture specific. <br /> For example, powerpc with hash translation doesn&amp;#39;t have vmemmap mappings<br /> in init_mm page table instead they are bolted table entries in the<br /> hardware page table<br /> <br /> vmemmap_populate_compound_pages() used by vmemmap optimization code is not<br /> aware of these architecture-specific mapping. Hence allow architecture to<br /> opt for this feature. I selected architectures supporting<br /> HUGETLB_PAGE_OPTIMIZE_VMEMMAP option as also supporting this feature.<br /> <br /> This patch fixes the below crash on ppc64.<br /> <br /> BUG: Unable to handle kernel data access on write at 0xc00c000100400038<br /> Faulting instruction address: 0xc000000001269d90<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries<br /> Modules linked in:<br /> CPU: 7 PID: 1 Comm: swapper/0 Not tainted 6.3.0-rc5-150500.34-default+ #2 5c90a668b6bbd142599890245c2fb5de19d7d28a<br /> Hardware name: IBM,9009-42G POWER9 (raw) 0x4e0202 0xf000005 of:IBM,FW950.40 (VL950_099) hv:phyp pSeries<br /> NIP: c000000001269d90 LR: c0000000004c57d4 CTR: 0000000000000000<br /> REGS: c000000003632c30 TRAP: 0300 Not tainted (6.3.0-rc5-150500.34-default+)<br /> MSR: 8000000000009033 CR: 24842228 XER: 00000000<br /> CFAR: c0000000004c57d0 DAR: c00c000100400038 DSISR: 42000000 IRQMASK: 0<br /> ....<br /> NIP [c000000001269d90] __init_single_page.isra.74+0x14/0x4c<br /> LR [c0000000004c57d4] __init_zone_device_page+0x44/0xd0<br /> Call Trace:<br /> [c000000003632ed0] [c000000003632f60] 0xc000000003632f60 (unreliable)<br /> [c000000003632f10] [c0000000004c5ca0] memmap_init_zone_device+0x170/0x250<br /> [c000000003632fe0] [c0000000005575f8] memremap_pages+0x2c8/0x7f0<br /> [c0000000036330c0] [c000000000557b5c] devm_memremap_pages+0x3c/0xa0<br /> [c000000003633100] [c000000000d458a8] dev_dax_probe+0x108/0x3e0<br /> [c0000000036331a0] [c000000000d41430] dax_bus_probe+0xb0/0x140<br /> [c0000000036331d0] [c000000000cef27c] really_probe+0x19c/0x520<br /> [c000000003633260] [c000000000cef6b4] __driver_probe_device+0xb4/0x230<br /> [c0000000036332e0] [c000000000cef888] driver_probe_device+0x58/0x120<br /> [c000000003633320] [c000000000cefa6c] __device_attach_driver+0x11c/0x1e0<br /> [c0000000036333a0] [c000000000cebc58] bus_for_each_drv+0xa8/0x130<br /> [c000000003633400] [c000000000ceefcc] __device_attach+0x15c/0x250<br /> [c0000000036334a0] [c000000000ced458] bus_probe_device+0x108/0x110<br /> [c0000000036334f0] [c000000000ce92dc] device_add+0x7fc/0xa10<br /> [c0000000036335b0] [c000000000d447c8] devm_create_dev_dax+0x1d8/0x530<br /> [c000000003633640] [c000000000d46b60] __dax_pmem_probe+0x200/0x270<br /> [c0000000036337b0] [c000000000d46bf0] dax_pmem_probe+0x20/0x70<br /> [c0000000036337d0] [c000000000d2279c] nvdimm_bus_probe+0xac/0x2b0<br /> [c000000003633860] [c000000000cef27c] really_probe+0x19c/0x520<br /> [c0000000036338f0] [c000000000cef6b4] __driver_probe_device+0xb4/0x230<br /> [c000000003633970] [c000000000cef888] driver_probe_device+0x58/0x120<br /> [c0000000036339b0] [c000000000cefd08] __driver_attach+0x1d8/0x240<br /> [c000000003633a30] [c000000000cebb04] bus_for_each_dev+0xb4/0x130<br /> [c000000003633a90] [c000000000cee564] driver_attach+0x34/0x50<br /> [c000000003633ab0] [c000000000ced878] bus_add_driver+0x218/0x300<br /> [c000000003633b40] [c000000000cf1144] driver_register+0xa4/0x1b0<br /> [c000000003633bb0] [c000000000d21a0c] __nd_driver_register+0x5c/0x100<br /> [c000000003633c10] [c00000000206a2e8] dax_pmem_init+0x34/0x48<br /> [c000000003633c30] [c0000000000132d0] do_one_initcall+0x60/0x320<br /> [c000000003633d00] [c0000000020051b0] kernel_init_freeable+0x360/0x400<br /> [c000000003633de0] [c000000000013764] kernel_init+0x34/0x1d0<br /> [c000000003633e50] [c00000000000de14] ret_from_kernel_thread+0x5c/0x64

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix integer overflow in amdgpu_cs_pass1<br /> <br /> The type of size is unsigned int, if size is 0x40000000, there will<br /> be an integer overflow, size will be zero after size *= sizeof(uint32_t),<br /> will cause uninitialized memory to be referenced later.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: x86: s2idle: Catch multiple ACPI_TYPE_PACKAGE objects<br /> <br /> If a badly constructed firmware includes multiple `ACPI_TYPE_PACKAGE`<br /> objects while evaluating the AMD LPS0 _DSM, there will be a memory<br /> leak. Explicitly guard against this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ring-buffer: Handle race between rb_move_tail and rb_check_pages<br /> <br /> It seems a data race between ring_buffer writing and integrity check.<br /> That is, RB_FLAG of head_page is been updating, while at same time<br /> RB_FLAG was cleared when doing integrity check rb_check_pages():<br /> <br /> rb_check_pages() rb_handle_head_page():<br /> -------- --------<br /> rb_head_page_deactivate()<br /> rb_head_page_set_normal()<br /> rb_head_page_activate()<br /> <br /> We do intergrity test of the list to check if the list is corrupted and<br /> it is still worth doing it. So, let&amp;#39;s refactor rb_check_pages() such that<br /> we no longer clear and set flag during the list sanity checking.<br /> <br /> [1] and [2] are the test to reproduce and the crash report respectively.<br /> <br /> 1:<br /> ``` read_trace.sh<br /> while true;<br /> do<br /> # the "trace" file is closed after read<br /> head -1 /sys/kernel/tracing/trace &gt; /dev/null<br /> done<br /> ```<br /> ``` repro.sh<br /> sysctl -w kernel.panic_on_warn=1<br /> # function tracer will writing enough data into ring_buffer<br /> echo function &gt; /sys/kernel/tracing/current_tracer<br /> ./read_trace.sh &amp;<br /> ./read_trace.sh &amp;<br /> ./read_trace.sh &amp;<br /> ./read_trace.sh &amp;<br /> ./read_trace.sh &amp;<br /> ./read_trace.sh &amp;<br /> ./read_trace.sh &amp;<br /> ./read_trace.sh &amp;<br /> ```<br /> <br /> 2:<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 9 PID: 62 at kernel/trace/ring_buffer.c:2653<br /> rb_move_tail+0x450/0x470<br /> Modules linked in:<br /> CPU: 9 PID: 62 Comm: ksoftirqd/9 Tainted: G W 6.2.0-rc6+<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:rb_move_tail+0x450/0x470<br /> Code: ff ff 4c 89 c8 f0 4d 0f b1 02 48 89 c2 48 83 e2 fc 49 39 d0 75 24<br /> 83 e0 03 83 f8 02 0f 84 e1 fb ff ff 48 8b 57 10 f0 ff 42 08 0b 83<br /> f8 02 0f 84 ce fb ff ff e9 db<br /> RSP: 0018:ffffb5564089bd00 EFLAGS: 00000203<br /> RAX: 0000000000000000 RBX: ffff9db385a2bf81 RCX: ffffb5564089bd18<br /> RDX: ffff9db281110100 RSI: 0000000000000fe4 RDI: ffff9db380145400<br /> RBP: ffff9db385a2bf80 R08: ffff9db385a2bfc0 R09: ffff9db385a2bfc2<br /> R10: ffff9db385a6c000 R11: ffff9db385a2bf80 R12: 0000000000000000<br /> R13: 00000000000003e8 R14: ffff9db281110100 R15: ffffffffbb006108<br /> FS: 0000000000000000(0000) GS:ffff9db3bdcc0000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00005602323024c8 CR3: 0000000022e0c000 CR4: 00000000000006e0<br /> Call Trace:<br /> <br /> ring_buffer_lock_reserve+0x136/0x360<br /> ? __do_softirq+0x287/0x2df<br /> ? __pfx_rcu_softirq_qs+0x10/0x10<br /> trace_function+0x21/0x110<br /> ? __pfx_rcu_softirq_qs+0x10/0x10<br /> ? __do_softirq+0x287/0x2df<br /> function_trace_call+0xf6/0x120<br /> 0xffffffffc038f097<br /> ? rcu_softirq_qs+0x5/0x140<br /> rcu_softirq_qs+0x5/0x140<br /> __do_softirq+0x287/0x2df<br /> run_ksoftirqd+0x2a/0x30<br /> smpboot_thread_fn+0x188/0x220<br /> ? __pfx_smpboot_thread_fn+0x10/0x10<br /> kthread+0xe7/0x110<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x2c/0x50<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> <br /> [ crash report and test reproducer credit goes to Zheng Yejian]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7921: fix error code of return in mt7921_acpi_read<br /> <br /> Kernel NULL pointer dereference when ACPI SAR table isn&amp;#39;t implemented well.<br /> Fix the error code of return to mark the ACPI SAR table as invalid.<br /> <br /> [ 5.077128] mt7921e 0000:06:00.0: sar cnt = 0<br /> [ 5.077381] BUG: kernel NULL pointer dereference, address:<br /> 0000000000000004<br /> [ 5.077630] #PF: supervisor read access in kernel mode<br /> [ 5.077883] #PF: error_code(0x0000) - not-present page<br /> [ 5.078138] PGD 0 P4D 0<br /> [ 5.078398] Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 5.079202] RIP: 0010:mt7921_init_acpi_sar+0x106/0x220<br /> [mt7921_common]<br /> ...<br /> [ 5.080786] Call Trace:<br /> [ 5.080786] <br /> [ 5.080786] mt7921_register_device+0x37d/0x490 [mt7921_common]<br /> [ 5.080786] mt7921_pci_probe.part.0+0x2ee/0x310 [mt7921e]<br /> [ 5.080786] mt7921_pci_probe+0x52/0x70 [mt7921e]<br /> [ 5.080786] local_pci_probe+0x47/0x90<br /> [ 5.080786] pci_call_probe+0x55/0x190<br /> [ 5.080786] pci_device_probe+0x84/0x120