Page 5 of 1645 results (0.008 seconds)

CVSS: -EPSS: 0%CPEs: 10EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report. • https://git.kernel.org/stable/c/27ce405039bfe6d3f4143415c638f56a3df77dca https://git.kernel.org/stable/c/b2b6cadad699d44a8a5b2a60f3d960e00d6fb3b7 https://git.kernel.org/stable/c/fe6c9b48ebc920ff21c10c50ab2729440c734254 https://git.kernel.org/stable/c/e7ea60184e1e88a3c9e437b3265cbb6439aa7e26 https://git.kernel.org/stable/c/3f9e88f2672c4635960570ee9741778d4135ecf5 https://git.kernel.org/stable/c/d7dc68d82ab3fcfc3f65322465da3d7031d4ab46 https://git.kernel.org/stable/c/05ade5d4337867929e7ef664e7ac8e0c734f1aaf https://git.kernel.org/stable/c/1884ab3d22536a5c14b17c78c2ce76d17 •

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: security/keys: fix slab-out-of-bounds in key_task_permission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. • https://git.kernel.org/stable/c/b2a4df200d570b2c33a57e1ebfa5896e4bc81b69 https://git.kernel.org/stable/c/c3ce634ad953ce48c75c39bdfd8b711dd95f346f https://git.kernel.org/stable/c/4efb69a0e294ef201bcdf7ce3d6202cd0a545a5d https://git.kernel.org/stable/c/1e4332581cd4eed75aea77af6f66cdcdda8b49b9 https://git.kernel.org/stable/c/199c20fb7499c79557a075dc24e9a7dae7d9f1ce https://git.kernel.org/stable/c/bbad2d5b6c99db468d8f88b6ba6a56ed409b4881 https://git.kernel.org/stable/c/3e79ad156bedf2da0ab909a118d2cec6c9c22b79 https://git.kernel.org/stable/c/e0a317ad68e4ea48a0158187238c5407e •

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: sctp: properly validate chunk size in sctp_sf_ootb() A size validation fix similar to that in Commit 50619dbf8db7 ("sctp: add size validation when walking chunks") is also required in sctp_sf_ootb() to address a crash reported by syzbot: BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166 sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159 ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233 • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/67b9a278b80f71ec62091ded97c6bcbea33b5ec3 https://git.kernel.org/stable/c/9b5d42aeaf1a52f73b003a33da6deef7df34685f https://git.kernel.org/stable/c/40b283ba76665437bc2ac72079c51b57b25bff9e https://git.kernel.org/stable/c/a758aa6a773bb872196bcc3173171ef8996bddf0 https://git.kernel.org/stable/c/bf9bff13225baf5f658577f7d985fc4933d79527 https://git.kernel.org/stable/c/d3fb3cc83cf313e4f87063ce0f3fea76b071567b https://git.kernel.org/stable/c/8820d2d6589f62ee5514793fff9b50c9f •

CVSS: -EPSS: 0%CPEs: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: net: enetc: allocate vf_state during PF probes In the previous implementation, vf_state is allocated memory only when VF is enabled. However, net_device_ops::ndo_set_vf_mac() may be called before VF is enabled to configure the MAC address of VF. If this is the case, enetc_pf_set_vf_mac() will access vf_state, resulting in access to a null pointer. The simplified error log is as follows. root@ls1028ardb:~# ip link set eno0 vf 1 mac 00:0c:e7:66:77:89 [ 173.543315] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 [ 173.637254] pc : enetc_pf_set_vf_mac+0x3c/0x80 Message from sy [ 173.641973] lr : do_setlink+0x4a8/0xec8 [ 173.732292] Call trace: [ 173.734740] enetc_pf_set_vf_mac+0x3c/0x80 [ 173.738847] __rtnl_newlink+0x530/0x89c [ 173.742692] rtnl_newlink+0x50/0x7c [ 173.746189] rtnetlink_rcv_msg+0x128/0x390 [ 173.750298] netlink_rcv_skb+0x60/0x130 [ 173.754145] rtnetlink_rcv+0x18/0x24 [ 173.757731] netlink_unicast+0x318/0x380 [ 173.761665] netlink_sendmsg+0x17c/0x3c8 • https://git.kernel.org/stable/c/d4fd0404c1c95b17880f254ebfee3485693fa8ba https://git.kernel.org/stable/c/ef0edfbe9eeed1fccad7cb705648af5222664944 https://git.kernel.org/stable/c/7eb923f8d4819737c07d6a8d0daef0a4d7f99e0c https://git.kernel.org/stable/c/e15c5506dd39885cd047f811a64240e2e8ab401b •

CVSS: -EPSS: 0%CPEs: 9EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when uninstalling driver When the driver is uninstalled and the VF is disabled concurrently, a kernel crash occurs. The reason is that the two actions call function pci_disable_sriov(). The num_VFs is checked to determine whether to release the corresponding resources. During the second calling, num_VFs is not 0 and the resource release function is called. However, the corresponding resource has been released during the first invoking. Therefore, the problem occurs: [15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... [15278.131557][T50670] Call trace: [15278.134686][T50670] klist_put+0x28/0x12c [15278.138682][T50670] klist_del+0x14/0x20 [15278.142592][T50670] device_del+0xbc/0x3c0 [15278.146676][T50670] pci_remove_bus_device+0x84/0x120 [15278.151714][T50670] pci_stop_and_remove_bus_device+0x6c/0x80 [15278.157447][T50670] pci_iov_remove_virtfn+0xb4/0x12c [15278.162485][T50670] sriov_disable+0x50/0x11c [15278.166829][T50670] pci_disable_sriov+0x24/0x30 [15278.171433][T50670] hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3] [15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge] [15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230 [15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30 [15278.193848][T50670] invoke_syscall+0x50/0x11c [15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164 [15278.203837][T50670] do_el0_svc+0x34/0xcc [15278.207834][T50670] el0_svc+0x20/0x30 For details, see the following figure. rmmod hclge disable VFs ---------------------------------------------------- hclge_exit() sriov_numvfs_store() ... • https://git.kernel.org/stable/c/b06ad258e01389ca3ff13bc180f3fcd6a608f1cd https://git.kernel.org/stable/c/c4b64011e458aa2b246cd4e42012cfd83d2d9a5c https://git.kernel.org/stable/c/d36b15e3e7b5937cb1f6ac590a85facc3a320642 https://git.kernel.org/stable/c/0dd8a25f355b4df2d41c08df1716340854c7d4c5 https://git.kernel.org/stable/c/9b5a29f0acefa3eb1dbe2fa302b393eeff64d933 https://git.kernel.org/stable/c/a0df055775f30850c0da8f7dab40d67c0fd63908 https://git.kernel.org/stable/c/7ae4e56de7dbd0999578246a536cf52a63f4056d https://git.kernel.org/stable/c/590a4b2d4e0b73586e88bce9b8135b593 •