Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
ts dm thin trapped into a dead loop while looking up Z. Fix this by setting pmd->root in __open_metadata(), so that dm thin will use the last transaction's pmd->root if commit failed. Fetch a reproducer in [Link]. Linke: https://bugzilla.kernel.org/show_bug.cgi?id=216790 References: - https://git.kernel.org/stable/c/b35a22760aa5008d82533e59b0f0b5eb1b02d4e5 - https://git.kernel.org/stable/c/87d69b8824ca9b090f5a8ed47f758e8f6eecb871 - https://git.kernel.org/stable/c/3db757ffdd87ed8d7118b2250236a496502a660f - https://git.kernel.org/stable/c/f758987ff0af3a4b5ee69e95cab6a5294e4367b0 - https://git.kernel.org/stable/c/94f01ecc2aa0be992865acc80ebb6701f731f955 - https://git.kernel.org/stable/c/4b710e8
7b0 - https://git.kernel.org/stable/c/94f01ecc2aa0be992865acc80ebb6701f731f955 - https://git.kernel.org/stable/c/4b710e8481ade7c9200e94d3018e99dc42a0a0e8 - https://git.kernel.org/stable/c/a63ce4eca86fd207e3db07c00fb7ccf4adf1b230 - https://git.kernel.org/stable/c/b91f481300e3a10eaf66b94fc39b740928762aaf - https://git.kernel.org/stable/c/7991dbff6849f67e823b7cc0c15e5a90b0549b9f
CVE ID: CVE-2022-50535 State: PUBLISHED Published: 2025-10-07T15:21:02.347Z Last Updated: 2025-10-07T15:21:02.347Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix potential null-deref in dm_resume [Why] Fixing smatch error: dm_resume() error: we previously assumed 'aconnector->dc_link' could be null [How] Check if dc_link null at the beginning of the loop, so further checks can be dropped. References: - https://git.kernel.org/stable/c/fd79b61af2782f8875c78f50cdb8630ec43e2990 - https://git.kernel.org/stable/c/d236103782de25736996a45bd36ac2a89bdc93c6 - https://git.kernel.org/stable/c/9f73793b81637c60ccc83cc508
ernel.org/stable/c/d236103782de25736996a45bd36ac2a89bdc93c6 - https://git.kernel.org/stable/c/9f73793b81637c60ccc83cc508645310b8ab7d80 - https://git.kernel.org/stable/c/bb9a5562beb982aa5ebb73c521c49596ff8b8030 - https://git.kernel.org/stable/c/8e365f1bd672cc9320a936f6ae6f8087aa40e9bc - https://git.kernel.org/stable/c/00b655fa96b4e941351cc4bf5ca755a65ae94a8e - https://git.kernel.org/stable/c/7a7175a2cd84b7874bebbf8e59f134557a34161b
CVE ID: CVE-2022-50536 State: PUBLISHED Published: 2025-10-07T15:21:03.056Z Last Updated: 2025-10-07T15:21:03.056Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix repeated calls to sock_put() when msg has more_data In tcp_bpf_send_verdict() redirection, the eval variable is assigned to __SK_REDIRECT after the apply_bytes data is sent, if msg has more_data, sock_put() will be called multiple times. We should reset the eval variable to __SK_NONE every time more_data starts. This causes: IPv4: Attempt to release TCP socket in state 1 00000000b4c925d7 ------------[ cut here ]------------ refcount_t: addition on 0;
tempt to release TCP socket in state 1 00000000b4c925d7 ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 5 PID: 4482 at lib/refcount.c:25 refcount_warn_saturate+0x7d/0x110 Modules linked in: CPU: 5 PID: 4482 Comm: sockhash_bypass Kdump: loaded Not tainted 6.0.0 #1 Hardware name: Red Hat KVM, BIOS 1.11.0-2.el7 04/01/2014 Call Trace: <TASK> __tcp_transmit_skb+0xa1b/0xb90 ? __alloc_skb+0x8c/0x1a0 ? __kmalloc_node_track_caller+0x184/0x320 tcp_write_xmit+0x22a/0x1110 __tcp_push_pending_frames+0x32/0xf0 do_tcp_sendpages+0x62d/0x640 tcp_bpf_push+0xae/0x2c0 tcp_bpf_sendmsg_redir+0x260/0x410 ? preempt_count_add+0x70/0xa0 tcp_bpf_send_verdict+0x386/0x4b0 tc
_bpf_push+0xae/0x2c0 tcp_bpf_sendmsg_redir+0x260/0x410 ? preempt_count_add+0x70/0xa0 tcp_bpf_send_verdict+0x386/0x4b0 tcp_bpf_sendmsg+0x21b/0x3b0 sock_sendmsg+0x58/0x70 __sys_sendto+0xfa/0x170 ? xfd_validate_state+0x1d/0x80 ? switch_fpu_return+0x59/0xe0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd References: - https://git.kernel.org/stable/c/7508b9f4daac4ec7dfe0b6fb2d688b1c1c105e10 - https://git.kernel.org/stable/c/28e4a763cd4a2b1a78852216ef4bd7df3a05cec6 - https://git.kernel.org/stable/c/8786bde11a4f31b63b3036731df0b47337a7a245 - https://git.kernel.org/stable/c/578a7628b838a3ac8ad61deaab5a816ff032ac13 - https://git.kernel.org/stable/c/113236e8
45 - https://git.kernel.org/stable/c/578a7628b838a3ac8ad61deaab5a816ff032ac13 - https://git.kernel.org/stable/c/113236e8f49f262f318c00ebb14b15f4834e87c1 - https://git.kernel.org/stable/c/7a9841ca025275b5b0edfb0b618934abb6ceec15
CVE ID: CVE-2022-50537 State: PUBLISHED Published: 2025-10-07T15:21:03.749Z Last Updated: 2025-10-07T15:21:03.749Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: firmware: raspberrypi: fix possible memory leak in rpi_firmware_probe() In rpi_firmware_probe(), if mbox_request_channel() fails, the 'fw' will not be freed through rpi_firmware_delete(), fix this leak by calling kfree() in the error path. References: - https://git.kernel.org/stable/c/62ac943eb2a9d655e431b9bc98ff6d7bd51a0e49 - https://git.kernel.org/stable/c/d34742245e4366579f9a80f8cfe4a63248e838e0 - https://git.kernel.org/stable/c/b308fdedef095aac14569f810d46edf773ea7
table/c/d34742245e4366579f9a80f8cfe4a63248e838e0 - https://git.kernel.org/stable/c/b308fdedef095aac14569f810d46edf773ea7d1e - https://git.kernel.org/stable/c/6757dd2193fe18c5c5fe3050e7f2ff9dcbd1ff34 - https://git.kernel.org/stable/c/71d2abab374f707ab8ac8dcef191fd2b3b67b8bd - https://git.kernel.org/stable/c/7b51161696e803fd5f9ad55b20a64c2df313f95c
CVE ID: CVE-2022-50538 State: PUBLISHED Published: 2025-10-07T15:21:04.428Z Last Updated: 2025-10-07T15:21:04.428Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: vme: Fix error not catched in fake_init() In fake_init(), __root_device_register() is possible to fail but it's ignored, which can cause unregistering vme_root fail when exit. general protection fault, probably for non-canonical address 0xdffffc000000008c KASAN: null-ptr-deref in range [0x0000000000000460-0x0000000000000467] RIP: 0010:root_device_unregister+0x26/0x60 Call Trace: <TASK> __x64_sys_delete_module+0x34f/0x540 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_h
gister+0x26/0x60 Call Trace: <TASK> __x64_sys_delete_module+0x34f/0x540 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Return error when __root_device_register() fails. References: - https://git.kernel.org/stable/c/e831fdd60e5863ee03173baf5a0f7c5450b44381 - https://git.kernel.org/stable/c/69b43937f14bdc3594f57f1a507a14f3d1187136 - https://git.kernel.org/stable/c/09be0e7ac5f9374b6f8de72c89ed67129af71f65 - https://git.kernel.org/stable/c/f3f65c4177846c483bf009f8c512ab04b3c62466 - https://git.kernel.org/stable/c/37d3de40c1ffb6a5e626bf46ff5ef5766c824e2c - https://git.kernel.org/stable/c/4bc217b25ea81034fad8e33fd33e4659f086421d - https://git.kernel.org/stable/c/a2a93546d414c7fe4
s://git.kernel.org/stable/c/4bc217b25ea81034fad8e33fd33e4659f086421d - https://git.kernel.org/stable/c/a2a93546d414c7fe4862b87183fb737d1300d9d2 - https://git.kernel.org/stable/c/60ff9bd4ffc87bace581e235a6728f5ac8e5071f - https://git.kernel.org/stable/c/7bef797d707f1744f71156b21d41e3b8c946631f
CVE ID: CVE-2022-50539 State: PUBLISHED Published: 2025-10-07T15:21:05.152Z Last Updated: 2025-10-07T15:21:05.152Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ARM: OMAP2+: omap4-common: Fix refcount leak bug In omap4_sram_init(), of_find_compatible_node() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore. References: - https://git.kernel.org/stable/c/1d9452ae3bdb830f9309cf10a2f65977999cb14e - https://git.kernel.org/stable/c/049875b76660bbdc4873a915afb294f954eb7320 - https://git.kernel.org/stable/c/7c32919a378782c95c72bc028b5c30dfe8c11f82
CVE ID: CVE-2022-50540 State: PUBLISHED Published: 2025-10-07T15:21:05.836Z Last Updated: 2025-10-07T15:21:05.836Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dmaengine: qcom-adm: fix wrong sizeof config in slave_config Fix broken slave_config function that uncorrectly compare the peripheral_size with the size of the config pointer instead of the size of the config struct. This cause the crci value to be ignored and cause a kernel panic on any slave that use adm driver. To fix this, compare to the size of the struct and NOT the size of the pointer. References: - https://git.kernel.org/stable/c/f1dd45a6585a1689e1e8906b3f9e302
he struct and NOT the size of the pointer. References: - https://git.kernel.org/stable/c/f1dd45a6585a1689e1e8906b3f9e302b9d40c715 - https://git.kernel.org/stable/c/7490274b41a432824f7df5071ace3df2ab59caa7 - https://git.kernel.org/stable/c/7c8765308371be30f50c1b5b97618b731514b207
CVE ID: CVE-2022-50541 State: PUBLISHED Published: 2025-10-07T15:21:06.548Z Last Updated: 2025-10-30T19:33:04.866Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: k3-udma: Reset UDMA_CHAN_RT byte counters to prevent overflow UDMA_CHAN_RT_*BCNT_REG stores the real-time channel bytecount statistics. These registers are 32-bit hardware counters and the driver uses these counters to monitor the operational progress status for a channel, when transferring more than 4GB of data it was observed that these counters overflow and completion calculation of a operation gets affected and the transfer hangs indefinitely. This c
se counters overflow and completion calculation of a operation gets affected and the transfer hangs indefinitely. This commit adds changes to decrease the byte count for every complete transaction so that these registers never overflow and the proper byte count statistics is maintained for ongoing transaction by the RT counters. Earlier uc->bcnt used to maintain a count of the completed bytes at driver side, since the RT counters maintain the statistics of current transaction now, the maintenance of uc->bcnt is not necessary. References: - https://git.kernel.org/stable/c/d68da10b0cceb4177b653833e794b2923a4ffbd7 - https://git.kernel.org/stable/c/e0b16bfbd3a4a8d09614046335f4482313e7c0c4 - http
8da10b0cceb4177b653833e794b2923a4ffbd7 - https://git.kernel.org/stable/c/e0b16bfbd3a4a8d09614046335f4482313e7c0c4 - https://git.kernel.org/stable/c/a065657643a62a24b4435ddcaea45f1e9378749e - https://git.kernel.org/stable/c/7c94dcfa8fcff2dba53915f1dabfee49a3df8b88
CVE ID: CVE-2022-50542 State: PUBLISHED Published: 2025-10-07T15:21:07.236Z Last Updated: 2025-10-07T15:21:07.236Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: si470x: Fix use-after-free in si470x_int_in_callback() syzbot reported use-after-free in si470x_int_in_callback() [1]. This indicates that urb->context, which contains struct si470x_device object, is freed when si470x_int_in_callback() is called. The cause of this issue is that si470x_int_in_callback() is called for freed urb. si470x_usb_driver_probe() calls si470x_start_usb(), which then calls usb_submit_urb() and si470x_start(). If si470x_start_usb() fails, si
_probe() calls si470x_start_usb(), which then calls usb_submit_urb() and si470x_start(). If si470x_start_usb() fails, si470x_usb_driver_probe() doesn't kill urb, but it just frees struct si470x_device object, as depicted below: si470x_usb_driver_probe() ... si470x_start_usb() ... usb_submit_urb() retval = si470x_start() return retval if (retval < 0) free struct si470x_device object, but don't kill urb This patch fixes this issue by killing urb when si470x_start_usb() fails and urb is submitted. If si470x_start_usb() fails and urb is not submitted, i.e. submitting usb fails, it just frees struct si470x_device object. References: - https://git.kernel.org/stable/c/146bd005ebb01ae190c22af050cb98
it just frees struct si470x_device object. References: - https://git.kernel.org/stable/c/146bd005ebb01ae190c22af050cb98623958c373 - https://git.kernel.org/stable/c/8c6151b8e8dd2d98ad2cd725d26d1e103d989891 - https://git.kernel.org/stable/c/52f54fe78cca24850a30865037250f63eb3d5bf7 - https://git.kernel.org/stable/c/0ca298d548461d29615f9a2b1309e8dcf4a352c6 - https://git.kernel.org/stable/c/1c6447d0fc68650e51586dde79b5090d9d77f13a - https://git.kernel.org/stable/c/6c8aee0c8fcc6dda94315f7908e8fa9bc75abe75 - https://git.kernel.org/stable/c/63648a7bd1a7599bcc2040a6d1792363ae4c2e1b - https://git.kernel.org/stable/c/92b0888398e4ba51d93b618a6506781f4e3879c9 - https://git.kernel.org/stable/c/7d21e0b1b4
- https://git.kernel.org/stable/c/92b0888398e4ba51d93b618a6506781f4e3879c9 - https://git.kernel.org/stable/c/7d21e0b1b41b21d628bf2afce777727bd4479aa5
CVE ID: CVE-2022-50543 State: PUBLISHED Published: 2025-10-07T15:21:07.939Z Last Updated: 2025-10-07T15:21:07.939Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix mr->map double free rxe_mr_cleanup() which tries to free mr->map again will be called when rxe_mr_init_user() fails: CPU: 0 PID: 4917 Comm: rdma_flush_serv Kdump: loaded Not tainted 6.1.0-rc1-roce-flush+ #25 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x45/0x5d panic+0x19e/0x349 end_report.part.0+0x54/0x7c kasan_report.cold+0xa/0xf rxe_mr_cleanup+0x9d
SK> dump_stack_lvl+0x45/0x5d panic+0x19e/0x349 end_report.part.0+0x54/0x7c kasan_report.cold+0xa/0xf rxe_mr_cleanup+0x9d/0xf0 [rdma_rxe] __rxe_cleanup+0x10a/0x1e0 [rdma_rxe] rxe_reg_user_mr+0xb7/0xd0 [rdma_rxe] ib_uverbs_reg_mr+0x26a/0x480 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x1a2/0x250 [ib_uverbs] ib_uverbs_cmd_verbs+0x1397/0x15a0 [ib_uverbs] This issue was firstly exposed since commit b18c7da63fcb ("RDMA/rxe: Fix memory leak in error path code") and then we fixed it in commit 8ff5f5d9d8cf ("RDMA/rxe: Prevent double freeing rxe_map_set()") but this fix was reverted together at last by commit 1e75550648da (Revert "RDMA/rxe: Create duplicate mapping tables for FMRs") Simp
was reverted together at last by commit 1e75550648da (Revert "RDMA/rxe: Create duplicate mapping tables for FMRs") Simply let rxe_mr_cleanup() always handle freeing the mr->map once it is successfully allocated. References: - https://git.kernel.org/stable/c/6ce577f09013206e36e674cd27da3707b2278268 - https://git.kernel.org/stable/c/06f73568f553b5be6ba7f6fe274d333ea29fc46d - https://git.kernel.org/stable/c/7d984dac8f6bf4ebd3398af82b357e1d181ecaac
CVE ID: CVE-2022-50544 State: PUBLISHED Published: 2025-10-07T15:21:08.629Z Last Updated: 2025-10-07T15:21:08.629Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: host: xhci: Fix potential memory leak in xhci_alloc_stream_info() xhci_alloc_stream_info() allocates stream context array for stream_info ->stream_ctx_array with xhci_alloc_stream_ctx(). When some error occurs, stream_info->stream_ctx_array is not released, which will lead to a memory leak. We can fix it by releasing the stream_info->stream_ctx_array with xhci_free_stream_ctx() on the error path to avoid the potential memory leak. References: - https://git.kernel.
rray with xhci_free_stream_ctx() on the error path to avoid the potential memory leak. References: - https://git.kernel.org/stable/c/7fc6bab3413e6a42bb1264ff7c9149808c93a4c7 - https://git.kernel.org/stable/c/e702de2f5c893bf2cdb0152191f99a6ad1411823 - https://git.kernel.org/stable/c/ddab9fe76296840aad686c66888a9c1dfdbff5ff - https://git.kernel.org/stable/c/9fa81cbd2dd300aa8fe9bac70e068b9a11cbb144 - https://git.kernel.org/stable/c/91271a3e772e180bbb8afb114c72fd294a02f93d - https://git.kernel.org/stable/c/fcd594da0b5955119d9707e4e0a8d0fb1c969101 - https://git.kernel.org/stable/c/a40ad475236022f3432880e3091c380e46e71a71 - https://git.kernel.org/stable/c/782c873f8e7686f5b3c47e8b099f7e08c3dd1fdc -
/c/a40ad475236022f3432880e3091c380e46e71a71 - https://git.kernel.org/stable/c/782c873f8e7686f5b3c47e8b099f7e08c3dd1fdc - https://git.kernel.org/stable/c/7e271f42a5cc3768cd2622b929ba66859ae21f97
CVE ID: CVE-2022-50545 State: PUBLISHED Published: 2025-10-07T15:21:09.288Z Last Updated: 2025-10-07T15:21:09.288Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: r6040: Fix kmemleak in probe and remove There is a memory leaks reported by kmemleak: unreferenced object 0xffff888116111000 (size 2048): comm "modprobe", pid 817, jiffies 4294759745 (age 76.502s) hex dump (first 32 bytes): 00 c4 0a 04 81 88 ff ff 08 10 11 16 81 88 ff ff ................ 08 10 11 16 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff815bcd82>] kmalloc_trace+0x22/0x60 [<ffffffff827e20ee>] phy_device_create+0x4e/0x90 [<ffffffff827e
backtrace: [<ffffffff815bcd82>] kmalloc_trace+0x22/0x60 [<ffffffff827e20ee>] phy_device_create+0x4e/0x90 [<ffffffff827e6072>] get_phy_device+0xd2/0x220 [<ffffffff827e7844>] mdiobus_scan+0xa4/0x2e0 [<ffffffff827e8be2>] __mdiobus_register+0x482/0x8b0 [<ffffffffa01f5d24>] r6040_init_one+0x714/0xd2c [r6040] ... The problem occurs in probe process as follows: r6040_init_one: mdiobus_register mdiobus_scan <- alloc and register phy_device, the reference count of phy_device is 3 r6040_mii_probe phy_connect <- connect to the first phy_device, so the reference count of the first phy_device is 4, others are 3 register_netdev <- fault inject succeeded, goto error handling path // error handling path er
_device is 4, others are 3 register_netdev <- fault inject succeeded, goto error handling path // error handling path err_out_mdio_unregister: mdiobus_unregister(lp->mii_bus); err_out_mdio: mdiobus_free(lp->mii_bus); <- the reference count of the first phy_device is 1, it is not released and other phy_devices are released // similarly, the remove process also has the same problem The root cause is traced to the phy_device is not disconnected when removes one r6040 device in r6040_remove_one() or on error handling path after r6040_mii probed successfully. In r6040_mii_probe(), a net ethernet device is connected to the first PHY device of mii_bus, in order to notify the connected driver when t
), a net ethernet device is connected to the first PHY device of mii_bus, in order to notify the connected driver when the link status changes, which is the default behavior of the PHY infrastructure to handle everything. Therefore the phy_device should be disconnected when removes one r6040 device or on error handling path. Fix it by adding phy_disconnect() when removes one r6040 device or on error handling path after r6040_mii probed successfully. References: - https://git.kernel.org/stable/c/a04707f4596952049da05756c27398c34d9a1d36 - https://git.kernel.org/stable/c/b4448816e6a565e08236a6009c6bf48c6836cdfd - https://git.kernel.org/stable/c/2ce242e1b9ad31c1f68496b3548e407a8cb2c07d - https:/
816e6a565e08236a6009c6bf48c6836cdfd - https://git.kernel.org/stable/c/2ce242e1b9ad31c1f68496b3548e407a8cb2c07d - https://git.kernel.org/stable/c/b0a61359026b57a287a48fbb4ba1d097023eca3e - https://git.kernel.org/stable/c/3d5f83a62e8235d235534b3dc6f197d8a822c269 - https://git.kernel.org/stable/c/9b5b50329e2e966831a7237dd6949e7b5362a49a - https://git.kernel.org/stable/c/ad2c8f25457ca9a81e7e958148cbc26600ce3071 - https://git.kernel.org/stable/c/5944c25c67de54e0aa53623e1e1af3bf8b16ed44 - https://git.kernel.org/stable/c/7e43039a49c2da45edc1d9d7c9ede4003ab45a5f
CVE ID: CVE-2022-50546 State: PUBLISHED Published: 2025-10-07T15:21:09.963Z Last Updated: 2025-10-07T15:21:09.963Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: fix uninititialized value in 'ext4_evict_inode' Syzbot found the following issue: ===================================================== BUG: KMSAN: uninit-value in ext4_evict_inode+0xdd/0x26b0 fs/ext4/inode.c:180 ext4_evict_inode+0xdd/0x26b0 fs/ext4/inode.c:180 evict+0x365/0x9a0 fs/inode.c:664 iput_final fs/inode.c:1747 [inline] iput+0x985/0xdd0 fs/inode.c:1773 __ext4_new_inode+0xe54/0x7ec0 fs/ext4/ialloc.c:1361 ext4_mknod+0x376/0x840 fs/ext4/namei.c:2844 vfs_mkn
fs/inode.c:1773 __ext4_new_inode+0xe54/0x7ec0 fs/ext4/ialloc.c:1361 ext4_mknod+0x376/0x840 fs/ext4/namei.c:2844 vfs_mknod+0x79d/0x830 fs/namei.c:3914 do_mknodat+0x47d/0xaa0 __do_sys_mknodat fs/namei.c:3992 [inline] __se_sys_mknodat fs/namei.c:3989 [inline] __ia32_sys_mknodat+0xeb/0x150 fs/namei.c:3989 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82 Uninit was created at: __alloc_pages+0x9f1/0xe80 mm/page_alloc.c:5578 alloc_pages+0xaae/0xd80 mm/mempolicy.c:2285 alloc_s
ninit was created at: __alloc_pages+0x9f1/0xe80 mm/page_alloc.c:5578 alloc_pages+0xaae/0xd80 mm/mempolicy.c:2285 alloc_slab_page mm/slub.c:1794 [inline] allocate_slab+0x1b5/0x1010 mm/slub.c:1939 new_slab mm/slub.c:1992 [inline] ___slab_alloc+0x10c3/0x2d60 mm/slub.c:3180 __slab_alloc mm/slub.c:3279 [inline] slab_alloc_node mm/slub.c:3364 [inline] slab_alloc mm/slub.c:3406 [inline] __kmem_cache_alloc_lru mm/slub.c:3413 [inline] kmem_cache_alloc_lru+0x6f3/0xb30 mm/slub.c:3429 alloc_inode_sb include/linux/fs.h:3117 [inline] ext4_alloc_inode+0x5f/0x860 fs/ext4/super.c:1321 alloc_inode+0x83/0x440 fs/inode.c:259 new_inode_pseudo fs/inode.c:1018 [inline] new_inode+0x3b/0x430 fs/inode.c:1046 __ext4_n
_inode+0x83/0x440 fs/inode.c:259 new_inode_pseudo fs/inode.c:1018 [inline] new_inode+0x3b/0x430 fs/inode.c:1046 __ext4_new_inode+0x2a7/0x7ec0 fs/ext4/ialloc.c:959 ext4_mkdir+0x4d5/0x1560 fs/ext4/namei.c:2992 vfs_mkdir+0x62a/0x870 fs/namei.c:4035 do_mkdirat+0x466/0x7b0 fs/namei.c:4060 __do_sys_mkdirat fs/namei.c:4075 [inline] __se_sys_mkdirat fs/namei.c:4073 [inline] __ia32_sys_mkdirat+0xc4/0x120 fs/namei.c:4073 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82 CPU: 1 PID
mmon.c:203 do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82 CPU: 1 PID: 4625 Comm: syz-executor.2 Not tainted 6.1.0-rc4-syzkaller-62821-gcb231e2f67ec #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 ===================================================== Now, 'ext4_alloc_inode()' didn't init 'ei->i_flags'. If new inode failed before set 'ei->i_flags' in '__ext4_new_inode()', then do 'iput()'. As after 6bc0d63dad7f commit will access 'ei->i_flags' in 'ext4_evict_inode()' which will lead to access uninit-value. To solve above issue just init 'ei->i_flags' in 'ext4_alloc_inode()'. References: - https://g
ad to access uninit-value. To solve above issue just init 'ei->i_flags' in 'ext4_alloc_inode()'. References: - https://git.kernel.org/stable/c/f0bffdcc7cb14598af2aa706f1e0f2a9054154ba - https://git.kernel.org/stable/c/e431b4fb1fb8c2654b808086e9747a000adb9655 - https://git.kernel.org/stable/c/091f85db4c3fb1734a6d7fb4777a2b2831da6631 - https://git.kernel.org/stable/c/3c31d8d3ad95aef8cc17a4fcf317e46217148439 - https://git.kernel.org/stable/c/56491d60ddca9c697d885394cb0173675b9ab81f - https://git.kernel.org/stable/c/9f966e021c20caae639dd0e404c8761e8281a2c4 - https://git.kernel.org/stable/c/7ea71af94eaaaf6d9aed24bc94a05b977a741cb9