Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: qcom: qmi_encdec: Restrict string length in decode<br /> <br /> The QMI TLV value for strings in a lot of qmi element info structures<br /> account for null terminated strings with MAX_LEN + 1. If a string is<br /> actually MAX_LEN + 1 length, this will cause an out of bounds access<br /> when the NULL character is appended in decoding.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-iocost: use spin_lock_irqsave in adjust_inuse_and_calc_cost<br /> <br /> adjust_inuse_and_calc_cost() use spin_lock_irq() and IRQ will be enabled<br /> when unlock. DEADLOCK might happen if we have held other locks and disabled<br /> IRQ before invoking it.<br /> <br /> Fix it by using spin_lock_irqsave() instead, which can keep IRQ state<br /> consistent with before when unlock.<br /> <br /> ================================<br /> WARNING: inconsistent lock state<br /> 5.10.0-02758-g8e5f91fd772f #26 Not tainted<br /> --------------------------------<br /> inconsistent {IN-HARDIRQ-W} -&gt; {HARDIRQ-ON-W} usage.<br /> kworker/2:3/388 [HC0[0]:SC0[0]:HE0:SE1] takes:<br /> ffff888118c00c28 (&amp;bfqd-&gt;lock){?.-.}-{2:2}, at: spin_lock_irq<br /> ffff888118c00c28 (&amp;bfqd-&gt;lock){?.-.}-{2:2}, at: bfq_bio_merge+0x141/0x390<br /> {IN-HARDIRQ-W} state was registered at:<br /> __lock_acquire+0x3d7/0x1070<br /> lock_acquire+0x197/0x4a0<br /> __raw_spin_lock_irqsave<br /> _raw_spin_lock_irqsave+0x3b/0x60<br /> bfq_idle_slice_timer_body<br /> bfq_idle_slice_timer+0x53/0x1d0<br /> __run_hrtimer+0x477/0xa70<br /> __hrtimer_run_queues+0x1c6/0x2d0<br /> hrtimer_interrupt+0x302/0x9e0<br /> local_apic_timer_interrupt<br /> __sysvec_apic_timer_interrupt+0xfd/0x420<br /> run_sysvec_on_irqstack_cond<br /> sysvec_apic_timer_interrupt+0x46/0xa0<br /> asm_sysvec_apic_timer_interrupt+0x12/0x20<br /> irq event stamp: 837522<br /> hardirqs last enabled at (837521): [] __raw_spin_unlock_irqrestore<br /> hardirqs last enabled at (837521): [] _raw_spin_unlock_irqrestore+0x3d/0x40<br /> hardirqs last disabled at (837522): [] __raw_spin_lock_irq<br /> hardirqs last disabled at (837522): [] _raw_spin_lock_irq+0x43/0x50<br /> softirqs last enabled at (835852): [] __do_softirq+0x558/0x8ec<br /> softirqs last disabled at (835845): [] asm_call_irq_on_stack+0xf/0x20<br /> <br /> other info that might help us debug this:<br /> Possible unsafe locking scenario:<br /> <br /> CPU0<br /> ----<br /> lock(&amp;bfqd-&gt;lock);<br /> <br /> lock(&amp;bfqd-&gt;lock);<br /> <br /> *** DEADLOCK ***<br /> <br /> 3 locks held by kworker/2:3/388:<br /> #0: ffff888107af0f38 ((wq_completion)kthrotld){+.+.}-{0:0}, at: process_one_work+0x742/0x13f0<br /> #1: ffff8881176bfdd8 ((work_completion)(&amp;td-&gt;dispatch_work)){+.+.}-{0:0}, at: process_one_work+0x777/0x13f0<br /> #2: ffff888118c00c28 (&amp;bfqd-&gt;lock){?.-.}-{2:2}, at: spin_lock_irq<br /> #2: ffff888118c00c28 (&amp;bfqd-&gt;lock){?.-.}-{2:2}, at: bfq_bio_merge+0x141/0x390<br /> <br /> stack backtrace:<br /> CPU: 2 PID: 388 Comm: kworker/2:3 Not tainted 5.10.0-02758-g8e5f91fd772f #26<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> Workqueue: kthrotld blk_throtl_dispatch_work_fn<br /> Call Trace:<br /> __dump_stack lib/dump_stack.c:77 [inline]<br /> dump_stack+0x107/0x167<br /> print_usage_bug<br /> valid_state<br /> mark_lock_irq.cold+0x32/0x3a<br /> mark_lock+0x693/0xbc0<br /> mark_held_locks+0x9e/0xe0<br /> __trace_hardirqs_on_caller<br /> lockdep_hardirqs_on_prepare.part.0+0x151/0x360<br /> trace_hardirqs_on+0x5b/0x180<br /> __raw_spin_unlock_irq<br /> _raw_spin_unlock_irq+0x24/0x40<br /> spin_unlock_irq<br /> adjust_inuse_and_calc_cost+0x4fb/0x970<br /> ioc_rqos_merge+0x277/0x740<br /> __rq_qos_merge+0x62/0xb0<br /> rq_qos_merge<br /> bio_attempt_back_merge+0x12c/0x4a0<br /> blk_mq_sched_try_merge+0x1b6/0x4d0<br /> bfq_bio_merge+0x24a/0x390<br /> __blk_mq_sched_bio_merge+0xa6/0x460<br /> blk_mq_sched_bio_merge<br /> blk_mq_submit_bio+0x2e7/0x1ee0<br /> __submit_bio_noacct_mq+0x175/0x3b0<br /> submit_bio_noacct+0x1fb/0x270<br /> blk_throtl_dispatch_work_fn+0x1ef/0x2b0<br /> process_one_work+0x83e/0x13f0<br /> process_scheduled_works<br /> worker_thread+0x7e3/0xd80<br /> kthread+0x353/0x470<br /> ret_from_fork+0x1f/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netlink: fix potential deadlock in netlink_set_err()<br /> <br /> syzbot reported a possible deadlock in netlink_set_err() [1]<br /> <br /> A similar issue was fixed in commit 1d482e666b8e ("netlink: disable IRQs<br /> for netlink_lock_table()") in netlink_lock_table()<br /> <br /> This patch adds IRQ safety to netlink_set_err() and __netlink_diag_dump()<br /> which were not covered by cited commit.<br /> <br /> [1]<br /> <br /> WARNING: possible irq lock inversion dependency detected<br /> 6.4.0-rc6-syzkaller-00240-g4e9f0ec38852 #0 Not tainted<br /> <br /> syz-executor.2/23011 just changed the state of lock:<br /> ffffffff8e1a7a58 (nl_table_lock){.+.?}-{2:2}, at: netlink_set_err+0x2e/0x3a0 net/netlink/af_netlink.c:1612<br /> but this lock was taken by another, SOFTIRQ-safe lock in the past:<br /> (&amp;local-&gt;queue_stop_reason_lock){..-.}-{2:2}<br /> <br /> and interrupts could create inverse lock ordering between them.<br /> <br /> other info that might help us debug this:<br /> Possible interrupt unsafe locking scenario:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> lock(nl_table_lock);<br /> local_irq_disable();<br /> lock(&amp;local-&gt;queue_stop_reason_lock);<br /> lock(nl_table_lock);<br /> <br /> lock(&amp;local-&gt;queue_stop_reason_lock);<br /> <br /> *** DEADLOCK ***

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Fix NULL dereference in ni_write_inode<br /> <br /> Syzbot reports a NULL dereference in ni_write_inode.<br /> When creating a new inode, if allocation fails in mi_init function<br /> (called in mi_format_new function), mi-&gt;mrec is set to NULL.<br /> In the error path of this inode creation, mi-&gt;mrec is later<br /> dereferenced in ni_write_inode.<br /> <br /> Add a NULL check to prevent NULL dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: disable sdma ecc irq only when sdma RAS is enabled in suspend<br /> <br /> sdma_v4_0_ip is shared on a few asics, but in sdma_v4_0_hw_fini,<br /> driver unconditionally disables ecc_irq which is only enabled on<br /> those asics enabling sdma ecc. This will introduce a warning in<br /> suspend cycle on those chips with sdma ip v4.0, while without<br /> sdma ecc. So this patch correct this.<br /> <br /> [ 7283.166354] RIP: 0010:amdgpu_irq_put+0x45/0x70 [amdgpu]<br /> [ 7283.167001] RSP: 0018:ffff9a5fc3967d08 EFLAGS: 00010246<br /> [ 7283.167019] RAX: ffff98d88afd3770 RBX: 0000000000000001 RCX: 0000000000000000<br /> [ 7283.167023] RDX: 0000000000000000 RSI: ffff98d89da30390 RDI: ffff98d89da20000<br /> [ 7283.167025] RBP: ffff98d89da20000 R08: 0000000000036838 R09: 0000000000000006<br /> [ 7283.167028] R10: ffffd5764243c008 R11: 0000000000000000 R12: ffff98d89da30390<br /> [ 7283.167030] R13: ffff98d89da38978 R14: ffffffff999ae15a R15: ffff98d880130105<br /> [ 7283.167032] FS: 0000000000000000(0000) GS:ffff98d996f00000(0000) knlGS:0000000000000000<br /> [ 7283.167036] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 7283.167039] CR2: 00000000f7a9d178 CR3: 00000001c42ea000 CR4: 00000000003506e0<br /> [ 7283.167041] Call Trace:<br /> [ 7283.167046] <br /> [ 7283.167048] sdma_v4_0_hw_fini+0x38/0xa0 [amdgpu]<br /> [ 7283.167704] amdgpu_device_ip_suspend_phase2+0x101/0x1a0 [amdgpu]<br /> [ 7283.168296] amdgpu_device_suspend+0x103/0x180 [amdgpu]<br /> [ 7283.168875] amdgpu_pmops_freeze+0x21/0x60 [amdgpu]<br /> [ 7283.169464] pci_pm_freeze+0x54/0xc0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mfd: pcf50633-adc: Fix potential memleak in pcf50633_adc_async_read()<br /> <br /> `req` is allocated in pcf50633_adc_async_read(), but<br /> adc_enqueue_request() could fail to insert the `req` into queue.<br /> We need to check the return value and free it in the case of failure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clocksource/drivers/cadence-ttc: Fix memory leak in ttc_timer_probe<br /> <br /> Smatch reports:<br /> drivers/clocksource/timer-cadence-ttc.c:529 ttc_timer_probe()<br /> warn: &amp;#39;timer_baseaddr&amp;#39; from of_iomap() not released on lines: 498,508,516.<br /> <br /> timer_baseaddr may have the problem of not being released after use,<br /> I replaced it with the devm_of_iomap() function and added the clk_put()<br /> function to cleanup the "clk_ce" and "clk_cs".

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: csum: Fix OoB access in IP checksum code for negative lengths<br /> <br /> Although commit c2c24edb1d9c ("arm64: csum: Fix pathological zero-length<br /> calls") added an early return for zero-length input, syzkaller has<br /> popped up with an example of a _negative_ length which causes an<br /> undefined shift and an out-of-bounds read:<br /> <br /> | BUG: KASAN: slab-out-of-bounds in do_csum+0x44/0x254 arch/arm64/lib/csum.c:39<br /> | Read of size 4294966928 at addr ffff0000d7ac0170 by task syz-executor412/5975<br /> |<br /> | CPU: 0 PID: 5975 Comm: syz-executor412 Not tainted 6.4.0-rc4-syzkaller-g908f31f2a05b #0<br /> | Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023<br /> | Call trace:<br /> | dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:233<br /> | show_stack+0x2c/0x44 arch/arm64/kernel/stacktrace.c:240<br /> | __dump_stack lib/dump_stack.c:88 [inline]<br /> | dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106<br /> | print_address_description mm/kasan/report.c:351 [inline]<br /> | print_report+0x174/0x514 mm/kasan/report.c:462<br /> | kasan_report+0xd4/0x130 mm/kasan/report.c:572<br /> | kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:187<br /> | __kasan_check_read+0x20/0x30 mm/kasan/shadow.c:31<br /> | do_csum+0x44/0x254 arch/arm64/lib/csum.c:39<br /> | csum_partial+0x30/0x58 lib/checksum.c:128<br /> | gso_make_checksum include/linux/skbuff.h:4928 [inline]<br /> | __udp_gso_segment+0xaf4/0x1bc4 net/ipv4/udp_offload.c:332<br /> | udp6_ufo_fragment+0x540/0xca0 net/ipv6/udp_offload.c:47<br /> | ipv6_gso_segment+0x5cc/0x1760 net/ipv6/ip6_offload.c:119<br /> | skb_mac_gso_segment+0x2b4/0x5b0 net/core/gro.c:141<br /> | __skb_gso_segment+0x250/0x3d0 net/core/dev.c:3401<br /> | skb_gso_segment include/linux/netdevice.h:4859 [inline]<br /> | validate_xmit_skb+0x364/0xdbc net/core/dev.c:3659<br /> | validate_xmit_skb_list+0x94/0x130 net/core/dev.c:3709<br /> | sch_direct_xmit+0xe8/0x548 net/sched/sch_generic.c:327<br /> | __dev_xmit_skb net/core/dev.c:3805 [inline]<br /> | __dev_queue_xmit+0x147c/0x3318 net/core/dev.c:4210<br /> | dev_queue_xmit include/linux/netdevice.h:3085 [inline]<br /> | packet_xmit+0x6c/0x318 net/packet/af_packet.c:276<br /> | packet_snd net/packet/af_packet.c:3081 [inline]<br /> | packet_sendmsg+0x376c/0x4c98 net/packet/af_packet.c:3113<br /> | sock_sendmsg_nosec net/socket.c:724 [inline]<br /> | sock_sendmsg net/socket.c:747 [inline]<br /> | __sys_sendto+0x3b4/0x538 net/socket.c:2144<br /> <br /> Extend the early return to reject negative lengths as well, aligning our<br /> implementation with the generic code in lib/checksum.c

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: fq_pie: avoid stalls in fq_pie_timer()<br /> <br /> When setting a high number of flows (limit being 65536),<br /> fq_pie_timer() is currently using too much time as syzbot reported.<br /> <br /> Add logic to yield the cpu every 2048 flows (less than 150 usec<br /> on debug kernels).<br /> It should also help by not blocking qdisc fast paths for too long.<br /> Worst case (65536 flows) would need 31 jiffies for a complete scan.<br /> <br /> Relevant extract from syzbot report:<br /> <br /> rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 0-.... } 2663 jiffies s: 873 root: 0x1/.<br /> rcu: blocking rcu_node structures (internal RCU debug):<br /> Sending NMI from CPU 1 to CPUs 0:<br /> NMI backtrace for cpu 0<br /> CPU: 0 PID: 5177 Comm: syz-executor273 Not tainted 6.5.0-syzkaller-00453-g727dbda16b83 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023<br /> RIP: 0010:check_kcov_mode kernel/kcov.c:173 [inline]<br /> RIP: 0010:write_comp_data+0x21/0x90 kernel/kcov.c:236<br /> Code: 2e 0f 1f 84 00 00 00 00 00 65 8b 05 01 b2 7d 7e 49 89 f1 89 c6 49 89 d2 81 e6 00 01 00 00 49 89 f8 65 48 8b 14 25 80 b9 03 00 00 01 ff 00 74 0e 85 f6 74 59 8b 82 04 16 00 00 85 c0 74 4f 8b<br /> RSP: 0018:ffffc90000007bb8 EFLAGS: 00000206<br /> RAX: 0000000000000101 RBX: ffffc9000dc0d140 RCX: ffffffff885893b0<br /> RDX: ffff88807c075940 RSI: 0000000000000100 RDI: 0000000000000001<br /> RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000000 R12: ffffc9000dc0d178<br /> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000<br /> FS: 0000555555d54380(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f6b442f6130 CR3: 000000006fe1c000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> <br /> <br /> pie_calculate_probability+0x480/0x850 net/sched/sch_pie.c:415<br /> fq_pie_timer+0x1da/0x4f0 net/sched/sch_fq_pie.c:387<br /> call_timer_fn+0x1a0/0x580 kernel/time/timer.c:1700

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.