Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
+0x27/0x60 [<000000000b1954a0>] 0xffffffffc45200a9 [<00000000abbf1da0>] do_one_initcall+0xd0/0x4f0 [<000000001505ee87>] do_init_module+0x1a4/0x680 [<00000000958079ad>] load_module+0x6249/0x7110 [<00000000117e4696>] __do_sys_finit_module+0x140/0x200 [<00000000f74b12d2>] do_syscall_64+0x35/0x80 [<000000008fc6fcde>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 The reason is that the vkms_init() returns without checking the return value of vkms_create(), and if the vkms_create() failed, the config allocated at the beginning of vkms_init() is leaked. vkms_init() config = kmalloc(...) # config allocated ... return vkms_create() # vkms_create failed and config is leaked Fix this problem by checking ret
) # config allocated ... return vkms_create() # vkms_create failed and config is leaked Fix this problem by checking return value of vkms_create() and free the config if error happened. References: - https://git.kernel.org/stable/c/bad13de764888b765ceaa4668893b52bd16653cc - https://git.kernel.org/stable/c/bebd60ec3bf21062f103e32e6203c6daabdbd51b - https://git.kernel.org/stable/c/07ab77154d6fd2d67e465ab5ce30083709950f02 - https://git.kernel.org/stable/c/0d0b368b9d104b437e1f4850ae94bdb9a3601e89
CVE ID: CVE-2022-50270 State: PUBLISHED Published: 2025-09-15T14:21:06.735Z Last Updated: 2025-09-15T14:21:06.735Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: f2fs: fix the assign logic of iocb commit 18ae8d12991b ("f2fs: show more DIO information in tracepoint") introduces iocb field in 'f2fs_direct_IO_enter' trace event And it only assigns the pointer and later it accesses its field in trace print log. Unable to handle kernel paging request at virtual address ffffffc04cef3d30 Mem abort info: ESR = 0x96000007 EC = 0x25: DABT (current EL), IL = 32 bits pc : trace_raw_output_f2fs_direct_IO_enter+0x54/0xa4 lr : trace_raw_outpu
007 EC = 0x25: DABT (current EL), IL = 32 bits pc : trace_raw_output_f2fs_direct_IO_enter+0x54/0xa4 lr : trace_raw_output_f2fs_direct_IO_enter+0x2c/0xa4 sp : ffffffc0443cbbd0 x29: ffffffc0443cbbf0 x28: ffffff8935b120d0 x27: ffffff8935b12108 x26: ffffff8935b120f0 x25: ffffff8935b12100 x24: ffffff8935b110c0 x23: ffffff8935b10000 x22: ffffff88859a936c x21: ffffff88859a936c x20: ffffff8935b110c0 x19: ffffff8935b10000 x18: ffffffc03b195060 x17: ffffff8935b11e76 x16: 00000000000000cc x15: ffffffef855c4f2c x14: 0000000000000001 x13: 000000000000004e x12: ffff0000ffffff00 x11: ffffffef86c350d0 x10: 00000000000010c0 x9 : 000000000fe0002c x8 : ffffffc04cef3d28 x7 : 7f7f7f7f7f7f7f7f x6 : 00000000020000
ffef86c350d0 x10: 00000000000010c0 x9 : 000000000fe0002c x8 : ffffffc04cef3d28 x7 : 7f7f7f7f7f7f7f7f x6 : 0000000002000000 x5 : ffffff8935b11e9a x4 : 0000000000006250 x3 : ffff0a00ffffff04 x2 : 0000000000000002 x1 : ffffffef86a0a31f x0 : ffffff8935b10000 Call trace: trace_raw_output_f2fs_direct_IO_enter+0x54/0xa4 print_trace_fmt+0x9c/0x138 print_trace_line+0x154/0x254 tracing_read_pipe+0x21c/0x380 vfs_read+0x108/0x3ac ksys_read+0x7c/0xec __arm64_sys_read+0x20/0x30 invoke_syscall+0x60/0x150 el0_svc_common.llvm.1237943816091755067+0xb8/0xf8 do_el0_svc+0x28/0xa0 Fix it by copying the required variables for printing and while at it fix the similar issue at some other places in the same file. Ref
ing the required variables for printing and while at it fix the similar issue at some other places in the same file. References: - https://git.kernel.org/stable/c/d555aa37566c5c3728f2e52047a9722eae2aed93 - https://git.kernel.org/stable/c/b4244ca341ea95c52ee8fa93d04f5af3e584dd37 - https://git.kernel.org/stable/c/0db18eec0d9a7ee525209e31e3ac2f673545b12f
CVE ID: CVE-2022-50271 State: PUBLISHED Published: 2025-09-15T14:21:07.563Z Last Updated: 2025-09-15T14:21:07.563Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: vhost/vsock: Use kvmalloc/kvfree for larger packets. When copying a large file over sftp over vsock, data size is usually 32kB, and kmalloc seems to fail to try to allocate 32 32kB regions. vhost-5837: page allocation failure: order:4, mode:0x24040c0 Call Trace: [<ffffffffb6a0df64>] dump_stack+0x97/0xdb [<ffffffffb68d6aed>] warn_alloc_failed+0x10f/0x138 [<ffffffffb68d868a>] ? __alloc_pages_direct_compact+0x38/0xc8 [<ffffffffb664619f>] __alloc_pages_nodemask+0x84c/0x90d
38 [<ffffffffb68d868a>] ? __alloc_pages_direct_compact+0x38/0xc8 [<ffffffffb664619f>] __alloc_pages_nodemask+0x84c/0x90d [<ffffffffb6646e56>] alloc_kmem_pages+0x17/0x19 [<ffffffffb6653a26>] kmalloc_order_trace+0x2b/0xdb [<ffffffffb66682f3>] __kmalloc+0x177/0x1f7 [<ffffffffb66e0d94>] ? copy_from_iter+0x8d/0x31d [<ffffffffc0689ab7>] vhost_vsock_handle_tx_kick+0x1fa/0x301 [vhost_vsock] [<ffffffffc06828d9>] vhost_worker+0xf7/0x157 [vhost] [<ffffffffb683ddce>] kthread+0xfd/0x105 [<ffffffffc06827e2>] ? vhost_dev_set_owner+0x22e/0x22e [vhost] [<ffffffffb683dcd1>] ? flush_kthread_worker+0xf3/0xf3 [<ffffffffb6eb332e>] ret_from_fork+0x4e/0x80 [<ffffffffb683dcd1>] ? flush_kthread_worker+0xf3/0xf3 Work
orker+0xf3/0xf3 [<ffffffffb6eb332e>] ret_from_fork+0x4e/0x80 [<ffffffffb683dcd1>] ? flush_kthread_worker+0xf3/0xf3 Work around by doing kvmalloc instead. References: - https://git.kernel.org/stable/c/0d720c3f0a03e97867deab7e480ba3d3e19837ba - https://git.kernel.org/stable/c/7aac8c63f604e6a6a46560c0f0188cd0332cf320 - https://git.kernel.org/stable/c/e6d0152c95108651f1880c1ddfab47cb9e3e62d0 - https://git.kernel.org/stable/c/b4a5905fd2ef841cd61e969ea692c213c2e5c1f7 - https://git.kernel.org/stable/c/e28a4e7f0296824c61a81e7fd54ab48bad3e75ad - https://git.kernel.org/stable/c/a99fc6d818161d6f1ff3307de8bf5237f6cc34d8 - https://git.kernel.org/stable/c/36c9f340c60413e28f980c0224c4e9d35851526b - https:/
6d818161d6f1ff3307de8bf5237f6cc34d8 - https://git.kernel.org/stable/c/36c9f340c60413e28f980c0224c4e9d35851526b - https://git.kernel.org/stable/c/0e3f72931fc47bb81686020cc643cde5d9cd0bb8
CVE ID: CVE-2022-50272 State: PUBLISHED Published: 2025-09-15T14:21:08.534Z Last Updated: 2025-09-15T14:21:08.534Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer() Wei Chen reports a kernel bug as blew: general protection fault, probably for non-canonical address KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] ... Call Trace: <TASK> __i2c_transfer+0x77e/0x1930 drivers/i2c/i2c-core-base.c:2109 i2c_transfer+0x1d5/0x3d0 drivers/i2c/i2c-core-base.c:2170 i2cdev_ioctl_rdwr+0x393/0x660 drivers/i2c/i2c-dev.c:297 i2cdev_ioctl+0x75d/0x9f0 drivers/i2c/i2c
2c/i2c-core-base.c:2170 i2cdev_ioctl_rdwr+0x393/0x660 drivers/i2c/i2c-dev.c:297 i2cdev_ioctl+0x75d/0x9f0 drivers/i2c/i2c-dev.c:458 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fd834a8bded In az6027_i2c_xfer(), if msg[i].addr is 0x99, a null-ptr-deref will caused when accessing msg[i].buf. For msg[i].len is 0 and msg[i].buf is null. Fix this by checking msg[i].len in az6027_i2c_xfer(). References: - https://git.kernel.org/stable/c/2b6a8a1a32746981044e7ab06649c804acb4068a -
sg[i].len in az6027_i2c_xfer(). References: - https://git.kernel.org/stable/c/2b6a8a1a32746981044e7ab06649c804acb4068a - https://git.kernel.org/stable/c/c712d1ccbfb787620422b437a5b8fac0802547bd - https://git.kernel.org/stable/c/7abfe467cd685f5da7ecb415441e45e3e4e2baa8 - https://git.kernel.org/stable/c/8b256d23361c51aa4b7fdb71176c1ca50966fb39 - https://git.kernel.org/stable/c/559891d430e3f3a178040c4371ed419edbfa7d65 - https://git.kernel.org/stable/c/210fcf64be4db82c0e190e74b5111e4eef661a7a - https://git.kernel.org/stable/c/6fbc44731a4665cbe92a5090e9804a388a72214b - https://git.kernel.org/stable/c/6b60cf73a931af34b7a0a3f467a79d9fe0df2d70 - https://git.kernel.org/stable/c/0ed554fd769a19ea8464bb
it.kernel.org/stable/c/6b60cf73a931af34b7a0a3f467a79d9fe0df2d70 - https://git.kernel.org/stable/c/0ed554fd769a19ea8464bb83e9ac201002ef74ad
CVE ID: CVE-2022-50273 State: PUBLISHED Published: 2025-09-15T14:21:09.496Z Last Updated: 2025-09-19T15:21:23.218Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on destination blkaddr during recovery As Wenqing Liu reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216456 loop5: detected capacity change from 0 to 131072 F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1 F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0 F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1 F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0 F2FS-fs (l
cover_inode: ino = 6, name = hln, inline = 1 F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0 F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1 F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0 F2FS-fs (loop5): Bitmap was wrongly set, blk:5634 ------------[ cut here ]------------ WARNING: CPU: 3 PID: 1013 at fs/f2fs/segment.c:2198 RIP: 0010:update_sit_entry+0xa55/0x10b0 [f2fs] Call Trace: <TASK> f2fs_do_replace_block+0xa98/0x1890 [f2fs] f2fs_replace_block+0xeb/0x180 [f2fs] recover_data+0x1a69/0x6ae0 [f2fs] f2fs_recover_fsync_data+0x120d/0x1fc0 [f2fs] f2fs_fill_super+0x4665/0x61e0 [f2fs] mount_bdev+0x2cf/0x3b0 legacy_get_tree+0xed/0x1d0 vfs_get_tre
+0x120d/0x1fc0 [f2fs] f2fs_fill_super+0x4665/0x61e0 [f2fs] mount_bdev+0x2cf/0x3b0 legacy_get_tree+0xed/0x1d0 vfs_get_tree+0x81/0x2b0 path_mount+0x47e/0x19d0 do_mount+0xce/0xf0 __x64_sys_mount+0x12c/0x1a0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd If we enable CONFIG_F2FS_CHECK_FS config, it will trigger a kernel panic instead of warning. The root cause is: in fuzzed image, SIT table is inconsistent with inode mapping table, result in triggering such warning during SIT table update. This patch introduces a new flag DATA_GENERIC_ENHANCE_UPDATE, w/ this flag, data block recovery flow can check destination blkaddr's validation in SIT table, and skip f2fs_replace_block() to
lag, data block recovery flow can check destination blkaddr's validation in SIT table, and skip f2fs_replace_block() to avoid inconsistent status. References: - https://git.kernel.org/stable/c/68b1e607559d3dc85f94b0d738d7c4e8029b0cfa - https://git.kernel.org/stable/c/73fb4bd2c055a393816f078f158cdd3025006f1d - https://git.kernel.org/stable/c/ed854f10e6afd5cbd5c3274d4c4df4bfe0ab4362 - https://git.kernel.org/stable/c/8f0a47def4722c5fd8d6b9268b5ffed8a249e2db - https://git.kernel.org/stable/c/3a4d24d746866dd45d970bd565ff3886e839366a - https://git.kernel.org/stable/c/0ef4ca04a3f9223ff8bc440041c524b2123e09a3
CVE ID: CVE-2022-50274 State: PUBLISHED Published: 2025-09-15T14:21:10.383Z Last Updated: 2025-09-15T14:21:10.383Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: adopts refcnt to avoid UAF dvb_unregister_device() is known that prone to use-after-free. That is, the cleanup from dvb_unregister_device() releases the dvb_device even if there are pointers stored in file->private_data still refer to it. This patch adds a reference counter into struct dvb_device and delays its deallocation until no pointer refers to the object. References: - https://git.kernel.org/stable/c/ac521bbe3d00fa574e66a9361763f2b37725bc97 - http
nter refers to the object. References: - https://git.kernel.org/stable/c/ac521bbe3d00fa574e66a9361763f2b37725bc97 - https://git.kernel.org/stable/c/219b44bf94203bd433aa91b7796475bf656348e5 - https://git.kernel.org/stable/c/6d18b44bb44e1f4d97dfe0efe92ac0f0984739c2 - https://git.kernel.org/stable/c/2abd73433872194bccdf1432a0980e4ec5273c2a - https://git.kernel.org/stable/c/88a6f8a72d167294c0931c7874941bf37a41b6dd - https://git.kernel.org/stable/c/a2f0a08aa613176c9688c81d7b598a7779974991 - https://git.kernel.org/stable/c/9945d05d6693710574f354c5dbddc47f5101eb77 - https://git.kernel.org/stable/c/0fc044b2b5e2d05a1fa1fb0d7f270367a7855d79
CVE ID: CVE-2022-50275 State: PUBLISHED Published: 2025-09-15T14:21:11.388Z Last Updated: 2025-09-15T14:21:11.388Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/radeon: Add the missed acpi_put_table() to fix memory leak When the radeon driver reads the bios information from ACPI table in radeon_acpi_vfct_bios(), it misses to call acpi_put_table() to release the ACPI memory after the init, so add acpi_put_table() properly to fix the memory leak. v2: fix text formatting (Alex) References: - https://git.kernel.org/stable/c/4539e3211a9bd2418e76797718a4e60a7ae34fcf - https://git.kernel.org/stable/c/4760fa67aff6bd8ef0b14c1fa04c2
el.org/stable/c/4539e3211a9bd2418e76797718a4e60a7ae34fcf - https://git.kernel.org/stable/c/4760fa67aff6bd8ef0b14c1fa04c295e734c7309 - https://git.kernel.org/stable/c/a0f26560be2c566b62331cb0eeffa52929aa4d44 - https://git.kernel.org/stable/c/b4b30f56ec512e2c35fc0761bc90b0e519d8fa6e - https://git.kernel.org/stable/c/6d25bc63708145c10f9c099d5c005602a7f2ef5f - https://git.kernel.org/stable/c/50113de0f1e913c0b733e21d3e61fe9c0f2e9d50 - https://git.kernel.org/stable/c/9e203e437310f61fdf3c1107f41f85864cf4f6b1 - https://git.kernel.org/stable/c/10276a20be1115e1f76c189330da2992df980eee
CVE ID: CVE-2022-50276 State: PUBLISHED Published: 2025-09-15T14:21:13.542Z Last Updated: 2025-09-15T14:21:13.542Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: power: supply: fix null pointer dereferencing in power_supply_get_battery_info when kmalloc() fail to allocate memory in kasprintf(), propname will be NULL, strcmp() called by of_get_property() will cause null pointer dereference. So return ENOMEM if kasprintf() return NULL pointer. References: - https://git.kernel.org/stable/c/8ea68b4e3fa9392ef9dae303abc8735a033c280f - https://git.kernel.org/stable/c/5beadb55f4e36fafe5d6df5dcd5f85d803f3f134 - https://git.kernel.org/st
3abc8735a033c280f - https://git.kernel.org/stable/c/5beadb55f4e36fafe5d6df5dcd5f85d803f3f134 - https://git.kernel.org/stable/c/d21534ab4fd7883e1c8037a76671d4e8b6ea14cb - https://git.kernel.org/stable/c/279af90e65cbdb3e5c4519b0043324d7876bc5ec - https://git.kernel.org/stable/c/b8131efb89d9f837c9244f900f0fc2699fd1181d - https://git.kernel.org/stable/c/104bb8a663451404a26331263ce5b96c34504049
CVE ID: CVE-2022-50277 State: PUBLISHED Published: 2025-09-15T14:21:14.381Z Last Updated: 2025-09-15T14:21:14.381Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: don't allow journal inode to have encrypt flag Mounting a filesystem whose journal inode has the encrypt flag causes a NULL dereference in fscrypt_limit_io_blocks() when the 'inlinecrypt' mount option is used. The problem is that when jbd2_journal_init_inode() calls bmap(), it eventually finds its way into ext4_iomap_begin(), which calls fscrypt_limit_io_blocks(). fscrypt_limit_io_blocks() requires that if the inode is encrypted, then its encryption key must alre
_limit_io_blocks(). fscrypt_limit_io_blocks() requires that if the inode is encrypted, then its encryption key must already be set up. That's not the case here, since the journal inode is never "opened" like a normal file would be. Hence the crash. A reproducer is: mkfs.ext4 -F /dev/vdb debugfs -w /dev/vdb -R "set_inode_field <8> flags 0x80808" mount /dev/vdb /mnt -o inlinecrypt To fix this, make ext4 consider journal inodes with the encrypt flag to be invalid. (Note, maybe other flags should be rejected on the journal inode too. For now, this is just the minimal fix for the above issue.) I've marked this as fixing the commit that introduced the call to fscrypt_limit_io_blocks(), since that'
e above issue.) I've marked this as fixing the commit that introduced the call to fscrypt_limit_io_blocks(), since that's what made an actual crash start being possible. But this fix could be applied to any version of ext4 that supports the encrypt feature. References: - https://git.kernel.org/stable/c/1f7a6626f611aa06d7907aa45b484708dd5ac8bc - https://git.kernel.org/stable/c/bcc5057e1781a3ee889225480d995c3b5cbde555 - https://git.kernel.org/stable/c/105c78e12468413e426625831faa7db4284e1fec
CVE ID: CVE-2022-50278 State: PUBLISHED Published: 2025-09-15T14:21:15.208Z Last Updated: 2025-09-15T14:21:15.208Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: PNP: fix name memory leak in pnp_alloc_dev() After commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically, move dev_set_name() after pnp_add_id() to avoid memory leak. References: - https://git.kernel.org/stable/c/ea77b4b761cd75e5456f677311babfa0418f289a - https://git.kernel.org/stable/c/693a0c13c1f0c0fcaa1e38cb806cc0789bd415aa - https://git.kernel.org/stable/c/bbcf772216aa237036cc3ae3158288d0a95
/stable/c/693a0c13c1f0c0fcaa1e38cb806cc0789bd415aa - https://git.kernel.org/stable/c/bbcf772216aa237036cc3ae3158288d0a95aaf4d - https://git.kernel.org/stable/c/81b024df4755e6bb6993b786584eca6eabbb9791 - https://git.kernel.org/stable/c/dac87e295cddc8ab316cff14ab2071b5221d84fa - https://git.kernel.org/stable/c/c12b314bb23dc0c83e03402cc84574700947e3b2 - https://git.kernel.org/stable/c/1f50c7497a5f89de0c31f2edf086af41ff834320 - https://git.kernel.org/stable/c/290dd73b943c95c006df973257076ff163adf4d0 - https://git.kernel.org/stable/c/110d7b0325c55ff3620073ba4201845f59e22ebf
CVE ID: CVE-2022-50279 State: PUBLISHED Published: 2025-09-15T14:21:16.051Z Last Updated: 2025-09-15T14:21:16.051Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: Fix global-out-of-bounds bug in _rtl8812ae_phy_set_txpower_limit() There is a global-out-of-bounds reported by KASAN: BUG: KASAN: global-out-of-bounds in _rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae] Read of size 1 at addr ffffffffa0773c43 by task NetworkManager/411 CPU: 6 PID: 411 Comm: NetworkManager Tainted: G D 6.1.0-rc8+ #144 e15588508517267d37 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), Call Trace: <TASK> ... kasan_report+0xbb/0x1c0 _rt
15588508517267d37 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), Call Trace: <TASK> ... kasan_report+0xbb/0x1c0 _rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae] rtl8821ae_phy_bb_config.cold+0x346/0x641 [rtl8821ae] rtl8821ae_hw_init+0x1f5e/0x79b0 [rtl8821ae] ... </TASK> The root cause of the problem is that the comparison order of "prate_section" in _rtl8812ae_phy_set_txpower_limit() is wrong. The _rtl8812ae_eq_n_byte() is used to compare the first n bytes of the two strings from tail to head, which causes the problem. In the _rtl8812ae_phy_set_txpower_limit(), it was originally intended to meet this requirement by carefully designing the comparison order. For example, "pregulation" and
originally intended to meet this requirement by carefully designing the comparison order. For example, "pregulation" and "pbandwidth" are compared in order of length from small to large, first is 3 and last is 4. However, the comparison order of "prate_section" dose not obey such order requirement, therefore when "prate_section" is "HT", when comparing from tail to head, it will lead to access out of bounds in _rtl8812ae_eq_n_byte(). As mentioned above, the _rtl8812ae_eq_n_byte() has the same function as strcmp(), so just strcmp() is enough. Fix it by removing _rtl8812ae_eq_n_byte() and use strcmp() barely. Although it can be fixed by adjusting the comparison order of "prate_section", this m
_n_byte() and use strcmp() barely. Although it can be fixed by adjusting the comparison order of "prate_section", this may cause the value of "rate_section" to not be from 0 to 5. In addition, commit "21e4b0726dc6" not only moved driver from staging to regular tree, but also added setting txpower limit function during the driver config phase, so the problem was introduced by this commit. References: - https://git.kernel.org/stable/c/fc3442247716fc426bbcf62ed65e086e48a6d44f - https://git.kernel.org/stable/c/28ea268d95e57cdf6394a058f0d854206d478772 - https://git.kernel.org/stable/c/1e950b9a841bc96e98ee25680d5c7aa305120be1 - https://git.kernel.org/stable/c/0c962dcd6bf64b78eaffc09e497a2beb4e48bc
able/c/1e950b9a841bc96e98ee25680d5c7aa305120be1 - https://git.kernel.org/stable/c/0c962dcd6bf64b78eaffc09e497a2beb4e48bc32 - https://git.kernel.org/stable/c/f1fe40120de6ad4ffa8299fde035a5feba10d4fb - https://git.kernel.org/stable/c/057b52461dc005ecd85a3e4998913b1492ec0f72 - https://git.kernel.org/stable/c/117dbeda22ec5ea0918254d03b540ef8b8a64d53
CVE ID: CVE-2022-50280 State: PUBLISHED Published: 2025-09-15T14:21:16.891Z Last Updated: 2025-09-15T14:21:16.891Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: pnode: terminate at peers of source The propagate_mnt() function handles mount propagation when creating mounts and propagates the source mount tree @source_mnt to all applicable nodes of the destination propagation mount tree headed by @dest_mnt. Unfortunately it contains a bug where it fails to terminate at peers of @source_mnt when looking up copies of the source mount that become masters for copies of the source mount tree mounted on top of slaves in the destinatio
s of the source mount that become masters for copies of the source mount tree mounted on top of slaves in the destination propagation tree causing a NULL dereference. Once the mechanics of the bug are understood it's easy to trigger. Because of unprivileged user namespaces it is available to unprivileged users. While fixing this bug we've gotten confused multiple times due to unclear terminology or missing concepts. So let's start this with some clarifications: * The terms "master" or "peer" denote a shared mount. A shared mount belongs to a peer group. * A peer group is a set of shared mounts that propagate to each other. They are identified by a peer group id. The peer group id is availabl
set of shared mounts that propagate to each other. They are identified by a peer group id. The peer group id is available in @shared_mnt->mnt_group_id. Shared mounts within the same peer group have the same peer group id. The peers in a peer group can be reached via @shared_mnt->mnt_share. * The terms "slave mount" or "dependent mount" denote a mount that receives propagation from a peer in a peer group. IOW, shared mounts may have slave mounts and slave mounts have shared mounts as their master. Slave mounts of a given peer in a peer group are listed on that peers slave list available at @shared_mnt->mnt_slave_list. * The term "master mount" denotes a mount in a peer group. IOW, it denotes
st available at @shared_mnt->mnt_slave_list. * The term "master mount" denotes a mount in a peer group. IOW, it denotes a shared mount or a peer mount in a peer group. The term "master mount" - or "master" for short - is mostly used when talking in the context of slave mounts that receive propagation from a master mount. A master mount of a slave identifies the closest peer group a slave mount receives propagation from. The master mount of a slave can be identified via @slave_mount->mnt_master. Different slaves may point to different masters in the same peer group. * Multiple peers in a peer group can have non-empty ->mnt_slave_lists. Non-empty ->mnt_slave_lists of peers don't intersect. Con
le peers in a peer group can have non-empty ->mnt_slave_lists. Non-empty ->mnt_slave_lists of peers don't intersect. Consequently, to ensure all slave mounts of a peer group are visited the ->mnt_slave_lists of all peers in a peer group have to be walked. * Slave mounts point to a peer in the closest peer group they receive propagation from via @slave_mnt->mnt_master (see above). Together with these peers they form a propagation group (see below). The closest peer group can thus be identified through the peer group id @slave_mnt->mnt_master->mnt_group_id of the peer/master that a slave mount receives propagation from. * A shared-slave mount is a slave mount to a peer group pg1 while also a p