Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LSM: general protection fault in legacy_parse_param<br /> <br /> The usual LSM hook "bail on fail" scheme doesn&amp;#39;t work for cases where<br /> a security module may return an error code indicating that it does not<br /> recognize an input. In this particular case Smack sees a mount option<br /> that it recognizes, and returns 0. A call to a BPF hook follows, which<br /> returns -ENOPARAM, which confuses the caller because Smack has processed<br /> its data.<br /> <br /> The SELinux hook incorrectly returns 1 on success. There was a time<br /> when this was correct, however the current expectation is that it<br /> return 0 on success. This is repaired.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hns3: add vlan list lock to protect vlan list<br /> <br /> When adding port base VLAN, vf VLAN need to remove from HW and modify<br /> the vlan state in vf VLAN list as false. If the periodicity task is<br /> freeing the same node, it may cause "use after free" error.<br /> This patch adds a vlan list lock to protect the vlan list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: sparx5: switchdev: fix possible NULL pointer dereference<br /> <br /> As the possible failure of the allocation, devm_kzalloc() may return NULL<br /> pointer.<br /> Therefore, it should be better to check the &amp;#39;db&amp;#39; in order to prevent<br /> the dereference of NULL pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: nomadik: Add missing of_node_put() in nmk_pinctrl_probe<br /> <br /> This node pointer is returned by of_parse_phandle() with refcount<br /> incremented in this function. Calling of_node_put() to avoid<br /> the refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: visconti: prevent array overflow in visconti_clk_register_gates()<br /> <br /> This code was using -1 to represent that there was no reset function.<br /> Unfortunately, the -1 was stored in u8 so the if (clks[i].rs_id &gt;= 0)<br /> condition was always true. This lead to an out of bounds access in<br /> visconti_clk_register_gates().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: Fix clk_hw_get_clk() when dev is NULL<br /> <br /> Any registered clk_core structure can have a NULL pointer in its dev<br /> field. While never actually documented, this is evidenced by the wide<br /> usage of clk_register and clk_hw_register with a NULL device pointer,<br /> and the fact that the core of_clk_hw_register() function also passes a<br /> NULL device pointer.<br /> <br /> A call to clk_hw_get_clk() on a clk_hw struct whose clk_core is in that<br /> case will result in a NULL pointer derefence when it calls dev_name() on<br /> that NULL device pointer.<br /> <br /> Add a test for this case and use NULL as the dev_id if the device<br /> pointer is NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> remoteproc: qcom_q6v5_mss: Fix some leaks in q6v5_alloc_memory_region<br /> <br /> The device_node pointer is returned by of_parse_phandle() or<br /> of_get_child_by_name() with refcount incremented.<br /> We should use of_node_put() on it when done.<br /> <br /> This function only call of_node_put(node) when of_address_to_resource<br /> succeeds, missing error cases.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: qcom: clk-rcg2: Update logic to calculate D value for RCG<br /> <br /> The display pixel clock has a requirement on certain newer platforms to<br /> support M/N as (2/3) and the final D value calculated results in<br /> underflow errors.<br /> As the current implementation does not check for D value is within<br /> the accepted range for a given M &amp; N value. Update the logic to<br /> calculate the final D value based on the range.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: act_ct: fix ref leak when switching zones<br /> <br /> When switching zones or network namespaces without doing a ct clear in<br /> between, it is now leaking a reference to the old ct entry. That&amp;#39;s<br /> because tcf_ct_skb_nfct_cached() returns false and<br /> tcf_ct_flow_table_lookup() may simply overwrite it.<br /> <br /> The fix is to, as the ct entry is not reusable, free it already at<br /> tcf_ct_skb_nfct_cached().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: use spin_lock to avoid hang<br /> <br /> [14696.634553] task:cat state:D stack: 0 pid:1613738 ppid:1613735 flags:0x00000004<br /> [14696.638285] Call Trace:<br /> [14696.639038] <br /> [14696.640032] __schedule+0x302/0x930<br /> [14696.640969] schedule+0x58/0xd0<br /> [14696.641799] schedule_preempt_disabled+0x18/0x30<br /> [14696.642890] __mutex_lock.constprop.0+0x2fb/0x4f0<br /> [14696.644035] ? mod_objcg_state+0x10c/0x310<br /> [14696.645040] ? obj_cgroup_charge+0xe1/0x170<br /> [14696.646067] __mutex_lock_slowpath+0x13/0x20<br /> [14696.647126] mutex_lock+0x34/0x40<br /> [14696.648070] stat_show+0x25/0x17c0 [f2fs]<br /> [14696.649218] seq_read_iter+0x120/0x4b0<br /> [14696.650289] ? aa_file_perm+0x12a/0x500<br /> [14696.651357] ? lru_cache_add+0x1c/0x20<br /> [14696.652470] seq_read+0xfd/0x140<br /> [14696.653445] full_proxy_read+0x5c/0x80<br /> [14696.654535] vfs_read+0xa0/0x1a0<br /> [14696.655497] ksys_read+0x67/0xe0<br /> [14696.656502] __x64_sys_read+0x1a/0x20<br /> [14696.657580] do_syscall_64+0x3b/0xc0<br /> [14696.658671] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [14696.660068] RIP: 0033:0x7efe39df1cb2<br /> [14696.661133] RSP: 002b:00007ffc8badd948 EFLAGS: 00000246 ORIG_RAX: 0000000000000000<br /> [14696.662958] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007efe39df1cb2<br /> [14696.664757] RDX: 0000000000020000 RSI: 00007efe399df000 RDI: 0000000000000003<br /> [14696.666542] RBP: 00007efe399df000 R08: 00007efe399de010 R09: 00007efe399de010<br /> [14696.668363] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000000000<br /> [14696.670155] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000<br /> [14696.671965] <br /> [14696.672826] task:umount state:D stack: 0 pid:1614985 ppid:1614984 flags:0x00004000<br /> [14696.674930] Call Trace:<br /> [14696.675903] <br /> [14696.676780] __schedule+0x302/0x930<br /> [14696.677927] schedule+0x58/0xd0<br /> [14696.679019] schedule_preempt_disabled+0x18/0x30<br /> [14696.680412] __mutex_lock.constprop.0+0x2fb/0x4f0<br /> [14696.681783] ? destroy_inode+0x65/0x80<br /> [14696.683006] __mutex_lock_slowpath+0x13/0x20<br /> [14696.684305] mutex_lock+0x34/0x40<br /> [14696.685442] f2fs_destroy_stats+0x1e/0x60 [f2fs]<br /> [14696.686803] f2fs_put_super+0x158/0x390 [f2fs]<br /> [14696.688238] generic_shutdown_super+0x7a/0x120<br /> [14696.689621] kill_block_super+0x27/0x50<br /> [14696.690894] kill_f2fs_super+0x7f/0x100 [f2fs]<br /> [14696.692311] deactivate_locked_super+0x35/0xa0<br /> [14696.693698] deactivate_super+0x40/0x50<br /> [14696.694985] cleanup_mnt+0x139/0x190<br /> [14696.696209] __cleanup_mnt+0x12/0x20<br /> [14696.697390] task_work_run+0x64/0xa0<br /> [14696.698587] exit_to_user_mode_prepare+0x1b7/0x1c0<br /> [14696.700053] syscall_exit_to_user_mode+0x27/0x50<br /> [14696.701418] do_syscall_64+0x48/0xc0<br /> [14696.702630] entry_SYSCALL_64_after_hwframe+0x44/0xae

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: don&amp;#39;t BUG if someone dirty pages without asking ext4 first<br /> <br /> [un]pin_user_pages_remote is dirtying pages without properly warning<br /> the file system in advance. A related race was noted by Jan Kara in<br /> 2018[1]; however, more recently instead of it being a very hard-to-hit<br /> race, it could be reliably triggered by process_vm_writev(2) which was<br /> discovered by Syzbot[2].<br /> <br /> This is technically a bug in mm/gup.c, but arguably ext4 is fragile in<br /> that if some other kernel subsystem dirty pages without properly<br /> notifying the file system using page_mkwrite(), ext4 will BUG, while<br /> other file systems will not BUG (although data will still be lost).<br /> <br /> So instead of crashing with a BUG, issue a warning (since there may be<br /> potential data loss) and just mark the page as clean to avoid<br /> unprivileged denial of service attacks until the problem can be<br /> properly fixed. More discussion and background can be found in the<br /> thread starting at [2].<br /> <br /> [1] https://lore.kernel.org/linux-mm/20180103100430.GE4911@quack2.suse.cz<br /> [2] https://lore.kernel.org/r/Yg0m6IjcNmfaSokM@google.com