Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: arm_scmi: Fix list protocols enumeration in the base protocol<br /> <br /> While enumerating protocols implemented by the SCMI platform using<br /> BASE_DISCOVER_LIST_PROTOCOLS, the number of returned protocols is<br /> currently validated in an improper way since the check employs a sum<br /> between unsigned integers that could overflow and cause the check itself<br /> to be silently bypassed if the returned value &amp;#39;loop_num_ret&amp;#39; is big<br /> enough.<br /> <br /> Fix the validation avoiding the addition.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dpaa2-eth: retrieve the virtual address before dma_unmap<br /> <br /> The TSO header was DMA unmapped before the virtual address was retrieved<br /> and then used to free the buffer. This meant that we were actually<br /> removing the DMA map and then trying to search for it to help in<br /> retrieving the virtual address. This lead to a invalid virtual address<br /> being used in the kfree call.<br /> <br /> Fix this by calling dpaa2_iova_to_virt() prior to the dma_unmap call.<br /> <br /> [ 487.231819] Unable to handle kernel paging request at virtual address fffffd9807000008<br /> <br /> (...)<br /> <br /> [ 487.354061] Hardware name: SolidRun LX2160A Honeycomb (DT)<br /> [ 487.359535] pstate: a0400005 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 487.366485] pc : kfree+0xac/0x304<br /> [ 487.369799] lr : kfree+0x204/0x304<br /> [ 487.373191] sp : ffff80000c4eb120<br /> [ 487.376493] x29: ffff80000c4eb120 x28: ffff662240c46400 x27: 0000000000000001<br /> [ 487.383621] x26: 0000000000000001 x25: ffff662246da0cc0 x24: ffff66224af78000<br /> [ 487.390748] x23: ffffad184f4ce008 x22: ffffad1850185000 x21: ffffad1838d13cec<br /> [ 487.397874] x20: ffff6601c0000000 x19: fffffd9807000000 x18: 0000000000000000<br /> [ 487.405000] x17: ffffb910cdc49000 x16: ffffad184d7d9080 x15: 0000000000004000<br /> [ 487.412126] x14: 0000000000000008 x13: 000000000000ffff x12: 0000000000000000<br /> [ 487.419252] x11: 0000000000000004 x10: 0000000000000001 x9 : ffffad184d7d927c<br /> [ 487.426379] x8 : 0000000000000000 x7 : 0000000ffffffd1d x6 : ffff662240a94900<br /> [ 487.433505] x5 : 0000000000000003 x4 : 0000000000000009 x3 : ffffad184f4ce008<br /> [ 487.440632] x2 : ffff662243eec000 x1 : 0000000100000100 x0 : fffffc0000000000<br /> [ 487.447758] Call trace:<br /> [ 487.450194] kfree+0xac/0x304<br /> [ 487.453151] dpaa2_eth_free_tx_fd.isra.0+0x33c/0x3e0 [fsl_dpaa2_eth]<br /> [ 487.459507] dpaa2_eth_tx_conf+0x100/0x2e0 [fsl_dpaa2_eth]<br /> [ 487.464989] dpaa2_eth_poll+0xdc/0x380 [fsl_dpaa2_eth]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: ti: ti_sci_pm_domains: Check for null return of devm_kcalloc<br /> <br /> The allocation funciton devm_kcalloc may fail and return a null pointer,<br /> which would cause a null-pointer dereference later.<br /> It might be better to check it and directly return -ENOMEM just like the<br /> usage of devm_kcalloc in previous code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: mediatek: Fix refcount leak in mtk_pcie_subsys_powerup()<br /> <br /> The of_find_compatible_node() function returns a node pointer with<br /> refcount incremented, We should use of_node_put() on it when done<br /> Add the missing of_node_put() to release the refcount.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: ocxl: fix possible double free in ocxl_file_register_afu<br /> <br /> info_release() will be called in device_unregister() when info-&gt;dev&amp;#39;s<br /> reference count is 0. So there is no need to call ocxl_afu_put() and<br /> kfree() again.<br /> <br /> Fix this by adding free_minor() and return to err_unregister error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bonding: fix missed rcu protection<br /> <br /> When removing the rcu_read_lock in bond_ethtool_get_ts_info() as<br /> discussed [1], I didn&amp;#39;t notice it could be called via setsockopt,<br /> which doesn&amp;#39;t hold rcu lock, as syzbot pointed:<br /> <br /> stack backtrace:<br /> CPU: 0 PID: 3599 Comm: syz-executor317 Not tainted 5.18.0-rc5-syzkaller-01392-g01f4685797a5 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106<br /> bond_option_active_slave_get_rcu include/net/bonding.h:353 [inline]<br /> bond_ethtool_get_ts_info+0x32c/0x3a0 drivers/net/bonding/bond_main.c:5595<br /> __ethtool_get_ts_info+0x173/0x240 net/ethtool/common.c:554<br /> ethtool_get_phc_vclocks+0x99/0x110 net/ethtool/common.c:568<br /> sock_timestamping_bind_phc net/core/sock.c:869 [inline]<br /> sock_set_timestamping+0x3a3/0x7e0 net/core/sock.c:916<br /> sock_setsockopt+0x543/0x2ec0 net/core/sock.c:1221<br /> __sys_setsockopt+0x55e/0x6a0 net/socket.c:2223<br /> __do_sys_setsockopt net/socket.c:2238 [inline]<br /> __se_sys_setsockopt net/socket.c:2235 [inline]<br /> __x64_sys_setsockopt+0xba/0x150 net/socket.c:2235<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7f8902c8eb39<br /> <br /> Fix it by adding rcu_read_lock and take a ref on the real_dev.<br /> Since dev_hold() and dev_put() can take NULL these days, we can<br /> skip checking if real_dev exist.<br /> <br /> [1] https://lore.kernel.org/netdev/27565.1642742439@famine/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/papr_scm: Fix leaking nvdimm_events_map elements<br /> <br /> Right now &amp;#39;char *&amp;#39; elements allocated for individual &amp;#39;stat_id&amp;#39; in<br /> &amp;#39;papr_scm_priv.nvdimm_events_map[]&amp;#39; during papr_scm_pmu_check_events(), get<br /> leaked in papr_scm_remove() and papr_scm_pmu_register(),<br /> papr_scm_pmu_check_events() error paths.<br /> <br /> Also individual &amp;#39;stat_id&amp;#39; arent NULL terminated &amp;#39;char *&amp;#39; instead they are fixed<br /> 8-byte sized identifiers. However papr_scm_pmu_register() assumes it to be a<br /> NULL terminated &amp;#39;char *&amp;#39; and at other places it assumes it to be a<br /> &amp;#39;papr_scm_perf_stat.stat_id&amp;#39; sized string which is 8-byes in size.<br /> <br /> Fix this by allocating the memory for papr_scm_priv.nvdimm_events_map to also<br /> include space for &amp;#39;stat_id&amp;#39; entries. This is possible since number of available<br /> events/stat_ids are known upfront. This saves some memory and one extra level of<br /> indirection from &amp;#39;nvdimm_events_map&amp;#39; to &amp;#39;stat_id&amp;#39;. Also rest of the code<br /> can continue to call &amp;#39;kfree(papr_scm_priv.nvdimm_events_map)&amp;#39; without needing to<br /> iterate over the array and free up individual elements.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/xive: Fix refcount leak in xive_spapr_init<br /> <br /> of_find_compatible_node() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when done.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: sparcspkr - fix refcount leak in bbc_beep_probe<br /> <br /> of_find_node_by_path() calls of_find_node_opts_by_path(),<br /> which returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when done.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/fsl_rio: Fix refcount leak in fsl_rio_setup<br /> <br /> of_parse_phandle() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/rtas: Keep MSR[RI] set when calling RTAS<br /> <br /> RTAS runs in real mode (MSR[DR] and MSR[IR] unset) and in 32-bit big<br /> endian mode (MSR[SF,LE] unset).<br /> <br /> The change in MSR is done in enter_rtas() in a relatively complex way,<br /> since the MSR value could be hardcoded.<br /> <br /> Furthermore, a panic has been reported when hitting the watchdog interrupt<br /> while running in RTAS, this leads to the following stack trace:<br /> <br /> watchdog: CPU 24 Hard LOCKUP<br /> watchdog: CPU 24 TB:997512652051031, last heartbeat TB:997504470175378 (15980ms ago)<br /> ...<br /> Supported: No, Unreleased kernel<br /> CPU: 24 PID: 87504 Comm: drmgr Kdump: loaded Tainted: G E X 5.14.21-150400.71.1.bz196362_2-default #1 SLE15-SP4 (unreleased) 0d821077ef4faa8dfaf370efb5fdca1fa35f4e2c<br /> NIP: 000000001fb41050 LR: 000000001fb4104c CTR: 0000000000000000<br /> REGS: c00000000fc33d60 TRAP: 0100 Tainted: G E X (5.14.21-150400.71.1.bz196362_2-default)<br /> MSR: 8000000002981000 CR: 48800002 XER: 20040020<br /> CFAR: 000000000000011c IRQMASK: 1<br /> GPR00: 0000000000000003 ffffffffffffffff 0000000000000001 00000000000050dc<br /> GPR04: 000000001ffb6100 0000000000000020 0000000000000001 000000001fb09010<br /> GPR08: 0000000020000000 0000000000000000 0000000000000000 0000000000000000<br /> GPR12: 80040000072a40a8 c00000000ff8b680 0000000000000007 0000000000000034<br /> GPR16: 000000001fbf6e94 000000001fbf6d84 000000001fbd1db0 000000001fb3f008<br /> GPR20: 000000001fb41018 ffffffffffffffff 000000000000017f fffffffffffff68f<br /> GPR24: 000000001fb18fe8 000000001fb3e000 000000001fb1adc0 000000001fb1cf40<br /> GPR28: 000000001fb26000 000000001fb460f0 000000001fb17f18 000000001fb17000<br /> NIP [000000001fb41050] 0x1fb41050<br /> LR [000000001fb4104c] 0x1fb4104c<br /> Call Trace:<br /> Instruction dump:<br /> XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX<br /> XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX<br /> Oops: Unrecoverable System Reset, sig: 6 [#1]<br /> LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries<br /> ...<br /> Supported: No, Unreleased kernel<br /> CPU: 24 PID: 87504 Comm: drmgr Kdump: loaded Tainted: G E X 5.14.21-150400.71.1.bz196362_2-default #1 SLE15-SP4 (unreleased) 0d821077ef4faa8dfaf370efb5fdca1fa35f4e2c<br /> NIP: 000000001fb41050 LR: 000000001fb4104c CTR: 0000000000000000<br /> REGS: c00000000fc33d60 TRAP: 0100 Tainted: G E X (5.14.21-150400.71.1.bz196362_2-default)<br /> MSR: 8000000002981000 CR: 48800002 XER: 20040020<br /> CFAR: 000000000000011c IRQMASK: 1<br /> GPR00: 0000000000000003 ffffffffffffffff 0000000000000001 00000000000050dc<br /> GPR04: 000000001ffb6100 0000000000000020 0000000000000001 000000001fb09010<br /> GPR08: 0000000020000000 0000000000000000 0000000000000000 0000000000000000<br /> GPR12: 80040000072a40a8 c00000000ff8b680 0000000000000007 0000000000000034<br /> GPR16: 000000001fbf6e94 000000001fbf6d84 000000001fbd1db0 000000001fb3f008<br /> GPR20: 000000001fb41018 ffffffffffffffff 000000000000017f fffffffffffff68f<br /> GPR24: 000000001fb18fe8 000000001fb3e000 000000001fb1adc0 000000001fb1cf40<br /> GPR28: 000000001fb26000 000000001fb460f0 000000001fb17f18 000000001fb17000<br /> NIP [000000001fb41050] 0x1fb41050<br /> LR [000000001fb4104c] 0x1fb4104c<br /> Call Trace:<br /> Instruction dump:<br /> XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX<br /> XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX<br /> ---[ end trace 3ddec07f638c34a2 ]---<br /> <br /> This happens because MSR[RI] is unset when entering RTAS but there is no<br /> valid reason to not set it here.<br /> <br /> RTAS is expected to be called with MSR[RI] as specified in PAPR+ section<br /> "7.2.1 Machine State":<br /> <br /> R1–7.2.1–9. If called with MSR[RI] equal to 1, then RTAS must protect<br /> its own critical regions from recursion by setting the MSR[RI] bit to<br /> 0 when in the critical regions.<br /> <br /> Fixing this by reviewing the way MSR is compute before calling RTAS. Now a<br /> hardcoded value meaning real <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: fix deadlock caused by calling printk() under tty_port-&gt;lock<br /> <br /> pty_write() invokes kmalloc() which may invoke a normal printk() to print<br /> failure message. This can cause a deadlock in the scenario reported by<br /> syz-bot below:<br /> <br /> CPU0 CPU1 CPU2<br /> ---- ---- ----<br /> lock(console_owner);<br /> lock(&amp;port_lock_key);<br /> lock(&amp;port-&gt;lock);<br /> lock(&amp;port_lock_key);<br /> lock(&amp;port-&gt;lock);<br /> lock(console_owner);<br /> <br /> As commit dbdda842fe96 ("printk: Add console owner and waiter logic to<br /> load balance console writes") said, such deadlock can be prevented by<br /> using printk_deferred() in kmalloc() (which is invoked in the section<br /> guarded by the port-&gt;lock). But there are too many printk() on the<br /> kmalloc() path, and kmalloc() can be called from anywhere, so changing<br /> printk() to printk_deferred() is too complicated and inelegant.<br /> <br /> Therefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so<br /> that printk() will not be called, and this deadlock problem can be<br /> avoided.<br /> <br /> Syzbot reported the following lockdep error:<br /> <br /> ======================================================<br /> WARNING: possible circular locking dependency detected<br /> 5.4.143-00237-g08ccc19a-dirty #10 Not tainted<br /> ------------------------------------------------------<br /> syz-executor.4/29420 is trying to acquire lock:<br /> ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline]<br /> ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023<br /> <br /> but task is already holding lock:<br /> ffff8880119c9158 (&amp;port-&gt;lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120<br /> <br /> which lock already depends on the new lock.<br /> <br /> the existing dependency chain (in reverse order) is:<br /> <br /> -&gt; #2 (&amp;port-&gt;lock){-.-.}-{2:2}:<br /> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]<br /> _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159<br /> tty_port_tty_get drivers/tty/tty_port.c:288 [inline] lock);<br /> tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47<br /> serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767<br /> serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854<br /> serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] #1 (&amp;port_lock_key){-.-.}-{2:2}:<br /> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]<br /> _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159<br /> serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198<br />