Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: qualcomm: rmnet: fix global oob in rmnet_policy<br /> <br /> The variable rmnet_link_ops assign a *bigger* maxtype which leads to a<br /> global out-of-bounds read when parsing the netlink attributes. See bug<br /> trace below:<br /> <br /> ==================================================================<br /> BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:386 [inline]<br /> BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600<br /> Read of size 1 at addr ffffffff92c438d0 by task syz-executor.6/84207<br /> <br /> CPU: 0 PID: 84207 Comm: syz-executor.6 Tainted: G N 6.1.0 #3<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106<br /> print_address_description mm/kasan/report.c:284 [inline]<br /> print_report+0x172/0x475 mm/kasan/report.c:395<br /> kasan_report+0xbb/0x1c0 mm/kasan/report.c:495<br /> validate_nla lib/nlattr.c:386 [inline]<br /> __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600<br /> __nla_parse+0x3e/0x50 lib/nlattr.c:697<br /> nla_parse_nested_deprecated include/net/netlink.h:1248 [inline]<br /> __rtnl_newlink+0x50a/0x1880 net/core/rtnetlink.c:3485<br /> rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3594<br /> rtnetlink_rcv_msg+0x43c/0xd70 net/core/rtnetlink.c:6091<br /> netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]<br /> netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345<br /> netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> sock_sendmsg+0x154/0x190 net/socket.c:734<br /> ____sys_sendmsg+0x6df/0x840 net/socket.c:2482<br /> ___sys_sendmsg+0x110/0x1b0 net/socket.c:2536<br /> __sys_sendmsg+0xf3/0x1c0 net/socket.c:2565<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x7fdcf2072359<br /> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007fdcf13e3168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 00007fdcf219ff80 RCX: 00007fdcf2072359<br /> RDX: 0000000000000000 RSI: 0000000020000200 RDI: 0000000000000003<br /> RBP: 00007fdcf20bd493 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007fffbb8d7bdf R14: 00007fdcf13e3300 R15: 0000000000022000<br /> <br /> <br /> The buggy address belongs to the variable:<br /> rmnet_policy+0x30/0xe0<br /> <br /> The buggy address belongs to the physical page:<br /> page:0000000065bdeb3c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x155243<br /> flags: 0x200000000001000(reserved|node=0|zone=2)<br /> raw: 0200000000001000 ffffea00055490c8 ffffea00055490c8 0000000000000000<br /> raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> <br /> Memory state around the buggy address:<br /> ffffffff92c43780: f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9 00 00 00 07<br /> ffffffff92c43800: f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 06 f9 f9 f9<br /> &gt;ffffffff92c43880: f9 f9 f9 f9 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9<br /> ^<br /> ffffffff92c43900: 00 00 00 00 00 00 00 00 07 f9 f9 f9 f9 f9 f9 f9<br /> ffffffff92c43980: 00 00 00 07 f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9<br /> <br /> According to the comment of `nla_parse_nested_deprecated`, the maxtype<br /> should be len(destination array) - 1. Hence use `IFLA_RMNET_MAX` here.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: vgic-its: Avoid potential UAF in LPI translation cache<br /> <br /> There is a potential UAF scenario in the case of an LPI translation<br /> cache hit racing with an operation that invalidates the cache, such<br /> as a DISCARD ITS command. The root of the problem is that<br /> vgic_its_check_cache() does not elevate the refcount on the vgic_irq<br /> before dropping the lock that serializes refcount changes.<br /> <br /> Have vgic_its_check_cache() raise the refcount on the returned vgic_irq<br /> and add the corresponding decrement after queueing the interrupt.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pwm: Fix out-of-bounds access in of_pwm_single_xlate()<br /> <br /> With args-&gt;args_count == 2 args-&gt;args[2] is not defined. Actually the<br /> flags are contained in args-&gt;args[1].

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: fix netdev_priv() dereference before check on non-DSA netdevice events<br /> <br /> After the blamed commit, we started doing this dereference for every<br /> NETDEV_CHANGEUPPER and NETDEV_PRECHANGEUPPER event in the system.<br /> <br /> static inline struct dsa_port *dsa_user_to_port(const struct net_device *dev)<br /> {<br /> struct dsa_user_priv *p = netdev_priv(dev);<br /> <br /> return p-&gt;dp;<br /> }<br /> <br /> Which is obviously bogus, because not all net_devices have a netdev_priv()<br /> of type struct dsa_user_priv. But struct dsa_user_priv is fairly small,<br /> and p-&gt;dp means dereferencing 8 bytes starting with offset 16. Most<br /> drivers allocate that much private memory anyway, making our access not<br /> fault, and we discard the bogus data quickly afterwards, so this wasn&amp;#39;t<br /> caught.<br /> <br /> But the dummy interface is somewhat special in that it calls<br /> alloc_netdev() with a priv size of 0. So every netdev_priv() dereference<br /> is invalid, and we get this when we emit a NETDEV_PRECHANGEUPPER event<br /> with a VLAN as its new upper:<br /> <br /> $ ip link add dummy1 type dummy<br /> $ ip link add link dummy1 name dummy1.100 type vlan id 100<br /> [ 43.309174] ==================================================================<br /> [ 43.316456] BUG: KASAN: slab-out-of-bounds in dsa_user_prechangeupper+0x30/0xe8<br /> [ 43.323835] Read of size 8 at addr ffff3f86481d2990 by task ip/374<br /> [ 43.330058]<br /> [ 43.342436] Call trace:<br /> [ 43.366542] dsa_user_prechangeupper+0x30/0xe8<br /> [ 43.371024] dsa_user_netdevice_event+0xb38/0xee8<br /> [ 43.375768] notifier_call_chain+0xa4/0x210<br /> [ 43.379985] raw_notifier_call_chain+0x24/0x38<br /> [ 43.384464] __netdev_upper_dev_link+0x3ec/0x5d8<br /> [ 43.389120] netdev_upper_dev_link+0x70/0xa8<br /> [ 43.393424] register_vlan_dev+0x1bc/0x310<br /> [ 43.397554] vlan_newlink+0x210/0x248<br /> [ 43.401247] rtnl_newlink+0x9fc/0xe30<br /> [ 43.404942] rtnetlink_rcv_msg+0x378/0x580<br /> <br /> Avoid the kernel oops by dereferencing after the type check, as customary.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxsw: spectrum_acl_tcam: Fix NULL pointer dereference in error path<br /> <br /> When calling mlxsw_sp_acl_tcam_region_destroy() from an error path after<br /> failing to attach the region to an ACL group, we hit a NULL pointer<br /> dereference upon &amp;#39;region-&gt;group-&gt;tcam&amp;#39; [1].<br /> <br /> Fix by retrieving the &amp;#39;tcam&amp;#39; pointer using mlxsw_sp_acl_to_tcam().<br /> <br /> [1]<br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [...]<br /> RIP: 0010:mlxsw_sp_acl_tcam_region_destroy+0xa0/0xd0<br /> [...]<br /> Call Trace:<br /> mlxsw_sp_acl_tcam_vchunk_get+0x88b/0xa20<br /> mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0<br /> mlxsw_sp_acl_rule_add+0x47/0x240<br /> mlxsw_sp_flower_replace+0x1a9/0x1d0<br /> tc_setup_cb_add+0xdc/0x1c0<br /> fl_hw_replace_filter+0x146/0x1f0<br /> fl_change+0xc17/0x1360<br /> tc_new_tfilter+0x472/0xb90<br /> rtnetlink_rcv_msg+0x313/0x3b0<br /> netlink_rcv_skb+0x58/0x100<br /> netlink_unicast+0x244/0x390<br /> netlink_sendmsg+0x1e4/0x440<br /> ____sys_sendmsg+0x164/0x260<br /> ___sys_sendmsg+0x9a/0xe0<br /> __sys_sendmsg+0x7a/0xc0<br /> do_syscall_64+0x40/0xe0<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hisi_acc_vfio_pci: Update migration data pointer correctly on saving/resume<br /> <br /> When the optional PRE_COPY support was added to speed up the device<br /> compatibility check, it failed to update the saving/resuming data<br /> pointers based on the fd offset. This results in migration data<br /> corruption and when the device gets started on the destination the<br /> following error is reported in some cases,<br /> <br /> [ 478.907684] arm-smmu-v3 arm-smmu-v3.2.auto: event 0x10 received:<br /> [ 478.913691] arm-smmu-v3 arm-smmu-v3.2.auto: 0x0000310200000010<br /> [ 478.919603] arm-smmu-v3 arm-smmu-v3.2.auto: 0x000002088000007f<br /> [ 478.925515] arm-smmu-v3 arm-smmu-v3.2.auto: 0x0000000000000000<br /> [ 478.931425] arm-smmu-v3 arm-smmu-v3.2.auto: 0x0000000000000000<br /> [ 478.947552] hisi_zip 0000:31:00.0: qm_axi_rresp [error status=0x1] found<br /> [ 478.955930] hisi_zip 0000:31:00.0: qm_db_timeout [error status=0x400] found<br /> [ 478.955944] hisi_zip 0000:31:00.0: qm sq doorbell timeout in function 2

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length<br /> <br /> If the host sends an H2CData command with an invalid DATAL,<br /> the kernel may crash in nvmet_tcp_build_pdu_iovec().<br /> <br /> Unable to handle kernel NULL pointer dereference at<br /> virtual address 0000000000000000<br /> lr : nvmet_tcp_io_work+0x6ac/0x718 [nvmet_tcp]<br /> Call trace:<br /> process_one_work+0x174/0x3c8<br /> worker_thread+0x2d0/0x3e8<br /> kthread+0x104/0x110<br /> <br /> Fix the bug by raising a fatal error if DATAL isn&amp;#39;t coherent<br /> with the packet size.<br /> Also, the PDU length should never exceed the MAXH2CDATA parameter which<br /> has been communicated to the host in nvmet_tcp_handle_icreq().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu: Don&amp;#39;t reserve 0-length IOVA region<br /> <br /> When the bootloader/firmware doesn&amp;#39;t setup the framebuffers, their<br /> address and size are 0 in "iommu-addresses" property. If IOVA region is<br /> reserved with 0 length, then it ends up corrupting the IOVA rbtree with<br /> an entry which has pfn_hi

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: imx: fix tx statemachine deadlock<br /> <br /> When using the serial port as RS485 port, the tx statemachine is used to<br /> control the RTS pin to drive the RS485 transceiver TX_EN pin. When the<br /> TTY port is closed in the middle of a transmission (for instance during<br /> userland application crash), imx_uart_shutdown disables the interface<br /> and disables the Transmission Complete interrupt. afer that,<br /> imx_uart_stop_tx bails on an incomplete transmission, to be retriggered<br /> by the TC interrupt. This interrupt is disabled and therefore the tx<br /> statemachine never transitions out of SEND. The statemachine is in<br /> deadlock now, and the TX_EN remains low, making the interface useless.<br /> <br /> imx_uart_stop_tx now checks for incomplete transmission AND whether TC<br /> interrupts are enabled before bailing to be retriggered. This makes sure<br /> the state machine handling is reached, and is properly set to<br /> WAIT_AFTER_SEND.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: 8250: omap: Don&amp;#39;t skip resource freeing if pm_runtime_resume_and_get() failed<br /> <br /> Returning an error code from .remove() makes the driver core emit the<br /> little helpful error message:<br /> <br /> remove callback returned a non-zero value. This will be ignored.<br /> <br /> and then remove the device anyhow. So all resources that were not freed<br /> are leaked in this case. Skipping serial8250_unregister_port() has the<br /> potential to keep enough of the UART around to trigger a use-after-free.<br /> <br /> So replace the error return (and with it the little helpful error<br /> message) by a more useful error message and continue to cleanup.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: add check that partition length needs to be aligned with block size<br /> <br /> Before calling add partition or resize partition, there is no check<br /> on whether the length is aligned with the logical block size.<br /> If the logical block size of the disk is larger than 512 bytes,<br /> then the partition size maybe not the multiple of the logical block size,<br /> and when the last sector is read, bio_truncate() will adjust the bio size,<br /> resulting in an IO error if the size of the read command is smaller than<br /> the logical block size.If integrity data is supported, this will also<br /> result in a null pointer dereference when calling bio_integrity_free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: v4l: async: Fix duplicated list deletion<br /> <br /> The list deletion call dropped here is already called from the<br /> helper function in the line before. Having a second list_del()<br /> call results in either a warning (with CONFIG_DEBUG_LIST=y):<br /> <br /> list_del corruption, c46c8198-&gt;next is LIST_POISON1 (00000100)<br /> <br /> If CONFIG_DEBUG_LIST is disabled the operation results in a<br /> kernel error due to NULL pointer dereference.