Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arp: Prevent overflow in arp_req_get().<br /> <br /> syzkaller reported an overflown write in arp_req_get(). [0]<br /> <br /> When ioctl(SIOCGARP) is issued, arp_req_get() looks up an neighbour<br /> entry and copies neigh-&gt;ha to struct arpreq.arp_ha.sa_data.<br /> <br /> The arp_ha here is struct sockaddr, not struct sockaddr_storage, so<br /> the sa_data buffer is just 14 bytes.<br /> <br /> In the splat below, 2 bytes are overflown to the next int field,<br /> arp_flags. We initialise the field just after the memcpy(), so it&amp;#39;s<br /> not a problem.<br /> <br /> However, when dev-&gt;addr_len is greater than 22 (e.g. MAX_ADDR_LEN),<br /> arp_netmask is overwritten, which could be set as htonl(0xFFFFFFFFUL)<br /> in arp_ioctl() before calling arp_req_get().<br /> <br /> To avoid the overflow, let&amp;#39;s limit the max length of memcpy().<br /> <br /> Note that commit b5f0de6df6dc ("net: dev: Convert sa_data to flexible<br /> array in struct sockaddr") just silenced syzkaller.<br /> <br /> [0]:<br /> memcpy: detected field-spanning write (size 16) of single field "r-&gt;arp_ha.sa_data" at net/ipv4/arp.c:1128 (size 14)<br /> WARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128<br /> Modules linked in:<br /> CPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014<br /> RIP: 0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128<br /> Code: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6<br /> RSP: 0018:ffffc900050b7998 EFLAGS: 00010286<br /> RAX: 0000000000000000 RBX: ffff88803a815000 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001<br /> RBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000<br /> R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010<br /> FS: 00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> arp_ioctl+0x33f/0x4b0 net/ipv4/arp.c:1261<br /> inet_ioctl+0x314/0x3a0 net/ipv4/af_inet.c:981<br /> sock_do_ioctl+0xdf/0x260 net/socket.c:1204<br /> sock_ioctl+0x3ef/0x650 net/socket.c:1321<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:870 [inline]<br /> __se_sys_ioctl fs/ioctl.c:856 [inline]<br /> __x64_sys_ioctl+0x18e/0x220 fs/ioctl.c:856<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x37/0x90 arch/x86/entry/common.c:81<br /> entry_SYSCALL_64_after_hwframe+0x64/0xce<br /> RIP: 0033:0x7f172b262b8d<br /> Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 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:00007f172bf300b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 00007f172b3abf80 RCX: 00007f172b262b8d<br /> RDX: 0000000020000000 RSI: 0000000000008954 RDI: 0000000000000003<br /> RBP: 00007f172b2d3493 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> afs: Increase buffer size in afs_update_volume_status()<br /> <br /> The max length of volume-&gt;vid value is 20 characters.<br /> So increase idbuf[] size up to 24 to avoid overflow.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.<br /> <br /> [DH: Actually, it&amp;#39;s 20 + NUL, so increase it to 24 and use snprintf()]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: act_mirred: use the backlog for mirred ingress<br /> <br /> The test Davide added in commit ca22da2fbd69 ("act_mirred: use the backlog<br /> for nested calls to mirred ingress") hangs our testing VMs every 10 or so<br /> runs, with the familiar tcp_v4_rcv -&gt; tcp_v4_rcv deadlock reported by<br /> lockdep.<br /> <br /> The problem as previously described by Davide (see Link) is that<br /> if we reverse flow of traffic with the redirect (egress -&gt; ingress)<br /> we may reach the same socket which generated the packet. And we may<br /> still be holding its socket lock. The common solution to such deadlocks<br /> is to put the packet in the Rx backlog, rather than run the Rx path<br /> inline. Do that for all egress -&gt; ingress reversals, not just once<br /> we started to nest mirred calls.<br /> <br /> In the past there was a concern that the backlog indirection will<br /> lead to loss of error reporting / less accurate stats. But the current<br /> workaround does not seem to address the issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dccp/tcp: Unhash sk from ehash for tb2 alloc failure after check_estalblished().<br /> <br /> syzkaller reported a warning [0] in inet_csk_destroy_sock() with no<br /> repro.<br /> <br /> WARN_ON(inet_sk(sk)-&gt;inet_num &amp;&amp; !inet_csk(sk)-&gt;icsk_bind_hash);<br /> <br /> However, the syzkaller&amp;#39;s log hinted that connect() failed just before<br /> the warning due to FAULT_INJECTION. [1]<br /> <br /> When connect() is called for an unbound socket, we search for an<br /> available ephemeral port. If a bhash bucket exists for the port, we<br /> call __inet_check_established() or __inet6_check_established() to check<br /> if the bucket is reusable.<br /> <br /> If reusable, we add the socket into ehash and set inet_sk(sk)-&gt;inet_num.<br /> <br /> Later, we look up the corresponding bhash2 bucket and try to allocate<br /> it if it does not exist.<br /> <br /> Although it rarely occurs in real use, if the allocation fails, we must<br /> revert the changes by check_established(). Otherwise, an unconnected<br /> socket could illegally occupy an ehash entry.<br /> <br /> Note that we do not put tw back into ehash because sk might have<br /> already responded to a packet for tw and it would be better to free<br /> tw earlier under such memory presure.<br /> <br /> [0]:<br /> WARNING: CPU: 0 PID: 350830 at net/ipv4/inet_connection_sock.c:1193 inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193)<br /> Modules linked in:<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193)<br /> Code: 41 5c 41 5d 41 5e e9 2d 4a 3d fd e8 28 4a 3d fd 48 89 ef e8 f0 cd 7d ff 5b 5d 41 5c 41 5d 41 5e e9 13 4a 3d fd e8 0e 4a 3d fd 0b e9 61 fe ff ff e8 02 4a 3d fd 4c 89 e7 be 03 00 00 00 e8 05<br /> RSP: 0018:ffffc9000b21fd38 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: 0000000000009e78 RCX: ffffffff840bae40<br /> RDX: ffff88806e46c600 RSI: ffffffff840bb012 RDI: ffff88811755cca8<br /> RBP: ffff88811755c880 R08: 0000000000000003 R09: 0000000000000000<br /> R10: 0000000000009e78 R11: 0000000000000000 R12: ffff88811755c8e0<br /> R13: ffff88811755c892 R14: ffff88811755c918 R15: 0000000000000000<br /> FS: 00007f03e5243800(0000) GS:ffff88811ae00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000001b32f21000 CR3: 0000000112ffe001 CR4: 0000000000770ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193)<br /> dccp_close (net/dccp/proto.c:1078)<br /> inet_release (net/ipv4/af_inet.c:434)<br /> __sock_release (net/socket.c:660)<br /> sock_close (net/socket.c:1423)<br /> __fput (fs/file_table.c:377)<br /> __fput_sync (fs/file_table.c:462)<br /> __x64_sys_close (fs/open.c:1557 fs/open.c:1539 fs/open.c:1539)<br /> do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)<br /> RIP: 0033:0x7f03e53852bb<br /> Code: 03 00 00 00 0f 05 48 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 43 c9 f5 ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 3d 00 f0 ff ff 77 35 44 89 c7 89 44 24 0c e8 a1 c9 f5 ff 8b 44<br /> RSP: 002b:00000000005dfba0 EFLAGS: 00000293 ORIG_RAX: 0000000000000003<br /> RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f03e53852bb<br /> RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000003<br /> RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000167c<br /> R10: 0000000008a79680 R11: 0000000000000293 R12: 00007f03e4e43000<br /> R13: 00007f03e4e43170 R14: 00007f03e4e43178 R15: 00007f03e4e43170<br /> <br /> <br /> [1]:<br /> FAULT_INJECTION: forcing a failure.<br /> name failslab, interval 1, probability 0, space 0, times 0<br /> CPU: 0 PID: 350833 Comm: syz-executor.1 Not tainted 6.7.0-12272-g2121c43f88f5 #9<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl (lib/dump_stack.c:107 (discriminator 1))<br /> should_fail_ex (lib/fault-inject.c:52 lib/fault-inject.c:153)<br /> should_failslab (mm/slub.c:3748)<br /> kmem_cache_alloc (mm/slub.c:3763 mm/slub.c:3842 mm/slub.c:3867)<br /> inet_bind2_bucket_create <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: smartpqi: Fix disable_managed_interrupts<br /> <br /> Correct blk-mq registration issue with module parameter<br /> disable_managed_interrupts enabled.<br /> <br /> When we turn off the default PCI_IRQ_AFFINITY flag, the driver needs to<br /> register with blk-mq using blk_mq_map_queues(). The driver is currently<br /> calling blk_mq_pci_map_queues() which results in a stack trace and possibly<br /> undefined behavior.<br /> <br /> Stack Trace:<br /> [ 7.860089] scsi host2: smartpqi<br /> [ 7.871934] WARNING: CPU: 0 PID: 238 at block/blk-mq-pci.c:52 blk_mq_pci_map_queues+0xca/0xd0<br /> [ 7.889231] Modules linked in: sd_mod t10_pi sg uas smartpqi(+) crc32c_intel scsi_transport_sas usb_storage dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse<br /> [ 7.924755] CPU: 0 PID: 238 Comm: kworker/0:3 Not tainted 4.18.0-372.88.1.el8_6_smartpqi_test.x86_64 #1<br /> [ 7.944336] Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 03/08/2022<br /> [ 7.963026] Workqueue: events work_for_cpu_fn<br /> [ 7.978275] RIP: 0010:blk_mq_pci_map_queues+0xca/0xd0<br /> [ 7.978278] Code: 48 89 de 89 c7 e8 f6 0f 4f 00 3b 05 c4 b7 8e 01 72 e1 5b 31 c0 5d 41 5c 41 5d 41 5e 41 5f e9 7d df 73 00 31 c0 e9 76 df 73 00 0b eb bc 90 90 0f 1f 44 00 00 41 57 49 89 ff 41 56 41 55 41 54<br /> [ 7.978280] RSP: 0018:ffffa95fc3707d50 EFLAGS: 00010216<br /> [ 7.978283] RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000000000010<br /> [ 7.978284] RDX: 0000000000000004 RSI: 0000000000000000 RDI: ffff9190c32d4310<br /> [ 7.978286] RBP: 0000000000000000 R08: ffffa95fc3707d38 R09: ffff91929b81ac00<br /> [ 7.978287] R10: 0000000000000001 R11: ffffa95fc3707ac0 R12: 0000000000000000<br /> [ 7.978288] R13: ffff9190c32d4000 R14: 00000000ffffffff R15: ffff9190c4c950a8<br /> [ 7.978290] FS: 0000000000000000(0000) GS:ffff9193efc00000(0000) knlGS:0000000000000000<br /> [ 7.978292] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 8.172814] CR2: 000055d11166c000 CR3: 00000002dae10002 CR4: 00000000007706f0<br /> [ 8.172816] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 8.172817] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 8.172818] PKRU: 55555554<br /> [ 8.172819] Call Trace:<br /> [ 8.172823] blk_mq_alloc_tag_set+0x12e/0x310<br /> [ 8.264339] scsi_add_host_with_dma.cold.9+0x30/0x245<br /> [ 8.279302] pqi_ctrl_init+0xacf/0xc8e [smartpqi]<br /> [ 8.294085] ? pqi_pci_probe+0x480/0x4c8 [smartpqi]<br /> [ 8.309015] pqi_pci_probe+0x480/0x4c8 [smartpqi]<br /> [ 8.323286] local_pci_probe+0x42/0x80<br /> [ 8.337855] work_for_cpu_fn+0x16/0x20<br /> [ 8.351193] process_one_work+0x1a7/0x360<br /> [ 8.364462] ? create_worker+0x1a0/0x1a0<br /> [ 8.379252] worker_thread+0x1ce/0x390<br /> [ 8.392623] ? create_worker+0x1a0/0x1a0<br /> [ 8.406295] kthread+0x10a/0x120<br /> [ 8.418428] ? set_kthread_struct+0x50/0x50<br /> [ 8.431532] ret_from_fork+0x1f/0x40<br /> [ 8.444137] ---[ end trace 1bf0173d39354506 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: virtio/akcipher - Fix stack overflow on memcpy<br /> <br /> sizeof(struct virtio_crypto_akcipher_session_para) is less than<br /> sizeof(struct virtio_crypto_op_ctrl_req::u), copying more bytes from<br /> stack variable leads stack overflow. Clang reports this issue by<br /> commands:<br /> make -j CC=clang-14 mrproper &gt;/dev/null 2&gt;&amp;1<br /> make -j O=/tmp/crypto-build CC=clang-14 allmodconfig &gt;/dev/null 2&gt;&amp;1<br /> make -j O=/tmp/crypto-build W=1 CC=clang-14 drivers/crypto/virtio/<br /> virtio_crypto_akcipher_algs.o

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: roles: fix NULL pointer issue when put module&amp;#39;s reference<br /> <br /> In current design, usb role class driver will get usb_role_switch parent&amp;#39;s<br /> module reference after the user get usb_role_switch device and put the<br /> reference after the user put the usb_role_switch device. However, the<br /> parent device of usb_role_switch may be removed before the user put the<br /> usb_role_switch. If so, then, NULL pointer issue will be met when the user<br /> put the parent module&amp;#39;s reference.<br /> <br /> This will save the module pointer in structure of usb_role_switch. Then,<br /> we don&amp;#39;t need to find module by iterating long relations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix racing between bpf_timer_cancel_and_free and bpf_timer_cancel<br /> <br /> The following race is possible between bpf_timer_cancel_and_free<br /> and bpf_timer_cancel. It will lead a UAF on the timer-&gt;timer.<br /> <br /> bpf_timer_cancel();<br /> spin_lock();<br /> t = timer-&gt;time;<br /> spin_unlock();<br /> <br /> bpf_timer_cancel_and_free();<br /> spin_lock();<br /> t = timer-&gt;timer;<br /> timer-&gt;timer = NULL;<br /> spin_unlock();<br /> hrtimer_cancel(&amp;t-&gt;timer);<br /> kfree(t);<br /> <br /> /* UAF on t */<br /> hrtimer_cancel(&amp;t-&gt;timer);<br /> <br /> In bpf_timer_cancel_and_free, this patch frees the timer-&gt;timer<br /> after a rcu grace period. This requires a rcu_head addition<br /> to the "struct bpf_hrtimer". Another kfree(t) happens in bpf_timer_init,<br /> this does not need a kfree_rcu because it is still under the<br /> spin_lock and timer-&gt;timer has not been visible by others yet.<br /> <br /> In bpf_timer_cancel, rcu_read_lock() is added because this helper<br /> can be used in a non rcu critical section context (e.g. from<br /> a sleepable bpf prog). Other timer-&gt;timer usages in helpers.c<br /> have been audited, bpf_timer_cancel() is the only place where<br /> timer-&gt;timer is used outside of the spin_lock.<br /> <br /> Another solution considered is to mark a t-&gt;flag in bpf_timer_cancel<br /> and clear it after hrtimer_cancel() is done. In bpf_timer_cancel_and_free,<br /> it busy waits for the flag to be cleared before kfree(t). This patch<br /> goes with a straight forward solution and frees timer-&gt;timer after<br /> a rcu grace period.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/srpt: Support specifying the srpt_service_guid parameter<br /> <br /> Make loading ib_srpt with this parameter set work. The current behavior is<br /> that setting that parameter while loading the ib_srpt kernel module<br /> triggers the following kernel crash:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> Call Trace:<br /> <br /> parse_one+0x18c/0x1d0<br /> parse_args+0xe1/0x230<br /> load_module+0x8de/0xa60<br /> init_module_from_file+0x8b/0xd0<br /> idempotent_init_module+0x181/0x240<br /> __x64_sys_finit_module+0x5a/0xb0<br /> do_syscall_64+0x5f/0xe0<br /> entry_SYSCALL_64_after_hwframe+0x6e/0x76

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: act_mirred: don&amp;#39;t override retval if we already lost the skb<br /> <br /> If we&amp;#39;re redirecting the skb, and haven&amp;#39;t called tcf_mirred_forward(),<br /> yet, we need to tell the core to drop the skb by setting the retcode<br /> to SHOT. If we have called tcf_mirred_forward(), however, the skb<br /> is out of our hands and returning SHOT will lead to UaF.<br /> <br /> Move the retval override to the error path which actually need it.

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

The HCL BigFix Inventory server is vulnerable to path traversal which enables an attacker to read internal application files from the Inventory server. The BigFix Inventory server does not properly restrict the served static file.<br />