Page 32 of 4579 results (0.011 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: igb: Initialize mailbox message for VF reset When a MAC address is not assigned to the VF, that portion of the message sent to the VF is not set. The memory, however, is allocated from the stack meaning that information may be leaked to the VM. Initialize the message buffer to 0 so that no information is passed to the VM in this case. • https://git.kernel.org/stable/c/6ddbc4cf1f4d5a3a58b4223c80881f299dae3774 https://git.kernel.org/stable/c/a6629659af3f5c6a91e3914ea62554c975ab77f4 https://git.kernel.org/stable/c/ef1d739dd1f362aec081278ff92f943c31eb177a https://git.kernel.org/stable/c/c581439a977545d61849a72e8ed631cfc8a2a3c1 https://git.kernel.org/stable/c/f2479c3daaabccbac6c343a737615d0c595c6dc4 https://git.kernel.org/stable/c/367e1e3399dbc56fc669740c4ab60e35da632b0e https://git.kernel.org/stable/c/51fd5ede7ed42f272682a0c33d6f0767b3484a3d https://git.kernel.org/stable/c/c383c7c35c7bc15e07a04eefa060a8a80 •

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

In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: Prevent buffer overflow in setup handler Setup function uvc_function_setup permits control transfer requests with up to 64 bytes of payload (UVC_MAX_REQUEST_SIZE), data stage handler for OUT transfer uses memcpy to copy req->actual bytes to uvc_event->data.data array of size 60. This may result in an overflow of 4 bytes. • https://git.kernel.org/stable/c/cdda479f15cd13fa50a913ca85129c0437cc7b91 https://git.kernel.org/stable/c/4972e3528b968665b596b5434764ff8fd9446d35 https://git.kernel.org/stable/c/06fd17ee92c8f1704c7e54ec0fd50ae0542a49a5 https://git.kernel.org/stable/c/bc8380fe5768c564f921f7b4eaba932e330b9e4b https://git.kernel.org/stable/c/b8fb1cba934ea122b50f13a4f9d6fc4fdc43d2be https://git.kernel.org/stable/c/c79538f32df12887f110dcd6b9c825b482905f24 https://git.kernel.org/stable/c/6b41a35b41f77821db24f2d8f66794b390a585c5 https://git.kernel.org/stable/c/7b1f773277a72f9756d47a41b94e43506 •

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

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix u8 overflow By keep sending L2CAP_CONF_REQ packets, chan->num_conf_rsp increases multiple times and eventually it will wrap around the maximum number (i.e., 255). This patch prevents this by adding a boundary check with L2CAP_MAX_CONF_RSP Btmon log: Bluetooth monitor ver 5.64 = Note: Linux version 6.1.0-rc2 (x86_64) 0.264594 = Note: Bluetooth subsystem version 2.22 0.264636 @ MGMT Open: btmon (privileged) version 1.22 {0x0001} 0.272191 = New Index: 00:00:00:00:00:00 (Primary,Virtual,hci0) [hci0] 13.877604 @ RAW Open: 9496 (privileged) version 2.22 {0x0002} 13.890741 = Open Index: 00:00:00:00:00:00 [hci0] 13.900426 (...) > ACL Data RX: Handle 200 flags 0x00 dlen 1033 #32 [hci0] 14.273106 invalid packet size (12 != 1033) 08 00 01 00 02 01 04 00 01 10 ff ff ............ > ACL Data RX: Handle 200 flags 0x00 dlen 1547 #33 [hci0] 14.273561 invalid packet size (14 != 1547) 0a 00 01 00 04 01 06 00 40 00 00 00 00 00 ........@..... > ACL Data RX: Handle 200 flags 0x00 dlen 2061 #34 [hci0] 14.274390 invalid packet size (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 00 00 00 04 ........@....... > ACL Data RX: Handle 200 flags 0x00 dlen 2061 #35 [hci0] 14.274932 invalid packet size (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 07 00 03 00 ........@....... = bluetoothd: Bluetooth daemon 5.43 14.401828 > ACL Data RX: Handle 200 flags 0x00 dlen 1033 #36 [hci0] 14.275753 invalid packet size (12 ! • https://git.kernel.org/stable/c/49d5867819ab7c744852b45509e8469839c07e0e https://git.kernel.org/stable/c/95f1847a361c7b4bf7d74c06ecb6968455082c1a https://git.kernel.org/stable/c/ad528fde0702903208d0a79d88d5a42ae3fc235b https://git.kernel.org/stable/c/9fdc79b571434af7bc742da40a3405f038b637a7 https://git.kernel.org/stable/c/f3fe6817156a2ad4b06f01afab04638a34d7c9a6 https://git.kernel.org/stable/c/19a78143961a197de8502f4f29c453b913dc3c29 https://git.kernel.org/stable/c/5550bbf709c323194881737fd290c4bada9e6ead https://git.kernel.org/stable/c/bcd70260ef56e0aee8a4fc6cd214a4199 • CWE-190: Integer Overflow or Wraparound •

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

In the Linux kernel, the following vulnerability has been resolved: udf: Fix preallocation discarding at indirect extent boundary When preallocation extent is the first one in the extent block, the code would corrupt extent tree header instead. Fix the problem and use udf_delete_aext() for deleting extent to avoid some code duplication. • https://git.kernel.org/stable/c/c8b6fa4511a7900db9fb0353b630d4d2ed1ba99c https://git.kernel.org/stable/c/7665857f88557c372da35534165721156756f77f https://git.kernel.org/stable/c/72f651c96c8aadf087fd782d551bf7db648a8c2e https://git.kernel.org/stable/c/4d835efd561dfb9bf5409f11f4ecd428d5d29226 https://git.kernel.org/stable/c/1a075f4a549481ce6e8518d8379f193ccec6b746 https://git.kernel.org/stable/c/63dbbd8f1499b0a161e701a04aa50148d60bd1f7 https://git.kernel.org/stable/c/ae56d9a017724f130cf1a263dd82a78d2a6e3852 https://git.kernel.org/stable/c/12a88f572d6d94b5c0b72e2d1782cc2e9 •

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

In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Avoid null pointer deref during path establishment For RTRS path establishment, RTRS client initiates and completes con_num of connections. After establishing all its connections, the information is exchanged between the client and server through the info_req message. During this exchange, it is essential that all connections have been established, and the state of the RTRS srv path is CONNECTED. So add these sanity checks, to make sure we detect and abort process in error scenarios to avoid null pointer deref. • https://git.kernel.org/stable/c/394b2f4d5e014820455af3eb5859eb328eaafcfd https://git.kernel.org/stable/c/b5d4076664465487a9a3d226756995b12fb73d71 https://git.kernel.org/stable/c/ccb8e44ae3e2391235f80ffc6be59bec6b889ead https://git.kernel.org/stable/c/b720792d7e8515bc695752e0ed5884e2ea34d12a https://git.kernel.org/stable/c/d0e62bf7b575fbfe591f6f570e7595dd60a2f5eb •